[FFmpeg-devel] default lock mechanism in libavcodec/utils.c
anshul
anshul.ffmpeg at gmail.com
Sat Mar 1 10:27:51 CET 2014
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
More information about the ffmpeg-devel
mailing list