[MPlayer-dev-eng] proposal of a dvdnav layer

[Arpi]

Hi,

> dvdnav is a lot more complicated than you are assuming.

agree

> As one of the main authors of libdvdnav, I offered to help with 
> integrating it with mplayer, but received no contructive feedback.

please do not lie!

we've exchanged several mails discussing the dvdnav api problems
and possible changes, until you stopped answering...
here's my last mail (i sent you) in that thread:


--------- Forwarded message ---------
From: Arpi <arpi at thot.banki.hu>
To: James Courtier-Dutton <James at superbug.demon.co.uk>
Date: Fri Jun 20 15:24:44 2003
Subject: Re: dvd support in mplayer

Hi,

> >>I am about to make some changes to the libdvdnav api, and was wanting 
> >>some input from you regarding any api features you might want to let 
> >>libdvdnav work better with mplayer.
> >>
> >>I am planning to add a new api so that application do not have to call 
> >>get_next_block, but only need to call libdvdnav to find out which 
> >>sectors need reading, and then let the application decide how to read 
> >>the sectors. This should allow applications to use their own caching 
> >>mechanisms.
> > 
> > 
> > sounds good!
> > 
> > 
> >>Do you have anything you can contribute?
> > 
> > 
> > i've never work on dvdnav support in mplayer, so i have no ideas or code,
> > but i've forwarded your mail to mplayer-dev-eng list.
> > 
> > anyway in mplayer there were 2 main problems with dvdnav:
> > - no cache (less important)
> > - events are received at the stream layer, while it's needed at player ui.
> >   the stream layer of mplayer is simple open/read/seek/close api, like
> >   the kernel's file i/o functions, no clean way to passthru events and
> >   such things.
> > 
> > if you split the lib to navi parser and disk reading, it will make it
> > possible to do disk read at stream layer, but call the parser stuff from
> > the demuxer layer. (it even allows reading disk image through samba share,
> > or http streaming or whatever protocol supported by mplayer's stream drivers)
> > 
> > do you plan to completely split out libdvdread dependency from libdvdnav,
> > or just separate the related dvdnav api functions?
> > 
> > 
> > A'rpi / Astral & ESP-team
> > 
> > --
> > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
> > 
> > 
> 
> 
> The difficult part is deciding where to break the api up.
> I don't think the .ifo files are protected or encrypted, so in theory we 
> should be able to have the nav parts not use libdvdcss at all.

they aren't encrypted (afaik) but the drive is locked until you
authenticate (disc key) to unlock and allow reading.
although they may be encrypted, afaik nothing stops dvd makers doing so.

> Also, I don't think reading the .ifo files needs any caching.
> 
> The reading of the .VOB files needs libdvdcss for decryption and 
> authentication of the DVD.
> 
> In the .VOB file are NAV DSI and NAV PCI info needed for deciding what 
> other sectors to read (for doing angles etc.) so the application might 
> need some lib functions to decode and handle those.
> 
> DVD playing is generally not well suited to the open/read/seek/close api
> Hopefully I can design the api in such a way as to make it possible to 
> simulate open/read/seek/close api.

Actually it would be the best to separate dvdnav compeltely from the lower
layer: raw media (disc) reading functions (which may be open/read/seek/close
api and may implement cache, and decryption).

I see 2 methods to reach this goal:
- simple: request the caller to 'register' callbacks for seeking and reading
  of the disc. its' easy to implement, makes possible to use any raw i/o
  library, cache etc. alrhough it doesn't allow well separating demuxer and
  stream layers in caller.
- push method: something like current libmpeg2 api, ie. the caller will
  call the raw i/o code, and then call the navigation parser/handler code
  (libdvdnav) to process it. it may request more data or seeking to other
  position.


> The current get_next_block api inserts special info into the stream 
> because it has to, in order to mark a particular frame as a still frame, 

hmm, i didn't know that.
but i remember we failed with dvd nav support because of the still frames, i
couldn't see at decoder level when to stop decoding and pause display.

> so that the engine only goes into still mode once the still frame has 
> actually made it through the demuxer,decoder and been displayed.

cool.

> Other control info is also needed to inform the demuxer/decoder that the 
> stream has switched. Like changing channels on a TV, selecting a DVD 

yes

> menu is just the same. We might have sent half a frame to the decoder, 
> but the stream switches, so we need to inform the decoder to drop all 
> frames and start anew. These control messages have to pass with the 
> stream because they have to be acted on at exactly the correct point in 
> the stream.

btw another problem we couldn't resolve yet in mplayer, when user input gets
back to dvdnav. at leats it needs some ugly hacks in mplayer-g1.

> I am still thinking how best to achieve a solution whereby the nav 
> portion does not do any reading of the actual VOB.

unfortunatelly i don't know enough about teh dvd navigation details,
just the minimal info i gathered from problem discussions on mplayer lists.


A'rpi / Astral & ESP-team

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



A'rpi / MPlayer, Astral & ESP-team

--
PyMaViS - my answer to worm storm - http://mplayerhq.hu/~arpi/pymavis/