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

[Alexander Strange]

On Mon, Nov 15, 2010 at 10:50 PM, Alexander Strange
<astrange at ithinksw.com> 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.

My experiment failed- I can't use mplayer's vo_corevideo or vo_gl +
secondary threads + direct rendering without some code changes. After
some thought I see no reason _not_ to forbid strange calling patterns
inside the codec, so I'll try the safe way after all. Players can be
thread-safe to gain (even more) speed later when they need to.

I'll apply the other patches after this one is ready, they don't
really provide any benefit on their own.