* 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.
The SRTP replay detection was disabled recently.
But, they were effectively getting dropped in `sfu.bucket`.
Doing two things with RTX packets in this PR
1. Update stats - add to packet count and bytes
2. Process header extension - to process TWCC
* Force DTLE role client for the simulated client side peer connection
during migration.
Without that, with remote side being ice-lite (i. e. server offer
is subscriber peer connection), pion chooses the server DTLS role
and both side end up being servers.
* pion/webrtc -> 3.1.21
* remove local reference
* Use setup from previous answer
* more comments
* WIP commit
* fix test
* More clean up
* cast to right size
* use local variable
* set a default RTT
* Do not log RTX, although need to figure out source of RTX
* fix test
* Cleaning/simplifying some buffer bits
1. NACKs are always inserted in order. So, get rid of
bunch of out-of-order handling in there and simplify.
2. For now, removing triggering a key frame from NACKs.
Let subs drive it.
3. Move to 16-bit sequence numbers except for receiver
report handling. Simplify bits about unwrapping sequence
number on all packets.
4. Remove unused code.
* remove unused field
* Use ParticipantInfo version to ensure consistency
Deprecating time.Time and avoid locking unnecessarily
* properly adjust ulimit. update protocol
* Save initial version from params
* get rid of metadata field, use grants copy
* fix test
