mirror of
https://github.com/livekit/livekit.git
synced 2026-07-02 09:11:56 +00:00
cloudwebrtc
3fa24cf7c8
A subscriber that requests the top spatial layer would briefly decode a lower layer before settling on the requested one (e.g. layer 0 -> layer 2), a visible low->high quality ramp. Two distinct causes: 1. Simulcast.Select latched opportunistically onto the first key frame of any layer <= target, so a lower layer's key frame (which usually arrives first) was selected before the requested layer's. 2. When the subscriber joined before the publisher started, the layers are detected gradually and `maxSeen` climbs 0->1->2. AllocateOptimal caps the target at `min(maxSeen, requested)`, so the target itself ramped up and Select followed it. The new behavior is gated behind a `LiveStreamingMode` Room config option (default false -> original opportunistic behavior unchanged): - Select latches directly onto the target layer during initial acquisition. - Forwarder gains an initial-acquisition grace: while not yet streaming and the requested layer has not been seen, the target/key-frame-request aim straight at the requested layer instead of the highest seen so far. Gated on `maxSeen < requested` so steady-state behavior (incl. overshoot) is unchanged. - If the requested layer never shows up within the grace, the key frame requester triggers a re-allocation so the target falls back to the highest layer actually seen, avoiding a stall/black screen. - On bind, a live-streaming subscriber requests the highest layer up front (instead of the adaptive-stream LOW start) so it is acquired directly. LiveStreamingMode is threaded from config.RoomConfig through the participant (GetLiveStreamingMode) and SubscribedTrack/DownTrack params into the Forwarder and Simulcast layer selector. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>