[vlc-devel] [RFC] (libvlc) playlist changes

[Filippo Carone]

Pierre d'Herbemont ha scritto:
> Hello,
>
> I have been struggling a bit in getting playlist to work seemlessly  
> in libvlc, and the Mac OS X Framework goal, but without much success.  
> I wanted to get a clean separation from the playlist data (item code)  
> and the playlist player (engine code).
>
> My conclusion was, it is easier to implement playlist management on  
> top of libvlc. So I poke around and re-implemented a simple  
> hierarchical playlist management within libvlc. And I came to the  
> conclusion that hierarchical playlist was the wrong way to go: It  
> makes the code more hack-ish, and doesn't bring much features.
>
> So far, we can regain hierarchical advantages (that is sorting) using  
> tags. We can even implement hierarchy on top of tags easily.
>
>   

Hi Pierre,
while I can see clearly the problems you are addressing to the current 
playlist implementation, I'm not understanding what you really mean by 
'tag'. This term is quite meaning-overbloated nowadays, so in order to 
be able to really catch your point, I'll make you some questions 
directly on the interface methods.

> Also, jb pointed that it is hard to implement a nice playlist  
> interface from gui code. What is wanted here, is a clean interface  
> for media library, playlists, and service discovery.
>
> Here is one interface proposition:
>
> media_descriptor
> 	_add_tag()
> 	_tags_count()
> 	_tag_at_index()
> 	_event_manager()
>
>   

So a media_descriptor can be decorated by one or more tags, giving the 
ability to classify each media_descriptor in many ways and giving many 
views of the same playlist. Right? The event_manager should be 
responsible for event handling, but I wouldn't expose the manager itself 
as a method, but handle events with a couple of:

add_<specifier>_listener()
remove_<specifier>_listener()

where <specifier> could be one of, 'tag', 'status', etc... Each listener 
is fed with an event object containing all the event specific details. 
This is much what happens when handling UI events.

so that each media_descriptor can have its listener (which can be the 
same object for each media_descriptor).

> media_list
> 	_new()
> 	_retain()
> 	_release()
> 	_add_media_descriptor()
> 	_insert_media_descriptor()
> 	_media_descriptor_at_index()
> 	_media_descriptor_count()
> 	_sublist_with_tags()
> 	_tags_count()
> 	_tags_at_index()
> 	_event_manager()
>
> media_list_player
> 	_new_from_media_list()
> 	_set_media_instance()
> 	_play()
> 	_pause()
> 	_stop()
> 	_event_manager()
>
> media_library
> 	_default() (returns the default media library)
> 	_media_list()
> 	_event_manager()
>
>   

If I understand well, the library, list and list_player are parented in 
this way:

a media_library is the place where all the media_lists are placed; a 
media_list is a collection of media_descriptors; a media_list_player is 
the actor who plays all the media_descriptors of the library it belongs 
to (the _new_from_media_list()). Here too, I would opt to have 
(add|remove)_<specifier>_listener instead of a reference to a manager.

> service_discoverer
> 	_default() (returns the default service discoverer)
> 	_media_discoverer_at_index()
> 	_media_discoverer_count()
> 	_event_manager()
>
> media_discoverer
> 	_name() (Such as "SAP", "Bonjour", depending on the plugin)
> 	_media_list()
> 	_event_manager()
>
>
>   

I don't know anything about the current status of service discovery, so 
I won't discuss it here.

> * (hierarchical) Playlist support would come right away from tags,  
> something like
> 	media_list_sublist_width_tags(media_library_media_list(), "Cool tag");
> would be enough.
>
>   

If I understood it well, I like the overall design, but IMHO having this 
level of flexibility (media_library, media_list + tags) is way too 
overkill for the 'average' application. Exposing these interfaces to the 
world, since it's the aim of libvlc, could confuse developers who want 
to embed media capabilities in apps whose primary focus is not to be a 
media player with all bells'n'whistles (like videolan ;). This said, my 
suggestion is to provide some smart defaults for each object of the 
chain, for example to ease development of apps which need 1 playlist 
with no hierarchies or tags. Perhaps a developer should easily create 
one media_list whose media_descriptors point to local files or remote 
uris, without having to care about all the other objects (or properties) 
of the chain.

> * Item addition/removal/changing could be easily tracked through the  
> new libvlc_event system.
>
> * it's not said in the proposition, but media_list_player won't run  
> in a dedicated thread
>
>   
Does this mean that issuing a _player_play is synchronous?

> This is not a perfect solution:
> - We have to merge libvlc-control.so back into libvlc.so
>   

I don't see this as a bug, but a feature. The general reason of libvlc 
and libvlc-control decoupling is that libvlc.so is not meant to be 
stable over releases (even minor) since it is used only by modules. I 
don't see that reason as a good one, and we should concentrate on being 
more stable and plan apis more seriously (and Pierre's email is a good 
example of this).

> - We might loose some cool abilities we currently have (If one come  
> to your mind, please point it out)
>
>   

I don't see any features drop. While the current libvlc-control is very 
simple and easy to use, it suffers of method invocation asynchronicity 
and lacks a solid event support on all layers: this results in the heavy 
use of polling to get the state of objects and a lot cpu cycles waste 
(besides the unclean coding needed to keep things in sync).

So, to recap, I like the concepts you exposed and I don't see any major 
problems with them. From the bindings and general library usability 
point of view, adding some helper methods with sensible defaults could 
make this solution appealing for any project out there. Sadly the 
current license plans, ie switching to GPL3, do not match well with a 
library and will for sure limit, if not annihilate, its adoption.


Cheers,
Filippo

_______________________________________________
vlc-devel mailing list
vlc-devel at videolan.org
http://mailman.videolan.org/listinfo/vlc-devel