Glossary
H.264 (AVC)
The codec that runs almost everywhere. H.264 compresses video efficiently enough for streaming and calls, and two decades of hardware support make it the safe default when battery and compatibility matter.
General definition
H.264 (AVC) is a video compression standard published jointly by the ITU-T (as H.264) and ISO/IEC (as MPEG-4 Part 10, Advanced Video Coding) in 2003. It reduces the size of video by predicting each frame from neighbouring frames and from already-decoded parts of the same frame, then coding only the difference. More than twenty years on it is still the most widely supported video codec in existence: Blu-ray, broadcast, streaming, security cameras, phones and video calls all use it.
Its lasting advantage is hardware. Nearly every phone, laptop and browser has a dedicated H.264 encoder and decoder in silicon, so encoding a call costs little battery and CPU. Newer codecs compress better but often run in software on older hardware, which is expensive on a phone in a long video call.
- Profiles: Baseline and Constrained Baseline for low-complexity real-time use, Main and High for streaming and broadcast quality
- Efficiency: HEVC (H.265) and VP9 reach similar quality at roughly 30 to 50 percent lower bitrate; AV1 improves further, at higher encoding cost
- Licensing: H.264 is covered by patent pools with royalties for some uses; VP8, VP9 and AV1 are royalty-free
- Real-time transport: RFC 6184 defines how H.264 is packetised over RTP
For calling, RFC 7742 requires WebRTC browsers to support both H.264 Constrained Baseline and VP8, so any two browsers can always find a common codec. In practice H.264 wins when hardware acceleration matters (phones, tablets, screen sharing from a busy laptop) and VP8 or VP9 wins where software encoding is acceptable and royalty-free licensing is preferred. Endpoints negotiate the choice per call through SDP, and an SFU forwards each sender’s stream without transcoding, so every receiver must be able to decode the codec each sender picked.
In the Ethora ecosystem
Ethora calls are built on WebRTC with an SFU, so codec choice follows the WebRTC rules above: the browsers and client apps on a call negotiate a codec both ends support, hardware acceleration is used where the device provides it, and the SFU forwards packets rather than re-encoding them. H.264 is therefore available on a call wherever the participating devices and browsers offer it, which today is nearly everywhere. The voice and video call API page describes the calling features that sit on top of this.
The practical implication for buyers is that H.264 hardware support is what keeps a long video consultation from draining a patient’s phone, and that a self-hosted or dedicated deployment puts the SFU in the region you choose, so media stays on infrastructure you control. Codec efficiency then decides how much bandwidth each participant needs, which matters most on mobile networks and in group calls where a device receives several streams at once.
