mirror of
https://github.com/livekit/livekit.git
synced 2026-04-01 06:35:57 +00:00
72ed5b19f7
* Use receiver report stats for loss/rtt/jitter. Reversing a bit of https://github.com/livekit/livekit/pull/1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later. * return available streams * fix test