[Libav-user] FFmpeg thread safety

wm4 nfxjfg at googlemail.com
Wed Aug 20 18:42:14 CEST 2014


On Wed, 20 Aug 2014 11:32:12 -0400
John Orr <john.orr at scala.com> wrote:

> On 8/18/2014 5:22 PM, Patrick Dehne wrote:
> > Am 18.08.2014 um 23:10 schrieb wm4 <nfxjfg at googlemail.com>:
> >
> >> On Mon, 11 Aug 2014 12:39:02 +0200
> >> Ole Andre Birkedal <o.birkedal at sportradar.com> 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
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user



More information about the Libav-user mailing list