Hi,
Am 20.08.2013 15:58, schrieb Derek Chow:
> Hi,
>
> FFMpeg usage should use register a lock manager with av_lockmgr_register() so that
> multithreaded use of libavcodec can mutex critical sections and avoid errors such as
> "Insufficient thread locking around avcodec_open/close()" in the FFMpeg plugin.
>
> See attached patch for a suggestion (based on http://code.opencv.org/issues/1369) on
> how this could be addressed.
Good that you address this, but your approach is somewhat dangerous.
Imagine an application, which uses ffmpeg through libquicktime and additionally through
some other library. If you set a global callback from a dynamically loaded module, your
application crashes when avcodec_open() is called from somewhere else *after* the lqt
module was unloaded.
AFAIK the global locking is needed because libavcodec uses some global variables, mostly
tables, which are runtime generated. The cleanest way to solve this would be a global mutex
inside libavcodec. This way, the application programmer wouldn't have to care at all.
Another (less clean) solution could be a global mutex within libquicktime, accessible e.g.
via functions like lqt_ffmpeg_[un]lock(). If you make sure that on every call to
avcodec_open*() and avcodec_close*() the global mutex is locked, concurrent calls to
avcodec_open() from within libquicktime are save. Concurrent calls from lqt and another library
can IMO only be protected with a mutex inside libavcodec as said above, especially when
applications make heavy use of dynamic modules.
Burkhard
|
