[MPlayer-dev-eng] Playlists & MPlayer
Arpi
arpi at thot.banki.hu
Sat Jan 11 19:15:42 CET 2003
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
More information about the MPlayer-dev-eng
mailing list