[FFmpeg-devel] default lock mechanism in libavcodec/utils.c
Michael Niedermayer
michaelni at gmx.at
Tue Jan 28 16:01:20 CET 2014
On Mon, Jan 27, 2014 at 12:25:32PM +0530, anshul wrote:
> Hi
>
> Problem 1:
> I just wanted to know whether we really need one lock between all different
> codec, for example if I am decoding one h264 and one ogg, does they
> have some
> common resource that we need lock.
ogg can use various codecs, they may need to be opened to get stream
parameters.
do any of them need a lock during init, i dont know, and it doesnt
really matter as nothing can be simplified if the awnser is that
they dont.
>
> can we put the static lock in libavcodec/utils.c in codec context
> structure?
static lock != per context lock
the lock has to be where the data that is shared is
also, IMHO if you are concered that the lock is freed by the OS
at execution end instead of explicitly freed by the application.
work on fixing that. Dont try to redesign the system.
A redesign will have other problems
>
> I dont have lots of knowledge of all codecs, but if any one have
> great Idea how to figure out
> for the common resources that are shared between different codec
> context are welcome.
>
> Problem 2:
> I came at the locking mecanism, after looking for memory leakage of
> pthread_mutex.
> Though it does not effect any single or multithreaded application.
> and I have no idea where
> to destroy pthread_mutex in any existing user function.
>
> but If we had any function avcodec_unregister_all(); or some
> similar thing we could have destroyed
> the mutex threre
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140128/7b610e26/attachment.asc>
More information about the ffmpeg-devel
mailing list