[FFmpeg-devel] [PATCH 1/6] Frame-based multithreading framework using pthreads

[Reimar Döffinger]

I'd still prefer for the threading being hidden from the application,
in particular no new requirements on get/release_buffer, but
I fear I'm not going to win that argument.

On Mon, Nov 15, 2010 at 08:37:01AM -0500, Alexander Strange wrote:
> +* The client's get_buffer() and release_buffer() must be thread-safe as well.

Here be dragons. You can't require thread-safety without defining what
a thread is. And no, that is not obvious, while in most cases only
one definition is in significant use per OS, there are kernel-level,
user-level, m:n mapped, (Java) Virtual Machine threads etc.,
and their is not reason the locking/thread-safety mechanism of the
application will work for FFmpeg.
So at the very least this would require functions to achieve that
thread-safety as well (it would also make things simpler for any
application that wants to profit of FFmpeg-multithreading without
using it itself since it does not need bothering to find and link
against an appropriate threading library itself etc.).

> +* There is one frame of delay added for every thread beyond the first one.
> +  Clients using dts must account for the delay; pts sent through reordered_opaque
> +  will work as usual.

Is there a way to query this? I mean the application
knows how many threads it set, but that might not always
be the same number as FFmpeg uses or so?