*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 <finlay...@live555.com> wrote: > > > > On May 13, 2020, at 2:05 AM, Lionel Koenig <lionel.koe...@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@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
