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 availab
> 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 ava
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 t
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
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 ti
I had a problem when using VLC to transcode from an AXIS camera into an RTP
stream. In the RTCP Sender Report the AXIS camera is deriving its NTP time
from the monotonic uptime instead of the wall clock. Then it converts it
from unix epoch time into NTP time.
The real issue is that VLC/live555 sta
