[MPlayer-G2-dev] G2, DVDnav, etc.

[Dmitry Baryshkov]

Hello!
В ?? 25.05.2003, в 15:58, Arpi пишет:
> > 1. Unlike G1, stream+cache layer behaves like DVD (using stream_dvd),
> > and not like MPEG stream after libdvdnav.
> 
> i don't understand this
> 
> 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?
> 
> > 2. Next part is a code, which emulates DVDnav VM, seeks to correct
> > places of DVD, etc. Of course it belongs somwhere between stream_dvd and
> > demux_mpeg. So here is first question: what is better: to break into
> > demux_mpeg, and add a lot of if(dvdnav){...}, or to create an especial
> > demuxer for DVDnav? Or maybe there are other solutions?
> 
> imho it's all UI problem, not demuxer.
Why VM (Virtual Machine - I meant it, and not seeking, etc. caused
by user).
Probably you messed two event types:
a) coming from user. They of course should pass from UI to dvdnav code.
b) coming from nav VM. They are events, that libdvdnav returns.
Maybe, if G2's DVDnav code will be placed in demuxer,most of such events
won't exist (suppose, there will be only two - STILL_FRAME and STOP).
> imho dvdnav interface should go to the stream layer. some method could be
Why stream layer? Keep in mind MOV/NUT/etc. navigation. They of course
belong to demuxer layer!So navigation-code placing must be standard.
> added to pass events to/from UI from/to stream layer.
> any ideas? i'm not familiar with UI/events design at all.
> 
> > Anyway demuxer must be able to control, which of audio/subtitle streams
> 
> no, UI must be able to control it, and it IS able to do that.
> 
> > are decoded. Probably, his would require significant changes in libao2.
> why? libao has nothing with that. you probably meant mpeg demuxer + audio
> codecs? g2 is designed to handle runtime codec/stream switch.
> (although multiple codec for single stream (aka mov's variable fourcc)
> not supported (yet))
OK. This is probably a better idea:) My idea was to give all audio 
streams to decoder. Now I understand, that it was wrong idea.
> > 3. Still frames support. Sorry, dunno g2 arch well enough, to even
> > imagine, what changes are necessary here.
> 
> 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?
> 
> > FIXME :)
> > 
> > 4. Interaction with user.
> > Currently, IIUC, event hanling can be done only through libvo2. Suppose,
> 
> not really
> libvo2 has event callback to be able to pass events from vo drivers to
> the UI. it's required as only the vo drivers are able to catch some input
> events.
That's what I told about
> 
> the real event handling core is in libinput.
> > it's not the best way. It's more or less acceptable for vo's, like xv,
> > x11, etc. But for vo_vesa, and similars 'fake mouse' layer will be
> > usefull. Such OSD-rendered 'mouse' (read pointer) will be controled via
> > libinput. Moreover demuxer (at least its navigation part) also must be
> > user-controled! Also keep in mind, some more 'controllable' demuxers
> > (navigation in MOV's, NUT, and Matroska; maybe something else).
> > I don't see proposed way for such control.
> 
> I don't think that navigation belongs to the demuxers.
Ok. So What part of player must control the behavior of demuxer, by
reading navigation stream (Of couse, demuxer may simply read navigation
commands from source file/stream and tranclate them to universal
commands).
Do you think, that it's a part of UI? then playing of same file/DVD
will (or at least can) be UI-dependant. I suppose, that UI must only
control parameters of playing.
I really suppose, that navigation belongs to demuxer. Really:
for DVDs it must be placed not later, than demuxer(or it will require
more hacks), and for file-navigation (MOV/etc), it can't be placed
before demuxer. So:
navigation >= demuxer
and
navigation <= demuxer
\longrightarrow
navigation \in demuxer :)
> 
> > 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.
> 
> > 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.
> 
> > So many parts of G2 must be changed/discussed to ease adding support for
> 
> i disagree
Suppose, you know better :)
> 
> > DVD (and maybe for Matroska/NUT/etc.) navigation. Good news are, that it
> > will be (I hope) easier, than for G1.
> 
> sure
good news
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
> 
> _______________________________________________
> MPlayer-G2-dev mailing list
> MPlayer-G2-dev at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev

-- 
With best wishes
	Dmitry