[FFmpeg-devel] libavcodec: inter thread signaling

[Reimar Döffinger]

On Tue, Feb 28, 2012 at 08:35:14PM +0100, Anoop Bhagyanath wrote:
> *my point is "can we not have a dynamic thread management,
>  which basically looks at the number of active threads and spawns a new
> thread everytime it
>  finds num_active_threads < num_cores.

Spawning a new thread means adding one more frame delay.
The FFmpeg API avoids requiring forcing applications to be
able to handle changing decode delay.
Also if your application can handle such a huge decode delay
you can just run FFmpeg -threads 100 or so, the overhead
shouldn't be that large.

> make sure that
>  we give it an entity(frame or slice, frame in this case ), which can be
> definitely decoded

If it can be decoded independently and you always add such a frame when
there is not enough to do you introduce a risk of making FFmpeg strangle
itself.
For example:
You 4 CPUs, 3 threads waiting for one reference frame to finish.
So you start 3 other threads to fill up the CPU, all of them active.
Now the main thread unblocks the waiting threads.
Suddenly you have 7 threads on 4 CPUs, and the threads you spawned
in addition hinder the one thread that is on the critical path.
If now the frame on the critical path is particularly complex,
those extra threads you spawned will maybe finish before and you'll
yet again find more frames to decode in parallel.
In the end you have decoded some video frames 10 seconds in the future
while the one the encoder/user/whatever needs _right now_ has barely
made any progress.
You could probably play with thread priorities to avoid this, but that
is a rather unreliable dark magic (and it doesn't help if e.g. the
issue is cache misses and not raw CPU time).