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

[Michael Niedermayer]

On Mon, Nov 15, 2010 at 10:50:29PM -0500, Alexander Strange wrote:
> 
> On Nov 15, 2010, at 1:30 PM, Alexander Strange wrote:
> 
> > 
> > On Nov 15, 2010, at 12:56 PM, Alexander Strange wrote:
> > 
> >> 
> >> On Nov 15, 2010, at 12:20 PM, Reimar D?ffinger wrote:
> >> 
> >>> 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.
> >> 
> >> This can be done but I think it would seriously compromise speed (from the client's point of view).
> >> libavcodec would have to block the client thread by waiting for the codec to message back to it asking
> >> for the buffer callback to be called. That's clock time that could be spent in the client code doing something useful.
> >> 
> >> The problem here is just that I used "thread-safe", which doesn't mean anything, instead of the real requirement,
> >> which is that it can't use thread-local variables. Nothing to do with reentrancy or locks.
> > 
> > Sorry, uau pointed out I'm wrong here. The thread can call the client's get_buffer() while the main thread is running client code, and obviously then it can do something unsafe.
> > 
> > The extra-safe option is to make frame threading opt-in, so committing it will never break anyone's client unless they turn it on. I don't mind that, but clients not paying attention might forget to add the code.
> > 
> > Another option would be to block the client thread until it's done with buffer operations, but allow clients to declare their callbacks completely thread-safe and get out of that for some more speed. Either way they'd still have to avoid thread-local data, but I think that's not a problem.
> 
> Actually, pretty sure this is impossible in general. We can't know when the thread will be done calling get_buffer() (codecs can do it more than once, unless we just forbid them from having weird calling patterns), and obviously it defeats the point of MT if we wait forever.

if the whole code depends on pthreads anyway then you can just put a mutex in
AVCodecContext, set by the user.
If its NULL frame multithreading has to be disabled, it cant work that way ...
If its non NULL, get/release_buffer() calls would be protected by that mutex
in lavc and the user would use the same mutex around buffer management outside
lavc as well

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101117/2043db96/attachment.pgp>