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

[Henk D. Schoneveld]

On 03 Dec 2015, at 16:43, D <dcmhoybdpzkh at web.de> wrote:

> 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 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=6: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=300:keyint_min=30:scenecut=40:intra_refresh=0:rc_lookahead=40:rc=abr:mbtree=1:bitrate=1000:ratetol=1.0:qcomp=0.60:qpmin=0:qpmax=69:qpstep=4:ip_ratio=1.40:aq=1:1.00
> but about half of the settings were ignored.
The reason for his is that part of your options are contradictions.
If you instruct x264 to use -q 23 then rc=abr doesn’t make sense as bitrate 1000 doesn’t. Last instruction overrides the former one. q=23 means use the amount of bits needed to get this quality level, you can’t afterwards say use 1000k as bitrate. It’s the same as asking drive my car at 160km/h but don’t use more then 3ltr per 100km distance. It’s one or the other. And there are more contradictions in your command, study them and use what is important to you.
> 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
> 
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user