>As for approach to deal with it. I simply have NO idea Roland... The
>problem is that it basically affects all data between (in your sample
>208 and 212) to go "bad" which is quite a large gap of course. I you
>have a briljant idea, i'll welcome it :D
I'm taking Ross's advice and liberally distrust the presentationTime ;-)
Algorithm goes as follows (pseudocode):
sink::sink()
{
m_offset = 0;
m_last = 0;
}
sink::onFrame(data, presentationTime, ...)
{
if(0 == m_offset)
{
m_offset = presentationTime;
m_last = 0;
}
gap = (presentationTime - m_offset) - m_last;
if((gap > one_second) || (gap < -one_second))
{
m_offset += gap;
}
m_last = presentationTime - m_offset;
StoreFrameInPlaybackBufferWithCorrectedTS(data, m_last); // assert(two
consecutive timestamps are no more than 1 second apart)
}
The code above takes care of the -4 second shift I'm seeing in my streams.
However, it is still possible for time to go backwards (although at most 1
second). I'm going to experiment with variations of the 2nd if() like this:
if((gap > (1 second/rtpsink:: rtpTimestampFrequency()) || (gap < 0)
// assert(consecutive frames are strictly ordered and at most 1 sample
apart)
It's not super nice, but it gets the job done.
cheers,
Roland
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
