2013/12/3 Michael Chisholm <chish...@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 _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user