Repository navigation
Teams calls: fix the starved camera and smooth the far end's audio - #46
Merged
Merged
Conversation
A REMB for the audio line or a 0 for an unused line was taken as the link's estimate and held the camera at 150 kbit/s.
Conceal 60 ms before going silent, one frame across a trim, and fade in after silence, so none of them pops.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From a 27-minute Teams meeting where a coworker said my video lagged and the audio glitched.
Camera. A second after the camera started, the send estimate fell to 43 kbit/s and later 0, on a direct path with 18 ms RTT and no loss, so the camera sat at its lowest step (150 kbit/s at 960x540, ~170 kbit/s out) while Teams allowed ~1.1 Mbit/s. str0m tags each REMB with its m-line, and we took any REMB as the link's estimate: one for the audio line or a 0 for a line we don't send on would do exactly this. A REMB now counts only for a line we send video on, and never a zero (Slack huddles: any line but the audio). The estimate line in the log says whether it came from transport-cc or REMB, so the next meeting confirms it.
Audio. The jitter buffer ran dry ~every 3.6 s and cut ~260 ms (13 frames) ~every 6.6 s, with no late or lost packets: the far end's audio comes in bursts. Each edge was a pop. Now a dry buffer conceals 60 ms before going silent (which also bridges short stalls), a cut while playing gets one concealed frame across it, and sound fades in over 5 ms after silence.
The stats line now also says how far behind its RTP timing incoming audio came and how long the media loop was busy at most, to tell a network burst from our own stall before changing how much is trimmed.
+247 / −26 lines. Needs #45 (rustls) for cargo-deny to pass.