elisa-developers team mailing list archive

[Michał Sawicz <michal@xxxxxxxxxx>]

Dnia 2010-02-23, wto o godzinie 23:02 +0100, Paul van Tilburg pisze:
> Yep.  We should allow for lists to be items as well with possibly the
> propertie to 

to...?

> > Also, as I mentioned somewhere before, there should only be one
> player,
> > that would behave differently based on type of the media played. No
> more
> > player_{audio,video,picture,...} please. We need to be able to have
> > mixed playlists.
> 
> I was thinking about this though.  I think there is an issue here with
> pictures and everything else.  While you'll probably never listen to
> music
> while playing a video, listening to music while watching a photo album
> might just happen.  How does that work.. playlist-wise?

Yeah, a second player, some way to avoid conflicts? Maybe pause the
other one if there's audio on both? Not sure if it should happen when
both have video/pictures (you might want to play a DVD concert while
watching pictures, too).

> > And the player needs to try and parse any playlist that comes its
> way. I
> > think intercepting any "can't play text/html" errors from gstreamer,
> > getting the data and adding a 'children' entries to current playlist
> > would be a way to go.
> 
> The same way you could feed it a webpage and it plays the video that
> is
> on it?   So we need a kind of playlist hints.
> I mean, I can already distinguish different playlist types:
> - an album: it's a list of tracks, should be skippable as a whole
> - an TV show season: the same (who skips a season, but ok)
> - a webradio "playlist": it's a list of servers, you should probably
> repeat
>   on it so go from server N back to 0, or should we go to the next
> after
>   trying all servers?
> - some .m3u file in the library: indistinguishable from this webradio
>   playlist (often allso m3u's) but the user probably mean: play all of
>   this, then continue
> - some RSS feed maybe? 

Yeah, content providers could register with url patterns that they are
able to convert into playlists and playables. Then the playlist could
simply contain links like:

      * http://www.youtube.com/watch?v=... [a single playable]
      * http://www.youtube.com/user/... [a list of user's videos]
      * http://vimeo.com/... [a single playable]
      * http://vimeo.com/channels/... [a list of channel's videos]
      * file:///home/user/Music/Artist [a list of playlists by folder]
      * file:///home/user/Music/Artist/Album/Song.mp3 [a single
        playable]
      * etc.

I think all media could be identified by such URLs by using custom
schemas for different things (say, miro://, upnp://, banshee://,
tracker://, also elisa:// if we have an internal library, possibly with
a way to talk to other instances on the network through extended UPnP).
When such a mechanism would be in place, playlists, favorites,
bookmarking (a param in the uri could hold time in playables, index in
playlists etc.) would be easy to implement.

If we get a URL no registered plugin can handle, we should search in the
plugin repo if there is one that can and tell the user that we need to
install the plugin first. If there is still no plugin that knows the
URL, we should typefind it and if it's text/(x|ht)ml - try to use some
generic parsers - all types of playlists, RSS/ATOM feeds, you name it.
In the end - try to play it in the hope that it will :) Think this could
be done? Makes sense? What am I missing that breaks this completely?

-- 
Cheers
Michał (Saviq) Sawicz

Attachment: signature.asc
Description: To jest część wiadomości podpisana cyfrowo