On Wed, 20 Aug 2014 11:32:12 -0400 John Orr <[email protected]> wrote:
> On 8/18/2014 5:22 PM, Patrick Dehne wrote: > > Am 18.08.2014 um 23:10 schrieb wm4 <[email protected]>: > > > >> On Mon, 11 Aug 2014 12:39:02 +0200 > >> Ole Andre Birkedal <[email protected]> wrote: > >> > >>> Hi. > >>> I'm currently developing a multithreaded C++ program using std::thread. > >>> Recently I have been having some crashing issues and it all seems to > >>> related non-thread safety of some function in the FFmpeg API. > >>> > >>> Does there exist an exhausting list of all the function that are not > >>> thread safe? > >> All of them. > > You may want to take a look at the documentation of av_lockmgr_register. > > > Certain ffmpeg open and close functions need to be serialized across all > threads. > > These include avformat_open_input/avformat_close_input and > avcodec_open/avcodec_close. > > By default ffmpeg assumes your app is single threaded and doesn't need > locking, so the underlying "locks" are no-ops. There is a function, > av_lockmgr_register, that allows the app to provide your locking mechanism. > > The docs for avcodec_open/close and avformat_open/close_input do not > mention av_lockmgr_register. It wasn't until I looked through ffmpeg > source code and found the no-op locking mechanism that I found out about > av_lockmgr_register. That gave me something to google for, so I found > some discussions about it, like this one: Like I mentioned in the other email, as long as ffmpeg is compiled with threading, and is recent enough, a default "lock manager" is set. > > http://stackoverflow.com/questions/13888915/thread-safety-of-libav-ffmpeg > > > --Johno > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
