How WebRTC Negotiates VP8 and H.264 Video Codecs

This article explains how WebRTC automatically negotiates video codecs, specifically VP8 and H.264, between two connecting peers. It covers the underlying Session Description Protocol (SDP) offer/answer exchange, how codec preferences are ordered, and how specific parameters like H.264 profiles are matched to ensure successful video transmission.

The SDP Offer/Answer Model

WebRTC utilizes the Session Description Protocol (SDP) within an offer/answer workflow to establish media sessions. When a connection is initiated, the calling peer (the offerer) generates an SDP “offer.” This text-based metadata lists the peer’s media capabilities, including supported audio and video codecs, network candidates, and security parameters.

The receiving peer (the answerer) parses this offer, compares the capabilities against its own, and returns an SDP “answer.” This exchange determines the exact codec and configuration that both peers will use to compress and decompress the video stream.

Codec Prioritization in the SDP

In an SDP offer, video codecs are listed in the media description section (m=video). Each codec is assigned a payload type number and defined using format parameters (a=rtpmap and a=fmtp).

The order of the payload types in the m=video line indicates the sender’s preference. For example, if a browser prefers VP8 over H.264, it will list the payload type for VP8 first:

m=video 9 UDP/TLS/RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

When the answering peer receives this list, it scans the codecs from left to right (highest preference to lowest). It matches the offered codecs against its own local capabilities and selects the first mutually supported codec to include in its SDP answer.

H.264 Profile Matching

Negotiating H.264 is more complex than VP8 due to the existence of various “profiles” and “levels.” Profiles define the feature set used to compress the video (e.g., Constrained Baseline Profile for low-latency/low-power devices, High Profile for better quality), while levels dictate the maximum resolution and bitrate.

During negotiation, H.264 codecs include a profile-level-id parameter in the SDP. For negotiation to succeed: * Both peers must support the exact same H.264 profile. * If Peer A offers H.264 High Profile, but Peer B only supports Constrained Baseline Profile, they cannot agree on that specific H.264 configuration. * If no matching H.264 profiles are found, the negotiation engine will fall back to VP8 (which has a singular, universally supported format in WebRTC).

Asymmetric vs. Symmetric Negotiation

By default, WebRTC implementations strive for symmetric codec negotiation, meaning both peers use the same codec to send and receive video (e.g., both send VP8). This simplifies resource allocation and hardware acceleration.

However, the WebRTC standard technically allows for asymmetric negotiation, where Peer A sends VP8 and receives H.264, while Peer B does the opposite. If the SDP answer maintains different preferences for sending and receiving, the WebRTC media pipeline will automatically configure separate encoders and decoders on each peer to match the negotiated parameters.