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

[gbazin at altern.org]

>
>but what about when the seeks happen often?
...
>then it seems to me that this could be a problem, i.e. 
>we're resetting the clock all of the time, and never 
>letting the clock expire naturally, so we in essence have 
>no clock anymore.

I don't think it should be a problem.
The clock should be restored properly the first time you 
call input_ManageClockRef() after a seek so the next sample 
you will be playing should be properly time-stamped (unless 
the demux is buggy and doesn't call input_ManageClockRef() 
when it should).

If you do lots of seeks without actually feeding anything 
to the decoder's fifo then you don't need the clock anyway. 
And next time you need it will be restored from the PCR 
info contained in the stream so it should get the right 
value independantly of how many seeks you did.

Actually, the problem you are seeing might also just be a bad PCR computation in the mpeg audio demuxer.

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>