Conversation
🦋 Changeset detectedLatest commit: fd44b10 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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
Nice, can you record some videos to show the impact in different network conditions ? You can share it in slack if that is easier. Thanks. |
|
@xianshijing-lk (2) On both real 4G network and WiFi network, we connect fast enough to avoid this path. |
Nice! I like the numbers. How about the false positive and false negative rates? I tried something similar this summer while I was in China behind a VPN, and sometimes I saw high latency under good network conditions and low latency under poor network conditions. I wouldn't think that is a blocker, but ideally it doesn't happen too frequently. |
Cap x-google-start-bitrate at 1 Mbps for connections that set up within 1.5 s, ramping linearly down to 300 kbps at 3.5 s or slower. Screen share is capped the same way once the cap is below 1 Mbps. Resumes keep their estimator; only a new peer connection (join or full reconnect) is measured.
…ports connect Room.connect returns after the signaling join, so an app that publishes video right away creates its first offer before the primary transport has connected and no setup time is recorded yet. The publisher now knows when the attempt began and uses the time elapsed so far for that offer, a lower bound on the eventual setup time, so it can only lean toward the 1 Mbps ceiling.
4e31c85 to
9ddd7d7
Compare
| if (oldVal != ConnectionState.RESUMING) { | ||
| recordConnectionSetupTime() | ||
| } |
There was a problem hiding this comment.
🟡 Early resume leaves video setup timer running
When signaling drops before initial ICE connection, RESUMING skips recording setup time after recovery. connectStartedAtMs keeps aging, so a later first video offer gets a 300 kbps hint regardless of the recovered link.
Learn more
A soft resume reuses the existing peer connection. If signaling closes during the initial connection, reconnect sets RESUMING while the publisher still holds the timestamp from setConnectStartedAt. On recovery, the connection-state callback skips recording, leaving both engine and publisher without a completed setup time. A later first video offer then uses the ever-growing elapsed time in connectionSetupTimeForOffer, even long after the connection stabilized.
Example: An initial join starts at 0 ms, signaling drops before ICE connects, and soft resume completes at 2 s. A camera first published at 30 s gets the 300 kbps hint rather than a value based on the completed connection.
Recommended fix: On RESUMING → CONNECTED, finalize a pending initial setup timestamp for the existing publisher, while continuing to skip timing for resumes of previously connected sessions.
Was this helpful? React with 👍 or 👎 to provide feedback.
detekt fails configure at its cyclomatic complexity threshold (15) with the extra branch. joinImpl calls configure before it negotiates, so setting the start time there is equally early.
|
Diffuse output: AARJAR |
2 participants
Linear: CLT-3380
Rust counterpart: livekit/rust-sdks#1467
Builds on #973, which introduced the connection-level 1 Mbps cap this change scales.
Problem
With #973 the
x-google-start-bitratehint is min(90% of target, 1 Mbps) for camera tracks, and uncapped for screen share, chosen with no information about the network. On a constrained uplink 1 Mbps overshoots: the estimator has to recover, which shows up as a freeze and a retransmit storm over the first 5–15 s. On a good network 1 Mbps is right. libwebrtc cannot probe the path before a video sender exists, so the SDK has to pick the seed without a measurement; connection setup time is the only network signal available before the first video offer.Change
RTCEnginetimes each connection attempt from the top ofjoinImpluntil the primary transport reports connected, and hands it to the publisherPeerConnectionTransport, which scales the hint's cap by it:joinImpland build a new publisher, so each times itself from scratch. A resume (RESUMING → CONNECTED) keeps its peer connections and estimator and never records a time. fix: improve initial video quality by setting x-google-start-bitrate for all video codecs #973's write-once latch is unchanged. With no setup time recorded, the cap stays at 1 Mbps.Measurements and validation
Setup-time measurements on shaped links and the camera validation runs (LK2/LK3/LK4 profiles, fixed cap vs ramp) are in CLT-3380 and in livekit/rust-sdks#1467; the anchors are the same as in the Rust SDK. In short: on constrained links (500 kbps and 300 kbps uplinks) the ramp removes the opening overshoot, with 40–90% fewer retransmits and the frame rate held from the first frame; on a 1 Mbps link the two are within run-to-run variance.
Tests
SdpMungingTest: 7 pass (5 existing + 2 new covering the ramp at the measured setup times and anchors, and the screen-share cap).spotlessCheckclean.