[Live-devel] RTCP SR clock sync diff

Ross Finlayson finlayson at live555.com
Wed Jun 25 08:53:04 PDT 2008


>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).
>
>
>Please point me at the section of RFC3550 that says that the RTCP SR 
>NTP timestamp is to be used for a presentation time.

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


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

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

(This will be my last posting on this thread.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20080625/0a646096/attachment.html>


More information about the live-devel mailing list