demo · v136
Codec negotiation
The sibling concept sets up a peer connection and pipes media; this one inspects the negotiation table. Press the button to enumerate RTCRtpSender.getCapabilities("video") and create a fake offer SDP — the H265 codec lines that 136 added are highlighted, and we mark each codec by hardware-accel availability.
Probing…
send capabilities
—
recv capabilities
—
generated offer SDP (m=video section)
—
the code
const caps = RTCRtpSender.getCapabilities("video");
const h265 = caps.codecs.filter(c => /H265|hev1|hvc1/i.test(c.mimeType));
// In 136+, h265 is non-empty.
const pc = new RTCPeerConnection();
pc.addTransceiver("video");
const offer = await pc.createOffer();
// Look for a=rtpmap:<n> H265/90000 in offer.sdp
why this angle
The sibling concept does end-to-end media: capture, peer, decode. This concept inspects the metadata that lets the negotiation happen at all — the codec capabilities table and the SDP it generates. That's where 136 changed: H265 lines now appear, and where the hardware encoder reports support, they're listed before VP9. The two views together cover what changed (capability table) and what runs (the peer connection).
see also
- H265 (HEVC) in WebRTC — feature index
- End-to-end peer concept
- ChromeStatus entry
- WebRTC spec