[Live-devel] Presentation timestamp - why wall clock? SR handling question too.

[Roland]

>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