| From: Lionel Koenig <lionelk@google.com> |
| |
| Exposes the RTP Timestamp in the liveMedia RTPSource object. |
| |
| This is a workaround and won't be upstreamed: |
| http://lists.live555.com/pipermail/live-devel/2020-May/021598.html |
| |
| Detailed explanation: |
| 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. |
| |
| More details in: |
| - https://tools.ietf.org/html/rfc3550#section-5.1 |
| - https://tools.ietf.org/html/rfc3551#section-4.3 |
| |
| --- a/liveMedia/include/RTPSource.hh |
| +++ b/liveMedia/include/RTPSource.hh |
| @@ -86,7 +86,6 @@ public: |
| // RTP sequence numbers and timestamps are usually not useful to receivers. |
| // (Our implementation of RTP reception already does all needed handling of RTP sequence numbers and timestamps.) |
| u_int16_t curPacketRTPSeqNum() const { return fCurPacketRTPSeqNum; } |
| -private: friend class MediaSubsession; // "MediaSubsession" is the only outside class that ever needs to see RTP timestamps! |
| u_int32_t curPacketRTPTimestamp() const { return fCurPacketRTPTimestamp; } |
| |
| protected: |
| -- |
| 2.21.0 |
| |
