x264 LAVF/FFMS input public beta test (v2.1)

[Dark Shikari]

Originally Posted by roozhou

CFR input module should let i_timebase_num = i_fps_num and i_timebase_den = i_fps_den, and leave i_pts unchanged

VFR input module should let i_timebase_num = 1 and i_timebase_den = i_fps_den, and let each i_pts = real_timestamp * i_timebase_den

Right?

Wrong.

CFR, by definition, must synthesize timestamps. There are no PTS to "remain unchanged". It makes up the PTS in x264.c.

VFR input module does not change the PTS or the timebase (unless the PTS are outright invalid, of course).

[roozhou]

Originally Posted by Dark Shikari

Wrong.

CFR, by definition, must synthesize timestamps. There are no PTS to "remain unchanged". It makes up the PTS in x264.c.

VFR input module does not change the PTS or the timebase (unless the PTS are outright invalid, of course).

I wonder how an input module should set i_pts in x264_picture_t. Of course I know VFR input should leave PTS as is because my x264 build started to support VFR since Oct 2008.

[JoeMiller]

currently, I compile x264 into mencoder. mencoder eats almost any input, no matter which codec or container. Does the x264 LAVF/FFMS version offer any advantage over my mencoder+x264 combination?

[Dark Shikari]

Originally Posted by JoeMiller

currently, I compile x264 into mencoder. mencoder eats almost any input, no matter which codec or container. Does the x264 LAVF/FFMS version offer any advantage over my mencoder+x264 combination?

Mencoder doesn't support VFR.

[roozhou]

Originally Posted by Dark Shikari

Mencoder doesn't support VFR.

Mencoder does support VFR input and output, but its lavf muxer is crappy. Remember to set -ofps to maximum possible fps of the input video, otherwise it may unnecessarily drop frames.

[Snowknight26]

ffms [info]: 640x480p 0:1 @ 30/1 fps (vfr)

Kind of weird that FFMS thinks Fraps videos are VFR. Oh well, glad you can force CFR.

[kemuri-_9]

Originally Posted by Snowknight26

Kind of weird that FFMS thinks Fraps videos are VFR. Oh well, glad you can force CFR.

http://doom10.org/index.php?topic=133.msg1151#msg1151

[Snowknight26]

Having ffmpeg pipe to x264:

ffmpeg -i "%%A" -vcodec rawvideo -f yuv4mpegpipe -an -pix_fmt yuv420p - | x264.x64 - --stdin y4m --crf 19 --bframes 5 --b-adapt 2 --ref 4 --mixed-refs --no-fast-pskip --direct auto --deblock -3:-3 --subme 10 --trellis 2 --analyse all --8x8dct --me umh --output "%%~nA.noaudio.mkv"

Having x264 open a file directly:

x264.x64 --crf 19 --bframes 5 --b-adapt 2 --ref 4 --mixed-refs --no-fast-pskip --direct auto --deblock -3:-3 --subme 10 --trellis 2 --analyse all --8x8dct --me umh --output "%%~nA.noaudio.mkv" "%%A"

Standard Fraps video (force lossless RGB unchecked). Haven't checked further but it might be an issue with the colorspace conversion (BGR24 -> YV12) that FFMS is doing. Check the window edges/reds if you can't see it.

[CruNcher]

yeah the chroma looks totally dead

[Dark Shikari]

Originally Posted by Snowknight26

Standard Fraps video (force lossless RGB unchecked). Haven't checked further but it might be an issue with the colorspace conversion (BGR24 -> YV12) that FFMS is doing. Check the window edges/reds if you can't see it.

I can't see any difference at all. If there is one, it's because swscale uses different algorithms from Avisynth. I trust swscale more.

[Mr VacBob]

I can see it. But I'd recommend turning off subpixel rendering for a screen recording anyway…

[Snowknight26]

Originally Posted by Dark Shikari

I can't see any difference at all.

Originally Posted by Dark Shikari

If there is one, it's because swscale uses different algorithms from Avisynth. I trust swscale more.

The first screenshot is identical to how the Fraps decoder decodes the video.. unlike the 2nd screenshot. Granted, the colors are more accurate in the 2nd, but the chroma is messed up as CruNcher noted.

Originally Posted by Mr VacBob

I can see it. But I'd recommend turning off subpixel rendering for a screen recording anyway…

How would I go about achieving that?

[me7]

I just started encoding a 24/1.001 fps BluRay rip where Avisynth apparently reports a wrong framerate:

avs [info]: 1280x692p 0:0 @ 250000/10427 fps (cfr)

Input file is AVC in mkv container, read via FFVideoSource.

Should I be worried? Will the encoded file have a wrong framerate in it's metadata? Will x264 alter the quality-per-frame in order to get a desired quality-per-second?

[kemuri-_9]

Originally Posted by me7

Should I be worried? Will the encoded file have a wrong framerate in it's metadata? Will x264 alter the quality-per-frame in order to get a desired quality-per-second?

A) yes, the encoded file will have the wrong framerate.
B) if using bitrate mode, this will have an extremely slight difference as 250000/10427 is extremely slightly different from 24000/1001.

and this issue has actually already been addressed and fixed in ffmpegsource so update to a newer version.

[me7]

Originally Posted by kemuri-_9

and this issue has actually already been addressed and fixed in ffmpegsource so update to a newer version.

I tried the latest version available here, but it doesn't fix the problem.

[rack04]

Originally Posted by me7

I tried the latest version available here, but it doesn't fix the problem.

The latest version is r263.

[me7]

Originally Posted by rack04

The latest version is r263.

Where can I get it?

[LoRd_MuldeR]

Originally Posted by me7

Where can I get it?

http://code.google.com/p/ffmpegsource/source/checkout

[me7]

Originally Posted by LoRd_MuldeR

http://code.google.com/p/ffmpegsource/source/checkout

Now I really regret not knowing anything about C++
Still, thanks for the info.

[LoRd_MuldeR]

Originally Posted by me7

Now I really regret not knowing anything about C++
Still, thanks for the info.

Actually most of the time you can compile stuff without having to understand the code. You don't even need to look at the code.

Once you have set up the build environment, you only need to know how to use SVN and Make