A quick run of --encoder-stats suggest that the encoder threads are spending 0000064:0000060% of the time asleep.

--queue and a grep of encoder-wake suggest the queue is always very small.

I guess this might need the butler to be used for the DCP transcode so that the ::prepare()s can be done in separate threads.

Maybe we can check to see if this user can reproduce the benchmarks.

It's weird that we have nice benchmark results for both a Threadripper 1950 and a Xeon Gold , but then two reports of very poor performance with similar CPUs...

Maybe they should check with 2.14.x or 2.12.x?

As CPUs with many more cores become now 'standard', wondering wether it would be useful to have more logging/timing options to analyze issues?

• Carsten

Emailed op to see if he's still having problems.

I guess this might need the butler to be used for the DCP transcode so that the ::prepare()s can be done in separate threads.

I can't see (any more) how this would help...! The only immediate idea I have is multiple encoders, each doing a reel. Sample-aligning them is a bit scary though. Although it is a bit weird that even on 48-core VMs we are seeing under-use of encoding threads but only 30-ish fps encoding; surely one core of those machines can decode a video at >30fps? Or maybe not...

Need to check what the decoder thread is doing and make sure there's nothing that could be moved out.