Re: G2, DVDnav, etc.

Hello!
В ?? 25.05.2003, в 21:11, Arpi пишет: 
> Hi,
> 
> > > btw the problem with libdvdnav is that you cannot use mplayer's cache2
> > > layer for it. i've heard about some patches which added some
> > > caching/buffering to libdvdnav, dunno if they are usable or still exists.
> > Yes it has caching support, but there is one small problem. We cannot
> > use external libdvdnav: recently, they imported libdvdread into it, so
> > mpdvdkit2 will probably clash with dvdread from libdvdnav. So, libdvdnav
> > must be imported into G2. Then, IIUC, if we must import G2, why we must
> > relay on their caching system, when there is good native cache?
> 
> our cache (if you mean my cache2.c) is not able to cache events., and to
> pass events to/from child process.
This isn't required: That's what I told in first letter. Cache layer
caches DVD (AS IS, I hope cache2.c can do this?). navigation 
(VM-emulation) takes place in main process. 
> > > I hope that nothing.
> > > The final a-v sync code will recognize and handle still frames.
> > > The only problem i can see is the OSD rendering. Ie if we have to render
> > > something over the still images.
> > We MUST render selections, which IIRC are SPU streams. Maybe there could
> > be a simple vf, that passes all non-still images, and when we receive
> > still-frame command, it stores frame in internal buffer?
> 
> yes, the OSD rendering filter (be it vf_expand or vf_vo2) should be able to
> restore original image after rendering osd into it.
Good news. 
> > I really suppose, that navigation belongs to demuxer. Really:
> 
> and where the mpeg demuxer belongs to? ui? :)
Why? I mean that code, that really 'navigates' - gets user events from 
libinput or anything else, and executes specified VM instructions.
It doesn't have anything to do with ui.
Why do you want to place VM in UI?
> > > > 5. Latest part is output. What is required here? libvo2 must support
> > > > image resizing/still frames. Resizing is supported (at least
> > > 
> > > why? (why do dvdnav requires resizing at vo ???)
> > not dvdnav. There are(or maybe it's a bug of ogle, but they could exist)
> > DVDs, where nav menus could use different resolutions.
> 
> it's codec's problem to detect aspect/size changes and notify swscale or vo
> to resize.
Ok. Of course VM-emulation doesn't have anything connected with direct
frames. 
> > > > theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned
> > > > above. Maybe I'm missing something,but IIUC, libaf chains are build
> > > > independantly for each audio stream. 
> > > 
> > > yes
> > Ok. Now we mustn't support switching of audio streams.
> > We must support rebuilding of the whole audio chain on-fly.
> 
> of course. but why is it a problem? it's normal.
I didn't say, that it's a problem. 
> if you switch from ac3 5.1 to ac3 2.0 or to lpcm you need to reconfigure
> the af layer to convert (up/downsample channels etc) the new codec's output
> format to the ao's input format. btw libaf was designed to allow runtime
> config changes without re-building the chain. so you need to replace codec
> but can keep af + ao. (but have to notify af about the change, of course).
Ok. 
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
> 
> _______________________________________________
> MPlayer-G2-dev mailing list
> [email protected]
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev
--
With best wishes
Dmitry Baryshkov <[email protected]>