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

[Dark Shikari]

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]

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]

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]

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]

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:
http://i47.tinypic.com/25ewvb8.jpg
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:
http://i45.tinypic.com/15p1h1e.jpg
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]

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]

I can't see any difference at all.

http://i46.tinypic.com/1zb71cl.jpg

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.

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]

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]

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 (http://code.google.com/p/ffmpegsource/downloads/list), but it doesn't fix the problem.

[rack04]

I tried the latest version available here (http://code.google.com/p/ffmpegsource/downloads/list), but it doesn't fix the problem.

The latest version is r263.

[me7]

The latest version is r263.

Where can I get it?

[LoRd_MuldeR]

Where can I get it?

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

[me7]

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

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

[LoRd_MuldeR]

Now I really regret not knowing anything about C++ :mad:
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 :)

[Darkwhisperer]

If your'll don't mind my asking, how are the tests going? Is there a planned release date perhaps?

:thanks:

[J_Darnley]

Why does something that was committed need updating?

[burfadel]

The all-in-one x264 is a great idea, however it does rely on a third party decoder that is under continual development. Since the third party tool is under continual development x264 will need to have that component continually updated to include the features added/fixed in the third party provision. The solution would be to simply update those components each time x264 components are updated, in order to stay current.

[smok3]

do we have osx and/or ubuntu-karmic builds?

[Audionut]

do we have osx and/or ubuntu-karmic builds?
http://doom10.org/index.php?topic=3.0

[hajj_3]

Does this mean we could have a 64bit of MeGUI and use a 64bit of x264.exe with LAVF/FFMS integrated into it? Do we know what kind of speed improvements we would get using this x264 beta compared to using regular x264.exe and avisynth 2.5.8 or 2.6.0 MT alpha?

[Blue_MiSfit]

I'm having great results with these new features! I've been doing lots of high speed transcodes of my movie / TV backups to baseline profile H.264 (for the iPhone).

Being able to directly open files in x264 without help from AviSynth, all in "pure" 64 bit is extremely convenient, and is pretty durn cool too :)

~MiSfit

[rack04]

I'm trying to mux a 264 stream generated by x264 using LAVF as the input method. The source file is mov. When I try to mux to mkv using eac3to it complains that the stream does not contain fps information. Is this intentional or a bug? Using avs input the file muxes without error. I am using this (http://forum.doom9.org/showthread.php?p=1374688#post1374688) build.

Here is a sample (http://www.multiupload.com/ME5ZMJJ7N8), x264 stats, and vui_parameters:

ffms [info]: 848x480p 0:1 @ 24000/1001 fps (vfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:51 Avg QP:18.35 size: 41968
x264 [info]: frame P:1235 Avg QP:23.91 size: 8045
x264 [info]: frame B:2309 Avg QP:28.10 size: 2366
x264 [info]: consecutive B-frames: 6.5% 18.9% 6.3% 63.8% 2.0% 2.5%
x264 [info]: mb I I16..4: 31.8% 18.9% 49.2%
x264 [info]: mb P I16..4: 8.4% 8.3% 3.9% P16..4: 22.0% 8.9% 4.6% 0.0% 0.0% skip:43.9%
x264 [info]: mb B I16..4: 0.8% 1.5% 1.0% B16..8: 20.0% 1.4% 1.6% direct: 1.6% skip:72.1% L0:39.1% L1:47.7% BI:13.2%
x264 [info]: 8x8 transform intra:38.7% inter:59.2%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra: 48.0% 59.4% 29.1% inter: 7.3% 10.9% 3.6%
x264 [info]: i16 v,h,dc,p: 44% 27% 11% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 19% 18% 6% 7% 8% 8% 7% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 20% 11% 6% 9% 8% 9% 7% 10%
x264 [info]: Weighted P-Frames: Y:7.9%
x264 [info]: ref P L0: 72.3% 9.1% 9.2% 2.9% 2.6% 1.5% 1.0% 0.5% 0.5% 0.4% 0.0% 0.0%
x264 [info]: ref B L0: 90.8% 4.4% 2.1% 0.9% 0.6% 0.5% 0.4% 0.2% 0.1%
x264 [info]: ref B L1: 98.5% 1.5%
x264 [info]: kb/s:935.79

encoded 3595 frames, 10.60 fps, 935.79 kb/s

vui_parameters_present_flag: 1
aspect_ratio_info_present_flag: 0
overscan_info_present_flag: 0
video_signal_info_present_flag: 0
chroma_loc_info_present_flag: 0
timing_info_present_flag: 1
num_units_in_tick: 1
time_scale: 5994
fixed_frame_scale: 0
nal_hrd_parameters_present_flag: 0
vcl_hrd_parameters_present_flag: 0
pic_struct_present_flag: 0
motion_vectors_over_pic_boundaries_flag: 1
max_bytes_per_pic_denom: 0
max_bits_per_mb_denom: 0
log2_max_mv_length_horizontal: 11
log2_max_mv_length_vertical: 11
num_reorder_frames: 2
max_dec_frame_buffering: 10

[Dark Shikari]

In VFR mode x264 does not write fixed_frame_rate_flag for obvious reasons.

You can use --force-cfr to get Avisynth's behavior in LAVF/FFMS.

[lucassp]

Why does it always default to VFR?

[Snowknight26]

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

5char.

[PowerGamer]

Currently (x264 rev. 1442) FFMS can't handle raw H.264 streams. x264 opens them with LAVF but is not able to determine total amount of frames in the video being encoded. I wonder if that (inability to determine total amount of frames) has any negative effect on quality/speed of the encoding process (because if it has I can always specify total amount of frames with --frames switch)?

[Dark Shikari]

Currently (x264 rev. 1442) FFMS can't handle raw H.264 streams. x264 opens them with LAVF but is not able to determine total amount of frames in the video being encoded. I wonder if that (inability to determine total amount of frames) has any negative effect on quality/speed of the encoding process (because if it has I can always specify total amount of frames with --frames switch)?No negative effect currently. In the future this may in theory change when using 1-pass ABR mode.

[bnshrdr]

Hey where can I get a completely up-to-date version of ffmpeg so that I can compile x264 with lavf support?
I would have thought git clone git://git.ffmpeg.org/ffmpeg/ would be as up-to-date as it is needed to be but keep getting this warning from x264's ./configure:
Warning: libavformat is too old, update to ffmpeg r18351+

[Dark Shikari]

Hey where can I get a completely up-to-date version of ffmpeg so that I can compile x264 with lavf support?
I would have thought git clone git://git.ffmpeg.org/ffmpeg/ would be as up-to-date as it is needed to be but keep getting this warning from x264's ./configure:
Warning: libavformat is too old, update to ffmpeg r18351+You likely have an older ffmpeg installed that x264 is trying to link to.

[bnshrdr]

Well I actually opened up the x264 ./configure file and saw that it was checking for the function avcodec_decode_video2 in one of the libavformat header files. I went and checked, and what do you know, x264 is right. Is there a chance that the master ffmpeg revision isn't truly the master revision.

[Mr VacBob]

ffmpeg git is up to date (r21977). You probably have an older version installed somewhere else.

[bnshrdr]

As much as I understand your logic, I am using a clean system and have not installed anything.

On line 529 of x264's configure script, it checks for most likely a critical function:
if cc_check libavformat/avformat.h "$LAVF_CFLAGS $LAVF_LIBS" "avcodec_decode_video2( NULL, NULL, NULL, NULL );" ; then
lavf_input="yes"
define LAVF_INPUT
else
echo "Warning: libavformat is too old, update to ffmpeg r18351+"

I took the liberty of opening libavformat/avformat.h myself to search for this function prototype and it cannot be found. In fact I scanned the whole source code tree to find out where it actually appears, and found it to be in the header file libavcodec/avcodec.h.

I'll try editing the configure script to check that file instead of the other header file and see what happens.

Edit: I seemed to have tricked it successfully. I compiled x264 with lavf support and tested it and it works. Might wanna take a look at that configure script.

Needs a diff that basically does this:
-if cc_check libavformat/avformat.h "$LAVF_CFLAGS $LAVF_LIBS" "avcodec_decode_video2( NULL, NULL, NULL, NULL );" ; then
+if cc_check libavcodec/avcodec.h "$LAVF_CFLAGS $LAVF_LIBS" "avcodec_decode_video2( NULL, NULL, NULL, NULL );" ; then

[kemuri-_9]

Needs a diff that basically does this:
-if cc_check libavformat/avformat.h "$LAVF_CFLAGS $LAVF_LIBS" "avcodec_decode_video2( NULL, NULL, NULL, NULL );" ; then
+if cc_check libavcodec/avcodec.h "$LAVF_CFLAGS $LAVF_LIBS" "avcodec_decode_video2( NULL, NULL, NULL, NULL );" ; then

A) libavformat/avformat.h includes "libavcodec/avcodec.h"
B) we're specifically using both libavformat and libavcodec
C) you removed the check to see if the critically required libavformat/avformat.h header is actually available/correct

so your change is incorrect and can cause issues. fix your installation rather than hack the configure.

[smok3]

http://doom10.org/index.php?topic=3.0

http://doom10.org/index.php?topic=220.0

i have to do everything myself.:devil:

[turbojet]

From about 30 different tries so far 24000/1001 m2ts input is detected at 23998/10001 and 24005/1001 both vfr but never has one been detected correctly at 24000/1001 cfr.

30000/1001 interlaced is detected as 60020/1001 vfr.

[Atak_Snajpera]

30000/1001 interlaced is detected as 60020/1001 vfr.
I had similar problem with FFmpegSource.
http://forum.doom9.org/showthread.php?p=1363469#post1363469
http://forum.doom9.org/showthread.php?p=1364213#post1364213

Nobody cares :/

[bnshrdr]

Hey I am not sure if this has been brought up yet, but recently I had an input file set to be demuxed with ffms2, and I threw the --frames switch to x264, but it still seemed to index the entire file, which depending on how long the video is it can be pretty lengthy if I only wanted 250 frames. Would there be a way that x264 could tell ffms2 to stop indexing at X frame?

I mean, yes, I could change the demuxer to lavf, but ffms2 has to stay competitive.

[kemuri-_9]

Hey I am not sure if this has been brought up yet, but recently I had an input file set to be demuxed with ffms2, and I threw the --frames switch to x264, but it still seemed to index the entire file, which depending on how long the video is it can be pretty lengthy if I only wanted 250 frames. Would there be a way that x264 could tell ffms2 to stop indexing at X frame?

I mean, yes, I could change the demuxer to lavf, but ffms2 has to stay competitive.

this is not currently possible on x264's side of things as all the API calls that FFMS2 has are to index the entire video file.
there are no 'stop indexing at frame X' options.
the only thing to alleviate this is the indexing file, which allows reading from the index on subsequent executions rather than re-indexing every time.
this is an option x264 has made available but is not on by default.

the ffms2 codebase is likely to be designed on the fact the entire video is indexed, so changing this would be (again, likely) be time consuming with a seemingly small return.

[roozhou]

Hey I am not sure if this has been brought up yet, but recently I had an input file set to be demuxed with ffms2, and I threw the --frames switch to x264, but it still seemed to index the entire file, which depending on how long the video is it can be pretty lengthy if I only wanted 250 frames. Would there be a way that x264 could tell ffms2 to stop indexing at X frame?

I mean, yes, I could change the demuxer to lavf, but ffms2 has to stay competitive.

I hate ffms's indexing too. It takes a long time for large files. A couple of questions about indexing:
1) Why on earth do we have to index a file that already has an index in the container(e.g. avi, mkv, mp4)?
2) If we only need linear access(encode from beginning to end), why can't we skip the indexing phase? Index can be generated during decoding.

I suggest the inclusion of on-demand indexing. That is only the needed part should be indexed. e.g. I need to encode from 1'0" to 1'30", so indexing should be done from beginning to the GOP containing the frame at 1'30".

FFMS2 was firstly designed to use with avisynth only and perhaps these features are not compatible with avisynth. I know that developers would say "we don't want to break API", but the current implementation really sucks.

[Myrsloik]

I hate ffms's indexing too. It takes a long time for large files. A couple of questions about indexing:
1) Why on earth do we have to index a file that already has an index in the container(e.g. avi, mkv, mp4)?
2) If we only need linear access(encode from beginning to end), why can't we skip the indexing phase? Index can be generated during decoding.


1. Because no one fixed ffmpeg so you can just seek to the nth real frame. That's why.

2. FFMS2 is mostly pointless to use in that scenario, but it's been on the todo list for ages and will probably happen some day.

[roozhou]

1. Because no one fixed ffmpeg so you can just seek to the nth real frame. That's why.
This is unrelated. My question is why not use the index in the container. It contains all the information you need and is much faster to read.

And when you need to seek to the nth real frame, just seek to the nearest key frame and start decoding. When the pts or dts matches your desired timestamp, you get it.

[Myrsloik]

I (and the rest of the world too, apparently) don't have the time or motivation to rewrite that many demuxers, especially not to a compatibility level near that of lavf. That's why.

[Dark Shikari]

I (and the rest of the world too, apparently) don't have the time or motivation to rewrite that many demuxers, especially not to a compatibility level near that of lavf. That's why.AFAIK lavf has an interface that allows you to access the index of files that have it (though I don't know how good it is).

Also, get on IRC, we have a crash report for you from a GSOC student.

[Mr VacBob]

I think lavf's index_entries is private. I know it contains confusingly incorrect data for some AVI files that nevertheless work with av_read_frame(). There is a SOC project for better seeking API, and I need an index reading API myself but haven't brought it up yet.