[Rust-KVM]

Requested by 4c · project thread

Summary

Before: mpph264enc emits High profile (level 5.2, 640034), but only a Constrained Baseline H.264 codec was registered, so the SDP answer always labelled the stream 42e01f. Chrome tolerates the mismatch; stricter decoders may not.

After: when the browser offers H.264 High (Chrome, Safari, Edge), the answer negotiates High and the SDP matches what the encoder sends. Offers without High fall back to the existing Constrained Baseline entry as before.

How

webrtc.rs: register a second H.264 codec (payload 106, profile-level-id=640034) next to the Constrained Baseline one, and give the video track the High fmtp so binding prefers the negotiated High payload. This assumes the default encoder profile; a --video-profile override is not reflected in the SDP.

Testing

• cargo +nightly fmt --all (CI)
• cargo +nightly clippy --workspace --release --all-targets -- -D warnings (CI)
• cargo +nightly test --workspace (CI)
• Frontend touched: not applicable
• Tested on an RK3588 device: a build with all three video branches (fast first frame, idle without viewer, H.264 High profile) was deployed to the NanoPC-T6 (health ok, 4K60, no WARN/ERROR at startup); video played in Chrome on cold connects and on 6 takeover reconnects, first frame 101–162 ms.

Checklist

• No #[allow(...)] suppressions and no new unwrap() / expect() in production paths
• Hot paths stay zero-copy; periodic loops use MissedTickBehavior::Delay
• Shared protocol types live in rkvm-proto
• RPC method set changed → not applicable
• Module tree or build invariants changed → not applicable

Part of a set of three video PRs (#60, #61); merges onto dev together with them without conflicts.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PbdzY6PfT28goR4BhqdsXR

---

Generated by Claude Code