Repository navigation
Keep screen share uncapped by the start bitrate ramp - #1036
Merged
changt merged 2 commits intoOct 7, 2026
Merged
Conversation
Screen share content needs its bitrate immediately to stay legible, so it is now exempt from the connection-setup-time ramp as well as the 1 Mbps ceiling. A slow setup lowers only the camera's hint. Matches client-sdk-flutter.
changt
requested review from
MaxHeimbrock,
davidliu and
xianshijing-lk
as code owners
October 6, 2026 20:13
|
| Name | Type |
|---|---|
| client-sdk-android | Patch |
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Contributor
|
Diffuse output: AAR |
xianshijing-lk
approved these changes
Oct 6, 2026
changt
added a commit
to livekit/rust-sdks
that referenced
this pull request
Oct 7, 2026
Linear: [CLT-3380](https://linear.app/livekit/issue/CLT-3380/scale-the-video-start-bitrate-300-1000-kbps-by-connection-setup-time) Android counterpart: livekit/client-sdk-android#1036 Flutter counterpart: livekit/client-sdk-flutter#1228 Follow-up to #1467. ## Change #1467 left screen share uncapped only while the setup-time cap was at the 1 Mbps ceiling; on a slow setup, screen share was ramped down with camera. We've decided screen share should be exempt from the ramp entirely: its content needs the bitrate right away to stay legible, so its hint is now always 90% of its target, however long setup took. Camera tracks are ramped as before. The core change is one condition in `PeerTransport::compute_start_bitrate_kbps`: `is_screen_share && cap_kbps >= Self::MAX_START_BITRATE_KBPS` becomes `is_screen_share`. The changeset from #1467 hasn't been released yet, so this updates its wording rather than adding a new one. ## Tests `slow_connection_setup_caps_screen_share_too` is renamed to `slow_connection_setup_leaves_screen_share_uncapped` and now checks that screen share stays at 2700 kbps (3 Mbps target) at 1.3 s, 2.5 s and 4.1 s setup. `cargo test -p livekit --lib` start-bitrate tests pass; `cargo fmt` clean.
changt
deleted the
senchang/clt-3380-exempt-screen-share-from-start-bitrate-ramp
branch
October 7, 2026 00:17
pblazej
pushed a commit
to livekit/client-sdk-swift
that referenced
this pull request
Oct 20, 2026
Follow-up to #1121. Ports the setup-time ramp from livekit/client-sdk-js#2146, livekit/rust-sdks#1467 and livekit/client-sdk-android#1031. ## Problem #1121 caps the camera `x-google-start-bitrate` hint at a fixed 1 Mbps. On slow or lossy links, that seed overshoots what the link can carry. ## Change Connection setup time (signaling join plus ICE/DTLS) is the only network signal available before the first video offer, since libwebrtc cannot probe the path until a video sender exists. Setup time grows with round-trip time and loss, so the camera cap now scales with it: - **Ramp:** 1 Mbps at a setup of 1.5 s or less, falling linearly to 300 kbps at 3.5 s or more. The anchors come from shaped-link measurements (CLT-3380). - **Screen share:** uncapped, however slow the setup, as in all three SDKs (livekit/rust-sdks#1505, livekit/client-sdk-android#1036, livekit/client-sdk-js#2146). - **What is timed:** from the top of `fullConnectSequence` until the primary transport connects. Every attempt is timed from scratch: initial connect, full reconnect and region failover. A quick reconnect keeps its peer connection and estimator, so it doesn't measure again. - **Publishing during connect:** a video published before the primary transport connects uses the time elapsed so far. That is a lower bound, so it can only err toward the 1 Mbps ceiling. - **Where the cap is applied:** in `Transport.startBitrateKbps(…connectionSetupTime:)`, the formula both `LocalParticipant` video publish paths already call. `addTransceiver` and the offer munge are unchanged. ## Differences from the other SDKs - **What is timed:** Swift matches Kotlin and JS (until the primary transport connects). Rust waits for both peer connections in dual-PC mode. - **Offer created mid-connect:** Swift matches Kotlin and JS (time elapsed so far). Rust uses no setup time, which leaves the cap at the 1 Mbps ceiling. - **Not ported:** the JS cap based on the browser's `navigator.connection.effectiveType`. It is browser-only and has no Apple-platform equivalent. ## Testing - **Ramp:** rust-sdks' cases at setup times measured on shaped links. - **Formula with a setup time:** camera capped, 90% of a low target kept, screen share uncapped. - **`Transport.connectionSetupTime`:** recorded, time elapsed so far, and unset. - The macOS build passes, the four start-bitrate and SDP suites pass (50 tests), and swiftlint and swiftformat are clean.
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
2 participants
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.
Linear: CLT-3380
Flutter counterpart: livekit/client-sdk-flutter#1228
Follow-up to #1031.
Change
#1031 left screen share uncapped only while the setup-time cap was at the 1 Mbps ceiling; on a slow setup, screen share was ramped down with camera. We've decided screen share should be exempt from the ramp entirely: its content needs the bitrate right away to stay legible, so its hint is now always 90% of its target, however long setup took. Camera tracks are ramped as before.
The core change is one condition in
computeTrackStartBitrate:isScreenShare && capKbps >= maxStartBitrateKbpsbecomesisScreenShare.Since the hint is the max across the connection's video m-sections, a connection that publishes both camera and screen share takes the screen share's uncapped value.
The changeset from #1031 hasn't been released yet, so this updates its wording rather than adding a new one.
Tests
SdpMungingTest: the screen-share test now checks that screen share stays at 2700 kbps (3 Mbps target) at 1.3 s, 2.5 s and 4.1 s setup, and that a slow setup with camera + screen share yields the screen share's 2700 while camera alone is still ramped to 650.spotlessCheckanddetektReleaseclean.