* Introducing OpsQueue
Creating a PR to get feedback on standardizing on this concept.
Can be used for callbacks.
Already a couple of places use this construct. Wondering if we
should standardize on this across the board.
Just changing one place to use the new struct. Another place
that I know of which uses this pattern is the telemetry package.
* atomic flag -> bool
* Fix no-video with adaptive streaming
With a recent change to initialize max quality for subscriber
synchronously, a subsequent update at the same quality was
getting ignored. So, there was no message back to publisher
to start up video layers. Reproducible every time the subscriber
joined after all the layers of publishers was turned off.
While not pretty, for now, disable the check for quality match
on subscriber update. That disabling itself is fine as there is
another check for consolidated quality match before sending
a message to the publisher, but in general this area has shown
some shakiness and needs some work.
* Use notify function to set initial quality also
total_bytes is aggregate, when we switch from higher layer to lower
layer, it takes time for lower layers total_bytes to catch up to
stopped higher layers
Signed-off-by: shishir gowda <shishir@livekit.io>
With screen sharing in Chrome 97, static content sends one packet
a second. Layer 0 stream tracker was configured to expect 2 per second.
Make it very relaxed so that one packet in two seconds declares layer 0
active.
* Compute delta stats to send downstream
Signed-off-by: shishir gowda <shishir@livekit.io>
* Update tests: total_packets should be diff between 2 packets
First packet was 1, second was 4. diff should be 3
Signed-off-by: shishir gowda <shishir@livekit.io>
* If there are no videoLayers, do not sent in Stats
For audio and Downstream tracks, we do not get layers
Signed-off-by: shishir gowda <shishir@livekit.io>
* Use prev Max layer for current delta and update layer info for next round
* Consolidating PLI throttle
Use the throttler in `sfu.WebRTCReceiver`.
Does change shape of config object.
* Move PLIThrottleConfig to sfu.WebRTCReceiver
* fix test compile
* Cleaning up unused stuff
* improve readability
* RTT
- Calculate down track RTT using RTCP Receiver report
- Surface it back to the participant
- Participant updates all its published trackes
(throttled to limit update to once in 5 seconds)
- That propagates to all the upstream sfu.Buffer and the nacker.
So, we will have RTT throttled NACKs.
* rtt callback
* Consolidating PLI throttle
Use the throttler in `sfu.WebRTCReceiver`.
Does change shape of config object.
* Move PLIThrottleConfig to sfu.WebRTCReceiver
* fix test compile
* Cleaning up unused stuff
* readability improvement
RTCP messages are going through two channel hops now.
Maybe we don't need that anymore now that the original
problem is diagnosed. But, pushing all RTCP via
the callbackOps channel for now to make it consistent.
