[FFmpeg-user] libx264 very bad scaling with 4 real CPU cores (no HT)

D dcmhoybdpzkh at web.de
Thu Dec 3 16:43:28 CET 2015

On 02.12.2015 16:12, Moritz Barsnick wrote:
> On Wed, Dec 02, 2015 at 15:56:41 +0100, D wrote:
>> Maybe it's possible with the -CLI version. I wonder what settings the
>> GUI creates and forwards to x264, so I could take them and just add
>> "-threads n" and see how it scales.
> (lib)x264 inserts information about its complete settings into a
> private part of the stream, as a human-readable string. Either use
> mediainfo, which exposes this, or simply:
> $ strings < file.mp4 | grep x264
> You will get something like this:
> $ strings < someoddfileifound.mp4 | grep x264
> x264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
> Good luck constructing a command line from that. ;-) At least you can
> compare settings, perhaps only two or three differ.
Thanks for the info.
First I tried the GUI, enabled the Advanced tab and added threads but it 
was ignored.
Then I tried the CLI:
$ time HandBrakeCLI -i a.mp4 -o b.mp4 -e x264 -q 23 --x264-preset 
ultrafast --encopts 
but about half of the settings were ignored.
Anyway HandBrake is offtopic and I don't think it makes sense to try get 
it running. Better to get straight x264 running. If someone is 
interested in porting these commands to x264 that would be nice. I think 
often adding a "--" before the name should work, I tried this with a few 
commands, but some commands were unknown to x264.
Anyway the scaling, as we figured out a few emails ago, is a x264 
problem, not ffmpeg's, so it's "solved" here. Thanks everyone.
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

More information about the ffmpeg-user mailing list