[vlc-devel] [PATCH 1/2] lib: media_player: keep player libvlc instance

Alexandre Janniaux ajanni at videolabs.io
Thu Jul 16 13:43:52 CEST 2020

Btw, this should probably gets backported to VLC 3.x,
especially since we cannot change the API and we still
have the crash there.

Alexandre Janniaux

On Thu, Jul 16, 2020 at 10:49:34AM +0200, Alexandre Janniaux wrote:
> Hi,
> On Wed, Jul 15, 2020 at 07:26:57PM +0300, Rémi Denis-Courmont wrote:
> > Le torstaina 9. heinäkuuta 2020, 18.21.50 EEST Alexandre Janniaux a écrit :
> > > The media_player instance retains and releases the libvlc instance it's
> > > created from. When using a different libvlc instance for media_player
> > > and media,
> >
> > Frankly, it makes zero sense for a media to be tied to an instance in the first
> > place. input_item_t is not tied to an instance. I think you're looking at it
> > from the wrong angle.
> I agree 200% on this, that's also what I suggested when
> discussing this in Videolabs, while suggesting to have
> different object for parsing too, but this patch is mainly
> for fixing VLCKit crashing, not fixing an API design. :)
> I just put a lot of details because the code removed falls
> a little from nowhere, and I haven't found much about the
> mentionned policy, and added a test case because it's
> basically what VLCKit is currently doing and not forbidden
> by the documentation.
> Feel free to suggest any work changing this of course.
> > Of course, an instance is necessary for certain operation on the media:
> > playing, parsing, etc. In all those case, we should do one of the following:
> > 1) implicitly use the instance from the actor object (as media player does)
> > 2) create an instance automatically,
> > 3) take an explicit instance pointer as parameter.
> 2/ is how VLCKit exposes it and it works quite well in the
> VLC for iSO application because we use the same library in
> any case -- meaning the default one.
> However, it raises issues on almost any other application
> which almost everytime need different options for the player
> and such create a different instance than the media.
> Like Thomas, I'm in favor of a dedicated object as it maps
> much better to the design of other objects. In particular,
> I believe it is much easier for the user to look for an
> object that maps the feature it needs, in a uniform way,
> and if I'm not wrong a somehow similar design was planned
> for the transcoding feature too at the last workshop.
> > Creating an instance is very cheap - if there is already at least one in the
> > process so option 2 is actually very viable for simple case like saving
> > metadata.
> >
> > It's also highly desirable where a consistent result is expected/assumed such
> > as preparsing, whose result should depend on media options but *not* on the
> > LibVLC instance.
> Regards,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list