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

[Alexandre Janniaux]

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

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