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

[D]

Thanks for the confirmation. I kind of expect that lots of people have 
this problem then. What is your CPU and OS?

Forget to add to my other email that HandBrake-GUI uses ~387% in top 
(which is good so far) but I couldn't test with "-threads 1" and so on 
and see how it scales. Maybe it's possible with the -CLI version. From 
my tests down below can be seen that settings might play a big role, not 
only input files.

On 01.12.2015 19:37, Henk D. Schoneveld wrote:
> On 01 Dec 2015, at 19:17, D <dcmhoybdpzkh at web.de> wrote:
>
>> Another test: this time I built ffmpeg myself according to https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
>> And here's the benchmark -- Very bad scaling:
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 1 -c:a libvorbis b.mp4 -y
>> real    9m51.886s
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 2 -c:a libvorbis b.mp4 -y
>> real    5m14.630s
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 3 -c:a libvorbis b.mp4 -y
>> real    4m11.611s
>> (should be: 9m51.886s / 3 = 3,28m)
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 4 -c:a libvorbis b.mp4 -y
>> real    3m27.341s
>> (should be: 9m51.886s / 4 = 2,46m -- as slow as 3 threads)
>>
>>
>> Another test -- Even worse scaling:
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 1 -c:a libvorbis b.mp4 -y
>> real    0m59.384s
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 2 -c:a libvorbis b.mp4 -y
>> real    0m37.741s
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 3 -c:a libvorbis b.mp4 -y
>> real    0m34.870s
>>
>> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 4 -c:a libvorbis b.mp4 -y
>> real    0m34.400s
>>
>> If I'm not the only one having this issue, then the devs should fix this.
> You are not the only one, I also observed less then optimal scaling, but also observed that 1 source, DVBS in my case, scales much worse then another also DVBS source. So scaling seems to be very dependent on source, I don’t have to encode in realtime, so I run multiple instances of ffmpeg on different sources to get CPU load to max available. The source of the problem AFAIK is in the x264 library and the developers of that library are on videolan.org not on ffmpeg. All AFAIK.
>> On 27.11.2015 17:04, D wrote:
>>> Here's the normal: http://pastebin.com/wyt56q4B
>>> And here's with debug: http://pastebin.com/WxfRDKPP
>>> (Upgraded to Ubuntu 15.10 that's why you see "gcc 5.2.1")
>>>
>>> It was a bit slower this time after OS Upgrade -- same command and everything otherwise:
>>> Ubuntu 15.04: 3m22
>>> Ubuntu 15.10: 3m45
>>> Anyway, this is not the priority right now.
>>>
>>> On 27.11.2015 16:15, James Darnley wrote:
>>>> On 2015-11-27 13:29, D wrote:
>>>>> Nevermind, libx264 isn't doing much better:
>>>> Have you posted the full output of ffmpeg somewhere in this thread?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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