[FFmpeg-devel] default lock mechanism in libavcodec/utils.c
anshul
anshul.ffmpeg at gmail.com
Wed Feb 19 09:22:37 CET 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-function-to-clean-up-libavcodec-library-locks.patch
Type: text/x-patch
Size: 2221 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140219/81b9b06b/attachment.bin>
More information about the ffmpeg-devel
mailing list