[MPlayer-G2-dev] G2, DVDnav, etc.
Arpi
arpi at thot.banki.hu
Sun May 25 19:11:34 CEST 2003
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
More information about the MPlayer-G2-dev
mailing list