Difference Between X264 and FFMPEg libx264

[Bathrone]

Hi

So I am experimenting with encoding from 4k tiff samples of the blender open source project mango "tears of steel"

My first problem was that AFAIK x264 wont accept tiffs as an imput format so I switched to using ffmpeg which does.

Q1: Is there any difference between using native x264 and ffmpeg via libx264? Assuming ofcourse both of them are compiled from the same git revision?

At the moment I'm using this command line:

ffmpeg -f image2 -i d:\encoding\1\graded_edit_%5d.tif -c:v libx264 -preset veryslow -tune film -x264opts bluray-compat:vbv-bufsize=30000:vbv-maxrate=40000 -level 41 -r 24 -t 20 -pix_fmt yuv420p -s 1920x1080 output.mkv

Q2: Is tune film a good choice for live action mixed with CG effects/scenes?

Q3: Would there be any benefit to me using another type of toolchain such as avisynth then into x264?

Q4: My CPU is 6 physical cores and 12 logical cores what would be the best thread setting to use?

Many thanks for help fellas

[mariush]

Why don't you use Avisynth?

You have imagesource function : http://avisynth.org/mediawiki/ImageSource

Write basic avisynth script, feed it to x264, problem solved.

[Bathrone]

Q3: Would there be any benefit to me using another type of toolchain such as avisynth then into x264?

Mariush thanks for trying to answer my question #3.

I'm not sure of the benefits to using Avisynth in this context. You dont articulate any benefits over the ffmpeg libx264 approach.

So I've been doing research on your suggestion. There seems to be largely drawbacks from what I've researched and cunlear benefits.

Avisynth as a 64 bit project seems to be dead. I'm using a 64 bit toolchain. When I do native 4K encodes in ffmpeg sometimes I'm chewing 6 GB of RAM in the ffmpeg process at the 4K resolution. Avisynth in version 2.6 isnt available in 64 bit, the original older 64 bit project is dead and apparently the new version 2.6 has important fixes over previous versions.

My research showed a blog with a workaround of using avs2pipemod:

http://jellyflower.github.io/blog/2013/03/09/how-to-use-64-bit-x264-with-32-bit-avisynth/

However as I did more research there was posts about how this can wreck the timing information

So unless Im missing something I dont see the benefits on this approach?

[Blue_MiSfit]

Regarding question 1 - not really - at least not in terms of encoding quality. The options are different, but I believe all the functionality in libx264 is implemented in both x264.exe and ffmpeg / libav etc.

Regarding question 2, the "film" tuning is reasonable in almost all cases, and certainly in your case.

Regarding question 3, perhaps, but as you've seen, 64 bit AviSynth is not exactly "production ready". I've never had good results.

Regarding question 4, I think you should use defaults for threading. x264 defaults to threads = numCores * 1.5 if I recall correctly. This is probably the case in libx264 as well, but I'm not totally certain.

[J_Darnley]

d:\encoding\1\graded_edit_%5d.tif

If you compile x264 with lavf input then you can use this same string as the input file to x264.

Re 1 - Yes. x264cli has some featres that libx264 does not. Level limiting reference frames for instance.

Re 2 - Film is for anything that tries to replicate the real world shot on film.

Re 3 - Only if you want easier control of scaling, colour space conversion, and better filtering. You may want this if you've got HD video otherwise ffmpeg is limited to the tv-range, bt.601 colour matrix.

Re 4 - Always auto, i.e. 0 (zero).

[pandy]

Re 3 - Only if you want easier control of scaling, colour space conversion, and better filtering. You may want this if you've got HD video otherwise ffmpeg is limited to the tv-range, bt.601 colour matrix.



ffmpeg .... -c:v libx264 ... -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709:fullrange=off ....

[J_Darnley]

And... what's the point?

colorprim=bt709:transfer=bt709:colormatrix=bt709:fullrange=off

Is this what you're trying to show me/us? Where exactly did you tell ffmpeg to use the 709 colour matrix when converting RGB to YUV?

[pandy]

And... what's the point?



Is this what you're trying to show me/us? Where exactly did you tell ffmpeg to use the 709 colour matrix when converting RGB to YUV?
Oh - sorry - point is colormatrix (http://ffmpeg.org/ffmpeg-filters.html#colormatrix)

[Selur]

to use the colormatrix video filter you need to use '-vf' ;)

[pandy]

to use the colormatrix video filter you need to use '-vf' ;)

yep - my fault - sorry once again (i mean i was aware but my point was to show that ffmpeg is capable to output valid information and thanks to colormatrix filter we can output 709 thus ffmpeg is not limited to 601 only)

ffmpeg -i xxx -vf "colormatrix=bt601:bt709" -c:v libx264 -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709:fullrange=off

there is obviously loss on conversion between 601 and 709 and this is not the best way to provide best results but... unless 709 will be introduced to ffmpeg this workaround is acceptable.

perhaps imagemagick pipe to ffmpeg can be used then RGB can be changed in imagemagick to final YCbCr without additional quality loss.

IM colorspace (http://www.imagemagick.org/script/command-line-options.php#colorspace)

[Bathrone]

Many thanks for the insights :)

EDIT: And yes very true thankyou for the suggestion I can video filter directly in x264 as well as present the 16bit 4k tiffs

Some CLI examples

x264.exe --fps 24 --input-res 4096x1714 --video-filter resize:width=1920,height=1088,sar=1:1,method=spline --preset placebo --tune film --vbv-bufsize 62000 --vbv-maxrate 62000 --nal-hrd vbr --crf 15 --profile high --level 41 -o "d:\encoding\test.mkv" "d:\encoding\1\graded_edit_%5d.tif"

x264.exe --fps 24 --input-res 4096x1714 --preset placebo --tune film --crf 15 -o "d:\encoding\test4k.mkv" "d:\encoding\1\graded_edit_%5d.tif

So I reckon for my setup the x264 CLI is the best method cos of the differences between CLI and the library in ffmpeg, and because 64 bit AviSynth frameserving with multi thread support isnt too great as of now