x264 --threads=x seems to be ignored

[graysky]

I've been looking at encoding efficiency as a function of threads using the following. What I'm noticing is that on my quad core (no hyperthreads), values >8 have no effect of throughput, encode time, or video quality. This cannot be... can it?

Threads

Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)

Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.

x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.

For example, I used a value of 6, 8, 32, 128 and all metrics were the same. Am I not calling the threads switch correctly?

$ x264 --preset medium --ssim --psnr --level=4.1 --threads=x -o /dev/null 23sec-720p60.m2ps

Example:
Threads/Encode Time
6 / 48 sec
8 / 44 sec
16 / 44 sec
32 / 44 sec
128 / 44 sec

Log:
$ x264 --preset medium --ssim --psnr --level=4.1 --threads=20 -o /dev/null 23sec-720p60.m2ps
lavf [info]: 1280x720p 1:1 @ 60000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.1
x264 [info]: frame I:11 Avg QP:22.64 size: 66218 PSNR Mean Y:44.37 U:47.20 V:49.11 Avg:45.28 Global:44.99
x264 [info]: frame P:687 Avg QP:26.24 size: 18376 PSNR Mean Y:46.05 U:48.49 V:50.38 Avg:46.86 Global:44.94
x264 [info]: frame B:679 Avg QP:26.78 size: 5293 PSNR Mean Y:40.54 U:44.49 V:47.35 Avg:41.66 Global:41.42
x264 [info]: consecutive B-frames: 19.4% 39.4% 15.7% 25.6%
x264 [info]: mb I I16..4: 5.7% 89.1% 5.2%
x264 [info]: mb P I16..4: 2.4% 13.8% 0.2% P16..4: 43.2% 11.3% 5.9% 0.0% 0.0% skip:23.2%
x264 [info]: mb B I16..4: 0.1% 0.6% 0.0% B16..8: 33.2% 2.0% 0.6% direct: 3.7% skip:59.8% L0:37.7% L1:58.5% BI: 3.8%
x264 [info]: 8x8 transform intra:84.5% inter:84.5%
x264 [info]: coded y,uvDC,uvAC intra: 68.1% 66.8% 10.1% inter: 22.3% 19.3% 0.5%
x264 [info]: i16 v,h,dc,p: 24% 20% 14% 42%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 17% 30% 6% 5% 5% 6% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 21% 17% 8% 8% 7% 7% 8% 7%
x264 [info]: i8c dc,h,v,p: 60% 20% 17% 3%
x264 [info]: Weighted P-Frames: Y:1.0% UV:0.1%
x264 [info]: ref P L0: 59.6% 16.9% 16.0% 7.4% 0.1%
x264 [info]: ref B L0: 87.0% 12.0% 1.0%
x264 [info]: ref B L1: 94.6% 5.4%
x264 [info]: SSIM Mean Y:0.9762474 (16.243db)
x264 [info]: PSNR Mean Y:44.509 U:47.372 V:49.535 Avg:45.406 Global:43.642 kb/s:3327.14

encoded 1377 frames, 37.36 fps, 3327.14 kb/s

[nurbs]

Why would you expect that more than 8 threads would improve your encoding performance? You get more threads, but your cores are already saturated, so no extra performance, plus there is an overhead to using more threads.
Since you are not using VBV or --non-deterministic the encodes should also be identical AFAIK, so no problem there either.

You can also use mediainfo to check how many threads were used, assuming you trust x264 to write the right values.

[sneaker_ger]

He probably expects encoding time to increase and quality to decrease.

[graysky]

He probably expects encoding time to increase and quality to decrease.

That's what I was looking to see since the overhead of all those extra threads should be reflected in the efficiency somewhere (time or quality). At least, that is my hypothesis but I'm not seeing it in the data and am questioning my experiment design.

EDIT: You'd think that, but according to my tests, there is no statically significant difference encode speed wise between threads of 6-64 using kernel 2.6.38.2 with the ck3 patchset (Brain Scheduler v0.400 (http://ck-hack.blogspot.com/2011/04/bfs-0400.html)):
http://img29.imageshack.us/img29/7954/screenshot1geq.png

Y-axis is total encode time; average of three runs per thread (x264-t06 is --threads=6 and x264-t12 is --threads=12, etc.).

Here is how you read that boxplot:
http://img824.imageshack.us/img824/1856/comparisoncircles1.png
http://img850.imageshack.us/img850/5746/comparisoncircles2.png
http://img402.imageshack.us/img402/1710/comparisoncircles3.png

[ajp_anton]

Try " " instead of "=".
--level 4.1 --threads x

[graysky]

Try " " instead of "=".
--level 4.1 --threads x

Same effect. Plus, mediainfo shows the corresponding threads values I used.

[kieranrk]

Input bottlenecked probably.

[Dark Shikari]

x264 limits the motion vector range between each thread, so past a point you won't be able to get any more threads running at once even if there's nominally more threads created.

[graysky]

x264 limits the motion vector range between each thread, so past a point you won't be able to get any more threads running at once even if there's nominally more threads created.

OK! This explains why overloading threads up to 64 does not seem to affect efficiency which is counterintuitive. Edited thread #4 by the way.