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

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

so actually it doesn't matter if you put navigation into stream or demux, it
will not be easier.

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

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)

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

if you put it into demuxer layer, where do you want to implement mpeg ps
stream demuxing?


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

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

btw do what you want, i'm interested in the actual implementation details,
or patches :)


A'rpi / Astral & ESP-team

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