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 <[email protected]> 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
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
