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

[Arpi]

Hi,

> Hello!
> Here are some of my thoughts about adding support for DVDnav into G2.
> (As most ideas here, probably they will be changed mostly, etc.)
> 
> 
> 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.

> 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.
imho dvdnav interface should go to the stream layer. some method could be
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))

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

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

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.

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

> 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

> So many parts of G2 must be changed/discussed to ease adding support for

i disagree

> DVD (and maybe for Matroska/NUT/etc.) navigation. Good news are, that it
> will be (I hope) easier, than for G1.

sure

A'rpi / Astral & ESP-team

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