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

[VFR maniac]

Would be cool if x264 could also create a timecode file, so that users who prefer (e.g. because they want to add multiple audiostream and a bunch of tag infos) to manually multiplex with mkvmerge/mp4box could use it.

How about this Win32 binary?
http://www.esnips.com/doc/1a661a92-01eb-417e-b68f-c8f34235cf7f/x264_vfr_rev1379_release3
Mirror (megaupload)
http://www.megaupload.com/?d=LY5OXCR3

The patch is here.
http://pastebin.com/m6d750da9
I am managing timecode format file I/O.

[Brazil2]

How about this Win32 binary?
http://www.esnips.com/doc/1a661a92-01eb-417e-b68f-c8f34235cf7f/x264_vfr_rev1379_release3

How do you download this file ? Looks like the site wants me to sign in and to enter a password.
Please could you upload it elsewhere (Megaupload) ?

[Dark Shikari]

Would be cool if x264 could also create a timecode file, so that users who prefer (e.g. because they want to add multiple audiostream and a bunch of tag infos) to manually multiplex with mkvmerge/mp4box could use it.We will merge VFRManiac's timecode patch after this is done.

[roozhou]

Would be cool if x264 could also create a timecode file, so that users who prefer (e.g. because they want to add multiple audiostream and a bunch of tag infos) to manually multiplex with mkvmerge/mp4box could use it.

This is useless because:
1) mkvmerge does not need timecodes file because it correctly handles pts from input files.
2) MP4Box does not support matroska timecode files

[Stephen R. Savage]

This is only tangentially related to the thread, but could a "--timecodes" parameter be added to x264, so it can load external timecodes (e.g. v1/v2 Matroska) for use with input methods other than LAVF/FFMS? This would allow for bitrate-based control over input formats that are CFR in nature (e.g. Avisynth, YUV, Y4M). This would eliminate the need to calculate the average framerate of these sources, and would allow an accurate bitrate report in the output.

[Dark Shikari]

This is only tangentially related to the thread, but could a "--timecodes" parameter be added to x264, so it can load external timecodes (e.g. v1/v2 Matroska) for use with input methods other than LAVF/FFMS? This would allow for bitrate-based control over input formats that are CFR in nature (e.g. Avisynth, YUV, Y4M). This would eliminate the need to calculate the average framerate of these sources, and would allow an accurate bitrate report in the output.Yes, that's what VFRmaniac's patch does. We'll be adding support for that.

[buzzqw]

fyi i added initial support for this x264 build to my MicroX264.

now is possible to select demuxer (no audio or resize is done)

BHH

[buzzqw]

--demuxer avs and --demuxer ffms detect different framerate even if both using ffmpegsource

C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer ffms vc1.fps.problem.m2ts
ffms [info]: 1920x1080p 1:1 @ 30000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
x264 [info]: profile High, level 4.0
^C
C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer avs vc1.fps.problem.m2ts
avs [info]: trying FFmpegSource2... indexing... succeeded
avs [info]: 1920x1080p 0:0 @ 250000/8211 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64

C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer lavf vc1.fps.problem.m2ts
[mpegts @ 0030a6b0]MAX_READ_SIZE:5000000 reached
lavf [info]: 1920x1080p 1:1 @ 30000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64

sample http://www.64k.it/andres/data/Varie/vc1.fps.problem.m2ts

BHH

[Selur]

1) mkvmerge does not need timecodes file because it correctly handles pts from input files.
2) MP4Box does not support matroska timecode files
Sad. Hoped for an easy way to create vfr files from cfr input in linux (without needing wine and avisynth) by:
1. reencode input with x264 (creating a .264 and a timecode file)
2. convert audio (creating a bunch of .mp3, .aac, .ac3 files)
3. multiplex subtitles, audio, video with the timecode file and a bunch of tags

Would it be hard to output mp4 time code files?

[roozhou]

--demuxer avs and --demuxer ffms detect different framerate even if both using ffmpegsource

C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer ffms vc1.fps.problem.m2ts
ffms [info]: 1920x1080p 1:1 @ 30000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
x264 [info]: profile High, level 4.0
^C
C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer avs vc1.fps.problem.m2ts
avs [info]: trying FFmpegSource2... indexing... succeeded
avs [info]: 1920x1080p 0:0 @ 250000/8211 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64

C:\PROGRA~1\PUREBA~2\_TESTF~1\NUOVAC~1>x264.exe --output zzz.mkv --demuxer lavf vc1.fps.problem.m2ts
[mpegts @ 0030a6b0]MAX_READ_SIZE:5000000 reached
lavf [info]: 1920x1080p 1:1 @ 30000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64

sample http://www.64k.it/andres/data/Varie/vc1.fps.problem.m2ts

BHH

That's normal because avs does not support vfr and requires an average fps.

With true vfr support the fps value does not really matter, you can use any value without losing a/v sync.

[roozhou]

Sad. Hoped for an easy way to create vfr files from cfr input in linux (without needing wine and avisynth) by:
1. reencode input with x264 (creating a .264 and a timecode file)
2. convert audio (creating a bunch of .mp3, .aac, .ac3 files)
3. multiplex subtitles, audio, video with the timecode file and a bunch of tags

Would it be hard to output mp4 time code files?
You don't need it because we have ffmpeg. Timecodes are only needed when you are using outdated frameworks that does not correctly handle timestamps.(e.g. avisynth, vfw)

1. encode input with x264 and create a vfr mp4
2. convert audio
3. multiplex subtitle, audio and video using ffmpeg

I know there are several bugs in ffmpeg's muxers, but one day ffmpeg will handle all these things.

[bob0r]

Patch used: "x264.LAVF.FFMS.input.public.beta.test.v2.2.diff", it's not public and probably not v2.2 eighter, i just saved it as 2.2 instead of 2.1 (laziness).
This patch was given to me by Dark to fix a x264 configure issue.

- pthreads, gpac, ffmpeg and ffmpegsource all compiled with gcc 4.4.2 aswell.
- upx --lzma --best x264.exe

x264.1376.LAVF.FFMS.gcc.4.4.2.make.exe (http://x264.nl/x264.1376.LAVF.FFMS.gcc.4.4.2.make.exe)
x264.1376.LAVF.FFMS.gcc.4.4.2.make.upx.exe (http://x264.nl/x264.1376.LAVF.FFMS.gcc.4.4.2.make.upx.exe)
x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.exe (http://x264.nl/x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.exe)
x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.upx.exe (http://x264.nl/x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.upx.exe)

What do we want to know? Are there any (encoding) speed differences?
Do they work at all? Compare them to Dark's .exe.

[roozhou]

What do we want to know? Are there any (encoding) speed differences?
Do they work at all? Compare them to Dark's .exe.

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

[kemuri-_9]

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

"2.2" is outdated, should wait on the current revision.


- pthreads, gpac, ffmpeg and ffmpegsource all compiled with gcc 4.4.2 aswell.

and supply what options you gave to configure for your ffmpeg compile....

[bob0r]

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

Speed between the versions, not speed input wise. :)

And yeah the patch is outdated, just need to know if it runs at all. (If there are no GCC 4.4.2 issues.)

[roozhou]

"2.2" is outdated, should wait on the current revision.


Where is the current version?

[Dark Shikari]

A lot of the "bugs" at this point are bugs in FFMS and in LAVF. Most programs don't run into these bugs because they use constant framerate, or they hack around them in ugly fashion.

For example, we have issues with:

1) LAVF returning invalid PTS (duplicate PTS, and sometimes AV_NOPTS_VALUE)
2) FFMS returning wrong FPS and broken PTS on telecined files
3) FFMS breaking on raw video AVIs
4) FFMS breaking on .h264 files

[LoRd_MuldeR]

I hope all the FFMS problems can be fixed and backported to the standalone FFMS2 plugin for Avisynth. Better FFMS2 source would be great :)

[popper]

You don't need it because we have ffmpeg. Timecodes are only needed when you are using outdated frameworks that does not correctly handle timestamps.(e.g. avisynth, vfw)

1. encode input with x264 and create a vfr mp4
2. convert audio
3. multiplex subtitle, audio and video using ffmpeg

I know there are several bugs in ffmpeg's muxers, but one day ffmpeg will handle all these things.

as i understand it <kierank> intends at some point to try and make a generic DVB-* style 'Stat Mux' capable TS (Transport Stream) framework for x264, so industrial Timecode capability and even New stat mux and related timecode insertion/editing apps if the need arises will be useful in the future for many AVC x264 things it seems, although its not clear exactly how he will impliment it yet!

BTW why dont you spend time on the #x264dev IRC roozhou ?,
http://gogloom.com/client2/index2?mainCHAT=1&network=FreeNode&channel=%23x264dev
your coding skills will help out there for review and patchs etc it seems.

[SledgeHammer_999]

I hope all the FFMS problems can be fixed and backported to the standalone FFMS2 plugin for Avisynth. Better FFMS2 source would be great :)

I second that!

Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)

[kemuri-_9]

as the avs plugin is a wrapper around the FFMS2 API, the same API that x264 uses, any issues found and fixed should also be fixed for the avisynth plugin.
Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)
no.

[roozhou]

I second that!

Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)

I have improved vsfilter.dll's csri interface and hardsub works perfectly with my dshow x264 build under windows. As soon as ffmpeg input in x264 is finished, this can be easily port to lavf input. However hardsub requires true timestamp for each frame not fake cfr or average fps.

[buzzqw]

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

thanks

BHH

[Sharc]

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

I one sets --bitrate yyyyy --size xxxx: who will be the winner? The last parameter superseding the first one?

[sneaker_ger]

I have improved vsfilter.dll's csri interface and hardsub works perfectly with my dshow x264 build under windows. As soon as ffmpeg input in x264 is finished, this can be easily port to lavf input. However hardsub requires true timestamp for each frame not fake cfr or average fps.

Can we expect this to be ported into FFmpegSource (https://forum.doom9.org/showthread.php?t=127037)?

[LoRd_MuldeR]

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

thanks

BHH

IMO a "--size" parameter would be kind of superfluous. All it would do is set "--bitrate" to "size/duration", which can be calculated easily before calling x264.

Also x264 doesn't always know the duration in advance! As far as I understood, it doesn't know the framecount in advance with the "lavc" demuxer, only with the "ffms2" demuxer. And of course with Avisynth.

It doesn't know the number of frames for sure when reading source from STDIN, unless the user passes "--frames" explicitly. So how should "--size" behave in those situations ???

I one sets --bitrate yyyyy --size xxxx: who will be the winner? The last parameter superseding the first one?

In that case, if "--size" really is added, x264 should abort with error, because the user has set contradictory options...

[J_Darnley]

In that case, if "--size" really is added, x264 should abort with error, because the user has set contradictory options...

x264 doesn't abort at present if you do --bitrate x --crf y. The latter option would be used. Whether it should, I don't know.

But I agree, with your statement that it is pointless.

[bnshrdr]

In my opinion, the whole --size option shouldn't be part of the program that does the encoding, but part of a front-end, as it has been done in the past. (MeGUI, Staxrip, and others....)

But then again, I have the whole linux way of looking at things, one program should have one task. I don't want to see my media players turn into web browsers :).

[roozhou]

It doesn't know the number of frames for sure when reading source from STDIN, unless the user passes "--frames" explicitly. So how should "--size" behave in those situations ???


--size should work in 2nd pass.

[kypec]

In my opinion, the whole --size option shouldn't be part of the program that does the encoding, but part of a front-end, as it has been done in the past. (MeGUI, Staxrip, and others....)
My words exactly. If someone is not able to calculate the most simple algebra of elementary school (Bitrate = Size / Duration hence Size = Bitrate * Duration) he shouldn't be using x264 at all.:p
It really goes beyond my comprehension why an author of multiple x264 GUI's [buzzqw] would have requested such useless option...:confused:

[buzzqw]

It really goes beyond my comprehension why an author of multiple x264 GUI's [buzzqw] would have requested such useless option...
because personally i don't use gui, only command line and notepad

BHH

[roozhou]

Can someone provide a compilation guide on lavf and ffms for x264?

[kypec]

because personally i don't use gui, only command line and notepad
BHH
<IRONICMOOD>Well, in that case I encourage you to try another amazing tool which could help you a lot -> calculator.</IRONICMOOD>

[ACoolie]

I'm sure size/duration works for the general case, but if you've ever looked at the code for the MeGUI bitrate calculator (which, in my experience has been somewhat more accurate than my own calculations), its not that simple. I'm not sure if it got into this patch, but someone suggested output.write_frame return the amount of new data written (or the written size of the frame?), which would make a --size option most accurate to implement, although I probably wouldn't want it committed.
Anyways, congrats on getting this done :)

[elguaxo]

can someone provide a compilation guide on lavf and ffms for x264?

+1 :)

[VFR maniac]

MSYS/MinGW32 (for static build)

pthreads-win32 (2.9.0.0 autostatic)
Patch this (http://pastebin.com/m476bc29).
make clean GC-autostatic
cp libpthreadGC2.a /usr/local/lib
cp pthread.h sched.h semaphore.h /usr/local/include


ffmpeg (rev21392) and libswscale (rev30392)
Note: If you didn't build pthreads-win32 as autostatic, remove --enable-pthreads. If you built it as autostatic, patch this (http://pastebin.com/maa04d5f).
./configure --enable-pthreads --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio --prefix=/usr/local --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib"
make
make install



ffms2 (rev262)
Requirments: zlib (http://sourceforge.net/projects/mingw/files/MinGW%20zlib/zlib-1.2.3-1-mingw32/zlib-1.2.3-1-mingw32-src.tar.gz/download), bzip2 (http://sourceforge.net/projects/mingw/files/MinGW%20bzip2/release%201.0.5-2/bzip2-1.0.5-2-mingw32-src.tar.gz/download), cmake (http://www.cmake.org/files/v2.8/cmake-2.8.0.zip) <--- install them in /usr/local
Patch this (http://pastebin.com/m66c52ea7).
cmake -G "MSYS Makefiles"
make
cp include/ffms.h /usr/local/include
cp libFFMS2.a /usr/local/lib


x264
./configure --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib"
make

[LoRd_MuldeR]

--size should work in 2nd pass.

You need to specify a target bitrate also for the first pass if a 2-Pass encode, so you'd need to know the total number of frames before the first pass.

[Selur]

Since 'LAVF/FFMS input support, native VFR timestamp handling' made it into the git repository I wanted to ask:
Does this feature provide any benefit over piping to x264 with ffmpeg/mencoder? (aside from the point of not needing an external decoder to pipe to x264)

[Dark Shikari]

Since 'LAVF/FFMS input support, native VFR timestamp handling' made it into the git repository I wanted to ask:
Does this feature provide any benefit over piping to x264 with ffmpeg/mencoder? (aside from the point of not needing an external decoder to pipe to x264)Piping loses timestamps.

[Selur]

yes, but does x264 profit from the timestamps? iirc (not too sure) decoding a vfr source with ffmpeg/mencoder should result in a cfr output with duplicated frames and since the frames should be exact duplicates it shouldn't harm compression so it seems like it might be the question is x264 can detect duplicate frames and 'create vfr output' (not code duplicates and adjust the timestamps accordingly).

Cu Selur

[Dark Shikari]

yes, but does x264 profit from the timestamps? iirc (not too sure) decoding a vfr source with ffmpeg/mencoder should result in a cfr output with duplicated frames and since the frames should be exact duplicates it shouldn't harm compression so it seems like it might be the question is x264 can detect duplicate frames and 'create vfr output' (not code duplicates and adjust the timestamps accordingly).

Cu Selurffmpeg does not duplicate frames unless you use -r to tell it to.

[Selur]

Assuming I use -r FRAMERATE for the output (which I normally do when piping to x264), will it make a difference for the output if x264 is fed via ffmpeg&pipe or directly with the file?

[Dark Shikari]

Assuming I use -r FRAMERATE for the output (which I normally do when piping to x264), will it make a difference for the output if x264 is fed via ffmpeg&pipe or directly with the file?No. Using -r forces CFR by duplicating or dropping frames.

Do note that using --fps in x264 does not force CFR at the moment when dealing with VFR input: we will change that in a future patch.

Also note that x264 WILL NEVER DROP FRAMES currently: it has no internal sync system, so you can't convert VFR->CFR. "Forcing CFR" just changes the timestamps on existing frames, potentially losing sync.

[Selur]

Thanks for clearing that up. :)

[roozhou]

Hi DS,

- pic.i_pts = (int64_t)i_frame * param->i_fps_den;
+ if( !param->b_vfr_input )
+ pic.i_pts = i_frame;


Why? MP4, flv and mkv muxer can assume all streams vfr (timestamp based) and easily handle them. But now they have to treat cfr and vfr differently.

[Dark Shikari]

Hi DS,

- pic.i_pts = (int64_t)i_frame * param->i_fps_den;
+ if( !param->b_vfr_input )
+ pic.i_pts = i_frame;


Why? MP4, flv and mkv muxer can assume all streams vfr (timestamp based) and easily handle them. But now they have to treat cfr and vfr differently.Huh? That code you quoted is synthesizing timestamps for the muxers, AFAIK.

[kemuri-_9]

Huh? That code you quoted is synthesizing timestamps for the muxers, AFAIK.

yes, that synthesizes timestamps for CFR input (which is exactly how it reads :P)

[roozhou]

Really confused on this. What is the real PTS for each frame (in seconds)?

A) i_pts * i_fps_den / i_fps_num
B) i_pts * i_timebase_num / i_timebase_den

[Dark Shikari]

Really confused on this. What is the real PTS for each frame (in seconds)?

A) i_pts * i_fps_den / i_fps_num
B) i_pts * i_timebase_num / i_timebase_denThe timebase is fps_den / fps_num.

This means that if the pts of frames are:

0, 1, 2, 3, 4, 5...

And the fps is:

24000/1001

The frames' times, in seconds, are:

0/24000, 1001/24000, 2002/24000, 3003/24000, 4004/24000, 5005/24000...

[roozhou]

The timebase is fps_den / fps_num.

This means that if the pts of frames are:

0, 1, 2, 3, 4, 5...

And the fps is:

24000/1001

The frames' times, in seconds, are:

0/24000, 1001/24000, 2002/24000, 3003/24000, 4004/24000, 5005/24000...
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?