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

[Dmitry Baryshkov]

Hello!
Thank you for response.
В ?? 26.05.2003, в 22:04, Arpi пишет:
> Hi,
> 
> > > hm, its both a stream and a demuxer ... perhaps it should be really BOTH ...
> > This was discussed (if it can be called that) in other thread, but:
> > IMHO how it's organized in hardware player:
> > 1) DVD-ROM provides raw DVD stream (mostly it's MPEG stream, and
> > 	sometimes IFO files with commands for VM).
> > 2) VM (or even special CPU) 'navigates' - gets user events, processes
> > 	them, executes internal commands (from IFO files). At the end,
> > 	if produces MPEG stream, which goes to demuxer (or something
> > 	like that) and tells demuxer, which streams (Audio/SPU) to use.
> > 3) Demuxer - demuxes, and gives audio, video and SPU streams
> > 	to hardware decoders/etc.
> 
> there is a big difference, in hw players demux/decode work as push, not as
> pull. ie the VM push teh stream into the decoder hw and it will read and
> decoder the stream based on hw clock.
> 
> 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.
Then, user selects next chapter, and the audio playing must be restored!

Moreover, things are even worse. Demuxer functions won't be called
during STILL_FRAME's, unless they are supported directly in vf_vd.c .
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.
> 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.
> 
> > 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. 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.
> 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
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).
> 
> maybe the new libdvdread's approach is better for mplayer g2, it uses
> callbacks to communicate with UI.
You mean libdvdplay? I looked in two-days-old CVS of dvdread,
and I don't see any callbacks.
> 
> 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
code). But, I hope, that in July I'll have a lot of free time
to work for G2.
> 
> 
> 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>