<div dir="ltr"><b style="font-weight:normal" id="gmail-docs-internal-guid-aba5ece4-7fff-c681-d8cf-3be817960e23"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Hi Ross,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Thanks for the explanation. I was indeed well aware of the relationship between presentation time and RTP Timestamp.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Let me clarify a little be more the issue I am facing:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">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).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">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).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">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.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Hope it clarifies this use case of the RTP timestamps.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">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?</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Kind regards,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Lionel</span></p></b><br class="gmail-Apple-interchange-newline"><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 4:44 PM Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On May 13, 2020, at 2:05 AM, Lionel Koenig <<a href="mailto:lionel.koenig@codemill.se" target="_blank">lionel.koenig@codemill.se</a>> wrote:<br>
> <br>
> Hi,<br>
> 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<br>
<br>
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.<br>
<br>
If you haven’t done so already, see<br>
<a href="http://live555.com/liveMedia/faq.html#separate-rtp-streams" rel="noreferrer" target="_blank">http://live555.com/liveMedia/faq.html#separate-rtp-streams</a><br>
and<br>
<a href="http://live555.com/liveMedia/faq.html#rtcp-synchronization-issue" rel="noreferrer" target="_blank">http://live555.com/liveMedia/faq.html#rtcp-synchronization-issue</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>