[vlc-devel] [RFC] (libvlc) playlist changes
filippo at carone.org
Tue Aug 7 00:01:51 CEST 2007
Pierre d'Herbemont ha scritto:
> 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.
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:
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:
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).
> _default() (returns the default media library)
If I understand well, the library, list and list_player are parented in
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.
> _default() (returns the default service discoverer)
> _name() (Such as "SAP", "Bonjour", depending on the plugin)
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.
vlc-devel mailing list
vlc-devel at videolan.org
More information about the vlc-devel