FF7 PSX videos

  • Thread starter Thread starter Hellbringer616
  • Start date Start date
Status
Not open for further replies.
just been testing different codecs and they all seem to have the same problem or a worse problem.
But i have noticed that a uncompressed AVI will play perfectly at any FPS and any res but the only drawback with this is the huge filesize (for example i converted your flame video into uncompressed AVI, 1280x896, 23.976fps and it played fine but the size of the video was 743MB)
so i supose if its for personal use and if you have alot of HDD space you could use this method.
 
(for example i converted your flame video into uncompressed AVI, 1280x896, 23.976fps and it played fine but the size of the video was 743MB)
Lol.  Well that would work all well and good for me :)  But I would ideally like to distribute these when I'm finished.
 
lol yeah. i am looking into uncompressed codecs now to see if they make any filesize difference but i am not holding much hope for this method, especially since like you say it would be hard as hell to distribute. (although it may be possible if you distribute the small file in H264 format with a batch convertor so that it will be decompressed to a uncompressed AVI but this would still be a pain for ppl with small HDD's)
 
Since VLC can easily play these formats (and from what I remember it uses ffmpeg and mencoder, etc)  I think it is possible for Aali to make some kind of alteration to his driver to allow seamless integration of these videos.

Until I hear from him I will continue experimenting to see what works best.
 
The video plugin is very inefficient in general, anything that doesn't output clean BGRA (read: any modern video codec) will go through a very slow conversion process, without any kind of hardware acceleration. The next version of the driver will notify you when you play something that needs to be converted and the format it's using and if I deem that the codec is important enough I will implement a fast path for that format.
 
So, to put that in laymans terms, it would be best use a lossless format, like the 750mb video kranmer made?

If you can add a fast path for h264 (x264 especially), I think that's all that would be needed for us to have videos that are small in size but high in quality.   Why does the driver play lower resolutions fine (at 23.97fps), but once it gets to 1280x896 begin stuttering?
 
It would be best to wait for the next version of the driver and make awesome FMVs in a good "master" format in the meantime :P
I will add a fast path for h264 since it uses the most common YUV format which will make it and many other codecs A LOT faster if you have shader support (without shaders you are more or less fucked when it comes to OpenGL and video decoding).

Anything that makes the file bigger (higher resolution, higher framerate) means more bits to twiddle for the driver, which takes time, which in turn makes it lag.
 
Well I've tried .7.6, and the slow/choppy versions that used to work, now crash it. 
I've tried h264 as an avi and mp4 (mp4 renamed as an avi I mean).  I've also tried with different combinations of aac main, aac lc, and mp3.  All just crash now.
 
What the hell? Now that one-frame dummy file is messing it up all of a sudden. Could you also post that somewhere?
 
yes the dumy file seems to cause that crash, if you use the original eidoslogo.avi (or any video that isnt a dummy) it wont crash.
Also Aali here is the dummy file
http://www.mediafire.com/?gewtmtumjdd

Also Obsesbear i just tried that Sephiroth video and it crashes for me to but i have found that if you change the bitrate to 3264 or below in Super the video will work (although this drops the quality), bitrates of over 3504 seem to make it crash towards the end of the video (i know this isnt a solution but thought you might want to know anyway)
 
Last edited:
sorry for the double post, But on 0.7.6 it now seems possible to get Xvid files working at bigger sizes (before on 0.7.5 i could only get upto just under 1024x896 to work) So now its possible to get a Xvid of 1280x896 to work (i can get it upto the same quality as well but to have the same quality the filesize does increase slightly)
So here is a Xvid+AC3 1280x896 version of your fire video
http://www.mediafire.com/?dnk3dxy2mei
(also i made a mistake on the archive name and named it 1280x960 so just ignore that)
it can proberly be made smaller but i wanted to try to keep the same quality as your original.
Also i used AC3 audio instead of MP3 since it seemed to give slightly higher audio quality for me (this could be my own problem though)
 
I've recently had to remaster some videos from another PlayStation game. As a result, I may have found a technique that maintains the most amount of quality by adding a new format to jPSXdec: pc.601 (a.k.a. jpeg or jfif) YUV (possibly available in v0.93.2+).

Code: [Select]
Code:
java -jar jpsxdec.jar ff7disc1.bin -i ff7disc1.idx -d 3472 -quality high -vf avi:jyuv
I then let Avisynth and plugins do the heavy lifting.

Requires Avisynth 2.6 (alpha)
Uses nnedi3 for scaling as suggested by superbbjai, and DGMPGDec for deblocking.

Code: [Select]
Code:
# OPENINGE.avsLoadPlugin("nnedi3.dll")LoadPlugin("DGDecode.dll")AviSource("OPENINGE[0].avi")# Deblocking# quant is the strength between 1 and 31# 12 seemed to be good, but the value could certainly be explored# There is a huge list of similar filters on this page# http://www.aquilinestudios.org/avsfilters/spatial.html# which I didn't tryBlindPP(quant=12)# Scale up by 4x for a final resolution of 1280x896# The results of nnedi3 appeared slightly bettern than Spline64Resizennedi3_rpow2(rfactor=4)# Convert to RGB mostly to ensure there is no chroma shift later,# but is only available in 2.6# matrix is to specify that the input uses the pc.601 [0-255] component rangeConvertToRGB32(matrix="pc.601", chromaplacement="MPEG1")# ffmpeg likes to flip Avisynth rgba inputFlipVertical()
Then ffmpeg for the encoding.
Code: [Select]
Code:
ffmpeg -i OPENINGE.avs -acodec libmp3lame -ab 128k -vcodec libx264 -vpre veryslow -crf 12 -threads 0 OPENINGE.mp4
Code: [Select]
Code:
-acodec libmp3lame -ab 128kEncode mp3 at 128kbps. My Windows binary didn't have aac included for audio, otherwise I would have used that.-vcodec libx264Encode video as h.264-vpre veryslowUse the best encoding preset-crf 12Encode at a constant quality.Value is usually between 12-24. Lower value is better.12 is probably overkill for this case.-threads 0Use all the processors!
The end result:

vlcsnap-2010-09-11-00h19m12s229.png


Full video
http://www.megaupload.com/?d=LCGPEC6G

I know this can't work with the current PC drivers, but I figured I'd share my work in case someone found it useful.
 
I know this can't work with the current PC drivers, but I figured I'd share my work in case someone found it useful.
That video plays fine in my FF7, the sound is jittery and out of sync though.
 
Last edited:
That is actually a fairly impressive redo of the video. I would imagine that is most likely the best we will get out of the source material.
 
That is actually a fairly impressive redo of the video. I would imagine that is most likely the best we will get out of the source material.
A bit late on that, but that's not a redo it's a refilter and re encode. Redoing it would be what the people in Team Avalanch are doing.  I can't look at it in vdub at the moment but just looking at the video in MPC it is rather interesting to see how well it did on sharp lines such as the hair jaw and eye lashes of Areth. You can see though some of the DCT noise from the lossy compression of the motion JPEG codec. Makes for an interesting subject matter.

In any case I could go on and on about various 'stuff'.  Interesting what the filters managed to do I suppose deblocking and decoding the original data and adding the correct DCT noise/data one could 'add' more detail that was thrown out in the original. I'll have to look at the filters and see what they are up too.

By the way AVISYNTH is AWESOME for this kind of stuff. It has to be run in a batch mode but who cares. Does great stuff (especially if your video editor doesn't like the video format of a file it can act as a YUV/RGB video source for it and decode the video without even batting an eyelash).

Cyb
 
That is actually a fairly impressive redo of the video. I would imagine that is most likely the best we will get out of the source material.
A bit late on that, but that's not a redo it's a refilter and re encode. Redoing it would be what the people in Team Avalanch are doing.  I can't look at it in vdub at the moment but just looking at the video in MPC it is rather interesting to see how well it did on sharp lines such as the hair jaw and eye lashes of Areth. You can see though some of the DCT noise from the lossy compression of the motion JPEG codec. Makes for an interesting subject matter.

In any case I could go on and on about various 'stuff'.  Interesting what the filters managed to do I suppose deblocking and decoding the original data and adding the correct DCT noise/data one could 'add' more detail that was thrown out in the original. I'll have to look at the filters and see what they are up too.

By the way AVISYNTH is AWESOME for this kind of stuff. It has to be run in a batch mode but who cares. Does great stuff (especially if your video editor doesn't like the video format of a file it can act as a YUV/RGB video source for it and decode the video without even batting an eyelash).

Cyb
Sorry, poor choice of words. And yes i know what Team Avalanche is doing. I did kind of start it after all.
 
M35

Whilst that does look smoother, it has lost a lot of its detail.  You can get the same result with any number of filters, even inside sony vegas.  The best method seems to be to use your video converter, then place uncompressed result inside vegas and add a few simple filters then export to h.264.

There is always going to be a loss here.  The smoother you go the less detailed but less pixelated.  As it is, the fact is we are working with 320X224 videos and you can't polish a turd :P
 
Status
Not open for further replies.
Back
Top