[MPlayer-dev-eng] (Cache & demuxers) & Movs (= 0 if cache too small ;
arpi at thot.banki.hu
Sun Jan 12 15:15:50 CET 2003
> I am in the way of implementing reference file support for mov-files ...
> During this I found out that mplayer has problems with streaming mov-files ...
only if they have teh header at the end of the file
> They read huge amount of data and then want to seek to the beginning again,
> which of course fails if the cache is too small ...
huge amount? headers is usually a few kB.
> One idea to solve this problem would be to have a self-growing cache (only
> when seeking will fail) ...
> This cache could be enabled by mplayer when it streams by doing
> stream_enable_intelligent_cache(stream, 1) before demuxers start and after
> detection was successful:
> stream_enable_inteligent_cache(stream, 0) to disable it again ...
> This intelligent cache will work like the old cache did but also grow
> accordingly in some fixed size chunks ...
> So everything that is read by the demuxers will be cached and so there will be
> no problems with seeking ...
> What do you think of it ?
> Are there problems one must notice ?
- may eat lots of memory
- how do you resize cache buffer after fork()'ing the cache process???
> btw. Speaking of reference files ...
> This format can easily be parsed by the parse_playtree-function (of course
> after this format was added), after the demuxer finally fails ... (no
> Problem is: How to get it to the main-program as demuxer=NULL ...
> global var -> bad :-(
> stream-layer -> hm, but is it possible to write to the stream layer? , but
> also bad :-(
> another var to open_demux -> also bad :-(
what about returning a valid demuxer, with DEMUXER_TYPE_PLAYLIST ?
and not use a big string for the list, but send each entry as a demux_packet.
so mplayer could do
ok it's also a bit tricky (messy) but not so bad :)
and if once done we could move the other parsers to the demuxer layer this way :)
> But there must be a solution and I think the pseudo-format is the cleanest I
> could think of ...
> The parse_playlist code can then remove all the unnecessary QTxgate-references
> and decide based on min data rate ... :-)
unfortunatelly that min data rate parameter is fake, at least i didn't see
any ref. mov file having valid values there.
> PS: I'm awaiting answer to 3 other mails I've sent lately ;-)) i know, I know
i know i know
A'rpi / Astral & ESP-team
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-dev-eng