Single thread vs multithread in terms of speed

[Chengbin]

Assuming we have a 2.5GHz quad core CPU and a 9GHz single core CPU, all in the same family. Assuming that x264 can use on an average 90% of the quad core CPU, which will give the quad core a theoretical clock speed of 9GHz. If we encode the same video on both processors, using the same settings, will they have the same speed?

[LoRd_MuldeR]

Despite the fact that we don't have a 9 GHz CPU, I'd assume such CPU had a worse "cycles per instruction" ratio than the 2.5 GHz one...

[Chengbin]

Despite the fact that we don't have a 9 GHz CPU, I'd assume such CPU had a worse "cycles per instruction" ratio than the 2.5 GHz one...

Assume that it does, that's why I mentioned both CPUs are in the same family.

[LoRd_MuldeR]

Assume that it does, that's why I mentioned both CPUs are in the same family.

It's pretty unlikely that we have two CPU's of the same family, where one runs at 2.5 GHz and one runs at 9 GHz ...

[Sagekilla]

If you theoretically had a single core CPU running at 8 GHz, and an indentical (architecture wise) quad core CPU running at 2 GHz, you should more or less get the same speed.

But, those "speed demon" CPUs (Read: Pentium 4) have been known to have very poor IPC / CPI. Whereas the "brainy" cpus like Core 2 run slower (not true anymore) but have extremely good IPC / CPI.

[Chengbin]

It's pretty unlikely that we have two CPU's of the same family, where one runs at 2.5 GHz and one runs at 9 GHz ...

I know, this is purely a hypothetical question.

[Shinigami-Sama]

x264 scales almost lineally until you get to somewhere around 16 threads I think it was
so basically the same speed

[henryho_hk]

Don't forget other bottlenecks like memory bandwidth.

[roozhou]

Well, x264's multi-threading brings quality loss, so even you use "the same settings" the resulting videos will not be identical.

[Esurnir]

Well, x264's multi-threading brings quality loss, so even you use "the same settings" the resulting videos will not be identical.

some metrics show gains. so I guess it's kind of depends on the vids, the age of the captain and the current phase of the moon.

[Shinigami-Sama]

Well, x264's multi-threading brings quality loss, so even you use "the same settings" the resulting videos will not be identical.

you won't notice that loss, ever - unless you're at something insane like 48 threads
so its not really worth mentioning

[LoRd_MuldeR]

Well, x264's multi-threading brings quality loss, so even you use "the same settings" the resulting videos will not be identical.

But that "quality loss" is very very small for any sane number of threads.

The OP speculated about a Quadcore, which means that x264 would use 6 threads to get 100% load.

That's a number of threads where the quality loss should be negligible...

EDIT: Shinigami-Sama was faster ;)

[roozhou]

But that "quality loss" is very very small for any sane number of threads.

The OP speculated about a Quadcore, which means that x264 would use 6 threads to get 100% load.

That's a number of threads where the quality loss should be negligible...

EDIT: Shinigami-Sama was faster ;)

How "small" is it? AFAIK multithreading has a big affect on frame-type decision.

Try comparing threads 1 + subme 8 vs threads 16 + subme 9 at the same bitrate. I wonder which has better quality.

[Sagekilla]

Why would you be comparing subme 8 vs subme 9 with different threads? You should compare --threads 1 vs --threads 16 with all other settings constant. If you're trying to measure the effects of threads on quality, you shouldn't let the other parameters vary or you'll get skewed results.

Theoretically, --threads 1 will have better quality than --threads 16, but practically speaking it doesn't matter at all.


Note: If you're talking about frame type decision being single threaded, then yes, eventually you'll hit a wall where you'll be limited by the frame type decision.

[Mr VacBob]

How "small" is it? AFAIK multithreading has a big affect on frame-type decision.

Try comparing threads 1 + subme 8 vs threads 16 + subme 9 at the same bitrate. I wonder which has better quality.

Frametype decision is run in lookahead which runs ahead of all the encoder threads, so it's not affected. Ratecontrol and noise reduction efficiency will be worse, but I don't think it'll be noticeable.

[roozhou]

Why would you be comparing subme 8 vs subme 9 with different threads? You should compare --threads 1 vs --threads 16 with all other settings constant. If you're trying to measure the effects of threads on quality, you shouldn't let the other parameters vary or you'll get skewed results.

Theoretically, --threads 1 will have better quality than --threads 16, but practically speaking it doesn't matter at all.


Note: If you're talking about frame type decision being single threaded, then yes, eventually you'll hit a wall where you'll be limited by the frame type decision.

Everyone knows threads 1 has better quality than threads 16. I need to measure how "small" the effect of threads is.

If threads 1 + subme 8 has better quality than threads 16 + subme 9, then i can conclude that the quality loss of threads 16 vs 1 is larger than subme 8 vs 9.

[Shinigami-Sama]

the difference in quality versus threads is so small you will need to either use stupid low bitrates or look for differences frame by frame...

[Sagekilla]

@roozhou, the difference in quality isn't going to be that huge. You'd have to use a ridiculously low resolution like 320x240 since at that resolution, each thread would have only 15 pixels (height wise) to work with.

Get a nice quality (blu-ray, preferrably) source with lots of motion. Go try encoding that at 1080p, 720p, 480p, and 320x176, changing only threads 1 and threads 16 for each resolution. You'll see practically -no- difference until you get towards the absurdly low resolutions. Even there, if it becomes an issue you can drop the number of encoding threads since low resolution material is extremely easy to encode.

[IgorC]

--threads 16? Yeah and don't forget about SSE5, SSE6, SSE7 and GPGPU. Common!

How about sane numbers for threads like 3 and 6.
Is there any CPU available to exploit --threads 16? Even i7 with its 4core+HT (8 streams) doesn't need more than -threads 12.

x264's devs made a good job. Practically -threads 3/6 for 2/4 cores haven't any quality impact. Don't worry about future 128 cores. By this time devs will do something.

Don't waste people's time to read about speculation around 16 threads. When you buy CPU with >10 cores then you can cry.

[Sagekilla]

If you get a system running a pair of Dunningtons, then yeah you do . ;) But, realistically speaking, I do know some development work was done a while ago on supporting systems with large thread numbers. Someone came along with a multi-socket encoding workhorse that needed to get the most performance possible. I don't remember there being any issues with 16 threads causing a drop in quality.

[Snowknight26]

How about sane numbers for threads like 3 and 6.
Is there any CPU available to exploit --threads 16? Even i7 with its 4core+HT (8 streams) doesn't need more than -threads 12.

Sure is.* (http://stfcc.org/misc/server/)

*I know you said CPU, but I thought this would be a good opportunity to link that. :P

[Sagekilla]

Well, there you have it. Someone with a sixteen core rig. Not many people with one, but there are a few.

Say, you think I could take a look at that for a day or five hundred? ;)

[roozhou]

--threads 16? Yeah and don't forget about SSE5, SSE6, SSE7 and GPGPU. Common!

How about sane numbers for threads like 3 and 6.
Is there any CPU available to exploit --threads 16? Even i7 with its 4core+HT (8 streams) doesn't need more than -threads 12.

x264's devs made a good job. Practically -threads 3/6 for 2/4 cores haven't any quality impact. Don't worry about future 128 cores. By this time devs will do something.

Don't waste people's time to read about speculation around 16 threads. When you buy CPU with >10 cores then you can cry.

Well I am just trying to MEASURE the quality loss of multithreading. Of course you can use threads 3/6.

On a dual core, threads 1 is slower than threads 2 and subme 9 is also slower than subme 8. I need to measure which one gives me better quality/speed.

[Sagekilla]

roozhou, again, trying to measure the effects of threads on quality is our proverbial finding a needle in a haystack. You can try, but it's going to be mostly pointless since any sane number of threads on a sane resolution isn't going to show a noticeable quality drop.

[roozhou]

roozhou, again, trying to measure the effects of threads on quality is our proverbial finding a needle in a haystack. You can try, but it's going to be mostly pointless since any sane number of threads on a sane resolution isn't going to show a noticeable quality drop.

Will --subme 8 show a noticeable quality drop compared to --subme 9 on a sane resolution? And what about --me umh compared to --me tesa? But why ppl use --subme 9 and --me tesa?

[Shinigami-Sama]

Will --subme 8 show a noticeable quality drop compared to --subme 9 on a sane resolution? And what about --me umh compared to --me tesa? But why ppl use --subme 9 and --me tesa?

because they don't care about speed
and most that use tesa have quadcores
or are limited by their input anyways
or they leave the encode overnight/work

[roozhou]

because they don't care about speed
and most that use tesa have quadcores
or are limited by their input anyways
or they leave the encode overnight/work

Yes, and --threads 1 is just another insane setting for multicore CPUs. If you need to get the "best" quality or the "smallest" size, use --threads 1.

[IgorC]

http://forum.doom9.org/showthread.php?p=1252267#post1252267

For this source (SD resolution) I obtained the following results with sane settings ref 4, umh, b-frames 3, merange 16:
--threads 3 requires +0.2% bitrate comparing to --threads 1.
--threads 6 requires +0.35% bitrate comparing to --threads 1.
--threads 12 requires +0.75-0.80% bitrate comparing to --threads 1.

The difference is less than 1%. It's impossible to say which is better even on screenshots.

But if you need a meaningless ideal quality and wait 16 or 32 hours instead of 8 hours...

[roozhou]

But if you need a meaningless ideal quality and wait 16 or 32 hours instead of 8 hours...

This also applies to --me tesa, --subme 9, -b16 w/ --b-adapt2,--merange 32 etc.

IMO threads 6 won't always give you 4x speed. Don't forget --thread-input which has no effect on encoding result.

[IgorC]

Yes.
So?
I don't understand what you want. It's your personal decision to encode at good speed with sane settings and obtain 98%-99% of quality video or 5x slower encoding to squeeze the rest 1-2%. It's up to you. Do your own measurements: objective, subjective, metrics... and make final decision.

[roozhou]

Yes.
So?
I don't understand what you want. It's your personal decision to encode at good speed with sane settings and obtain 98%-99% of quality video or 5x slower encoding to squeeze the rest 1-2%. It's up to you. Do your own measurements: objective, subjective, metrics... and make final decision.

Most people always forget to use --threads 1 w/ their "insane" settings.

[IgorC]

More probably they don't forget. --threads 3 has no any quality impact for HD 720p/1080p.
Just checked for blu sky 1080p sample:
Results:
--threads 1 SSIM: 79.835 OPSNR: 38.248 (6002.4 kbit/s)
--threads 3 SSIM: 79.840 OPSNR: 38.246 (5979.66 kbit/s)

No quality loss at all.

[roozhou]

More probably they don't forget. --threads 3 has no any quality impact for HD 720p/1080p.
Just checked for blu sky 1080p sample:
Results:
--threads 1 SSIM: 79.835 OPSNR: 38.248 (6002.4 kbit/s)
--threads 3 SSIM: 79.840 OPSNR: 38.246 (5979.66 kbit/s)

No quality loss at all.

You need to prove it.

My test encode on a 1080p content shows that subme 9 gives higher bitrate than subme 6 w/ the same crf value. I can also conclude subme 6 gives no quality loss at all compared to subme 9.

--crf 20 -r4 -b3 --b-adapt 2 -t1 -m6 --me umh --merange 16 --threads 3 : 5.62 fps, 9636.00 kb/s
--crf 20 -r4 -b3 --b-adapt 2 -t1 -m9 --me umh --merange 16 --threads 3 : 4.40 fps, 10072.59 kb/s

[nm]

You need to prove it.

My test encode on a 1080p content shows that subme 9 gives higher bitrate than subme 6 w/ the same crf value. I can also conclude subme 6 gives no quality loss at all compared to subme 9.
How exactly do you conclude that? I think IgorC's method and results are much more convincing.

Also, subme 6 is only ~30% faster than subme 9 (according to your numbers), while threads=3 is almost 100 % faster than threads=1 and the quality difference is so minimal that it can't even be measured in some cases.

[Manao]

My test encode on a 1080p content shows that subme 9 gives higher bitrate than subme 6 w/ the same crf value. I can also conclude subme 6 gives no quality loss at all compared to subme 9.No you cannot, since you didn't check the PSNR / SSIM figures, while IgorC did. It has already been stated several times that subme6 and subme9 don't have the same bitrate/quality tradeoff, but that, at the same bitrate, subme9 will have a higher quality, and at the same quality, it'll have a lower bitrate. That doesn't prevent it from having a higher bitrate than subme6 in CRF.

[roozhou]

No you cannot, since you didn't check the PSNR / SSIM figures, while IgorC did. It has already been stated several times that subme6 and subme9 don't have the same bitrate/quality tradeoff, but that, at the same bitrate, subme9 will have a higher quality, and at the same quality, it'll have a lower bitrate. That doesn't prevent it from having a higher bitrate than subme6 in CRF.

Guys you misunderstood me. Of course my "conclusion" is meaningless. That is just an analogy.

Perhaps --threads 1 and --threads 3 don't have the same bitrate/quality tradeoff either. And PSNR / SSIM is not equal to visual quality(e.g. aq, psy-rd). The conclusion threads 3 brings no quality loss at all compared to threads 1 is groundless.

[roozhou]

while threads=3 is almost 100 % faster than threads=1 and the quality difference is so minimal that it can't even be measured in some cases.

Never if you use --thread-input or --b-adapt 2.

--crf 20 -r4 -b3 --b-adapt 2 -t1 -m6 --me umh --merange 16 --thread-input --threads 1 : 4.31 fps, 9730.75 kb/s
--crf 20 -r4 -b3 --b-adapt 2 -t1 -m6 --me umh --merange 16 --thread-input --threads 3 : 5.62 fps, 9636.00 kb/s

Well, only 30% faster. I am using an E8400.

[Audionut]

lmfao, arguing that threads 1 should be enabled for best quality.

I'm board, so i'll do my own tests and report back.

[nm]

Never if you use --thread-input or --b-adapt 2.

--crf 20 -r4 -b3 --b-adapt 2 -t1 -m6 --me umh --merange 16 --thread-input --threads 1 : 4.31 fps, 9730.75 kb/s
--crf 20 -r4 -b3 --b-adapt 2 -t1 -m6 --me umh --merange 16 --thread-input --threads 3 : 5.62 fps, 9636.00 kb/s

Well, only 30% faster. I am using an E8400.
I forgot the input thread. Apparently it does some relatively heavy processing in your case, because of decoding or filtering. Personally I rarely use AviSynth or any filtering whatsoever and my sources are MPEG-2, so scaling from 1 thread to 3 almost doubles my encoding speed even with b-adapt 2.

[roozhou]

I forgot the input thread. Apparently it does some relatively heavy processing in your case, because of decoding or filtering. Personally I rarely use AviSynth or any filtering whatsoever and my sources are MPEG-2, so scaling from 1 thread to 3 almost doubles my encoding speed even with b-adapt 2.

My source is 1440x1080 mpeg2 and the decoder is ffdshow's libmpeg2, no postprocessing no avisynth.

[Manao]

The conclusion threads 3 brings no quality loss at all compared to threads 1 is groundless. It's as groundless as the way some subme mode were tuned for speed vs quality/bitrate tradeoff. Those tunings were made taking only PSNR into account, yet they don't bother you. So thread 3 shouldn't either.

Furthermore, 30% speed is a lot. It's around the difference between subme 6 and 8. I think you'd rather use subme 8 + thread 3 than subme 6, wouldn't you ?

[Audionut]

CPU : Intel(R) Core(TM)2 Quad CPU Q6600 @ 3.60GHz
Log for job3 (video, test.avs -> treads6m6.264)
[3/18/2009 10:39:12 PM] Started handling job
[3/18/2009 10:39:12 PM] Preprocessing
Job commandline: "C:\Documents and Settings\Audionut\My Documents\Downloads\x264.r1127M.SSSE3.x32.imk.exe" --crf 18.0 --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --no-chroma-me --trellis 2 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --ipratio 1.3 --pbratio 1.2 --me esa --merange 32 --threads auto --thread-input --aq-strength 0.6 --sar 1:1 --aud --progress --no-psnr --no-ssim --output "E:\treads6m6.264" "E:\test.avs"
[3/18/2009 10:39:13 PM] Encoding started
Standard output stream
Standard error stream
avis [info]: 1280x720 @ 23.98 fps (3037 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Slow_mod4_stack
x264 [info]: profile High, level 4.1

x264 [info]: slice I:25 Avg QP:17.27 size:102773
x264 [info]: slice P:1111 Avg QP:18.73 size: 45105
x264 [info]: slice B:1901 Avg QP:19.99 size: 21329
x264 [info]: consecutive B-frames: 0.9% 28.4% 51.4% 15.7% 3.7%
x264 [info]: mb I I16..4: 2.3% 91.2% 6.5%
x264 [info]: mb P I16..4: 1.1% 15.9% 1.2% P16..4: 43.2% 24.2% 12.3% 0.5% 0.4% skip: 1.3%
x264 [info]: mb B I16..4: 5.0% 0.0% 0.0% B16..8: 41.0% 4.2% 4.2% direct:27.3% skip:18.3% L0:35.9% L1:39.8% BI:24.3%
x264 [info]: 8x8 transform intra:62.2% inter:56.9%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: ref P L0 60.1% 23.3% 9.5% 7.1%
x264 [info]: ref B L0 71.1% 22.5% 6.4%
x264 [info]: ref B L1 95.0% 5.0%
x264 [info]: kb/s:5888.0
encoded 3037 frames, 4.78 fps, 5889.22 kb/s

Log for job4 (video, test.avs -> treads6m9.264)
[3/18/2009 10:49:48 PM] Started handling job
[3/18/2009 10:49:48 PM] Preprocessing
Job commandline: "C:\Documents and Settings\Audionut\My Documents\Downloads\x264.r1127M.SSSE3.x32.imk.exe" --crf 18.0 --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --subme 9 --no-chroma-me --trellis 2 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --ipratio 1.3 --pbratio 1.2 --me esa --merange 32 --threads auto --thread-input --aq-strength 0.6 --sar 1:1 --aud --progress --no-psnr --no-ssim --output "E:\treads6m9.264" "E:\test.avs"
[3/18/2009 10:49:48 PM] Encoding started
Standard output stream
Standard error stream
avis [info]: 1280x720 @ 23.98 fps (3037 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Slow_mod4_stack
x264 [info]: profile High, level 4.1

x264 [info]: slice I:25 Avg QP:17.27 size:105756
x264 [info]: slice P:1111 Avg QP:18.74 size: 46097
x264 [info]: slice B:1901 Avg QP:20.16 size: 20864
x264 [info]: consecutive B-frames: 0.9% 28.4% 51.4% 15.7% 3.7%
x264 [info]: mb I I16..4: 3.0% 91.2% 5.9%
x264 [info]: mb P I16..4: 1.1% 14.3% 1.0% P16..4: 44.6% 25.3% 11.4% 0.5% 0.3% skip: 1.4%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.1% B16..8: 49.7% 3.1% 4.3% direct:11.7% skip:29.7% L0:36.6% L1:50.0% BI:13.4%
x264 [info]: 8x8 transform intra:87.5% inter:76.1%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: ref P L0 61.3% 21.6% 10.1% 7.0%
x264 [info]: ref B L0 79.5% 16.8% 3.7%
x264 [info]: ref B L1 94.8% 5.2%
x264 [info]: kb/s:5906.5
encoded 3037 frames, 3.47 fps, 5907.75 kb/s

Log for job5 (video, test.avs -> treads1m6.264)
[3/18/2009 11:04:23 PM] Started handling job
[3/18/2009 11:04:23 PM] Preprocessing
Job commandline: "C:\Documents and Settings\Audionut\My Documents\Downloads\x264.r1127M.SSSE3.x32.imk.exe" --crf 18.0 --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --no-chroma-me --trellis 2 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --ipratio 1.3 --pbratio 1.2 --me esa --merange 32 --thread-input --aq-strength 0.6 --sar 1:1 --aud --progress --no-psnr --no-ssim --output "E:\treads1m6.264" "E:\test.avs"
[3/18/2009 11:04:24 PM] Encoding started
Standard output stream
Standard error stream
avis [info]: 1280x720 @ 23.98 fps (3037 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Slow_mod4_stack
x264 [info]: profile High, level 4.1

x264 [info]: slice I:25 Avg QP:17.09 size:105314
x264 [info]: slice P:1111 Avg QP:18.73 size: 45037
x264 [info]: slice B:1901 Avg QP:19.95 size: 21512
x264 [info]: consecutive B-frames: 0.9% 28.4% 51.4% 15.7% 3.7%
x264 [info]: mb I I16..4: 2.2% 91.3% 6.5%
x264 [info]: mb P I16..4: 1.0% 15.6% 1.1% P16..4: 43.3% 24.4% 12.4% 0.5% 0.4% skip: 1.3%
x264 [info]: mb B I16..4: 4.9% 0.0% 0.0% B16..8: 41.2% 4.2% 4.3% direct:27.5% skip:17.9% L0:35.9% L1:39.8% BI:24.3%
x264 [info]: 8x8 transform intra:61.9% inter:56.9%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: ref P L0 60.0% 23.3% 9.6% 7.1%
x264 [info]: ref B L0 70.9% 22.7% 6.4%
x264 [info]: ref B L1 95.0% 5.0%
x264 [info]: kb/s:5909.1
encoded 3037 frames, 1.41 fps, 5910.38 kb/s

Log for job6 (video, test.avs -> treads1m9.264)
[3/19/2009 10:09:42 AM] Started handling job
[3/19/2009 10:09:42 AM] Preprocessing
Job commandline: "C:\Documents and Settings\Audionut\My Documents\Downloads\x264.r1127M.SSSE3.x32.imk.exe" --crf 18.0 --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --subme 9 --no-chroma-me --trellis 2 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --ipratio 1.3 --pbratio 1.2 --me esa --merange 32 --thread-input --aq-strength 0.6 --sar 1:1 --aud --progress --no-psnr --no-ssim --output "E:\treads1m9.264" "E:\test.avs"
[3/19/2009 10:09:42 AM] Encoding started
Standard output stream
Standard error stream
avis [info]: 1280x720 @ 23.98 fps (3037 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Slow_mod4_stack
x264 [info]: profile High, level 4.1

x264 [info]: slice I:25 Avg QP:17.09 size:108216
x264 [info]: slice P:1111 Avg QP:18.74 size: 46025
x264 [info]: slice B:1901 Avg QP:20.12 size: 21040
x264 [info]: consecutive B-frames: 0.9% 28.4% 51.4% 15.7% 3.7%
x264 [info]: mb I I16..4: 2.7% 91.4% 5.9%
x264 [info]: mb P I16..4: 1.1% 14.0% 1.0% P16..4: 44.7% 25.5% 11.4% 0.5% 0.3% skip: 1.4%
x264 [info]: mb B I16..4: 0.1% 1.3% 0.1% B16..8: 49.8% 3.1% 4.3% direct:11.7% skip:29.5% L0:36.5% L1:50.1% BI:13.4%
x264 [info]: 8x8 transform intra:87.6% inter:76.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: ref P L0 61.1% 21.7% 10.2% 7.0%
x264 [info]: ref B L0 79.3% 16.9% 3.8%
x264 [info]: ref B L1 94.7% 5.3%
x264 [info]: kb/s:5926.5
encoded 3037 frames, 0.94 fps, 5927.72 kb/s

threads=6 m=9 is 3.7 x faster than than threads=1 m=9.

And I assume the difference would be even bigger for Core i7 and every CPU released for the next few years, with more and more cores added.

Stupid options to use to gain sfa in terms of quality.

--me tesa --refs 16 --bframes 16 --threads 1

[roozhou]

threads=6 m=9 is 3.7 x faster than than threads=1 m=9.


It should be 2.7x faster. And threads 6 m 6 is only 2.3x faster than threads 1 m 6. If you use faster settings, multithreading will be less advantageous.

[nm]

It should be 2.7x faster. And threads 6 m 6 is only 2.3x faster than threads 1 m 6.
For you perhaps, but not generally. It depends on how much time is spent in the input thread. You seem to have a bottleneck there, we don't.

[Manao]

Ok, I'll try one last time before giving up on him. Have a look at that document (http://compression.ru/video/codec_comparison/pdf/x264_options_analysis_08.pdf). It describes a methodology to find optimal speed/quality tradeoffs. I can bet you that all those optimal tradeoffs will use --threads auto (or, at least, not --threads 1), excepted the slowest ones : those that nobody sane will use. For example, -m 9 --me tesa --merange 128 -r 16 --threads 1 will probably be optimal, because the quality it gives couldn't have been reached with --threads auto. But take any sane settings, with --threads 1, and I can bet you I'll find a more optimal one using --threads auto that will - on your E8400 - either give the same quality with a better speed, or a better quality at the same speed.

[roozhou]

I can bet you that all those optimal tradeoffs will use --threads auto (or, at least, not --threads 1), excepted the slowest ones
You are right. I agree that threads 1 is not an optimal setting on multi-core CPUs.

But take any sane settings, with --threads 1, and I can bet you I'll find a more optimal one using --threads auto that will - on your E8400 - either give the same quality with a better speed, or a better quality at the same speed.
Is that "more optimal one" --me tesa, -m9 or -b16 w/ --b-adapt 2?

[Audionut]

If you use faster settings, multithreading will be less advantageous.

Why would you want to use a slow setting with faster settings!!! :confused:

And threads 6 m 6 is only 2.3x faster than threads 1 m 6

Only!!!


So subme 9 is 27% slower than subme 6 and threads 1 is 70% slower than threads auto.

So by your reasoning, I should use faster settings like subme 6 and trellis 1 and b-adapt 1, so that I can make up for the speed loss of using threads 1.

I assume this is correct. Because you seem to have this idea that threads 1 increases quality over threads auto more than all the other options being reduced as above.

[roozhou]

So subme 9 is 27% slower than subme 6 and threads 1 is 70% slower than threads auto.

It depends.
On my E8400 threads 1 is only ~25% slower than threads auto with --b-adapt 2.


So by your reasoning, I should use faster settings like subme 6 and trellis 1 and b-adapt 1, so that I can make up for the speed loss of using threads 1.

I will never use --threads 1 unless I am "insane". I need to find out among these "insane" settings which one is less insane.

Why not figure out a ranklist for x264's least "optimal" settings on a multi-core CPU? Here are the candidates: threads 1, me tesa, subme 9, bframes 16+b-adapt 2 and trellis 2.

[Manao]

A single switch in itself can't be considered optimal or not. It's the combination of switches that makes optimality. --me tesa is slow as hell, but when used together with a high number of ref, a high subme, b-adapt 2 and trellis 2 it makes a coherent configuration (albeit an insanely slow one).

And, apart from --threads and b-adapt 2, no quality/speed switch cares about having multi-core CPUs. b-adapt 2 -b 16 will create a bigger (relatively speaking) slow down on 4 or 8 cores (than on 1 or 2), if - and only if - the other settings are fast. That just means that, on computers with a lot of cores, going from -m 5 --b-adapt 1 to -m 9 --b-adapt 1 might create a better tradeoff than using -m 5 --b-adapt 2 -b 16. But then, perhaps -m 8 --b-adapt 2 -b 3 would be even better.

[_DW_]

Sure is.* (http://stfcc.org/misc/server/)

*I know you said CPU, but I thought this would be a good opportunity to link that. :P

Ahhh.. Those pictures where better than some porn I've seen...