[Libav-user] Multithreaded decoding of multi-program transport streams

[Andrey Utkin]

2013/12/3 Michael Chisholm <chisholm at mitre.org>:
> On 12/3/2013 2:36 AM, Antoine Martin wrote:
>> Can someone please clarify for me when using "av_lockmgr_register" is
>> required as I am not 100% sure I understand: on what types of builds
>> (win32threads? pthreads? all?) and under what circumstances? (encoders,
>> decoders, both? type of streams?)
>> Maybe it's always required and we've just not really hit the problem yet
>> because we don't use multi-clients often.. (each client gets its own
>> encoding thread). And multiple contexts from the same thread works just
>> fine.
>>
>
> I can't give an official answer, but awhile back during development of my
> tool, I started seeing warning messages from ffmpeg about insufficient
> locking.  I looked into the source and I remember there was a simple check:
> a counter incremented on entry to a function, and decremented on exit.  If
> the counter ever went greater than 1, the warning was generated.  It's a
> simple concurrency check, independent of thread library.  That led me to the
> av_lockmgr_register() function, which I used to make the warning go away.
>
> I peeked into the ffmpeg source again, and I see it being used in
> avcodec_open2(), as an example.  The doxygen docs say that function is not
> thread safe, but it appears to have some locking code which could make it
> thread-safe as long as you've registered a locking function. See
> libavcodec/utils.c.

That's user-settable callback function to avoid implementing locking
for all supported platforms inside of libavcodec. Used nearly the only
thing - opening new AVCodecContext.

-- 
Andrey Utkin