[MPlayer-dev-eng] DVD Navigation in mplayer.

Arpi arpi at mplayerhq.hu
Sat Jun 25 22:41:38 CEST 2005


Hi,

> I am one of the authors of libdvdnav.
I _was_ one of the mplayer authors.
So i'm out of business, but i'll try to help, as i'm also
interested in proper nav support in mplayer, as user...
(no, the rumours about i'm using xine nowdays are false...)

> I am about to rewrite libdvdnav so that the NAV bit is completely
> separate from the video stream.
Again? I remember you already asked these 1-2 years ago...

> I am doing this so that mplayer might be able to use libdvdnav.
> 
> I don't know much about mplayer's api, so could someone please help me
> understand what sort of functions would make libdvdnav compatible with
> the mplayer model.
> For example, I was thinking of the following type of scenario.
> 1) Open DVD.
> 2) Call first_play_PGC(). (This will set the DVD state engine pointing
> at a paticular Cell and VOBU.
> 3) Call get_next_vobu() (This will return a start sector, and length)
> 4) mplayer then plays those sectors.
> 5) return to (3).

Sounds good, but: where/how does libdvdnav will access the dvd sectors
(to read IFO and navi stuff) ???  Where is user input (buttons) handled?

The main problem of libdvdnav integration in mplayer is that mplayer
has a separated layer of low-level i/o (LBA-addressed file/device read/seek)
called stream-layer, and a demuxer layer which handles container-specific
stuff. In case of DVD playback, mplayer has a stream-layer driver
which reads the selected dvd title's sectors as a big file/device.
(so the upper layers access the dvd title as a big file, the driver
handles the navi stuff required for proper seeking, and multi-angle reading)

The demuxer-layer driver does the mpeg-2 demuxing.
Also, an optional cache layer exists, to be inserted between stream and
demuxer layers, so the demuxer layer requests sectors from the cache,
and it will query them from the stream layer if they aren't present
already in the cache.

So, libdvdnav could be put at 2 places: stream-layer or demuxer-layer.
if at stream layer:
- it can use libdvdcss/libdvdread functions directly to read sectors
- it will access dvd navi sectors directly, without caching
- it's difficult/impossible to handle/access user input at stream layer,
  especialy if cache is in use (then stream layer runs in a different
  process than player)
- it's difficult to tell demuxer extra data, like still images or
  tell video filters where to draw OSD buttons etc.
if at demuxer layer:
- it cannot use libdvdread directly, it has to call stream layer
  (through cache) with LBA sector number to read a sector
- any sector read will be cached, if cache enabled, including navi/ifo
- it's easier to access user input, but still a big hack
  (probably needs to call vo_get_events() or so from demuxer)
- it has to be integrated with demux_mpeg, or even better, write a
  new dvd-only mpeg2 demuxer for it, which uses the info from
  libdvdnav, instead of reading stream layer directly.
- it can set up flags in demuxer packets to tell decode/filters about
  still images and osd tricks

so, both has pros and contras. i personally vote for dvdnav in demuxer
layer, it simplifies user i/o a lot, while requires special mpeg2
demuxer integrated with dvdnav calls, and requires libdvdnav to read
dvd through callback (user-defined) function, instead of using
libdvdcss/libdvdread functions directly.

> Would this be mplayer compatible?

somewhat


A'rpi / MPlayer, Astral & ESP-team

--
Girls are like internet domain names, the ones I like are already taken.




More information about the MPlayer-dev-eng mailing list