Write the video start bitrate hint as one connection-level value, once

[xianshijing-lk]

Ports client-sdk-js#2102 to Flutter. Same change already landed for Rust in rust-sdks#1430.

Why the JS PR is the reference, not the Rust one

lib/src/core/transport.dart is a near-literal Dart transliteration of the pre-fix JS code — same TrackBitrateInfo shape, same append-only tracker list, same per-section msid match inside negotiate(), same setMungedSDP fallback that restores the original SDP on rejection. The JS diff maps onto it almost line for line, so this PR mirrors its structure: the logic moves out of negotiate() into top-level findTrackCodecPayload / computeTrackStartBitrate / computeConnectionStartBitrate / applyVideoStartBitrate functions, which is also what makes it testable without a PeerConnection.

Rust could not be a template. It keeps a single max_send_bitrate_bps slot on the transport and munges the SDP as a string over video payload types, with no m-section or msid concept at all — there is nothing to port across.

x-google-start-bitrate is connection-scoped, not per-section

libwebrtc reads it per m-section but doesn't apply it per m-section:

bitrate_config_ = GetBitrateConfigForCodec(send_codec()->codec);   // webrtc_video_engine.cc
...
call_->GetTransportControllerSend()->SetSdpBitrateParameters(bitrate_config_);

That lands in RtpBitrateConfigurator, which holds one BitrateConstraints for the entire peer connection. Every video m-section writes the same slot, last writer wins, and the order is just m-section order.

Today each track writes its own value, so publishing a camera and a screen share together seeds the estimator from whichever section happens to be last. computeConnectionStartBitrate now takes the largest hint among the video sections that can send, and every video section gets that same number.

Written once per connection, not on every offer

libwebrtc retains start_bitrate_bps in RtpBitrateConfigurator and re-applies it on network route changes (RtpTransportControllerSend::OnNetworkRouteChanged), so a WiFi→cellular handover re-seeds the estimator from this hint with no renegotiation. Rewriting it on a later offer is at best a no-op and at worst restarts a converged estimator.

_hasAppliedVideoStartBitrate latches only after setMungedSDP has accepted the offer — it falls back to the unmunged SDP on rejection — so a rejected munge retries on the next offer. A full reconnect builds a new Transport and seeds the new estimator again.

Only sections that can send

The bitrate tracker list is append-only and an unpublished section keeps its a=msid, so matching a section to a track by msid alone would still pair a stale entry with the section it used to occupy. That lets an uncapped screen-share target seed a connection that now carries only a camera, or consumes the one-shot hint on a section that sends nothing — which would leave every later publish with no hint at all.

The direction is the discriminator, as an exclusion rather than a match: recvonly and inactive are the only directions that cannot carry local media, and they are exactly where a section lands once its sender is removed (removeTrack moves sendonly → inactive and sendrecv → recvonly). sendonly, sendrecv and a section with no direction attribute — which SDP defaults to sendrecv — all send.

Two calculation changes

Cap and floor. Camera is now capped at 1 Mbps so the estimator does not open too aggressively; screen share is exempt, because its content needs the bitrate immediately to stay legible. Targets below 300 kbps get no hint. Both match client-sdk-js and the Rust SDK; Flutter had neither.

Target derivation. computeStartTargetBitrate replaces encodings[0].maxBitrate. Simulcast rids are ordered q, h, f, so reading the first encoding took the lowest layer — for a 720p publish that is ~150 kbps, giving a ~135 kbps "hint" that did nothing. This is not optional cleanup: with the new 300 kbps floor, the old derivation would have suppressed the hint entirely for most camera publishes. A single SVC stream still uses its first encoding, since it declares the whole budget there; plain simulcast and SVC-published-as-simulcast (L1T*) sum.

Tests

test/core/start_bitrate_test.dart, 13 cases mirroring the JS suite: section/codec matching, the cap and its screen-share exemption, the floor, the connection-level max, stale-entry filtering, exclusion of a section that stopped sending but kept its msid (both inactive and recvonly), inclusion of sendrecv and direction-less sections, and the target derivation.

Verified locally on Flutter 3.44.9 / Dart 3.12.2: flutter analyze clean, flutter test 437 passed / 1 skipped, dart format --set-exit-if-changed clean, import_sorter clean.