[vlc-devel] [RFC] design issue related to resources (input)

Laurent Aimar fenrir at elivagar.org
Thu Jun 3 14:58:46 CEST 2010


On Thu, Jun 03, 2010 at 02:00:31PM +0200, brezhoneg1 wrote:
> Recent change in git master have brought a regression with skins2, that may
> point out a deeper design issue and wider questions.
> Test case for regression
> - start 'vlc -I skins --no-video'
> - play an item
> - quit vlc (while playing is underway)
> vlc then crashes in input_resource_HoldAout with :
> LibVLC fatal error locking mutex (22) in thread 29236 at misc/pthread.c:223 in
> vlc_mutex_lock
> which means that we try to use an already deallocated mutex  (the lock_hold for
> resource)
> Note that --no-video is important in this test case. Otherwise, resource seems
> to be kept accessible longer, and no crash occurs.
> Cause for the problem
> Actually, during playlist deactivation, the current input thread is joined, the
> input object is released and resource is deallocated. Yet, the input object is
> still held by some other parts of vlc (the skins2 interface and the qt4 dialog
> provider) , and resource is a key part of the input object for input_GetAout,
> input_GetVout, .... helper functions to succeed.
 I will quickly fix this issue. Thanks for the report.

> Wider Reflection
> >From the perspective of an interface developer, the vlc core may be a bit
> complicated.  We need to retrieve the playlist object, then successive inputs,
> then aout or vout to add callbacks on all of them. Since aout/vout reuse, it is
> even trickier in a sense that not all variables are reset on a per input basis
> (see the audio equalizer). I always wondered why a single object (playlist,
> media player for libvlc or vlm manager) would not host all exported variables
> worth of interest for interface. Actually, aout/vout or successive inputs for a
> playlist should be kept as an internal implementation, not something interface
> developers must be aware of. Because of all these different objects, interfaces
> need to retain references or retrieve them with input_GetAout .... to properly
> remove callbacks. That may actually conflict with the way vlc core wishes to
> deallocate things. If interfaces were to handle only a single object, then all
> the complexity would be mutualized in a single place (at vlc core), instead of
> in all interfaces (qt4, skins, ....). This single object (playlist, media
> player, vlm manager) could be just a proxy for the already existing input/aout/
> vout objects and related variables.
 I do aggree that an input manager should be implemented. But it's a lot of work
with some tricky parts (like multiple vout/aout supports, configurations, API...).
 I am not interested to work on it for the moment. Dunno if someone feels up to the
task, knows the core and requirements and is motivated enough.


More information about the vlc-devel mailing list