[vlc-devel] re : At last, the problem! Now, what to do?

[gbazin at altern.org]

> This is a problem with input_Seek(), my ff / rewind code 
> exacerbates it because that's how it does its' thing.  I 
> want to fix this, but i'm not sure how yet.  Any ideas?  
> Should seeks be constrained by input_ManageClockRef(), as 
> reads are (by the demux module)?

A seek operation should normally reset the input's clock so new data is properly time-stamped. This should be enough to prevent the problem you are describing so there has to be a bug somewhere which let's improperly time-stamped samples pass through.

Seeks shouldn't have to be constrained by input_ManageClockRef(). This function is only used to regulate the reading pace of the demux (well, it is also used to detect PCR gaps and adjust the input's clock in these cases but this operation is done by the next demux loop after the seek).

You could maybe try to put a printf in src/input/input_clock.c:ClockNewRef() to check when the clock is reinitialized, as well as print the time-stamps of the samples the demux puts in the decoder fifo.

Hope this helps,

--
Gildas
-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>