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

[Fabian Franz]

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

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

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 ?

btw. Speaking of reference files ...

To keep the demuxer_level clean and compilable without mplayer-dependance, I 
thought of a semi fileformat, which works as a temporary buffer ...

So the quicktime demuxer finds a reference file and stores it into some string 
buffer with realloc.

pseudo-format is then:

[Quicktime-Playlist]
Ref=<url>
data_rate=2800
quality_index=1
Ref=<other url>
data_rate=2800
quality_index=1
[...]

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)

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

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

Many questions, many ideas ...

cu

Fabian

PS: I'm awaiting answer to 3 other mails I've sent lately ;-)) i know, I know 
no time, no time ...