[MPlayer-dev-eng] (Cache & demuxers) & Movs (= 0 if cache too small ;

Arpi arpi at thot.banki.hu
Sun Jan 12 15:15:50 CET 2003


Hi,

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

no.

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

bad idea

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

good idea

> 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 :-(

hmm.
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
if(demuxer->type==DEMUXER_TYPE_PLAYLIST){
	while(demux_read_packet(demuxer))
		playtree_add_entry()...
}

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 mailing list