Transcoding Thread Count doesn't do anything

[Maldark 1]

ffmpeg-transcode-e055ac46-a03f-4993-9ef9-bb46b44084f7_1.txtIt doesn't seem to matter what I set the Transcoding Thread Count to, it always utilises all 12 threads on my 6 core 12 thread CPU.

embyserver.txt ffmpeg-transcode-e055ac46-a03f-4993-9ef9-bb46b44084f7_1.txt

[ebr 16187]

@softworkz

[Maldark 1]

I had a quick peek in the logs and it appears the setting is going through to FFMpeg it's just not doing anything.... Is this an issue with FFMpeg and maybe not directly with Emby? Did they update their instructions or something?

[ebr 16187]

I think it is most likely just a mis-understanding of exactly what that setting does so I called softworkz into this conversation to explain.

Thanks.

[softworkz 5072]

Not all encoders and decoders support multi-threading, so this may have an effect in some cases but in others it won't change anything.

[ebr 16187]

14 hours ago, softworkz said:

Not all encoders and decoders support multi-threading, so this may have an effect in some cases but in others it won't change anything.

We need to note that in a comment under the setting I guess...

[Luke 42082]

On 6/12/2020 at 10:01 AM, ebr said:

We need to note that in a comment under the setting I guess...

I'm adding that.

[softworkz 5072]

Actually we need to re-think and re-work that parameter because there's another caveat:

The way we're specifying it right now will apply it to the first decoder only. That can be a video or an audio decoder, depending on which stream comes first and is actually being decoded (and not copied). It will never be applied to encoders when it's positioned before the input file.

We can not simply apply it to all decoders and encoders equally because that could have adverse effects. It's once again a matter which is much more involved than it looks at first sight...

I haven't touched it yet, because in its current form it can't do much harm at least

[rbjtech 5284]

I've never understood the logic behind this anyway tbh.

The more important factor is what Priority the task is vs how many threads it will use ?

If the idea is to protect ffmpeg from hogging all the threads on a 4K transcode for example - then surely it is better to simply set that task priority to very low - ie use them if they are free, if not then any other task will use the thread instead.  This is what I do whenever I am encoding, that way you do not notice the heavy CPU use on your normal (higher priority) tasks - of course, if other services are being hit (disk is the primary one) then there is not a lot you can do about that as they are generally FIFO/Queued.

 

 

 

 

Edited June 16, 2020 by rbjtech

[Riggs 312]

On 6/11/2020 at 11:04 AM, Maldark said:

ffmpeg-transcode-e055ac46-a03f-4993-9ef9-bb46b44084f7_1.txtIt doesn't seem to matter what I set the Transcoding Thread Count to, it always utilises all 12 threads on my 6 core 12 thread CPU.

 

In my case with that same configuration I only can use one thread    -->both on Linux.

The remote server--> Xeon E31230 @ 3.20GHz Ubuntu Server. Local server-->  i7-7700k - OMV5 over Debian Buster. None have nvidia or amd graphics card.

 

[Riggs 312]

Before publish the tread above, i did the test with maximun and 4 threads, but the result was the same.

Edited June 16, 2020 by Riggs

[Luke 42082]

Have our answers here helped?