[Live-devel] Expose RTP Timestamp as public in RTPSource

[Lionel Koenig]

*Hi Ross,Thanks for the explanation. I was indeed well aware of the
relationship between presentation time and RTP Timestamp.Let me clarify a
little be more the issue I am facing:The problem I am trying to solve is
sample accurate synchronization between the sender media clock, which is
reflected by exactly the RTP Timestamp in the media packet (not the sender
system clock), and the receiver media clock, which is driven by the
playback hardware (again not the system clock of the receiver).The
presentation time is adjusted via RTCP Sender Report every now and then
using the sender media clock through RTP Timestamps and the sender system
clock. This sender system clock might be adjusted via NTP causing some
occasional jumps (I've seen system clock being adjusted with NTP every few
seconds on some devices) leading to "time jumps" in the RTCP Sender Report
(Will most likely not change the strictly increasing nature of the whole
clock system).The presentation time clock the receiver sees then is a
combination of the media clock and the sender system clock. The adjustment
of the system clock via NTP (or maybe something else) introduces "noise" if
the media clock is then re-derived from this presentation time.Using the
RTP Timestamp directly allows a way to circumvent the noise introduced by
the different system clocks, sender report adjustment and so on, and only
focus on solving the media clock synchronization issue.Hope it clarifies
this use case of the RTP timestamps.Would you kindly reconsider exposing
the RTP timestamp in RTPSource? Alternatively, I'd be very open to other
ways of getting the accurate sender media clock if you have any ideas?Kind
regards,Lionel*



On Tue, May 12, 2020 at 4:44 PM Ross Finlayson <finlayson at live555.com>
wrote:

>
>
> > On May 13, 2020, at 2:05 AM, Lionel Koenig <lionel.koenig at codemill.se>
> wrote:
> >
> > Hi,
> > In order to achieve very precise digital audio converter clock
> synchronisation between server and client in a project I am currently
> working on, I need to access the exact RTP timestamp of the last packet
> from my MediaSink so I can precisely estimate the clock differences. Using
> presentation  timestamps is subject to clock adjustment
>
> Sorry, but you seem to be misunderstanding what the presentation time (as
> seen by the RTP/RTCP receiver does).  It (once RTCP synchronization has
> started) *already* gives you an exact representation of the RTP timestamp,
> and thus the LIVE555 libraries do not (and never will) expose the RTP
> timestamps to the receiver; that would give you no more information (and
> only lead to potential confusion).  The LIVE555 library automatically
> converts RTP timestamps to presentation times (and vice versa for
> servers).  Applications that use the LIVE555 libraries never need to
> concern themselves with RTP timestamps.
>
> If you haven’t done so already, see
>         http://live555.com/liveMedia/faq.html#separate-rtp-streams
> and
>         http://live555.com/liveMedia/faq.html#rtcp-synchronization-issue
>
> Note that the RTP timestamps (and thus, presentation times) are in based
> on the server’s (i.e., sender’s) clock. If there is clock drift between the
> sender and receivers’ clocks, then you might find that, over time, the
> presentation times shift compared to the receiver’s clock.  A RTP receiver
> application (e.g., a media player) is supposed to take account of this, and
> - if necessary - compensate by occasionally dropping or duplicating samples.
>
> Alternatively, if both server and client are under your control, then you
> might find it worthwhile to synchronize their system clocks - e.g., using
> NTP.
>
>
> 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/20200513/12587fa7/attachment.htm>