[vlc-devel] [PATCH v2 1/3] Introduce media source and media tree API

Romain Vimont rom1v at videolabs.io
Tue Jun 26 14:15:29 CEST 2018

On Tue, Jun 26, 2018 at 11:39:04AM +0300, Rémi Denis-Courmont wrote:
> Le lundi 25 juin 2018, 13:09:24 EEST Jean-Baptiste Kempf a écrit :
> > On Fri, 22 Jun 2018, at 21:21, Rémi Denis-Courmont wrote:
> > > Nack. We already have an SD abstraction and so far I have not seen a
> > > justification for replacing it. Hence adding any new VLC object
> > > derivative seems wrong.
> > 
> > I don't understand.
> > Are you against the media_source, media_source_provider or the
> > media_tree part?
> The design rationale is to get rid of the playlist. That only explains why 
> media-tree is needed, which replaces the playlist, the playlist lock and the 
> input item callbacks.

Yes, that was the main point.

> It does not explain why you need anything else.

You get a point: I failed to explain the rationale of the remaining.
Here is an attempt to fix this.

Several interfaces (qt, macosx) do the same work:
 - open SDs;
 - listen to SD, and add/remove items on SD events;
 - listen to input (preparsing), and add items on events;
 - close SD.

One initial idea of media source/tree was to factorize this common work,
and expose a "higher level" API: the exposed tree contains both item
detected by SD and added by preparsing.

In addition, to avoid to open the same SD several times by several
clients/interfaces, I added a single "media source provider" (bad name,
but I did not manage to get a better one yet), child of the libvlc
object, which allows to retrieve (refcounted) media sources (it handles
SD open/close automatically). Thus, several client may use the same
media source instance, holding a tree containing media detected by the
same "services discovery".

The clients may connect callbacks at any time (i.e. not necessarily on
SD open), without "missing" events.

More information about the vlc-devel mailing list