> 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
