On 12/3/2013 2:36 AM, Antoine Martin wrote:
I use multiple encoders, in my case, simultaneously in different
threads, and it works fine. I think decoders should work fine too.
One thing I do is register a custom locking function via
av_lockmgr_register() just in case some bit of internal library code
wants to serialize threads through a critical section.
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.
Andy
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
