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

[D]

On 03.12.2015 22:22, Lou wrote:

On Thu, 3 Dec 2015 16:43:28 +0100
D  wrote:


If someone is interested in porting these commands to x264 that would
be nice.

Don't try to manually set a each option. That's a waste of time &
effort. It usually results in contradictions and a less than optimal
output. Just use the x264 encoding presets: they were designed so users
wouldn't have to deal with dozens of options.
Thanks for mentioning this. I wasn't sure whether or not to do it 
because HandBrake utilizes the CPU very well (in $top: ~387%) and some 
presets like the ultrafast one wasn't scaling very well as all (4 cores, 
~210%) (029372.html). So I thought maybe it has something to do with the 
command, but you are right, if the presets are carefully done by the 
devs, they should scale.
Wanted to ask this in a x264 place -- 
https://www.videolan.org/developers/x264.html -- but I don't see a user 
mailing list or forum (they link to doom10 which doesn't exist, LOL) or 
something, there is only a x264-devel). Well I guess there is still "and 
IRC (#x264@freenode" but it's for chat where a topic is not organized 
and basically also lost in the future.


The other thing I find weird with -preset is that one can use -crf 
setting with it. I thought a preset would cover this and no -crf setting 
would be needed/allowed. But because it is, the question is what other 
settings are allowed/needed? Confusing.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Moritz Barsnick]

On Fri, Dec 04, 2015 at 12:06:24 +0100, D wrote:
> mailing list or forum (they link to doom10 which doesn't exist, LOL) or

doom9 perhaps?
http://forum.doom9.org/forumdisplay.php?f=77

> The other thing I find weird with -preset is that one can use -crf 
> setting with it. I thought a preset would cover this and no -crf setting 
> would be needed/allowed. But because it is, the question is what other 
> settings are allowed/needed? Confusing.

As far as my experience tells me, the presets control speed versus
size, at (approximately) constant quality. So "-preset veryslow" and
"-preset ultrafast" should show the same image quality. There are test
measurements out there to prove it, IIRC. You then use "-crf" to vary
the requested quality.

Indeed, asking x264 folk would be better. :)

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Jim Worrall]

On Fri, Dec 4, 2015 at 4:06 AM, D  wrote:

> On 03.12.2015 22:22, Lou wrote:
>
>> On Thu, 3 Dec 2015 16:43:28 +0100
>> D  wrote:
>>
> The other thing I find weird with -preset is that one can use -crf setting
> with it. I thought a preset would cover this and no -crf setting would be
> needed/allowed. But because it is, the question is what other settings are
> allowed/needed? Confusing.
>
> I would suggest you read a bit on x264 to reduce the confusion.  Here is a
good place to start:
https://trac.ffmpeg.org/wiki/x264EncodingGuide

When using presets, there are essentially three things you can vary:
encoding speed, quality, and bitrate.
You specify relative encoding speed with the choice of preset, then specify
either quality or bitrate.
You can't specify all three in one encode.

At a given quality level (crf), you will get lower bitrate with a slower
preset.
At a given bitrate level, you will get better quality with a slower preset.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Henk D. Schoneveld]

On 03 Dec 2015, at 16:43, D  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@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[D]

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.
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[D]

On 03.12.2015 18:37, Henk D. Schoneveld wrote:

On 03 Dec 2015, at 16:43, D  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.
Thanks. The settings are 1 to 1 taken over from $ strings < b.mp4 | grep 
x264 after it was created by HandBrake. Basically also the same what 
Moritz posted ("[...] .org/x264.html - options: cabac=1 [...] 
aq=1:1.00"). Also, removing "-q" doesn't make it better.

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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Henk D. Schoneveld]

On 03 Dec 2015, at 19:52, D  wrote:

> On 03.12.2015 18:37, Henk D. Schoneveld wrote:
>> On 03 Dec 2015, at 16:43, D  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.
> Thanks. The settings are 1 to 1 taken over from $ strings < b.mp4 | grep x264 
> after it was created by HandBrake. Basically also the same what Moritz posted 
> ("[...] .org/x264.html - options: cabac=1 [...] aq=1:1.00"). Also, removing 
> "-q" doesn't make it better.
Of course not, because bitrate 1000 disables -q 23
>>> 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@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>> ___
>>> ffmpeg-user mailing list
>>> ffmpeg-user@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Lou]

On Thu, 3 Dec 2015 16:43:28 +0100
D  wrote:

> If someone is interested in porting these commands to x264 that would
> be nice.

Don't try to manually set a each option. That's a waste of time &
effort. It usually results in contradictions and a less than optimal
output. Just use the x264 encoding presets: they were designed so users
wouldn't have to deal with dozens of options.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [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  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
libavformat57. 19.100 / 57. 19.100
libavdevice57.  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
libpostproc54.  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"
real1m33.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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Moritz Barsnick]

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.

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[D]

On 01.12.2015 19:29, Lou wrote:

On Tue, 1 Dec 2015 19:17:14 +0100
D  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
real9m51.886s

This means little without the complete console output. For example, how
do you know you didn't compile with --disable-yasm?
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
  libavformat57. 19.100 / 57. 19.100
  libavdevice57.  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
  libpostproc54.  0.100 / 54.  0.100



Why are you encoding audio if you want to benchmark video?

You don't need to output an actual file if you want to benchmark
encoding:

   $ time ffmpeg -i input -c:v libx264 -f null -

Yes


What kind of performance does the default threads setting give? You can
just omit -threads and the default will be used.
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.


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.


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"

real1m33.883s

$ time x264 --pass 1 --crf 23 --preset ultrafast --threads 2 -o "b.mp4" 
"a.mp4"

real0m46.055s

$ time x264 --pass 1 --crf 23 --preset ultrafast --threads 3 -o "b.mp4" 
"a.mp4"

real0m47.036s

$ time x264 --pass 1 --crf 23 --preset ultrafast --threads 4 -o "b.mp4" 
"a.mp4"

real0m51.750s

$ time x264 --pass 1 --crf 23 --preset ultrafast -o "b.mp4" "a.mp4"
ffms [info]: 1920x1080p 1:1 @ 30/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 
AVX2 LZCNT BMI2

x264 [info]: profile Constrained Baseline, level 4.0
x264 [info]: frame I:15Avg QP:20.67 size:206997
x264 [info]: frame P:3568  Avg QP:23.62  size: 62366
x264 [info]: mb I  I16..4: 100.0%  0.0%  0.0%
x264 [info]: mb P  I16..4: 15.0%  0.0%  0.0%  P16..4: 77.4%  0.0% 0.0%  
0.0%  0.0%skip: 7.6%
x264 [info]: coded y,uvDC,uvAC intra: 20.4% 91.6% 69.4% inter: 26.3% 
82.6% 27.2%

x264 [info]: i16 v,h,dc,p: 37% 23% 28% 12%
x264 [info]: i8c dc,h,v,p: 50% 20% 19% 11%
x264 [info]: kb/s:15119.82

encoded 3583 frames, 76.70 fps, 15119.86 kb/s

real0m46.987s

So unfortunately basically the same as with ffmpeg.


Of course you will need to use the same input for both ffmpeg and x264.

Same file.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [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  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
real9m51.886s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 2 -c:a libvorbis b.mp4 -y
real5m14.630s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 3 -c:a libvorbis b.mp4 -y
real4m11.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
real3m27.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
real0m59.384s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 2 -c:a 
libvorbis b.mp4 -y
real0m37.741s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 3 -c:a 
libvorbis b.mp4 -y
real0m34.870s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 4 -c:a 
libvorbis b.mp4 -y
real0m34.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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[D]

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

real9m51.886s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 2 -c:a libvorbis 
b.mp4 -y

real5m14.630s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 3 -c:a libvorbis 
b.mp4 -y

real4m11.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

real3m27.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

real0m59.384s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 2 
-c:a libvorbis b.mp4 -y

real0m37.741s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 3 
-c:a libvorbis b.mp4 -y

real0m34.870s

$ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 4 
-c:a libvorbis b.mp4 -y

real0m34.400s

If I'm not the only one having this issue, then the devs should fix this.

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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Lou]

On Tue, 1 Dec 2015 19:17:14 +0100
D  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
> real9m51.886s

This means little without the complete console output. For example, how
do you know you didn't compile with --disable-yasm?

Why are you encoding audio if you want to benchmark video?

You don't need to output an actual file if you want to benchmark
encoding:

  $ time ffmpeg -i input -c:v libx264 -f null -

What kind of performance does the default threads setting give? You can
just omit -threads and the default will be used.

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).

Now for the important question: did you also test the x264 cli tool?
Of course you will need to use the same input for both ffmpeg and x264.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

[Henk D. Schoneveld]

On 01 Dec 2015, at 19:17, D  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
> real9m51.886s
> 
> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 2 -c:a libvorbis b.mp4 -y
> real5m14.630s
> 
> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -threads 3 -c:a libvorbis b.mp4 -y
> real4m11.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
> real3m27.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
> real0m59.384s
> 
> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 2 -c:a 
> libvorbis b.mp4 -y
> real0m37.741s
> 
> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 3 -c:a 
> libvorbis b.mp4 -y
> real0m34.870s
> 
> $ time ffmpeg -i a.mp4 -c:v libx264 -crf 23 -preset ultrafast -threads 4 -c:a 
> libvorbis b.mp4 -y
> real0m34.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@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> 
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user