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

[Dmitry Baryshkov]

Hello!
В ?? 27.05.2003, в 00:26, Arpi пишет:
> > > 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.
Do you think, that UI must be notified about such changes?
Is  UI notified, when e.g. stream_cdda jumps to another track?
> 
> > 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.
So we are returning to the one of major questions: which part
of vf chain will support still frames & SPU rendering on them?

I think, that if still_frame storing will be placed near vf_vd,
other parts of player (excluding nav of course) can forget,
that this is still_frame :) vf_vd will simply check, that we
didn't get out of still_frame, and then it will simply return
stored frame, hat will be then processed via usual vf chain and
then merged with SPU and rendered via vf_vo2.
If you don't want to mess vf_vd, there can be special vf_vd_nav
that will be simple vf_vd with described changes.
However it's not completely true:) I have to study, how to get
that SPU patterns for buttons highlighting. I mean during
STILL_FRAME .
> 
> 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())

'menu' mode? Well... I saw DVD (LotR-TT), on which menus were
normal movie parts of ~5 secondslength, and only then followed
by still frame.
If 'menu mode' will be activated only at 'still frames', then
buttons won't be accessible in that 5-7 second's (or I'm
missing something). Moreover, I can imagine buttons in normal
movie playback (hidden features, etc.)

BTW. Have you seen LotR-TT trailers in QT player? It looks like
this:
+-----------------------+
|still banner of LotR-TT|
+-----------------------+
| normal movie playback |
+-----------------------+
|       menu bar        |
+-----------------------+
Will it be possible to support such mess?

> > > 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.
Does this 'true' means, that agree not to put dvdnav in stream
layer ?
> 
> > 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?
Well... It's my question too... I thought about library/API,
which will register callbacks for each event-from-UI type.
something like
register_event_callback(EVENT_MOUSE_CLICK, nav_mouse_clicked);
register_event_callback(EVENT_NAVIGATE_UP, nav_button_up);
register_event_callback(EVENT_NAVIGATE_ENTER,
 	nav_button_pressed);

Or maybe a better solution: add all that EVENTS to
demux->control function.


> 
> > > 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.
I'll look into it.
> > > 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.
Why? And what is 'normal' movie player? There are other nav's,
among DVDnav (MOV, etc.). Moreover, IIRC G2 isn't a player :)
> 
> 
> 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 Baryshkov <lumag at qnc.ru>