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

[Fabian Franz]

Am Sonntag, 12. Januar 2003 16:14 schrieb Arpi:
> Hi,
>
> > > - how do you resize cache buffer after fork()'ing the cache process???
> >
> > mremap and so an shmem_realloc ...
>
> and how do you tell the forked process it without using (dead)locks?

there is already a structure that is shared, but Ok... let's forget it ...

>
> anyway forget it, i'll debug & fix demux_mov.
> i have an idea what can be wrong there

:)

>
> > > so mplayer could do
> > > if(demuxer->type==DEMUXER_TYPE_PLAYLIST){
> > > 	while(demux_read_packet(demuxer))
> > > 		playtree_add_entry()...
> > > }
> >
> > ... nice idea ...
> >
> > > 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 ...
>
> no.
> ok the fileformat itself may allow that, but nor the specs nor the pratice
> says that.

ok, there is just one case, but it must not be followed:

"Optionally, the Movie atom can also include a movie itself, as shown below by 
the Movie Header and Track atoms. This movie will be used if an older version 
of QuickTime (2.x) is used, since previous versions of QuickTime will ignore 
the Reference Movie atom. This movie can also be one of the alternate movies. 
In this case, the Data Reference atom in the Reference Movie Descriptor atom 
will indicate that the movie is self-contained."

But I have never seen a self-contained movie ...

>
> > Second problem is that references are parsed in the header and not in
> > dexuxer-level ...
>
> why is it a problem?
> you can send packets to the queue from the header parsing too
> (see mpeg demuxer, it queues up many packets in demux_open(), since it has
> to parse out a valid whole video frame to have the video header)

ok, I now understand it ...

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

ok

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

... ok, ok, I understand ...
>
> i see only one problem:
> which stream should be these packets sent to?
> now there are audio, video, dvdsub.
> either we use one of them (it's confusing) or add a 4th queue 'references'.
> in teh later case we don't need (should not) change demuxer_type and we
> could even mix content & references.
>
> i mean, the demuxer can queue up references it finds, while parsing out
> normal data. when mplayer reaches eof (if no content, it'll reach it
> immediately) it can parse the references into playtree and jump to next
> file.
>
> we're going to overcomplicate things :(
> in a feature-freezeed period...
> just before whole rewrite of demuxer layer...

... ok, so just lets take the video-layer (its the first one :-)) ) ...

As there are in pratical no self-contained movies this can really wait after 
0.90...

As DEMUXER-TYPE is then set to playlist, it'll correctly end ...

>
> > 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 ;-))
>
> i hope we won't create reference-mov files :)

:))

cu

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