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

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

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.

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

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

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

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

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


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu