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)
>> 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
> xine-devel mailing list