[Live-devel] RTCP SR clock sync diff

[Mike Frantzen]

The RTCP SR NTP timestamp is only valid in direct comparison with a NTP
timestamp from another stream of the same reference clock. So you can use it
to synchronize the presentation times of multiple streams in the same
session. You're not supposed to use it to directly generate a presentation
time since you have no guarantee that you and the sender share a reference
clock.


The fSyncTime/fPresentationTime members are both being overloaded to be both
the multi-stream synchronization time and the presentation time. It works
great when the sync time and pts have the same reference clock. I tried to
preserve this behavior with my diff.


In an ideal world multiple RTP/RTCP streams would be grouped together. You
would compare their NTP timestamps and use the results to shift their RTP
timestamps. Thus synchronizing them between each other.

Otherwise the use() member should probably be passed both a presentation
time based off the RTP timestamp and a synchronization time (which is
actually the currently named fPresentationTime).  The callback could then
synchronize multiple RTP streams itself if it so chooses.

.mike


On Tue, Jun 24, 2008 at 2:53 PM, Ross Finlayson <finlayson at live555.com>
wrote:

> Sorry, but I won't be making any such change to the code.  Once
> RTCP-generated presentation times become available, they should *always* be
> used.  Note that the function "RTPSource:: hasBeenSynchronizedUsingRTCP()"
> can be used by a client to distinguish between 'guessed' initial
> presentation times, and accurate RTCP-generated presentation times.
>
> If VLC - as a RTSP client - is having trouble handling the transition
> between these two different kinds of presentation times, then please report
> this on a VLC mailing list.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20080624/19f42cda/attachment.html>