Describe the problem
PR #1740 (fixing #1713) extended the x-google-start-bitrate SDP parameter from AV1-only to all SVC codecs, but H.264 is still excluded because the guard uses isSVCCodec() which only matches vp9 and av1.
There are two places that gate on SVC:
PCTransport.ts line 325 — if (!isSVCCodec(trackbr.codec)) { return true; } skips the SDP munging entirely for H.264LocalParticipant.ts line 1201 — if (track.codec && isSVCCodec(track.codec) && encodings[0]?.maxBitrate) prevents setTrackCodecBitrate() from being called for H.264 tracks, so even if the SDP guard were removed, there would be no TrackBitrateInfo entry to match against
The result is that H.264 video tracks (particularly screen shares) suffer from a 10-15 second slow bitrate ramp-up from ~300kbps to the target bitrate, producing very blurry video at the start of every stream.
Describe the proposed solution
Remove the isSVCCodec gates from both locations so that x-google-start-bitrate is applied for all video codecs that have a maxBitrate set, not just SVC codecs.
The original issue #1713 mentioned H.264 in its title and body, but PR #1740 only addressed SVC codecs.
Importance
nice to have
Additional Information
The startBitrateForSVC multiplier (0.7) works well for H.264 in practice — starting at 70% of maxBitrate provides immediate high quality while still leaving headroom for the bandwidth estimator.
Describe the problem
PR #1740 (fixing #1713) extended the
x-google-start-bitrateSDP parameter from AV1-only to all SVC codecs, but H.264 is still excluded because the guard usesisSVCCodec()which only matchesvp9andav1.There are two places that gate on SVC:
PCTransport.tsline 325 —if (!isSVCCodec(trackbr.codec)) { return true; }skips the SDP munging entirely for H.264LocalParticipant.tsline 1201 —if (track.codec && isSVCCodec(track.codec) && encodings[0]?.maxBitrate)preventssetTrackCodecBitrate()from being called for H.264 tracks, so even if the SDP guard were removed, there would be noTrackBitrateInfoentry to match againstThe result is that H.264 video tracks (particularly screen shares) suffer from a 10-15 second slow bitrate ramp-up from ~300kbps to the target bitrate, producing very blurry video at the start of every stream.
Describe the proposed solution
Remove the
isSVCCodecgates from both locations so thatx-google-start-bitrateis applied for all video codecs that have amaxBitrateset, not just SVC codecs.The original issue #1713 mentioned H.264 in its title and body, but PR #1740 only addressed SVC codecs.
Importance
nice to have
Additional Information
The
startBitrateForSVCmultiplier (0.7) works well for H.264 in practice — starting at 70% of maxBitrate provides immediate high quality while still leaving headroom for the bandwidth estimator.