-
Notifications
You must be signed in to change notification settings - Fork 295
Write the video start bitrate hint as one connection-level value, once #2102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
xianshijing-lk
wants to merge
1
commit into
main
Choose a base branch
from
sxian/CLT-3068/video-start-bitrate-connection-level
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+200
−43
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| --- | ||
| 'livekit-client': patch | ||
| --- | ||
|
|
||
| Write the `x-google-start-bitrate` hint as a single connection-level value, once per publisher connection. | ||
|
|
||
| libwebrtc reads this fmtp parameter per m-section but applies it to the shared `Call` (`WebRtcVideoSendChannel::ApplyChangedParams` → `SetSdpBitrateParameters`), where `RtpBitrateConfigurator` holds one config for the whole peer connection. Differing per-section values were therefore last-writer-wins on m-section order, so publishing a camera and a screen share together could seed the estimator from either one depending on SDP layout. Every video section now carries the same value: the largest hint among the sections that map to a published track. | ||
|
|
||
| The hint is also written only on the first offer that carries local video, instead of on every offer. libwebrtc retains `start_bitrate_bps` and re-applies it on network route changes (`RtpTransportControllerSend::OnNetworkRouteChanged`), so rewriting it later is at best a no-op and at worst restarts a converged bandwidth estimator. A full reconnect builds a new peer connection and seeds the new estimator again. | ||
|
|
||
| Targets below 300 kbps now get no hint, matching the Rust SDK: below that, seeding above the real capacity costs more than the ramp it saves. |
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 Reverted tracks inflate start bitrate
When an unpublished section retains its
msid,computeConnectionStartBitratecounts its staletrackBitratesentry as published. A stale screen-share target can seed every active video section above its intended connection value.Learn more
Unpublishing a track can leave its old
a=msidand codec mapping in the SDP. The code already identifies these reverted sections through the transceiver's missing sender track in getPlaceholderMids. This computation instead treats any matchingmsidas proof that the track remains published. SincetrackBitratesis append-only, a reverted section can therefore contribute an obsolete maximum before the one-shot latch is set.Example: A 3,000 kbps screen share registers a 2,700 kbps hint, then is unpublished before the debounced first offer is created. Chrome retains its
msidon the inactive section. A 1,000 kbps camera in that offer receives the stale 2,700 kbps connection hint instead of 900 kbps.Recommended fix: Exclude mids returned by
getPlaceholderMids()when computing the connection value, or remove/updatetrackBitratesentries during unpublish. Add a test whose stale SDP section retains its originalmsidbut corresponds to a transceiver with no sender track.Was this helpful? React with 👍 or 👎 to provide feedback.