[Live-devel] Seeking with live.com library

[Ross Finlayson]

At 08:43 AM 8/21/2005, you wrote:
>Hi all,
>In the last couple of days I've been working a little bit with seeking
>rtsp on-demand streams.
>When the RTPInfo data is present (the rstp server indicates in the answer
>to the play command the first RTSP packets after the resync point)
>everything is OK, but unfortunately rtpinfo is not mandatory.
>Right now, I'm using DSS 5.5.1, and RTPInfo is present only for UDP
>streaming, and for TCP streaming in extreme situations (like seeking
>at intervals of <100msec). I suppose that there might be some race
>condition in DSS.
>Anyone has any idea/opinion about this problem?

There is a known bug in the DSS that may be related to your problem.

Here, FYI, is a bug report that I submitted to Apple's 
"streaming-server-dev" mailing list back in June.  However, Apple is 
pretty much useless at fixing DSS and Quicktime bugs, so I don't have 
any confidence that this will get fixed.

Note: Any follow-up messages should go to one of Apple's mailing 
lists - not this list - as this is not a problem with the "LIVE.COM 
Streaming Media" code.

[My bug report from 6/2005:]

>DSS (version 5.x, Build/475, and apparently earlier versions also) 
>has a bug in the way it generates the RTP-timestamp-to-NTP-time 
>mapping in RTCP Sender Report ("SR") packets, if the RTP/RTCP stream 
>is carried within the RTSP TCP connection (as described in RFC 2326, 
>section 10.12).  The problem occurs *only* with RTP/RTCP-over-TCP 
>streaming.  For RTP/RTCP-over-UDP streaming, there is not a problem.
>
>I believe that the problem occurs with any DSS stream; however, for 
>illustration, I will use the hinted file at 
><http://www.live.com/ct.mov> as an example.
>
>When this file is streamed over UDP, the RTCP "SR"s are 
>OK.  However, when this file is streamed over TCP, the RTCP "SR"s 
>appear as follows:
>
>1/ The first "SR" contains a reasonable RTP-timestamp-to-NTP-time 
>mapping (the NTP time is about 1 second less than the time that the 
>RTP packet with the corresponding RTP timestamp was received).
>
>2/ The second "SR" - which arrives about 13 seconds later, and which 
>contains a RTP timestamp that indicates a difference of about 14 
>seconds from the previous "SR" - contains a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>3/ The third "SR" - which arrives about 7 seconds later, and which 
>contains a RTP timestamp that indicates a difference of about 14 
>seconds from the previous "SR" - contains a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>4/ The fourth "SR" - which arrives about 7 seconds later, and which 
>contains a RTP timestamp that indicates a difference of about 14 
>seconds from the previous "SR" - contains a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>5/ The fifth "SR" - which arrives about 3 seconds later, and which 
>contains a RTP timestamp that indicates a difference of about 10 
>seconds from the previous "SR" - contains a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>6/ The sixth "SR" - which arrives about 4 seconds later, and which 
>contains a RTP timestamp that indicates a difference of about 7 
>seconds from the previous "SR" - contains a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>7/ The seventh and following "SR"s are OK: They arrive about 7 
>seconds apart,  contain a RTP timestamp that indicates a difference 
>of about 7 seconds from the previous "SR", and a NTP time that is 7 
>seconds later than that in the previous "SR".
>
>Therefore, the first, seventh and following "SR"s are OK; the second 
>through sixth "SR"s are bad.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>