Re: [xine-devel] metronom adjustments in flush_engine and seeking

[Miguel F. <mi...@ce...>]

Hi,

On Sat, 2002-05-25 at 18:00, Staszek Pasko wrote:
> 
> There is a problem with the seeking algorithm, that shows
> up when trying to continuosly seek over a movie (jump very little
> ahead very often). Try to hold the position indicator with a mouse
> and drag it. The result is that there will be a lot of skipping,
> no video, audio breaking. Everything comes back to normal after
> the final position is reached. I think it would be much nicer to
> display _something_ through this process. Now - the cause of this
> is most probably the xine_flush_engine routine. What it does is:
> clears input buffers
> tells decoders to reset themselves
> tells metronom to set new pts to current time (ie. after the seek).

I'm glad that i moved that code to outside the demuxers! Any
improvements to it should be much easier now.
 
> Now, what it does not do is to remember about already decoded frames
> in the output buffers. Now, when this operation is performed second
> time in a row, and the decoders did not have time to fill the output
> buffers there is a situation where newest output buffers hawe pts way
> below the current time (which was just updated).

I would say this is intentional: current time is updated exactly to
force discarding all output buffers. specially for audio, any output
buffer might represent a long delay in seeking...

> This process repeats
> forever, and only when the users stops for a moment, the decoders
> get a little time to fill the buffers and finally something is played.

weird, at least for me some frames seems to be displayed during the
seek. it's true that most will be discarded or not decoded, but some
"lucky" frames escaped from flush_engine! ;)

> I don't know what is the best solution to this problem. The 'cleanest'
> way would be to put discontinuity control buffers in the input queue, and
> this way _perhaps_ it would work. Another way is to ensure that at least
> one frame was already displayed (now, that's a bit of work).
> I'd just like to know whether anybody is taking care of this issue or
> perhaps someone just has an idea how to fix it properly... ?


Ensure that one frame is displayed? hmm, it doesn't sound good to me (to
make demuxer thread depend on output threads)...

I must say i failed to see exactly what the problem is. IMHO during the
seek (while user is moving the slider) he doesn't expect to _watch_ the
movie. Some casual displayed frames seems good to me. When he stops
moving the slider everything should work just fine.


regards,

Miguel