H.264 - also called MPEG-4 Part 10 or AVC (Advanced Video Coding) - is a video compression standard developed jointly by ITU-T and ISO/IEC MPEG, first published in 2003. It is the most widely deployed video codec in the world, used in everything from YouTube and Netflix to Zoom, security cameras, and broadcast television. Most video you have ever watched was encoded with H.264.
It is royalty-bearing and governed by the MPEG-LA.
H.264 in WebRTC
H.264 is one of the two mandatory-to-implement (MTI) video codecs in WebRTC, alongside VP8. Every browser that supports WebRTC supports H.264.
Browser implementations:
- Chrome: Uses OpenH264 (Cisco) for encode on most platforms; platform hardware for decode via DirectX Video Acceleration on Windows and VideoToolbox on Mac.
- Firefox: Downloads an OpenH264 binary module from Cisco's servers automatically. Cisco pays the MPEG-LA royalties on all compiled binaries they distribute - this is the mechanism that lets Firefox ship H.264 without licensing fees. Most people who use OpenH264 have never heard of this arrangement.
- Safari: Native hardware H.264 via Apple's VideoToolbox. Historically the most reliable H.264 hardware path on macOS and iOS.
- Edge: Follows Chromium.
H.264 negotiation in SDP uses a=rtpmap with a profile-level-id parameter. The most common value in WebRTC offers is 42e01f (Constrained Baseline, Level 3.1).
Android caveat: some older Android devices lack hardware H.264 support and may not offer H.264 in SDP at all. When targeting broad Android compatibility, test the target device range explicitly and implement VP8 as a fallback.
How H.264 Works
H.264 divides each video frame into 16x16 pixel blocks called macroblocks - a fixed block size, in contrast to newer codecs like H.265 and AV1 that use variable block sizes. Two types of prediction reduce redundancy:
- Intra-prediction removes spatial redundancy within a single frame by predicting each block from its neighbors in the same frame.
- Inter-prediction removes temporal redundancy across frames using motion vectors - how each block moved from a reference frame.
After prediction, the residual difference is transformed using the Discrete Cosine Transform (DCT), quantized, and entropy-coded. H.264 uses two entropy coders: CAVLC (Baseline and Main profiles) and the more efficient CABAC (Main and High profiles). The fixed-block architecture keeps encoder complexity low, which is why H.264 hardware implementations shipped on every platform first - and why H.264 hardware is still the most universal of any video codec.
Profiles and Levels
H.264 profiles define which encoding features are available. Levels set the maximum resolution, frame rate, and bitrate for a given profile.
| Profile | Key Feature | Typical Use |
|---|---|---|
| Constrained Baseline (CB) | No B-frames, no CABAC | WebRTC, mobile, low-latency |
| Main | B-frames, CABAC | Streaming, broadcast |
| High | 8x8 transform, custom quantization matrices | Blu-ray, high-quality VOD |
WebRTC mandates Constrained Baseline Profile, Level 1.2 per RFC 7742. Two reasons this matters: Constrained Baseline forbids B-frames (which require buffering future frames, adding latency), and its stripped-down feature set guarantees hardware decode on virtually every device built in the last 15 years. The tradeoff is slightly lower compression efficiency compared to Main or High Profile - a tradeoff that makes sense when latency and device compatibility are the hard constraints.
Constrained Baseline is a strict subset of Baseline: it removes FMO, ASO, and redundant slices on top of Baseline's restrictions. This extra constraint is what gives it the universal hardware guarantee.
The 42e01f profile-level-id appearing in WebRTC SDP offers is Constrained Baseline Profile, Level 3.1 - the most common negotiated profile in production WebRTC.
Hardware Encoding and Decoding
H.264 has the broadest hardware support of any video codec - including on $15 IoT boards and decade-old mobile handsets.
- Intel Quick Sync: H.264 encode and decode since Sandy Bridge (2011). Available on any modern Intel CPU with integrated graphics.
- NVIDIA NVENC: H.264 hardware encode on Kepler and newer GPUs.
- Apple VideoToolbox: H.264 hardware encode and decode on all Apple Silicon, recent Intel Macs, and all iOS devices.
- Qualcomm: Hardware encode on Snapdragon 800 series and newer.
- ARM Mali: H.264 decode on the majority of Android devices that ship Mali GPUs.
In WebRTC, hardware decode matters more than hardware encode - there are usually far more viewers than senders in any call. On Android devices without H.264 hardware support, Chrome falls back to software decode, which is CPU-intensive. This shows up in getStats() as qualityLimitationReason: 'cpu' on the sender side when the receiver cannot keep up.
VP8 and VP9 have notable hardware gaps on older devices. AV1 hardware encode is still rolling out on mid-range Android handsets as of 2026. H.264 hardware is the safe baseline when you need encode and decode to work reliably across your entire user base.
H.264 vs Other Video Codecs
| Feature | H.264 | VP8 | VP9 | AV1 |
|---|---|---|---|---|
| Royalties | Yes (MPEG-LA) | No | No | No |
| WebRTC MTI | Yes | Yes | No | No |
| Hardware support | Universal | Partial | Growing | Limited (encode) |
| Compression vs H.264 | Baseline | ~same | ~30-50% better | ~30% better than VP9 |
| Encoding complexity | Low | Low | Medium-High | Very High |
| Latency profile | Excellent (CB) | Good | Good | Higher (encode) |
The practical question in WebRTC is not "which codec has the best compression?" - it is "which codec works on every device in my user base with acceptable CPU load?" H.264's universal hardware support means lower battery drain and fewer CPU overload incidents on mobile. VP9 and AV1 offer better quality per bit but cost more compute - and AV1 hardware encode is still rolling out on the devices that matter most.
For mobile-first deployments with heterogeneous device ranges, H.264 remains the safe default in 2026. If your user base is predominantly desktop or latest-generation mobile, VP9 is worth evaluating. SVC is only available on VP9 and AV1 - not on H.264. For multi-quality streaming with H.264, simulcast is the answer.
Licensing and Royalties
H.264 is a royalty-bearing codec. MPEG-LA manages the patent pool covering H.264 encoding and decoding implementations.
The key practical exception: MPEG-LA made H.264 permanently royalty-free for internet video that is free to the viewer (announced 2010, confirmed as permanent 2015). Commercial products that encode or decode H.264 - hardware or software - still pay royalties under the standard terms.
The second exception is OpenH264: Cisco released an open-source H.264 implementation in 2013 and pays MPEG-LA directly for all compiled binaries they distribute. Any product using those specific Cisco-compiled binaries gets H.264 effectively royalty-free. Both Firefox and Chrome use this mechanism for their H.264 implementations.
The licensing complexity is one reason the industry is moving toward royalty-free codecs. VP9 and AV1 are both patent-pool-free. But H.264 is too deeply embedded in hardware silicon and existing deployments to disappear anytime soon.
