What is the maximum number of threads in x264?

[Jamaika]

I know that the x264 codec isn't improved. The codec is in use though.
I'm interested in the topic of correctly adding the default number of threads in x264 for the i5 13600K processor. For me x264 adds threads=30. Doesn't it overstate?

https://code.videolan.org/videolan/x...30973295c87aca

[microchip8]

Amount of threads is, IIRC, 1.5x num of CPU. You should just use 'auto' and don't bother.

[Jamaika]

My question is for auto 30 threads. Is this value from outer space and heats the processor until I finally burn it? For vvenv, xeve there are protections up to 12 threads.
resolution < 720p: 4, < 5K 2880p: 8, >= 5K 2880p: 12 threads

https://www.intel.com/content/www/us...fications.html
For 13600K total threads 20

For x265 is:
x265 [info]: Thread pool created using 20 threads

[microchip8]

It's not out of space. There's a formula behind it. I recall back in the days Dark Shikari explained it once how the amount is calculated but I can't find it no more :/

[jpsdr]

If i remember properly, the max = height/40.
Another thing i vaguely remember, it wasn't also recommended to have more than 20, as above there is a several quality drop.

[Jamaika]

Originally Posted by jpsdr

If i remember properly, the max = height/40.
Another thing i vaguely remember, it wasn't also recommended to have more than 20, as above there is a several quality drop.

Impossible. For my video 1920 divided by 40 is 48.

[FranceBB]

You may wanna take a look at my post from earlier on this year: https://forum.doom9.org/showthread.php?p=1999533
Jean Philippe was spot on then and is spot on now:

Originally Posted by jpsdr

max = height/40.

In my example, I was encoding a UHD source, so 3840x2160 which means 2160:40 = 54 maximum threads and sure enough if you count all the "boxes" you get 54:




We can make a little list here:

720x480 = 480/40 = 12 maximum threads (SD NTSC)
720x576 = 576/40 = 14 maximum threads (SD PAL)
1280x720 = 720/40 = 18 maximum threads (HD)
1920x1080 = 1080/40 = 27 maximum threads (FULL HD)
3840x2160 = 2160/40 = 54 maximum threads (UHD)


To me, however, more than the lack of ability to scale on multiple cores/threads, the biggest downside is the lack of AVX512 which are there for x264 8bit but are missing for x264 10bit.

[Jamaika]

Originally Posted by FranceBB

To me, however, more than the lack of ability to scale on multiple cores/threads, the biggest downside is the lack of AVX512 which are there for x264 8bit but are missing for x264 10bit.

Thanks for the answer. Now it's more correct, although x264 adds 30 threads and not 27. Correct or incorrect? Should max threads be added?
X264 is an old codec that only has AVX512F. I think AVX10 is already there.
Free OpenCL has also been abandoned.

[FranceBB]

Opencl is still supported as per x264 8bit and you can still compile x264 with support for it. I use it with --opencl all the time. The problem is that once again that's only for the 8bit version as it never made its way into the 10bit version (and probably never will).

[Jamaika]

True but X264 OpenCL doesn't support the motherboard and is at version level 1.2.

[Z2697]

Originally Posted by Jamaika

My question is for auto 30 threads. Is this value from outer space and heats the processor until I finally burn it? For vvenv, xeve there are protections up to 12 threads.
resolution < 720p: 4, < 5K 2880p: 8, >= 5K 2880p: 12 threads

https://www.intel.com/content/www/us...fications.html
For 13600K total threads 20

For x265 is:
x265 [info]: Thread pool created using 20 threads

Use more therads than "physical" threads won't burn you CPU more than "1:1 threads".

Also I don't think that 12 threads thing is protection.

[Jamaika]

Originally Posted by Z2697

Also I don't think that 12 threads thing is protection.

Xeve gives max 8 threads. Where does this preventiveness come from?
I read and read. I wasn't interested when I had old processor 4 threads that x264 gives 6. Today I find out that vvenc is tested only for 8/12 threads because otherwise other functions may work incorrectly and be e.g. fps incompatible.

How is compatibility for x264/x265 with max thread 30? 10 years ago it was not possible to add 30 threads.

[Z2697]

Originally Posted by Jamaika

Xeve gives max 8 threads. Where does this preventiveness come from?
I read and read. I wasn't interested when I had old processor 4 threads that x264 gives 6. Today I find out that vvenc is tested only for 8/12 threads because otherwise other functions may work incorrectly and be e.g. fps incompatible.

How is compatibility for x264/x265 with max thread 30? 10 years ago it was not possible to add 30 threads.

They are limitations, I guess. Either lacking the implementation of atuomatically choose thread count based on "physical threads" or lacking enough parallel capability.

High core count CPUs did exist 10 years ago, but less common. I know some people prefer to limit the threads in x264 to 16 and use multiple concurrent encoding sessions to utilize the rest of total threads, but that just their personal preference, there's no major downside to use more threads.

[microchip8]

Do note that x264 is not very effective at utilizing so many threads. I have a 12c/24t CPU and even though x264 runs with 25 threads on it, the cores/threads are not fully pegged at 100%. I get more like 80-85% utilization per core/thread. Also, the more threads you throw at it, there will be a small decrease in quality.

[Z2697]

Originally Posted by microchip8

Do note that x264 is not very effective at utilizing so many threads. I have a 12c/24t CPU and even though x264 runs with 25 threads on it, the cores/threads are not fully pegged at 100%. I get more like 80-85% utilization per core/thread. Also, the more threads you throw at it, there will be a small decrease in quality.

I tried the "more thread less quality" with x265 and found "not quite".
The situations which make difference are:
1) pools < 4 / pools >= 4
2) frames-threads = 1 / frame-threads > 1
3) no-wpp / wpp
For pools and frame-threads, the number beyond the upper bound (4 and 1 respectively, as above) don't seem to impact any quality.

I might find some time to test x264 as well.

[microchip8]

The loss is there, you just can't see it. It's not like it loses so much quality that it's blatently visible.

[Z2697]

Originally Posted by microchip8

The loss is there, you just can't see it. It's not like it loses so much quality that it's blatently visible.

For x265 the results which I referred as "don't impact quality" are bitexact if --no-info is used.
The loss is not there.

But for the "make difference" situations, you are correct, the loss is very small, very hard to see.

[microchip8]

I was talking about x264, since this thread is about x264. And the quality drop due to very many threads doesn't come from my mouth but from a past main dev of x264, Dark Shikari.

[Z2697]

The source is 3840x2160 video scaled from 1920x1080 'cause it's just for testing
(How to limit the [IMG] display size?)

[Jamaika]

Thanks for the test. I understand that there is no difference in speed between thread 48 and 64. What is processor? What does adding the graphics card opencl option do?

The 30 threads option is therefore recommended for editing movies.