DVD tools for Linux

Hi James, hi lists,

On Sun, 21 Oct 2001, James Courtier-Dutton wrote:

> I have just checked in some new code for libspudec and navdvd
> into the CVS.

very nice work. Heiko and I have been thinking about a schedule for the
upcoming 1.0 release which basically looks like this:

11.11.2001 - feature freeze, I'll cut out a "1.0-stabel" branch in
             the xine CVS

08.12.2001 - 1.0 release if all goes well

I think it would be nice to have a 1.0 navdvd release at that time too. As
far as I can tell, you have made great progress on your plugin, very nice
work so I think this timeframe is reasonable - but I'd like to hear your
opinion on this - do you think we can have a rock-stable release at the
beginning of december (or at least before xmas) ?

BTW: The feature freeze will only affect the xine-lib and xine-ui modules,
not the upcoming kxine (qt/kde frontend), gxine (gnome frontend) and
xine-plugin (netscape/mozilla xine plugin) frontends or any other more or
less external work.

On my personal wishlist (until 11.11.2001) are, btw:

- a config dialog in xine-ui
- user-configurable keyboard mappings (~/.xinekeymap)
- streaming support (that's what I'm working on at the moment)
- osd ?

Everybody keep up the good work and let's hope we'll see a working linux
kernel until xmas again.

   Guenter

--
time is a funny concept

On Sun, 21 Oct 2001, Guenter Bartsch wrote:

> Hi James, hi lists,
>
> On Sun, 21 Oct 2001, James Courtier-Dutton wrote:
>
> > I have just checked in some new code for libspudec and navdvd
> > into the CVS.
>
> very nice work. Heiko and I have been thinking about a schedule for the
> upcoming 1.0 release which basically looks like this:
>
> 11.11.2001 - feature freeze, I'll cut out a "1.0-stabel" branch in
>              the xine CVS
>
> 08.12.2001 - 1.0 release if all goes well
>
> I think it would be nice to have a 1.0 navdvd release at that time too. As
> far as I can tell, you have made great progress on your plugin, very nice
> work so I think this timeframe is reasonable - but I'd like to hear your
> opinion on this - do you think we can have a rock-stable release at the
> beginning of december (or at least before xmas) ?

Well feature-wise. The only features I think we are lacking for a 1.0
release are angles, seeking and keyboard-based menu nav.

All of these require some changes to xine:

angles - Some GUI chages (perhaps xine_select_video_channel() API
functions as well).

seeking - Another Input API change but this time allow input plugins to do
the seeking rather than Xine stop them and re-start them.

keyboard-based nav - Make Xine pass the keyboard events to the plugin as
the handle_input_event API function implies it does.

These are relatively minor problems so should be possible to achieve
before Xmas.

As regards stability, I've very rarely had a segfault which was a direct
cause of the later released dvdnav plugins but an audit for common causes
(e.g. not trapping errors etc) should probably be done at some point.

What dvdnav /really/ needs is compatability testing. If all memebers of
the xine list could test their DVDs with xine-dvdnav we could probably
work out the major compat. problems which remain.

Cesar Talon has done a great job creating a way for people to report DVDs
which work/don't work which is here:

http://dvd.sourceforge.net/dvd_titles.php

As long as I don't se Mr Goatse popping up anywhere, people can add
entries to this and they will appear in a MySQL datatbase for perusal by
the dvdnav developers.

> BTW: The feature freeze will only affect the xine-lib and xine-ui modules,
> not the upcoming kxine (qt/kde frontend), gxine (gnome frontend) and
> xine-plugin (netscape/mozilla xine plugin) frontends or any other more or
> less external work.
>
> On my personal wishlist (until 11.11.2001) are, btw:
>
> - a config dialog in xine-ui
> - user-configurable keyboard mappings (~/.xinekeymap)
> - streaming support (that's what I'm working on at the moment)
> - osd ?
>
> Everybody keep up the good work and let's hope we'll see a working linux
> kernel until xmas again.

-- 
Rich Wareham

http://www.srcf.ucam.org/~rjw57/...
...sc/   -- Linux Software for the Cambridge University Smartcard
...xine/ -- Xine HOWTO

Hi,

> angles - Some GUI chages (perhaps xine_select_video_channel() API
> functions as well).

humm - mpeg files can have multiple video channels too so I'd expect a
xine_select_video_channel() function in the interface to select one of
these (but I have never seen files with more than one video channel - dvb
perhaps?). For the angle stuff, maybe we could get away with just defining
some events / keys for this?

> seeking - Another Input API change but this time allow input plugins to do
> the seeking rather than Xine stop them and re-start them.

I still don't see how this could work. Think of the file plugin - how
should the file plugin do seeking in an avi or mov file ?

Is it really so hard to implement seeking in dvdnav with the current api?

I've just added a small function to xine so the ui can check if the stream
is seekable at the moment. So, dvdnav could set it's capabilities to
non-seekable while in menu mode and to seekable otherwise.

I don't know much about IFO navigation - but what I understand from the
docs you have on dvd.sf.net "cells" are the smallest units on DVDs while
are simply played begin-to-end without any interference from the vm. So
seeking within the current cell should be very easy to implement - at
least if my assumption is true. Just make sure you keep the current state
of the vm when dvdnav is closed and check on the next open if the plugin
is already initialized. Then seek within the current cell.

One step further would be chapter parsing - on a seek you basically would
have to step back to the beginning of the current chapter (that should be
possible as there are functions in ogle to skip to the next/prev chapter)
and then do a loop like this:

pos = beginning_of_chapter ();

while (pos < seek_pos) {

  if (cell_end_reached())
    do_vm_stuff	();

  pos ++;

}

(basically simulate playback of the chapter without actually reading and
handing over the video data to the xine engine)

> keyboard-based nav - Make Xine pass the keyboard events to the plugin
> as the handle_input_event API function implies it does.

oki, I've added events for prev/next chapter now and all the input events
are mapped to the numpad (this should be configurable soon).

keep up the great work, comments on my proposals are welcome

   Guenter

--
time is a funny concept

> I don't know much about IFO navigation - but what I understand from the
> docs you have on dvd.sf.net "cells" are the smallest units on DVDs while
> are simply played begin-to-end without any interference from the vm. So
> seeking within the current cell should be very easy to implement - at
> least if my assumption is true. Just make sure you keep the current state
> of the vm when dvdnav is closed and check on the next open if the plugin
> is already initialized. Then seek within the current cell.
>
A "cell" is not the smallest element.
I don't know the real name for it, but I call it a "sub-cell" or "NAV cell".
Each "cell" has a number of "NAV cells" inside it in the mpeg stream.
When playing the stream, not all NAV cells are played.
Each "NAV cell" will have a pointer telling us where on the disc the next
"NAV cell" is, until it reaches the end of the "cell". This also a bit like
how angles are handled.

A "Chapter" contains a number of cells.

We know how long a "Chapter" is in time, but not in number of sectors. (Any
length of time).
We know how long a "Cell" is in time, but not in number of sectors.
(Normally about 1-2 mins long)
We know how long a "NAV Cell" is in time, and also in number of sectors.
(Normally about 1 second long)

So, if xine can send us a "seek_to_time_offset" instead of
"seek_to_file_offset", we can do it.
If the new "xine_is_stream_seekable" could return an indication as to
whether the seek should be via "file offset" or "time offset", then maybe
xine could make different calls to the input plugin depending on the two
different modes.
This "seek_to_time_offset" might be useful for Video on demand streaming
control as well when the video on demand server will know about
time_offsets, but not file_offsets.

I suggest we have a Prev/Next Chapter button, and then a "seek time within
chapter" seek function.

Cheers
James

On Mon, 22 Oct 2001, James Courtier-Dutton wrote:

> > I don't know much about IFO navigation - but what I understand from the
> > docs you have on dvd.sf.net "cells" are the smallest units on DVDs while
> > are simply played begin-to-end without any interference from the vm. So
> > seeking within the current cell should be very easy to implement - at
> > least if my assumption is true. Just make sure you keep the current state
> > of the vm when dvdnav is closed and check on the next open if the plugin
> > is already initialized. Then seek within the current cell.
> >
> A "cell" is not the smallest element.
> I don't know the real name for it, but I call it a "sub-cell" or "NAV cell".
> Each "cell" has a number of "NAV cells" inside it in the mpeg stream.

Just for your info, I've just looked in DVD Demystified for the
'definitive answer':

It is a VOBU (Video Object Unit) which contains a number (normally 1)
ILVUs (InterLeaved Video Units)

-- 
Rich Wareham

http://www.srcf.ucam.org/~rjw57/...
...sc/   -- Linux Software for the Cambridge University Smartcard
...xine/ -- Xine HOWTO

Mon Oct 22 2001, Guenter Bartsch wrote:
> Hi,
> 
> > angles - Some GUI chages (perhaps xine_select_video_channel() API
> > functions as well).
> 
> humm - mpeg files can have multiple video channels too so I'd expect a
> xine_select_video_channel() function in the interface to select one of
> these (but I have never seen files with more than one video channel - dvb
> perhaps?). For the angle stuff, maybe we could get away with just defining
> some events / keys for this?
> 
> > seeking - Another Input API change but this time allow input plugins to do
> > the seeking rather than Xine stop them and re-start them.
> 
> I still don't see how this could work. Think of the file plugin - how
> should the file plugin do seeking in an avi or mov file ?
> 
How can Xine do it then?  I guess that you use some tricks with the 
demuxer and such.. and don't want the input plugins to know anything 
about the data that they read?  In that case the thing with the dvdnav
plug in is that it does know better than Xine how to do the seeking.

> Is it really so hard to implement seeking in dvdnav with the current api?
> 
> I've just added a small function to xine so the ui can check if the stream
> is seekable at the moment. So, dvdnav could set it's capabilities to
> non-seekable while in menu mode and to seekable otherwise.
> 
Why should there be any difference?

> I don't know much about IFO navigation - but what I understand from the
> docs you have on dvd.sf.net "cells" are the smallest units on DVDs while
> are simply played begin-to-end without any interference from the vm. So
> seeking within the current cell should be very easy to implement - at
> least if my assumption is true. 
>
Which documents are that?  You mean the ones linked from dvd.sf.net
but really on aol.com?

Cells are not the smalles unit.. they are the smalles unit that can be
pointe to/jumped to by DVD instructions. The smalles part is VOBU, a
VOBU is mostly 0.5 seconds of video/audio data and they are allocated
in one continues block.  A Cell consists of one or more VOBUs, and
they migh have VOBUs interleaved that are not part of that Cell.  It's
also the case that there could be a DVD command and/or button with in
a Cell that can change the playback without the cell reaching the end.
It's not a bit probvlem though.  That a title has a Time map table
should be a good indication that you are allowed to seek freely with
in all the Cells of that PGC, need to rember to update PG number ,
Cell number and perhaps ofther internal state when doing this.
Seeking with in a cell is real easy because there is a table of offset
pointers for different times in the NAV blocks (there is a NAV block
first in every VOBU) for exact seeking you migh need to read a few of
them, or use the time map table found in the IFO file.

> Just make sure you keep the current state of the vm when dvdnav is 
> closed and check on the next open if the plugin
> is already initialized. Then seek within the current cell.
> 
I don't know much about how Xine work but why should it be necessary to
close and re open the plugin?  Just query it about how long the current
segment is (you get back say 1h35m26s) and then you simply ask it to
jump to a specified time (i.e. 0h20m00s) or even a relative time.

-- 
Håkan Hjort
d95hjort@...

Hi James,

On Mon, 22 Oct 2001, James Courtier-Dutton wrote:

[... cell not smallest unit ... ]

oki, let's forget about the cell-based navigation and talk about the
chapter-based solution

> A "Chapter" contains a number of cells.
>
> We know how long a "Chapter" is in time, but not in number of sectors. (Any
> length of time).

humm - I don't understand why you don't know how many sectors a chapter
contains - you could simply count them by simulating the playback process
of the complete chapter and counting the number of sectors you access -
a similar algorithm to the one I proposed to implement seeking. Is there
any problem that could prevent this from working?

> So, if xine can send us a "seek_to_time_offset" instead of
> "seek_to_file_offset", we can do it.
> If the new "xine_is_stream_seekable" could return an indication as to
> whether the seek should be via "file offset" or "time offset", then maybe
> xine could make different calls to the input plugin depending on the two
> different modes.

humm - I don't see how this would fit into the xine architecture, seeking
is done at the demux level and the demuxer transforms times to file
offsets, ususally based on a bitrate estimation (this doesn't have to be
very precise btw. a accuracy of +- 1 sec is more than enough).

> I suggest we have a Prev/Next Chapter button, and then a "seek time within
> chapter" seek function.

yep - the prev/next chapter button is already implemented on the xine
side (although I still propose you implement playlist support too), now we
need to find a way to implement the seeking in dvdnav.

Cheers,

   Guenter

--
time is a funny concept

On Mon, 22 Oct 2001, Guenter Bartsch wrote:

> Hi James,
>
> On Mon, 22 Oct 2001, James Courtier-Dutton wrote:
>
> [... cell not smallest unit ... ]
>
> oki, let's forget about the cell-based navigation and talk about the
> chapter-based solution
>
> > A "Chapter" contains a number of cells.
> >
> > We know how long a "Chapter" is in time, but not in number of sectors. (Any
> > length of time).
>
> humm - I don't understand why you don't know how many sectors a chapter
> contains - you could simply count them by simulating the playback process
> of the complete chapter and counting the number of sectors you access -
> a similar algorithm to the one I proposed to implement seeking. Is there
> any problem that could prevent this from working?

ermmm... ogle_get_current_program_length() returns the number of sectors
in the current program.... so we do :)

-- 
Rich Wareham

http://www.srcf.ucam.org/~rjw57/...
...sc/   -- Linux Software for the Cambridge University Smartcard
...xine/ -- Xine HOWTO

Hi there,

On Mon, 22 Oct 2001, H}kan Hjort wrote:

> > > seeking - Another Input API change but this time allow input plugins to do
> > > the seeking rather than Xine stop them and re-start them.
> >
> > I still don't see how this could work. Think of the file plugin - how
> > should the file plugin do seeking in an avi or mov file ?
> >
> How can Xine do it then?  I guess that you use some tricks with the
> demuxer and such.. and don't want the input plugins to know anything
> about the data that they read?

exactly. For many file formats timing information is available in the
system layer (avi for example), for others the demuxer estimates the
bitrate of the stream and uses this information to convert time offsets to
file offsets.


> In that case the thing with the dvdnav plug in is that it does know
> better than Xine how to do the seeking.

right - the question is if this more accurate seeking function is really
needed - and I think the answer is no. Most users won't care if the
seeking function is no more accurate than +- 1 sec, they basically want to
skip "a bit forward/backward" and this definitely can be done based on the
estimated bitrate information.

> > I've just added a small function to xine so the ui can check if the stream
> > is seekable at the moment. So, dvdnav could set it's capabilities to
> > non-seekable while in menu mode and to seekable otherwise.
> >
> Why should there be any difference?

well this is of course up to the dvdnav plugin, but do you really think it
makes sense to seek within a dvd menu?

> > Just make sure you keep the current state of the vm when dvdnav is
> > closed and check on the next open if the plugin
> > is already initialized. Then seek within the current cell.
> >
> I don't know much about how Xine work but why should it be necessary to
> close and re open the plugin?

this is, of course, a design issue. As most of the engine has to be
restarted to seek to another position in the stream (audio/video decoder
have to be resetted for example) I came to the conclusion that the xine
api doesn't need an extra seek function but can simply have one single
xine_open(...) function where you specify the file or time offset you want
playback to start from.

Actually there is a small hack in the xine engine at the moment which
checks if the new mrl is the same as the old one and in that case calls
input_plugin->stop instead of input_plugin->close so the input plugin
knows this is only a seek operation. But, I don't think this makes any
real difference (that's why I objected this hack for a long time ;)).

> Just query it about how long the current segment is (you get back say
> 1h35m26s) and then you simply ask it to jump to a specified time (i.e.
> 0h20m00s) or even a relative time.

well most input plugins don't know anything about time, but if this is
possible it should be easy to implement file offset based seeking too; if
there shouldn't be any better solution dvdnav could simply assume a
certain bitrate of the stream and transform sector offsets to time offsets
using this bitrate (therefore reversing what happens in the demuxer)

Cheers,

   Guenter

Hi,

I don't know much about DVD structure but i want to share some comments...I see Guenter tends to be overconservative sometimes but i'm with him in this case: why do we need a new api for input, changing all demuxers to pass the time seek info down?

At general rule i think xine is absolutely right. input shouldn't know anything about time seeking into the stream. period. imho, we would regret in the future if we assume the other. 

dvd may be a special case (input knows better than demux) however, but it's also up to input to tell whatever he wants about size and position. why can't dvdnav report choosen values for size, position, etc to revert the demux "estimation magic" (like values relative to a chapter)?

I also remember using an old dvd plugin somewhere that did the seek pretty well, the previous and next buttons didn't change the vob but a "scene unit", index, cell, whatever is this thing called...(this may be the most important feature for the user, even if time seek is disabled)

Regards,

Miguel

>> How can Xine do it then?  I guess that you use some tricks with the
>> demuxer and such.. and don't want the input plugins to know anything
>> about the data that they read?
> 
> exactly. For many file formats timing information is available in the
> system layer (avi for example), for others the demuxer estimates the
> bitrate of the stream and uses this information to convert time offsets
> to file offsets.
> 
> 
>> In that case the thing with the dvdnav plug in is that it does know
>> better than Xine how to do the seeking.
> 
> right - the question is if this more accurate seeking function is
> really needed - and I think the answer is no. Most users won't care if
> the seeking function is no more accurate than +- 1 sec, they basically
> want to skip "a bit forward/backward" and this definitely can be done
> based on the estimated bitrate information.
> 
>> > I've just added a small function to xine so the ui can check if the
>> > stream is seekable at the moment. So, dvdnav could set it's
>> > capabilities to non-seekable while in menu mode and to seekable
>> > otherwise.
>> >
>> Why should there be any difference?
> 
> well this is of course up to the dvdnav plugin, but do you really think
> it makes sense to seek within a dvd menu?
> 
>> > Just make sure you keep the current state of the vm when dvdnav is
>> > closed and check on the next open if the plugin
>> > is already initialized. Then seek within the current cell.
>> >
>> I don't know much about how Xine work but why should it be necessary
>> to close and re open the plugin?
> 
> this is, of course, a design issue. As most of the engine has to be
> restarted to seek to another position in the stream (audio/video
> decoder have to be resetted for example) I came to the conclusion that
> the xine api doesn't need an extra seek function but can simply have
> one single xine_open(...) function where you specify the file or time
> offset you want playback to start from.
> 
> Actually there is a small hack in the xine engine at the moment which
> checks if the new mrl is the same as the old one and in that case calls
> input_plugin->stop instead of input_plugin->close so the input plugin
> knows this is only a seek operation. But, I don't think this makes any
> real difference (that's why I objected this hack for a long time ;)).
> 
>> Just query it about how long the current segment is (you get back say
>> 1h35m26s) and then you simply ask it to jump to a specified time (i.e.
>> 0h20m00s) or even a relative time.
> 
> well most input plugins don't know anything about time, but if this is
> possible it should be easy to implement file offset based seeking too;
> if there shouldn't be any better solution dvdnav could simply assume a
> certain bitrate of the stream and transform sector offsets to time
> offsets using this bitrate (therefore reversing what happens in the
> demuxer)
> 
> Cheers,
> 
>    Guenter
> 
> 
> 
> _______________________________________________
> xine-devel mailing list
> xine-devel@...
> https://lists.sourceforge.net/lists/listinfo/xine-devel

> 
> ermmm... ogle_get_current_program_length() returns the number of sectors
> in the current program.... so we do :)
> 
> -- 
> Rich Wareham
> 
I did not know that.
So we have : -
ogle_get_current_pos_in_program
ogle_get_current_program_length

All we need now is to implement
ogle_set_current_pos

Any clues how?

Cheers
James

On Mon, 22 Oct 2001, Miguel Freitas wrote:

> Hi,
>
>
> At general rule i think xine is absolutely right. input shouldn't know
> anything about time seeking into the stream. period. imho, we would
> regret in the future if we assume the other.
>

Actually I just wanted a way for the input plugin to know when you are
seeking rather than closing/starting. The stop vs. close API seems OK
IMHO.

Rich

-- 
Rich Wareham

http://www.srcf.ucam.org/~rjw57/...
...sc/   -- Linux Software for the Cambridge University Smartcard
...xine/ -- Xine HOWTO

On Mon, 22 Oct 2001, James Courtier-Dutton wrote:

> I did not know that.

Isn't it amazing what appears in CVS every now and again without people
noticing :)

> So we have : -
> ogle_get_current_pos_in_program
> ogle_get_current_program_length
>
> All we need now is to implement
> ogle_set_current_pos
>
> Any clues how?

Well my first thought was to see if the magic CVS fairy would leave me a
present :)

Second thought is that it would simply find the cell corresponding to the
requested block and set cellN appropriately. This may be enough, or
you could always search through the VOBUs for the nearest one. Then just
call ogle_do_post_jump.

However, I wanted to wait until I knew how seeking was to work before
doing this. I'm currently looking to see why the audio selection mechanism
is broken _AGAIN_ :(.

I think I might leave it and see if the magic CVS fairy visits me in the
night :)

Rich

-- 
Rich Wareham

http://www.srcf.ucam.org/~rjw57/...
...sc/   -- Linux Software for the Cambridge University Smartcard
...xine/ -- Xine HOWTO

> However, I wanted to wait until I knew how seeking was to work before
> doing this. I'm currently looking to see why the audio selection mechanism
> is broken _AGAIN_ :(.
>
I just thought I just fixed the audio selection bit.
What is wrong with the current CVS.
The fix involved changing xine as well as navdvd.

Cheers
James