Repository navigation
Additionally use browser effective connection type in determining start bitrate - #2149
Merged
Merged
Conversation
…rt bitrate Chromium's navigator.connection.effectiveType catches links with low bandwidth but low latency, which set up quickly and so slip past the connection setup time ramp. The camera x-google-start-bitrate cap is now the lower of the setup time cap and: - 300 kbps for slow-2g and 2g - 500 kbps for 3g - the 1 Mbps ceiling for 4g, and for browsers without the API Screen share stays uncapped. The API's rtt is not used: it lags behind network changes, and the setup time already reflects latency.
changt
requested review from
1egoman,
lukasIO and
xianshijing-lk
as code owners
October 13, 2026 22:48
🦋 Changeset detectedLatest commit: 5eb9d8a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
size-limit report 📦
|
lukasIO
requested changes
Oct 14, 2026
| */ | ||
| function connectionEffectiveTypeStartBitrateCap(): number { | ||
| // `navigator.connection` is missing from the DOM typings, being Chromium only. | ||
| const connection = (globalThis.navigator as { connection?: { effectiveType?: string } }) |
Contributor
There was a problem hiding this comment.
fix: do not read globalThis here. The supported browsers (Chrome 64, Firefox 58, Safari 11.1) have no globalThis, and the build adds no polyfill. Use a typeof navigator guard, as the rest of the file does.
| function connectionEffectiveTypeStartBitrateCap(): number { | ||
| // `navigator.connection` is missing from the DOM typings, being Chromium only. | ||
| const connection = (globalThis.navigator as { connection?: { effectiveType?: string } }) | ||
| ?.connection; |
Contributor
There was a problem hiding this comment.
suggestion: replace the cast with a declared NetworkInformation type, or a package that provides it.
globalThis is missing from supported browsers older than Chrome 71, Firefox 65 and Safari 12.1, and the build does not polyfill it, so reading globalThis.navigator threw a ReferenceError while building the first camera offer on those browsers. Check typeof navigator instead, and type the API with a local NetworkInformation interface in place of the inline cast.
Merged
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.
Builds on #2146, which scales the camera
x-google-start-bitratecap by connection setup time.Problem
Connection setup time grows with round-trip time and loss, so it misses links with low bandwidth but low latency. Those set up quickly and still get the 1 Mbps seed, which overshoots their uplink. In the browser, Chromium's Network Information API reports an effective connection type (
navigator.connection.effectiveType) that does flag such links as3gor slower.Change
The camera cap is now the lower of the setup time cap and a cap from the effective connection type:
effectiveTypeslow-2g,2g3g4g, or no API (Firefox, Safari)connectionEffectiveTypeStartBitrateCap(), applied in one place incomputeTrackStartBitrate.rttis not used. It lags behind network changes, and setup time already reflects latency. Setup time stays the primary signal because every platform has it.Testing
PCTransport.test.ts: caps for each effective type, no cap for4gor withoutnavigator.connection, the lower of the two caps applies, 90% of a target below the cap, and screen share uncapped.npx vitest run src: 920 passed, 1 skipped.