[FFmpeg-devel] default lock mechanism in libavcodec/utils.c

anshul anshul.ffmpeg at gmail.com
Thu Mar 6 10:11:34 CET 2014


On 03/01/2014 02:57 PM, anshul wrote:
> On 02/19/2014 01:52 PM, anshul wrote:
>> On 02/18/2014 10:02 PM, Michael Niedermayer wrote:
>>> On Wed, Jan 29, 2014 at 11:49:41AM +0530, anshul wrote:
>>>> On 01/29/2014 11:11 AM, anshul wrote:
>>>>> On 01/28/2014 08:31 PM, Michael Niedermayer wrote:
>>>>>> if you had avcodec_unregister_all() you will have to deal with
>>>>>> libgstreamer and libvlc calling it while your app is also
>>>>>> calling it and maybe another lib calling register and yet another
>>>>>> still using avcodec. all happening at the same time
>>>>>>
>>>>>> this can be solved in various ways, a lock and reference counting is
>>>>>> one, another is to use some code that gets called on exit or
>>>>>> lib unloading by the OS.
>>>>>> I think none of these will be really easy to do portably
>>>>> If I am planning to use some code that gets called when library is
>>>>> unloaded.
>>>>> I do need static avcodec lock acess out of library, I have
>>>>> attached one patch
>>>>> so that user might be able to call this function in his destructor
>>>>> of library
>>>>>
>>>>> But your idea about reference count is very good, but I don't
>>>>> where to keep that
>>>>> reference count variable, only thing that strike my mind was to
>>>>> make reference count variable global.
>>>>> If you have any other way then making it global please ...
>>>>>
>>>>>
>>>>> Thanks
>>>>> Anshul
>>>>>
>>>>>
>>>> forgot to add return 0; my new patch with same thing
>>>>
>>>> Thanks
>>>> Anshul Maheshwari
>>>>   internal.h |    1 +
>>>>   utils.c    |    8 ++++++++
>>>>   2 files changed, 9 insertions(+)
>>>> 47599b4e3f49bde9a68d3e398958472e4b18b61f  0001-added-ff_destroy_lock_avcodec-so-that-it-can-be-call.patch
>>>>  From 731dd24ba9b138f626baa9908fdb67f74ef64fe5 Mon Sep 17 00:00:00 2001
>>>> From: Anshul Maheshwari<er.anshul.maheshwari at gmail.com>
>>>> Date: Wed, 29 Jan 2014 11:39:11 +0530
>>>> Subject: [PATCH] added ff_destroy_lock_avcodec so that it can be called by
>>>>   user if they want to free the mutex
>>>>
>>>> ---
>>>>   libavcodec/internal.h | 1 +
>>>>   libavcodec/utils.c    | 8 ++++++++
>>>>   2 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>>>> index 8aa0ac1..2c85b7b 100644
>>>> --- a/libavcodec/internal.h
>>>> +++ b/libavcodec/internal.h
>>>> @@ -151,6 +151,7 @@ void avpriv_color_frame(AVFrame *frame, const int color[4]);
>>>>   extern volatile int ff_avcodec_locked;
>>>>   int ff_lock_avcodec(AVCodecContext *log_ctx);
>>>>   int ff_unlock_avcodec(void);
>>>> +int ff_destroy_lock_avcodec(void);
>>>>   
>>>>   int avpriv_lock_avformat(void);
>>>>   int avpriv_unlock_avformat(void);
>>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>>> index c8fd8c6..20cc00b 100644
>>>> --- a/libavcodec/utils.c
>>>> +++ b/libavcodec/utils.c
>>>> @@ -3318,6 +3318,14 @@ int ff_unlock_avcodec(void)
>>>>       return 0;
>>>>   }
>>>>   
>>>> +int ff_destroy_lock_avcodec(void)
>>>> +{
>>>> +    if(lockmgr_cb) {
>>>> +        if (lockmgr_cb(&codec_mutex, AV_LOCK_DESTROY))
>>>> +            return -1;
>>>> +    }
>>>> +    return 0;
>>>> +}
>>> ff_ prefixed functions are internal  and considering its in internal.h
>>> maybe thats what you intended but nothing calls it so this is just
>>> unused and undocumneted code.
>>> and if it wasnt internal people wouldnt know when or from where to
>>> call this without documentation
>>>
>>> also the function name should make it clear that it is unsafe to be
>>> called when anything is still running or might use the lib afterwards
>>> maybe
>>> av_cleanup_on_lib_unload()
>>> would be a better name for that ...
>>>
>>>
>>> [...]
>>>
>>>
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> New Patch is attached
>>
>> I have done some doxygen kind of Documentation for function 
>> av_cleanup_on_lib_unload()
>> I have called ff_destroy_lock_avcodec inside 
>> av_cleanup_on_lib_unload, since I am still looking for
>> reference counting idea over there i would require function 
>> ff_destroy_lock_avcodec.
>>
>> If anyone know some good example application where it use or require 
>> the libavcodec locks are welcome, i am unable to undestand the lock 
>> mecanism atleast with ffmpeg.
>>
>> If anyone know of any utility which show locking diagrammatically 
>> because I have a fear that I would miss some scenario while 
>> considering all.
>>
>> Thanks
>> Anshul Maheshwari
> ping
ping


More information about the ffmpeg-devel mailing list