[Live-devel] timekeeping in VLC

[Derk-Jan Hartman]

On 18-jan-2007, at 23:07, Ross Finlayson wrote:
>> I was further investigating the problems VLC has with timekeeping on
>> mostly QTSS and DSS streams. As such I was reading Appendix B of the
>> RTSP spec. I'm quite sure we are doing some stuff wrong in VLC and I
>> will fix it. But in order to fix it, I need to retrieve the "sequence
>> number" of the RTP packet and match it against the sequence number
>> mentioned in the RTP-Info field. Is there an easy way to retrieve
>> that last value from liveMedia ? I couldn't find it in the sources,
>> and without that, I can't exactly know from which packet I need to
>> start counting the NPT clock again after play, pause, seek.
>
> DJ,
>
> I'm not totally convinced that you really need the "RTP-Info" header
> information, because (assuming that RTCP is also being received) the
> LIVE555 library will continue to generate accurate time-synchronized
> presentation times (and pass it to the "StreamRead()" function in
> "live555.cpp").  However, perhaps there is a window of time - after
> resuming from a pause or seek but before receiving the next RTCP "SR"
> - in which you need this...  In this case, you can get the "RTP-Info"
> data using "MediaSubsession::struct rtpinfo", and the sequence number
> of the most recently-received RTP packet using "RTPSource::
> curPacketRTPSeqNum()".

I'll explain further. The only way you can calculate the current NPT,  
you need to base it on the NPT specified in the PLAY response.  
However. if you seek, you might still receive RTP data from before  
the seek. So in order to determine the exact point from which i have  
to continue updating my NPT counter during playback, i need to know  
when i'm at the point in the data at which the "response" NPT is  
reached. As far as i know, i can only do this is by taking the value  
from the RTP-Info field and compare it to the data seq nr of the  
currently received data.

thanks for the answer, i'll see if i can fix this stuff in VLC.

> BTW, if you do a 'seek' within a stream from a DSS/QTSS, then you may
> be tripping into the following bug (more than two years old) in DSS.
> (I'm not sure if it has been fixed recently, but I suspect not.)

I checked the MacWorld stream, and it seems that this stream has  
continuous PTS timeline wherever I seek.

DJ

>> Date: Wed, 26 Jan 2005 07:46:53 -0800
>> To: streaming-server-dev at lists.apple.com
>> From: Ross Finlayson <finlayson at live.com>
>> Subject: DSS RTP timestamp bug when 'seeking'
>> Cc:
>> Bcc:
>> X-Eudora-Signature: <Alternate>
>>
>> The DSS has a significant bug in the way that it handles RTSP 'seek'
>> operations - i.e., using the RTSP "PLAY" command with a "Range:"
>> header.  It turns out that the DSS (incorrectly) changes its
>> outgoing RTP timestamps to match the seeking that it performs.
>>
>> Suppose, for example, that I "PLAY" a stream (using "Range:
>> npt=0.000-") for three seconds, and then issue another "PLAY"
>> command, using "Range: npt=1.000-", i.e., to seek backwards two
>> seconds, to the one second mark.  It turns out that the DSS's
>> outgoing RTP timestamps also shift backwards two seconds.
>>
>> THIS IS WRONG!  RFC 3550, section 5.1 specifically says that the RTP
>> timestamp "MUST be derived from a clock that increases monotonically
>> and linearly in time".
>>
>> The RTP timestamp is supposed to represent the stream's
>> 'presentation time' - i.e., the time when audio or video frames
>> should be rendered by the receiving client(s).  This is independent
>> of any 'seeking' that may (or may not) have happened within the
>> underlying media (in the server's file system) in order to generate
>> the stream.
>>
>> (I have tested this with "DSS/5.x (Build/475; Platform/FreeBSD;
>> Release/Development;")
>
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel