Re: G2, DVDnav, etc.

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.

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

> I really suppose, that navigation belongs to demuxer. Really:

and where the mpeg demuxer belongs to? 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.

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


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu