elthariel/vlc-media-center.md

## vlc-media-center.md

      
    Raw
  

              vlc-media-center.md
            
          
    Medias Center Design Document

Introduction


In this document i'll gather thoughts, use cases, design ideas about refactoring
(and hardly simplifying) the VLC playlist code, as well as adding a new separate
subsystem for handling media discovery, browsing and searching features.
Any constructive comment (below or as a fork) is highly welcome and will be
discussed and/or  integrated. Any troll or disrepectfull comment will place
shame on the family of the author for approximatively 2.1 decades.
Why ?

This work started because media discovery and browsing in VLC currently sucks
pretty hard. This is my own opinion bu it seems to be shared, at least, by a few
regular contributors of the project. All this code is IMO too complex and in
some place really hacky. Also, this is pretty hard to see the lines between the
parts of the code that are responsible for finding medias and the parts that are
playing them, all the code seems just too tighly coupled to me.
I first run accross these issues when working on a simple service discovery
module for an API I was writing and rediscovered it later when i was thinking
about liBDSM integration. I'd like to share with you a few stuffs i've found on
this topic while wandering in the code:

When you open a directory vlc file:///my_folder/ there's an access module
that will readdir folder content and output an XSPF playlist in a buffer
that will be picked up by the XSPF module. (modules/access/directory.c)
Since playlist need to be read first before being parsed, all the playlist
parsing code is treated as a 'demux' (modules/demux/playlist/*.c, seems legit)
If you go into the main playlist structure (include/vlc_playlist.h), there
are 6 pointers that are duplicate of the others, i assume for historical
reasons
Every playlist_item_it holds a pointer on a vlc_input_item_t, that in turn
contains data about ES, a lock, an event_manager, some stats, etc. Most of
which is totally useless or too complex when just managing a playlist
In the main playlist object, every input_item_t gets stored in a flat array
as well as in on of the playlist tree
Most of SD (especially LUA ones) are creating an input by hand when they need
to access a remote HTTP API
More juice to come.

When you see each of this point alone, you can find a decent design decision.
When you watch all of this together, you might regard this whole stuff as a
mess.
Then what ?

Cut, Shave, Clean. When something is too big and too complex, one cuts it
appart. Here, i think we have 3 main stuffs:

The core playlist, i.e. a simple list of items that needs to be played, one
after the other
A Media library that need to references all the medias that are on the local
machine, or the user wants to organize and find very quickly.
A remote Medias browsing service, i.e. some kind of lazy Vfs.

Isn't that what we have already ? Not quite. Right now we have one big subsytem
that does it all. Ask yourself those questions ?

Does the core playlist really needs a tree structure ? (see the ~GetNext()
function to have an idea)
Does the media library needs so many complex data structures ? Does it need
this tree structure where everybody uses tags (which is also the nature of
metadata)

Does it needs to know everything about the core ? (and vice-versa)
Can you implement a media library using only public libvlc public API ?
Yes (I've had student who've done this for an assignment).


The media discovering and browsing shit it the only one that might need most
of the actual complexity of this system and maybe more, but since it's tighly
coupled to the core and to the universe, nobody wants to extend it as it'd
require too much refactoring.

Does it needs to know everything about the core ? (and vice-versa) Yeah ...
a little bit if you don't want to rewrite ftp/http/... access
Can you implement a media discovery solution and having the media played
using only libVLC public api ? (Yep, same student did that as well, but there
was some redundancy with some access modules)


I suggest that we cut all of this into three distinct subsytems:

Simplify the core playlist as much as possible :

Removing media_library from the core playlist system.
Removing SDs
Making the playlist a flat structure instead of a tree but keep the rest
untouched not to break the core that rely heavily on the playlist.


Implements a proper media library, on top of something like Xapian
Implements a modular ''Vfs'' like thing for browsing, reusing VLC module
infrastructure whenever possible (mostly access)

Use cases

If you read this, please help me fill this section with ya comments
* FIXME: Continue writing this *