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

Sun Jan 12 15:40:41 CET 2003

Am Sonntag, 12. Januar 2003 15:15 schrieb Arpi:
> 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

sure ?

sample: 
http://a772.g.akamai.net/5/772/51/20b9f288dddd83/1a1a1aaa2198c627970773d80669d84574a8d80d3cb12453c02589f25382f668c9329e0375e8177dec6493f758ca2f93f86ed743/daredevil-tlr_m320.mov

--- snipp ---
Resolving a772.g.akamai.net ...
Connecting to server a772.g.akamai.net[193.45.14.134]:80 ...
Request: [GET 
/5/772/51/20b9f288dddd83/1a1a1aaa2198c627970773d80669d84574a8d80d3cb12453c02589f25382f668c9329e0375e8177dec6493f758ca2f93f86ed743/daredevil-tlr_m320.mov 
HTTP/1.0
Host: a772.g.akamai.net
User-Agent: MPlayer/CVS-030111-11:36-2.95.4
Connection: closed

]
--- HTTP DEBUG HEADER --- START ---
protocol:           [HTTP/1.0]
http minor version: [0]
uri:                [(null)]
method:             [(null)]
status code:        [200]
reason phrase:      [OK]
body size:          [1136]
Fields:
 0 - Server: Apache/1.3.26 (Darwin)
 1 - Last-Modified: Tue, 12 Nov 2002 16:34:06 GMT
 2 - ETag: W/"71111-76482e-3dd1836a"
 3 - Accept-Ranges: bytes
 4 - Content-Length: 7751726
 5 - Content-Type: video/quicktime
 6 - Date: Sun, 12 Jan 2003 14:23:30 GMT
 7 - Connection: close
--- HTTP DEBUG HEADER --- END ---
Content-Type: [video/quicktime]
Content-Length: [7751726]
Cache size set to 40 KBytes
Connected to server: a772.g.akamai.net
CACHE_PRE_INIT: 0 [0] 0  pre:0  eof:0
Cache fill:  0,00% (0 bytes)    CACHE2_SEEK: 0x0 <= 0x0 (0x0) <= 0x0
Checking for MOV
MOV: Movie header found!
MOV: Movie header: start: 8 end: 0
MOV: free space (len: 16)
MOV: 'WIDE' chunk found!
MOV: Movie DATA found!
MOV: Movie data: start: 30b2 end: 0
MOV: Movie DATA found!
MOV: Movie data: start: 30ba end: 0
---

there it stands for a VERY long time ...

then it fails with:

---
QuickTime/MOV file format detected.
mov_read_header!
CACHE2_SEEK: 0x75C82E <= 0x0 (0x8) <= 0x76482E
Out of boundaries... seeking to 0x0
s->pos=0  newpos=0  new_bufpos=0  buflen=0
Stream not seekable!
Seek done. new pos: 0x0
cache_stream_seek: WARNING! Can't seek to 0x8 !
MOV: Cannot seek to the beginning of the Movie header (0x8)
---

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

I had to up the cachesize to at least: 8000 kB to have 20% (1.6 MB ) be big 
enough for the header ...

Or the mov demuxer is broken :-(

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

sure :-(

> - how do you resize cache buffer after fork()'ing the cache process???

mremap and so an shmem_realloc ...

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

... nice idea ...
>
> ok it's also a bit tricky (messy) but not so bad :)

sure

>
> and if once done we could move the other parsers to the demuxer layer this
> way :)

There is just one problem: 

MOV can have reference header AND movie content ...

Second problem is that references are parsed in the header and not in 
dexuxer-level ...

But ok, one could also use the pseudo-format with each packet coming from 
demuxer if TYPE=playlist ...

So one would have that big string in mem (not so big), but would send it in 
per packets to the mplayer-level ... 

I like the idea :-))

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

It is in the standard, but I haven't seen such files either... How about us ? 

(Let's produce some, when the MOV-Muxer-Layer is finished of course ;-))

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

;-)

cu

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