Codecs and Containers Explained for Video Streaming

Last updated: June 28, 2026

By the WpStream Editorial Team

Your browser plays MP4 files every day. That does not mean it can play every MP4 you throw at it. The .mp4 part is the box, not the thing inside, and the thing inside is what fails when a video refuses to play.

This is the “why won’t this video play?” problem, and it is also the decision your encoder makes every time you go live. Most explainers hand you a flat glossary and call it a day. The useful question is not “what is a codec.” It is which codec and which container belong at which end of the streaming pipeline, because the answer changes whether you are sending video to a server or to a viewer. That is what we map here: not a glossary, but a pipeline.

Codec vs container, in one sentence each

A video codec is the compression method (short for coder, decoder): the algorithm that squeezes raw video into a small bitstream and decodes it back into pictures. H.264, HEVC, VP9, and AV1 are video codecs. A video container is the wrapper file that holds the encoded video stream, the audio stream, any subtitles, and the metadata that keeps them in sync. MP4, MKV, MPEG-TS, FLV, and WebM are containers.

Here is the analogy worth keeping: the container is the box, the codec is how what is inside was packed.

That distinction bites constantly. One container holds many codecs. An MP4 can carry H.264, HEVC, AV1, or VP9 video alongside AAC, Opus, or MP3 audio. So “what format is this video?” is genuinely a two-part question. The compression itself is the codec layer, and our video compression explainer goes deep on how that squeezing works. The second consequence, which drives most playback failures, comes next: playback needs the container and the codec both supported, not just one.

The four video codecs that matter

Four codecs cover almost everything you will encounter, a progression from the universal default to the encumbered successor to the royalty-free challengers. Each one trades something away, so we name the cost.

H.264 / AVC is the one that plays everywhere. This is the compatibility floor. Every browser, every phone, every smart TV, and the default output of OBS, vMix, and Wirecast all speak H.264. Its compression is good, not the most efficient encoder by modern standards. Licensing is proprietary, run through the Via LA patent pool, but fees are waived for video delivered free to end users, a big reason it became the web’s default. If you ship exactly one codec, ship this one.

HEVC / H.265 buys better compression and inherits licensing friction. It delivers roughly the same quality at about half the bitrate of H.264, and it was built for 4K and HDR. The real story is licensing, not technology. HEVC patents are split across multiple competing pools (Via LA, Access Advance, plus patents in no pool at all). Encoder and decoder fees both apply, with no clean free-internet waiver. That fragmentation, not the codec, is why the open web never adopted it broadly, though it still dominates app and device delivery of 4K HDR. Use it for premium 4K and HDR, always behind an H.264 fallback.

VP9 is Google’s royalty-free answer. It is open and royalty-free, with compression in HEVC’s ballpark. Browser support is broad, and the standard pairing is VP9 plus Opus inside a WebM file. Its role: royalty-free web delivery when you control the container yourself.

AV1 is the royalty-free frontier. It comes from the Alliance for Open Media (AOMedia), a consortium founded in 2015 by Amazon, Cisco, Google, Intel, Microsoft, Mozilla, and Netflix, and it carries a royalty-free, perpetual, irrevocable license. It runs roughly 20 to 40 percent more efficient than HEVC, though the exact figure varies with content and encoder settings. The honest counterweight, and this is no AV1 hype reel: encoding AV1 is computationally expensive, which is why its heaviest users are big platforms that encode once and serve millions. As of June 2026, every major browser supports AV1, but Safari plays it only on Apple devices with an AV1 hardware decoder, meaning M3-generation Macs and later, iPhone 15 Pro, and iPhone 16 and newer. Hardware decode reaches an estimated 80 percent of streaming devices by rough industry counts (a ballpark that shifts every device generation, not a measured figure); the gap is older Android, iPhone 14 and earlier, and pre-2020 TVs. Confirm current coverage on caniuse before you rely on it. Its role is bandwidth savings on high-volume VOD, behind an H.264 or HEVC fallback.

VP8, Google’s pre-VP9 royalty-free codec, remains the mandatory baseline for WebRTC but is mostly legacy for file delivery now.

The containers you actually stream in

Containers make more sense placed where each one shows up in the pipeline.

MP4, built on ISOBMFF, is the universal box. It carries H.264, HEVC, AV1, or VP9 video with AAC or Opus audio, plays in every browser, and is the default for progressive web video and downloads.

Fragmented MP4, or fMP4, is the same box split into many small independently deliverable segments instead of one monolithic file. This is the container shape modern adaptive streaming actually uses.

CMAF is not a codec; it is a standardized fMP4 segment format. Apple and Microsoft proposed it in 2016, published in 2018. The point is to stop packaging the same video twice, once as MPEG-TS for HLS and once as fMP4 for DASH. With CMAF you encode and segment once, then serve both HLS and DASH from the same fMP4 segments, changing only the manifest. It is also the basis of low-latency HLS and DASH.

MPEG-TS, the .ts files, is the original HLS segment container. It was designed for broadcast transport, and for years HLS meant .ts segments. It is still common in deployed HLS, but the industry is migrating toward fMP4 and CMAF to unify with DASH and cut cost.

FLV is legacy, yet operationally alive as the RTMP ingest container. Flash playback is dead. FLV-over-RTMP as the contribution wrapper is not.

WebM and MKV round out the list. WebM is open, royalty-free, and the natural home for VP9 and AV1 web VOD. MKV is the flexible superset WebM derives from, but it is not natively browser-playable, so it lives in storage and archival rather than web delivery.

The trap: container support is not codec support

This is the central teaching point. A browser can support the container and still refuse the codec inside it. Chrome plays the MP4 container every day, but whether it plays HEVC-inside-MP4 depends on whether the machine has a hardware HEVC decoder. Same box, different result.

That is the real lesson: the adoption gate is hardware decode, not browser version. HEVC and AV1 both lean on the device’s silicon, so the browser version tells you almost nothing and the chip tells you everything. And the one combination with no caveats anywhere is H.264 with AAC, which is why it survives as the universal fallback. Support tables move, so as of June 2026, check caniuse before you depend on them.

Audio: AAC or Opus, and when

Audio gets treated as an afterthought almost everywhere. The pairing is simple once you say it plainly.

AAC is the default streaming audio codec. It plays natively everywhere, HLS and DASH overwhelmingly use AAC-LC, and it is the audio half of the H.264 pair RTMP ingest expects. Typical stereo bitrates run 128 to 256 kbps.

Opus is open, royalty-free, and more efficient. For comparable quality it needs roughly 15 to 25 percent less bitrate than AAC-LC, and it spans voice to music in a single codec. It is the mandatory audio codec for WebRTC and the standard audio in WebM. Apple has added Opus-in-HLS, but AAC stays the safe default for HLS and device compatibility.

The decision is short: AAC is the compatibility default for HLS delivery, Opus is the efficiency and real-time choice WebRTC builds on, and MP3 is the legacy universal-but-inefficient option.

One table: codec, container, audio, and where each belongs

Here is the whole thing as one scannable map, by pipeline stage.

Ingest vs delivery: two jobs, two choices

Most explainers stay vague here. Ingest and delivery are not the same job, and do not make the same codec choice.

Ingest is the contribution leg: camera or encoder to server. The dominant path is H.264 video plus AAC audio, muxed into FLV, sent over RTMP. That is what OBS, vMix, Wirecast, and StreamYard default to. It is a 2002-era stack that survives because it is universally supported and low-latency on that first hop. Enhanced RTMP, driven by the Veovera specification and supported in recent FFmpeg and OBS Studio builds, lifts the old H.264-only limit to add HEVC, AV1, VP9, HDR metadata, and multitrack audio. Treat it as emerging, not the default: a standard OBS configuration today still sends H.264, AAC, and FLV.

Delivery is the distribution leg: server to viewers. The dominant path is HLS, with DASH alongside it, serving an adaptive bitrate ladder of renditions as segments. The segment container is MPEG-TS historically and fMP4 or CMAF increasingly. Delivery codecs span H.264 for universal reach, HEVC for 4K and HDR to capable devices, and AV1 or VP9 to save bandwidth where decode hardware exists, offered as parallel renditions with H.264 as the fallback rung.

The bridge is transcoding: the encoder turns one ingest stream into a ladder of delivery renditions, which is why ingest and delivery are not the same decision. Most live streams still send H.264 over RTMP not because it is the most capable codec but because it works everywhere. The practical default: H.264 plus AAC, which ingests everywhere and delivers everywhere. Reach for HEVC or AV1 on the delivery side only when bandwidth savings to capable devices justify the extra encode cost and fallback complexity.

How this maps onto WpStream

WpStream is our WordPress live streaming and pay-per-view plugin, so treat what follows as the vendor speaking about its own product. It sits exactly on the standard pipeline above, which makes it a concrete example.

On the ingest side, WpStream takes H.264 over RTMP from OBS, vMix, Wirecast, and StreamYard, plus browser broadcasting on paid tiers. That is the standard contribution leg, the concrete reason your encoder sends H.264 at all. On the delivery side, WpStream delivers over HLS with adaptive bitrate across a multi-CDN, with encryption, DRM, and CORS access control on top. That maps directly onto the HLS delivery leg above, and glass-to-glass latency lands at a few seconds. Everything else here is general theory; only those two hooks are WpStream-specific, the parts you do not hand-configure.

Key Takeaways

• H.264 is the universal video codec, playing on every browser, phone, and smart TV, and remains the default for both live ingest and delivery.
• The video container (MP4, FLV, WebM) holds the encoded stream; supporting a container does not guarantee a device can decode every codec inside it.
• HEVC offers roughly half the bitrate of H.264 at comparable quality, but fragmented licensing kept it off the open web.
• AV1 is royalty-free and roughly 20 to 40 percent more efficient than HEVC, with about 80 percent hardware-decode coverage as of June 2026.
• For live streaming, H.264 plus AAC ingested over RTMP and delivered over HLS is still the combination that plays for everyone.

Frequently Asked Questions

Is a codec the same as a file format?

No. The file format, the extension, is usually the container; the codec is the compression inside it. A .mp4 file tells you the box, not whether the codec inside it will play on a given device, which is why WpStream delivers H.264, the codec with no playback caveats.

What is the best codec and container for live streaming?

For ingest, H.264 plus AAC in FLV over RTMP; for delivery, that same H.264 in an HLS adaptive ladder. That H.264-in, HLS-out path is exactly what WpStream uses, because it plays everywhere without fallback gymnastics.

Why does my MP4 play in one browser but not another?

Almost always it is the codec inside, not the MP4 container, because HEVC-in-MP4 needs a hardware decoder the other device lacks. WpStream sidesteps the problem by standardizing on H.264 for delivery.

Is AV1 ready to use today?

For high-volume VOD to modern devices, increasingly yes, with roughly 80 percent hardware-decode coverage by industry estimates as of June 2026, but keep an H.264 fallback for older hardware. WpStream’s adaptive delivery is built around H.264 reach for exactly that reason.

What is the difference between a container and a streaming protocol?

The container, such as MP4, fMP4, or a .ts file, holds the media; the protocol, RTMP or HLS, is how it travels. WpStream uses RTMP to ingest and HLS to deliver, carrying those containers across the pipeline.

What to watch next

Remember the box. The .mp4 was never the thing inside it, and the thing inside is where playback still succeeds or fails. The codec mix is shifting toward royalty-free options: AV1 hardware coverage climbs every year, and Enhanced RTMP is starting to carry it on the ingest side too. But the universal floor is not moving fast. H.264 plus AAC, ingested over RTMP and delivered over HLS, is still the combination that plays for everyone. That floor is what WpStream is built on. Let the silicon, not the spec sheet, tell you when the frontier has arrived.