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

[Alexandre Janniaux]

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