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

[Thomas Guillem]

On Thu, Jul 16, 2020, at 13:43, Alexandre Janniaux wrote:
> Btw, this should probably gets backported to VLC 3.x,
> especially since we cannot change the API and we still
> have the crash there.

+1

But we should have the libvlc_parser and remove the instance from the media  for VLC 4.0

> 
> Regards,
> --
> Alexandre Janniaux
> Videolabs
> 
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel