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/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
