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

[James Courtier-Dutton]

Arpi wrote:
> 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/
> 

I am not lying.
My last email on the subject had

date: 09/05/03 18:21  (5th Sept 2003)
subject: Re: [MPlayer-dev-eng] Feedback wanted regarding dvd playing in 
mplayer.

Look in the archives.
It was at that time that I actually wanted to start making changes to 
libdvdnav, taking some of your earlier comments on board.
It was responses to those emails that I did not find very contructive.

My concern at the time, is that if I change the libdvdnav to try and 
separate nav and stream api calls, what I come up with will still be 
un-usable by mplayer.

So, is there really a wish to add dvd menu support into mplayer. If so I 
will work with yourselves to create an api that would work.
For this to happen, I would need someone to put in time so that I fully 
understand mplayer's requirements, and also someone who is willing to 
understand how dvdnav works, so can appreciate the problems involved.

My first thoughts on this have been to change the libdvdnav api to 
separate the nav parts from the physical read parts like so:-

User inserts DVD.
app makes api call to libdvdnav so that it reads all the .ifo files into 
memory and returns a void *ifos; (Different api calls will be added so 
that the app can retrieve details it needs from the void *ifos. E.g. 
Subtitle languages.
With this done, the dvd vm will never have to read any sectors from the 
disc, and most importantly, the dvd vm will not have to open a new .ifo 
each time it changes vts domain.

app makes an api call to dvdnav_vm_new() which returns a void pointer 
handle.
app then does dvdnav_vm_start(void *handle, void *ifos);
this will start the dvd VM and execute vm commands until it returns.
This will normally take the user to the main menu, but if the dvd does 
not have a menu, it will start playing the first title on the DVD.

app then makes dvdnav_vm_get_state(void *handle, void *ifos);
this then returns details of which DVD vobu to play.
app then makes dvdnav_vm_dup_state(void *handle, void *ifos);
and stores the details away for later use.

the app can then make calls to dvdnav to find out how to convert vobu 
number to a physical sector, and then the app proceeds to play the sectors.
When the app finishes a cell, it calls dvdnav_vm_get_next_vobu(void 
*handle, void *ifos, void *nav_pci);
This will then return telling the app which vobu to play next.

This will continue on as long as no input is provided by the user.

If some input is provided by the user. The app shall work out what is 
currently being displayed on the screen and match it to the details it 
stored after calling dvdnav_vm_dup_state().
the app will then make api calls to update that state with user input.
the app will then call dvdnav_vm_get_next_vobu(), and if the state 
returned from that matches the state before the call, no action is taken 
and playback does not change. (e.g. user selected a different menu 
button, but does not actually activate it). If the state has changed, 
playback is stopped. buffers between read and display are cleared, and 
playback then continues from the new vobu.

If the app finishes playing a particular VOBU, if can call 
dvdnav_vm_free_state(void *handle) to release the resource used up by 
the dvdnav_vm_dup_state() call.

So that is the basics. Will that work at all with mplayer?

Cheers
James