Fix VP9 simulcast freezing on first layer switch

[iamadityaanjana]

Summary

Fixes #4594 — a VP9 simulcast (ONE_SPATIAL_LAYER_PER_STREAM) subscriber works on its initial layer, then freezes the instant the allocator first switches layers (e.g. a BWE-driven upgrade): the forwarder enters a constant processSourceSwitch loop (~60/s), output timestamps freeze (extNextTS = extLastTS + 1), and a NACK/PLI storm follows. H.264/VP8 simulcast is unaffected.

The issue reporter root-caused this on a v1.11.0 fork running in production (write-up). One of their four fixes (Simulcast selector for VP9 simulcast) has already landed upstream; this PR ports the remaining three to current master:

1. pkg/sfu/receiver_base.go — all rids collapsed to spatial layer 0. if extPkt.Spatial >= 0 overrode the rid/uptrack index with the in-packet spatial id. Each VP9 simulcast rid is single-spatial, so the DD SpatialId is 0 for every rid → all map to spatial layer 0 and the forwarder alternates SSRCs on every packet. (H.264/VP8 are unaffected because extPkt.Spatial == -1.) Fix: apply the override only for the base uptrack (layer == 0, the SVC case); for simulcast the uptrack index is authoritative.

2. pkg/sfu/forwarder.go — the cross-layer SR timestamp offset never establishes. Per-layer RTCP sender reports for VP9 simulcast do not provide a usable cross-layer offset, so tsOffset stays 0 and every switch errors switch point too far behind. Fix: treat VP9 simulcast like ONE_SPATIAL_LAYER_PER_STREAM_INCOMPLETE_RTCP_SR by skipping the reference-timestamp based switch point. skipReferenceTS is derived deterministically on every DetermineCodec call from the current mime + videoLayerMode, so a forwarder that regresses from VP9 simulcast to another codec (upstream codec change / receiver restart re-invoke DetermineCodec) re-enables the sender-report based path; the constructor-provided value (forceSkipReferenceTS) still forces it on, preserving existing test behavior.

3. pkg/sfu/buffer/dependencydescriptorparser.go — frame drops with frequent key frames. The drop threshold advanced on every structure-bearing key frame even when StructureId was unchanged, so reordered/retransmitted frames were dropped as "earlier than current structure" (severe with screen content). Fix: advance the drop threshold (structureChangeExtFrameNum) only on an actual StructureId change; structureExtFrameNum/ExtKeyFrameNum behavior is unchanged.

Note: the client SDK also needs to signal SimulcastCodec.videoLayerMode = ONE_SPATIAL_LAYER_PER_STREAM plus per-encoding scalabilityMode for VP9 — this is the server-side path only.

Test plan

• go build ./... passes
• go test ./pkg/sfu/ ./pkg/sfu/buffer/ passes (including existing forwarder tests that construct with skipReferenceTS=true)
• The equivalent changes have been running in production on the reporter's v1.11.0 fork (stable layer switches, no NACK/PLI storm)

Credit for the root-cause analysis and original fixes: @SpeakNow06

[cnderrauber]

An out-of-order keyframe with the same structure ID may arrive here with the new logic, and confused the downtrack's dependency descriptor selector. Need to add a check to filter out the old keyframe:

    if extFN < r.structureExtFrameNum {
        r.logger.Debugw("drop out-of-order key frame",
            "extFN", extFN, "structureExtFrameNum", r.structureExtFrameNum)
        ReleaseExtDependencyDescriptor(extDD)
        return nil, videoLayer, ErrFrameEarlierThanKeyFrame
    }

[iamadityaanjana]

I have resolved these issues and PR is ready for the review and merge.

[CLAassistant]

All committers have signed the CLA.