[FFmpeg-devel] [PATCH] avcodec thread safety fix

Daniel Steinberg daniel
Wed May 13 01:08:55 CEST 2009


2009/5/12 M?ns Rullg?rd <mans at mansr.com>:
> Daniel Steinberg <daniel at InstantHarmony.com> writes:
>
>> 2009/5/12 M?ns Rullg?rd <mans at mansr.com>:
>>> Daniel Steinberg <daniel at InstantHarmony.com> writes:
>>>
>>>> Although avcodec_open/avcodec_close are known to have thread-safety
>>>> issues (hence the entangled_thread_counter), it is not sufficient in a
>>>> multi-threaded environment to simply protect calls to them with a
>>>> mutex, because av_find_stream_info() internally calls them as well.
>>>> Further, av_find_stream_info() may subsequently block for input, so it
>>>> is not a good idea to hold a mutex for the duration of its call.
>>>>
>>>> Attached is a proposed fix that allows clients to specify a locking
>>>> routine that, if non-NULL, will be called by avcodec_open() and
>>>> avcodec_close(), thereby protecting them from re-entrancy regardless
>>>> of the calling source.
>>>
>>> Your patch does not solve the problem you describe. ?How would the
>>> callback get set for the calls from av_find_stream_info()?
>>
>> It is up to the caller to set the callback(s) before calling
>> av_find_stream_info() (and, of course, avcodec_open/close), eg:
>>
>> int MyFindStreamInfo(AVFormatContext *ic) {
>> ? for (int i = 0; i < ic->nb_streams; ++i) {
>> ? ? ic->streams[i]->codec->codec_mutex_cb = MyMutexCallback;
>> ? }
>> ? return av_find_stream_info(ic);
>> }
>
> That won't work. ?Streams can be added within an av_find_stream_info() call.

So, one alternative would be to add a similar field to
AVFormatContext, and propagate it to the AVCodecContext in
av_new_stream().  It could also be propagated to all codec contexts in
av_find_stream_info().

Got a better suggestion?



More information about the ffmpeg-devel mailing list