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

[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]

Originally Posted by buzzqw

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]

Originally Posted by roozhou

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.

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.

./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, bzip2, cmake <--- install them in /usr/local
Patch this.

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]

Originally Posted by roozhou

--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]

Originally Posted by 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)

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]

Originally Posted by 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

ffmpeg 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]

Originally Posted by 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?

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]

Originally Posted by 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.

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

[kemuri-_9]

Originally Posted by Dark Shikari

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]

Originally Posted by 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

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...

[roozhou]

Originally Posted by Dark Shikari

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?