[MPlayer-dev-eng] Playlists & MPlayer

[Arpi]

Hi,

> from my favorite movie player, I would expect to detect playlists and play 
> them without me having to do sth ...
> 
> Hmm, it turned out that it was not so easy ...
> 
> "mplayer -playlist playlistfile.pls" - worked!
> "mplayer -playlist somemovie.avi" - worked not!
> "mplayer playlistfile.pls" - worked not!
> "mplayer somemovie.avi" - of course worked!
> 
> While this could be expected with -playlist switch it gives certain problems 
> to for example browser plugins, which cannot know about files passed to 
> mplayer ...

agree.

> I would expect mplayer to try the playlist-format after all other demuxers 
> failed:

first i wanted to say it's a bad idea.
but as you said it's working, i re-started the thinking process :)
and it may work, at least for playlists <2048 (maybe <=2048) bytes.
(maybe this size limit exists only for streamed (non-seekable) playlist files)

> A quick hack turned out to solve the problem:
.. [ugly thing] :)

> This works with streamed and local files ... (Why didn't anyone try this 
> before ?)
dunno

> Btw. before I forget plaintext-parsing is not broken, but somewhat too 
> error-tolerant (Tries to include file with not allowed characters for example 
> ...)
patches welcomed.
also support for that silly win.ini-style format:
[Reference]
Ref1=http://195.228.246.70:80/0111/orult.wmv

> Ok, this works, but is imho not nice, as it duplicates code ... (Can Streaming 
> layer ever detect the format right in all cases ?)
since when is it the job of the stream layer to detect format?
ok i know there are some hacks in the network streaming code (network.c)
to guess fileformat from MIME types, but it's a hack.

fileformat detection should be content-based (only), and done by demuxer.c
by probing each demuxer.

> And for example for mov-referencing this has to be duplicated once more ...
demuxer layer shouldn't meet (directly) to playtree.
keep demuxers clean, and mplayer-independent ('make test' in libmpdemux/ dir)

> I therefor vote for a function, that does this:
> 
> e.g.: playtree_add_playlist(playtree_t entry)
> 
> And I think it would be even more nice to have this playlist-parsing in an own 
> demuxer ... (It is some kind of demuxing, isn't it ?)

good q.
i don't think it's demuxing, but placing it into the demuxer layer has some
advantages. so why not :)

> It would be even more nice, to have that "Sorry, this file format is not 
> recognized/supported" gone away, which of course now appears ...
yep

> Alas, there remain some questions open:
> 
> - Is such a function wished and should it be included in demuxer-level ?
>   - If so, how can it pass entry to mplayer.c (using some of the 
> demuxer->audio/video pointers as a hack ??? :-( )

for now (<=v0.90), it shouldn't be in demuxers.
the 'Sorry, this file format is ...' should be printed by mplayer, after
probing parse_playlist() after demux_open() failed.

after 0.90, we'll see. i'm planning to redesign demuxers, so we can count on
the playlist issue too (and the subtitles too, it's another issue).


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu