[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: Re: [xine-devel] Seeking problems
From:       tmattern () noos ! fr
Date:       2004-06-11 14:21:13
Message-ID: mnet2.1086963627.924.tmattern () noos ! fr
[Download RAW message or body]

Hi Mike,

> 
> > Hi,
> > 
> > Some demuxers return a error when seeking to the end of the stream (seek to pos \
> > 65535). I don't know if this has been specified, IMHO a demuxer should not fail \
> > to seek to a pos.
> 
> 	This is difficult to characterize. Remember, for some unknown
> reason, the xine engine chooses to transform the 0..65535 seek range into
> a stream offset. Thus, when you specify 65535, the demuxers are seeing a
> different offset depending on the file's size.

In my opinion, pos seeking (based on the file size) is useless/broken, as well as the \
position argument of the xine_get_pos_time function.

file pos seeking:
  I guess this has been designed for mpeg streams, because there is no header, no \
index, and they are interleaved. But it sucks with a non interleaved AVI with an \
index, what is the demuxer supposed to do in that case ?

get_pos_time (the file position argument):
  I think the concept is silly, audio and video are not interleaved with 0 pts diff \
inside a stream, so the current audio frame is not at the same position as the \
current video frame, especially with non interleaved stream, you know that better \
than me. There some hacks to not use audio frame position extrainfo if video frames \
report extrainfo. Some frontend use the position to display the slider, the result is \
a crappy slider that can accelerate due to the variable bitrate of the video, or stop \
if there is still frame, or jump strangely due to the switch from audio extrainfo to \
video extrainfo.

Sorry for this whining about the pos stuff, i have a bad day ;-)

> 	I have lobbied to change the internal protocol so that the engine
> passes the 0..65535 number straight through via start_pos. I got
> permission, I believe, but I have not been able to deploy the changes.

If the 0..65535 argument is relative to the stream duration and not to the stream \
size, I vote for that.

> > seek to pos 65535 test:
> > http://xinehq.de/~tmattern/report/seek_pos_65535.toxine/seek_pos_65535.toxine.html
> >  The problematic demuxers are:
> > asf       (works sometimes),
> > fli       (works sometimes)
> FLI is not supposed to be seekable and should ignore seek requests.

ok, so we have to find why it reports an error sometimes.

> > film      (one stream checked)
> Based on the same seeking algorithms as QT and should work.

maybe it's just an issue due to the 65535->file offset conversion, no ?

> > qt        (seems to always fail)
> This concerns me...

sam.

> > realaudio (one stream checked)
> > 
> > Some other problems detected with a stressing test:
> > http://xinehq.de/~tmattern/report/seek_stress.toxine/seek_stress.toxine.html
> > 
> > fli:    seems to fail at some random pos
> > idcin:  fails at pos 2000
> These 2 should not be seekable and should disregard seek requests in the
> first place.

ok.

> > film:   fails at pos 16000
> Cause for concern, FILM should have robust seeking.
> 
> > mve:    fails at pos 16000
> > or segfaults during xine_close()
> Interplay MVE or WC3 MVE? The latter should be seekable but not the
> former.

argl two different formats with the same extension ;<

> 	I am interested in addressing these issues. Though to be honest,
> it's a little frustrating because every time I go back and look at my
> demuxers, someone has monkeyed with the core engine again and changed the
> seeking/ flushing/ syncing protocol in some subtle way. I think that is
> how these breakages slip in.

hum.

> 	Thanks for the testing...

btw, the testsuite is currently broken, i will investigate during the weekend. And i \
can't test the new flac demuxer ! ;<

> --
> 	-Mike Melanson

cheers,
Thibaut



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel


[prev in list] [next in list] [prev in thread] [next in thread]