[MPlayer-dev-eng] Playlists & MPlayer

[Fabian Franz]

Am Samstag, 11. Januar 2003 19:15 schrieb 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.
ok
>
> > 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)

Are you sure there is a playlist-limit ? I tried one from my local webserver, 
that was 282418 bytes big and it still worked :)

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

That seems to be necessary, before rewrite of demuxers after 0.90 :-/ ...

>
> > 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, see patch in other mail ...

>
> > 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.

I thought the same, because of that I want to have it in the demux-level ...

>
> 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)

of course ...

>
> > 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
ok
>
> > 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.

ok, I'll implement this and send patch ...

>
> 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).

yes, a demux-redesign would be great ...

What I think works best for now are the audio/video_decoders. It is such a 
great architecture ... :)

cu

Fabian
>
>
> A'rpi / Astral & ESP-team