[Live-devel] timekeeping in VLC

[Ross Finlayson]

>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()".

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.)

>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/