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

[D]

On 01.12.2015 22:59, Lou wrote:
> On Tue, 1 Dec 2015 22:19:16 +0100
> D <dcmhoybdpzkh at web.de> wrote:
>
>> I built it with yasm. But $ ffmpeg seems not to display it? Or does it
>> only display it if it's disabled, so mine is enabled?
>>
>> ffmpeg version N-76952-g6b978da Copyright (c) 2000-2015 the FFmpeg
>> developers
>>     built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010
>>     configuration: --prefix=/home/username/ffmpeg_build
>> --pkg-config-flags=--static
>> --extra-cflags=-I/home/username/ffmpeg_build/include
>> --extra-ldflags=-L/home/username/ffmpeg_build/lib
>> --bindir=/home/username/bin --enable-gpl --enable-libass
>> --enable-libfreetype --enable-libopus --enable-libtheora
>> --enable-libvorbis --enable-libx264 --enable-nonfree
>>     libavutil      55.  9.100 / 55.  9.100
>>     libavcodec     57. 16.101 / 57. 16.101
>>     libavformat    57. 19.100 / 57. 19.100
>>     libavdevice    57.  0.100 / 57.  0.100
>>     libavfilter     6. 17.100 /  6. 17.100
>>     libswscale      4.  0.100 /  4.  0.100
>>     libswresample   2.  0.101 /  2.  0.101
>>     libpostproc    54.  0.100 / 54.  0.100
> That's not the complete console output. The "using cpu capabilities"
> output from libx264 is worth noting.
I already posted a full output a few emails ago but here you go again 
with my build this time (BTW: so far building ffmpeg myself didn't 
change anything vs using static builds from ffmpeg.org/download):
Without "-threads": http://pastebin.com/vHVYdkCf
With "-threads 1": http://pastebin.com/mcWuqS0N
>
>> If I omit it it's of course the same as "-threads 4" (I did already test
>> it and at least this is what I would expect because I have 4 real cores
>> on a 84W TDP Haswell i5 CPU). See without "-threads 4" down below.
> 4 cores does not mean that x264 will automatically choose 4 threads.
> For example, for my aging i7 860, x264 will use threads=12 (cores*1.5
> for frame threads).
That's good info.
>
> I did not read the whole thread, so I'm likely missing something
> obvious, why not just use the defaults? Why are you messing around with
> threads?
I was just wondering how it scales and found out it doesn't well.
>
>>> In the console output when using the defaults, what value appears for
>>> "threads=" in the x264 info? (You may have to output to a file instead
>>> of null for it to appear).
>> Don't know how to see it.
> Encode a file. Look at the console output; specifically the long line
> that starts something like this:
>
> [libx264 @ 0x55be781c6d40] 264 - core 148 r2579 73ae2d1 ...
>
>>> Now for the important question: did you also test the x264 cli tool?
>> Indeed an important question.
>> $ sudo apt-get install x264
>>
>> $ time x264 --pass 1 --crf 23 --preset ultrafast --threads 1 -o "b.mp4"
>> "a.mp4"
>> real    1m33.883s
> [...]
>> So unfortunately basically the same as with ffmpeg.
> In this case your questions should be asked at x264 help resources.
That's what I thought too.

PS: I tested HandBrake with HandBrake-GUI. It uses ~387% in top (which 
is good so far and utilized the CPU better than any other of my tests 
(well, VP9 did but the output files were corrupted and unreadable)) but 
I couldn't test with e.g. "-threads 1" and so on and see how it scales. 
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.

> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user