x264 What is the difference using raw input vs. AVS script that uses FFMS2?

[kotuwa]

x264 supports x264 of MKV files with x264/AVC video (and more).

what is the difference using raw input vs. input via .AVS script that uses FFMS2 etc?

(Nothing else like resizing is used... Just input...)

[poisondeathray]

x264 supports x264 of MKV files with x264/AVC video (and more).

what is the difference using raw input vs. input via .AVS script that uses FFMS2 etc?

(Nothing else like resizing is used... Just input...)

It only supports decoding of h.264 if support has been compiled (e.g. lavf, ffms). "vanilla" x264 library is encoder only. Various x264 binaries can have different things compiled, even filtering patches like resizing, cropping, adding borders etc... Some builds even have audio. But if you're going that route, you might as well use ffmpeg instead

If you use --demuxer ffms, it will give the same as results as avisynth + ffms2 . But --demuxer lavf is different, doesn't require indexing (so faster). Eitherway both are slightly faster than avs because avs adds a bit of overhead

And "raw" input actually means raw. Not compressed h.264 mkv files. They are different things

[LigH.de]

Also answered in the doom9 forum.

[kotuwa]

Thanks

What how much the difference between lavf and ffms2 !?
small or big?

Is it the difference that indexing part takes in the beginning,
or does it affect through the encoding process?!

[LigH.de]

FFMS2 for AviSynth certainly prefers the MKV container; even with the help of Haali Media Splitter installed, it still doesn't handle some other containers reliably. Most probably it will fail for Transport Streams with interlaced AVC, returning a video with strange framerate and frame order. It is a bit more reliable if you limit the decoding threads to only 1.

Instead, there is now "L-SMASH Works" as source plugin for AviSynth and VapourSynth, which is much more reliable with a variety of containers, using libav libraries (LwLibav{Video|Audio}Source), and also contains the L-SMASH splitter for ISO Media containers (e.g. MOV, MP4). It should not have problems with multithreaded decoding or interlaced content.

[hello_hello]

ffms2 has options for converting the frame rate. L-Smash doesn't. I find that handy for video which isn't perfect.... a video capture with a few dropped frames, for example. Both ffms2 and L-Smash handle such video in an odd way, in my opinion.

Even AVI kind of supports variable frame rate due to ability to store 0 byte chunks or null frames, whatever they're called, but by default ffms2 and L-Smash seem to ignore them and output the average frame rate instead. For example if you have a 25fps AVI with (I'm just making up numbers) 20 null frames plus 10,000 "normal" frames, both ffms2 and L-Smash output 10,000 frames with a slightly reduced frame rate. 24.879fps, for example.

I've found no way to correct this using L-Smash so the video needs to be treated as variable frame rate. For ffms2 you can simply convert the frame rate to 25fps, it'll replace the null frames with a duplicate of the previous frame (which is effectively what happens on playback anyway), the frame count will increase to 10,020 and the frame rate will be a constant 25fps. Most importantly of all, the audio won't go out of sync.

Maybe I've just been unlucky but I've come across a fair amount of video containing null frames. You can convert the frame rate with ffms2 like this:
FFVideoSource("E:\video.mkv", fpsnum=25, fpsden=1, threads=1)
I also use threads=1 because without it ffms2 has given me grief on occasion.

When it comes to AVIs will null frames, good old AVISource() has handled them "correctly" every time I've checked. The output would be the same as ffms2 with frame rate conversion included. I think DirectShow does the same but I'd need to check. If it doesn't, once again you can instruct it to.
DirectShowSource("E:\video.avi", fps=25, convertfps=true).
I don't understand why ffms2 and L-Smash don't do the same.

I use MeGUI a fair bit and these days it's adds frame rate "conversion" to the scripts it creates by default to avoid possible audio sync issues (when it can, depending on how the video is opened). I recall someone reported on one occasion that after indexing an AVI with ffms2 and adding it's frame rate conversion, the video motion became "jittery" even though the frame rate hadn't actually changed. If I remember correctly it only happened when the source AVI had been muxed with VirtualDub. I don't know if the cause was ever found or the problem fixed, but if I'm re-encoding an AVI I usually remux it as an MKV first, then index the MKV with ffms2 (as ffms2 and MKV seem to play well together). Other than that I've re-encoded lots of video with ffms2's frame rate conversion in a script without issue.

[LigH.de]

Not supporting "drop frames" in AVIs as repeating the last frame would be a bug, IMHO...