[MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main)

[Arpi]

Hi,

> > the main problem is here. mplayer has opposite design.
> > here the whole thing is pushed by the ao/vo end. so the control is done
> > at ao/vo insteda of teh other end, demuxer.
> > it was easier in g1, there demuxer was directly called by player, at least
> > for video (audio was pulled even in g1).
> Well...This really is a problem. Dunno, but suppose, that this situation
> can be possible: during calls of audio chain, VM jumps to (e.g.) STILL
> menu, where is no audio stream. Suppose, that in this situation, EOF
> will be returned for audio stream, and audio will be switched off.

yes

> Then, user selects next chapter, and the audio playing must be restored!

it's not a problem, the audio layer will be reinited then.
UI will call the seek function for chapter change, it will reset EOF flag
on demuxer streams and will reset audio and video decoder too.

> Moreover, things are even worse. Demuxer functions won't be called
> during STILL_FRAME's, unless they are supported directly in vf_vd.c .

yes it's a serious problem, i didn't even think of yet.

> It's the only place, where we can store still_frame, and then return it
> via get_pending_image, when we are in still_frame. Only in such way, we
> can keep calling demuxer, when G2 is in still_frame handler.

no, we shouldn't put such mess into vf_vd.

imho when we find a still frame, then demuxer should set video stream's EOF
flag. event control in 'menu' mode (be it still frame or looped video)
should be done via demuxer/stream control() function.
(actually it should always be done via control())

> > so actually it doesn't matter if you put navigation into stream or demux, it
> > will not be easier.
> I don't say that placing VM into demux will be too easy.
> There are no easy things on the Earth.

yes

> > > So navigation really lays between stream and demuxer.
> > 
> > yes.
> > 
> > > The main question is, where it will be easier to implement.
> > > 1. In stream layer. Then there must be API to pass events to/from
> > > 	stream layer. Moreover, (when using cache2.c) to/from caching
> > > 	process! Also, there is another problem. The main part of
> > > 	cache, is precache(IIUC), which means, that navigation will
> > > 	be _ALWAYS_ ahead of playing by some seconds.
> > 
> > ok, we have to decide something: do you plan to use libdvdnav as-is
> > (using its API), or modify/rewrite/restructure it to fit mplayer's
> > structure/layers?
> No.

No for which one? :)

> As I wrote in first letter, I will try to use VM-emulation
> and most types of events-from-VM(such as STILL_FRAME, HOP,
> SPU_CHANGE, etc.).
> > 
> > i'm asking it because dvdnav includes the dvd reading code.
> > so if we use it as-is, then we cannot use my cache2.c, for sure.
> > (cache's delay in navigation is not acceptable, as it locks on still frames)
> You are reading from my mind :)
> > 
> > > 2. In separate layer between stream layer and demuxer.
> > > 	Why we must add extra layer specifically for _DVD_ navigation VM?
> > > 	(I mean, that VM's for other navigations (NUT,MOV,etc) don't
> > > 	belong to such place, do they?)
> > > 3. In demuxer layer. Suppose, it's a best choice:
> > > Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using
> > > metalanguage):
> > 
> > if you look at what libdvdnav does, it's trivial that it's a stream level
> > element. it reads stream packets, and translates special (NAVI) packets
> > to event data, nothing more. all the demuxing (including stream separation,
> > format detection, timing) is done by demux_mpeg, not by libdvdnav.
> Maybe you meant that, but IIUC, NAVI packets(or even NAVI
> stream from MPEG stream) are/is  splitted into PCI[Presentation
> Control Information] and DSI[data search information]
> structures. Events (or better VM-instructions) comes from IFO
> files.

i'm not familiar with dvd details, just know about NAVI, as i had to mess
with that while implementing code of stream_dvd.c

> > if you put it into demuxer layer, where do you want to implement mpeg ps
> > stream demuxing?
> In demuxer :)
> Well...IIUC, current stream API on the side of main process
> either are calls to cache2 (If it's enabled), or calls to
> stream_<name>.c, but then cache2 is disabled.
> So, having DVDnav in stream layer will either require big
> changes to post-cache read functions (if we decide to put nav
> after cache2, but in stream layer), or hard-portable changes

hmm, true.

> to cache2 to pass msgqueues between two processes (I don't
> think that M$Win have SYSV IPC or POSIX 1.b msg queues.).

:)

> > > {
> > > 	exec_one_vm_instruction();
> > > 	if (some_conditions)
> > > 		return EVENT_HAPPENED;
> > > 	if(next_is_nav_packet)
> > > 	{
> > > 		process_it_and_store_pci_and_dsi(&pci, &dsi);
> > > 		return NAV_PACKET;
> > > 	}
> > > 	return BLOCK_OK;
> > > }
> > > 
> > > I really suppose, that this fits to the demuxer well (moreover, if
> > > there will be special demuxer for dvdnav, all if(dvdnav) can be
> > > ommited):
> > 
> > but how in the hell do you plan to pass to/from navigation events between
> > libdvdnav and UI ?
> That is one of questions in my first mail (of course if you
> mean button-press events, etc.). You said, that it must be
> done through libinput (or maybe I din't understand you).

libinput is at the other end of the pipe. it receives keyboard/mouse/lirc/etc
events (including mouse emulation if wanted) from all input devices,
including libvo2 drivers, and translates to command code + parameters format
based on input.conf.

my current question is about the other end of the pipe: how do you plan to
pass these events into the demuxers, and how do you plan to receive nav
events (like still image, switch stream, whatever) from demuxer?

> > maybe the new libdvdread's approach is better for mplayer g2, it uses
> > callbacks to communicate with UI.
> You mean libdvdplay?

yes.

> I looked in two-days-old CVS of dvdread,
> and I don't see any callbacks.

i meant libdvdplay, just mixed them, as dvdplay was made by dvdread authors
and is better layered over dvdread.

> > btw do what you want, i'm interested in the actual implementation details,
> > or patches :)
> Me too:) I mean SPU-stream, event passing, etc.

:)

> More concrete: In June I'll have exams in university, so don't
> expect too much. (The goal of theese letters was to discuss
> what is necessary in G2 to ease support of navigation (I don't
> mean only DVDnav). I suppose, that it's better to have such
> code from begining, than having to rewrite already-working

yes

btw while talking about the dvdnav issues every time, i'm more and more
close to the conclusion: it is much better and easier to implement separated
from a 'normal' movie player. it's very different philosophy.


A'rpi / Astral & ESP-team

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