[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