[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