<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] RTCP SR clock sync
diff</title></head><body>
<blockquote type="cite" cite>
<blockquote>This is incorrect. The information in incoming RTCP
"SR" packets is used to generate presentation times from
incoming RTP packets' timestamps. These presentation times -
like the RTP timestamps themselves - are (necessarily) based on the
sender's clock (because that was the only clock available to the
entity (the sender) that created the presentation times).<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Please point me at the section of RFC3550 that says that the RTCP SR
NTP timestamp is to be used for a presentation time.</blockquote>
<div><br></div>
<div>The text you quoted. Note that RTCP time synchronization is
also useful for *intra* media synchronization (i.e., even for an audio
stream only, or a video stream only).</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>By immediately adjusting the presentation
time based on the NTP timestamp the presentation times become
non-monotonic and the receiver does not know much much when to display
the new stream in relation to the old stream.</blockquote>
<div><br></div>
<div>Your real problem is with the small number of unsynchronized
('guessed') presentation times that the RTP client code returns before
RTCP synchronization begins. As I noted in my earlier message,
if these are a problem for your client application, you can use the
function "RTPSource:: hasBeenSynchronizedUsingRTCP()" to
distinguish between the two (and reject the initial, guessed times if
necessary).</div>
<div><br></div>
<div>(This will be my last posting on this thread.)</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>