Re: [xine-devel] $500 offer for a fix/patch to xine

[Alien <ali...@us...>]

in any case; a seek with customizable time-out, will solve your problem jus=
t=20
fine...

Op maandag 12 december 2005 22:32, schreef Michael Anderson:
> Hi,
>
> Thanks for the comments.  Perhaps I wasn't clear enough earlier...  The
> problem is not the accuracy of the seek.  Even if, worst case, it seeks
> backwards when we want it to go forwards that's not a major problem.  In
> other words, if we start at position 1.0 and try to seek 1.1, then 1.2,
> then 1.3, it's ok if it actually seeks to 0.95, then 1.15, then 1.28, then
> 1.4. The user still sees forward movement.  We're only doing 6 or so still
> frames a second and it's imperceptible to the user whether the seeks are
> precise. What matters is the consistent frame rate.
>
> So the problem we're having is not the accuracy of xine_play(); it is that
> with recent versions of Xine, xine_play() is *locking up*, blocking the
> thread for up to 1,500ms.  If you log the time, then call xine_play, then
> log the time again you see that sometimes xine_play only took 100ms to
> execute, but other times it takes 1,500 ms to execute.  And that only
> happens when we turn the metronome buffer on so we show still frames not
> motion.  With the old Xine .97 this didn't happen--xine_play() always took
> roughly 100ms to execute and therefore the framerate during fast
> forward/rewind was rhythmic and consistent.  *This* issue (the locking up
> of xine_play blocking our thread) is what makes the system appear broken.=
=20
> The user will see a frozen frame for 1.5 seconds and think it's 'locked u=
p'
> so they keep hitting fast forward more.  Then suddenly xine_play returns
> and the thread comes back to life and it will do 6 fast seeks before
> locking up again, maybe for 1,000 ms this time.
>
> With our old version based on Xine .97, I'm not sure that the seeks were
> any more accurate, but that's not important--they were rhythmic because
> xine_play() always returned within 100ms; it didn't block for long periods
> like it does now.
>
> Michael R gave us a sample app that did nothing but load a stream and then
> seek every 100ms; it didn't render or have any UI, just create stream and
> seek in a loop.  In this case the seeks were again consistent with both
> Xine .97 and Xine 1.02.  This would indicate the core engine and the mpeg
> decoding process is not the problem.  It's either something in the
> rendering, or more likely, something in our code that we're doing that is
> 'upsetting' the xine engine and making it lock up like this.
>
>
> Michael
>
> -----Original Message-----
> From: Thibaut Mattern [mailto:thi...@gm...]
> Sent: Monday, December 12, 2005 9:45 AM
> To: Michael Anderson
> Cc: James Courtier-Dutton; xin...@li...
> Subject: Re: [xine-devel] $500 offer for a fix/patch to xine
>
> Hi all,
>
> On 12/10/05, Michael Anderson <mic...@pl...> wrote:
> > > Please [post the code] and note, that the "seek" function works
> >
> > differently depending on the type of media file used
> >
> > I made a web page that has links to all the code and sample media files.
> > However the problem is unrelated to the media file.  With our old xine
> > .97-based version, it worked on all files (dvd, mpg, avi, etc), and with
>
> the
>
> > new 1.02-based version, it doesn't work on any files.
> >
> > http://plutohome.com/download/docs/xine/xine.html
>
> xine official seeking policy is to seek to the nearest keyframe before
> the seekpoint. So when you try to seek to +5 seconds, it seeks
> backward sometimes with formats like avi, asf, mov.
> I had some discussion months ago to change this policy to something
> more usable, i mean the nearest keyframe before the seekpoint when
> seeking backward, and the nearest keyframe after the seekpoint when
> seeking forward.
> But if we want a more precise seeking, the current policy is IMHO the
> right thing to do at the demuxer level, the engine should decode and
> discard frames until we reach the seekpoint, then restart the clock.
> Depends if you want fast seeking or precise seeking.
>
> I don't even talk about the "seek, decode and display one frame"
> feature/hack to emulate fast forward/rewind from Miguel, that's
> another problem.
>
> cheers,
> Thibaut
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel