mirror of
https://github.com/livekit/livekit.git
synced 2026-05-15 16:06:09 +00:00
Raja Subramanian
fdde44d926
There are cases where the RTP time stamp does not increment acros mute/unmute. Seems to happen fairly consistently with React Native clients. Something like the following happens - Track is progressing - Mute at `t = x`, assume RTP time stamp at the point is `y` and RTP clock rate is `z`. - Through mute, more RTCP sender reports come in from publisher and the RTP time stamp in those reports are progressing at expected rate of `z` RTP clock ticks per second. - Forwarding path uses those sender reports from publisher to build the sender report for subscribers. - Unmute happens at `t = x + a` seconds. - Ideally packets coming in after that, should have a time stamp of `y + (a * z)`, but they tend to have something a little bit more than `y`. - RTCP sender reports also have a time stamp that goes back. SFU ignores these. - Mean while the forwarding path has adjusted to the new RTP time stamp base and it has calculated a TS offset (from publisher -> subscriber). Effectively, that offset comes out close to `(a * z)`, i. e. jump corresponding to the mute interval. - When it is time to send a RTCP sender report to subscriber, the old sender report from publisher is used (as intervening ones from publisher were rejected because time stamp is moving backwards). The problem is that the old report is used with new offset. So, it looks like time stamp jumped ahead by `a` seconds. Address it by storing time stamp offset at the time of receiving the publisher side sender report. And use that while sending subscriber side sender report. There are very edge cases where this can get mismatched, but should be rare. Hopefully, this should prevent unnecessary jumps in time stamp in RTCP sender report to subscribers.