A codec shortlist is a set of testable candidates. Compatibility, quality, latency, encode cost, decode cost, packaging, licensing, and fallback all have to fit the same delivery job.
Compare codec families here; tune H.264 elsewhere
This page helps choose among H.264, HEVC, VP9, and AV1. If H.264 is already the baseline and the work concerns profiles, levels, or a receiver fallback, move to the focused H.264 compatibility guide. Containers are separate from codecs; the codec and container guide explains that boundary.
Freeze the delivery job before creating samples
Record live or VOD use, target quality, resolution, cadence, delay budget, audience devices, browser versions, native applications, hardware encoders and decoders, packaging, storage, regions, accessibility, battery sensitivity, and fallback expectation. Choose representative source clips with faces, motion, texture, gradients, low light, animation, and screen text. Every codec candidate must receive the same source and viewing conditions.
H.264
Often considered for broad established receiver reach. Verify the required profile, level, container, hardware path, and actual device cohort rather than assuming the codec name is sufficient.
HEVC
Evaluate HEVC where its measured quality or delivery result may justify receiver, hardware, packaging, and licensing work. Do not infer support from device age alone.
VP9
Test VP9 in the target browser, application, container, encoder, and decoder path. Web use in one environment does not prove every production receiver accepts it.
AV1
Trial AV1 when receiver coverage and available encode resources can support it. Measure time, energy, delay, quality, packaging, and fallback with the real content.
Build the receiver matrix from current sources
Browser documentation offers a starting point. Mozilla’s current web video codec guide summarizes format considerations, while the W3C WebCodecs codec registry defines codec-string registrations used with that API. Neither source proves that a particular profile, level, container, operating system, or hardware path works for your audience.
Create rows for the actual combinations: device model, OS, browser or app, version, container, codec string, profile, level where applicable, resolution, cadence, audio, and playback route. Mark start, sustained playback, seeking, switching, CPU or power observation, and visible errors. Keep failures; they define the fallback.
Test packaging and rendition selection together
Place every candidate inside the container and delivery format proposed for production. Verify codec strings, initialization data, encryption mode, captions, audio pairing, seeking, live joins, and switches between codec or resolution families where supported. A raw elementary-stream decode proves less than the packaged route viewers will receive.
Decide how the player chooses a fallback when the preferred decoder is missing, slow, or disabled. Test direct links, cached manifests, and a session resumed after an application update. Keep the fallback visible in analytics so apparent success does not hide that most of the audience never used the candidate codec.
| Candidate | Receiver result | Encode observation | Delivery and packaging | Diligence |
|---|---|---|---|---|
| H.264 | Tested profile/level cohort | Quality, time, load, delay | Required containers and fallback | Current licensing and product support |
| HEVC | Browsers, devices, apps, hardware decode | Matched-quality trial | Packaging and rendition selection | Licensing and workflow constraints |
| VP9 | Target web and native receivers | Software or hardware path | Container and player behavior | Operational support lifecycle |
| AV1 | Current mandatory and optional cohort | Encode time, energy, live suitability | Packaging, cache, switch, fallback | Implementation and support maturity |
Probe hardware instead of assuming acceleration
Identify the exact encoder and decoder devices, drivers, APIs, profiles, bit depth, session demands, and concurrent workload. NVIDIA publishes current capabilities through its Video Codec SDK, but support still depends on the specific GPU and matrix. Run the intended encode and decode while collecting load, memory, speed, dropped work, power where relevant, and a software fallback result.
Compare quality at an agreed operating point
Choose either a target bitrate or a target visual quality and state it before encoding. Use matched resolution, cadence, preprocessing, key-frame policy, and viewing conditions. Review blind where practical, then add objective measurements as supporting signals. A percentage saving from another clip, preset, or vendor does not transfer automatically to this workload.
Record encode time and end-to-end delay along with picture quality. A codec that reduces delivery bytes but multiplies production time may fit an offline library and fail a live channel. Use the bitrate guide to turn the selected quality point into a delivery budget.
Measure decoder cost on the viewer device
Observe startup, sustained frame delivery, dropped frames, CPU or hardware-decoder use, memory, temperature, and battery impact where those affect the audience. Include background-to-foreground transitions and a long-enough session to reveal thermal throttling. A codec can be technically supported yet provide an unacceptable experience on a mandatory receiver.
Accessibility assets and alternate audio must travel with the candidate during this test. Check captions, described audio, language selection, and seeking after a rendition change. Do not approve picture efficiency at the expense of a required track or control.
Keep licensing as a documented diligence item
Codec standards, open-source implementations, hardware, and distribution rights are different layers. Via LA publishes current information for its AVC/H.264 licensing programme. It cannot provide a complete legal conclusion for every implementation, pool, jurisdiction, or business model. Record which legal and procurement review applies to each candidate and revisit it before launch.
Operational support has a lifecycle too. Record encoder and decoder library versions, browser and operating-system support commitments, hardware replacement plans, and who can diagnose a failed file after launch. A royalty or open-technology description does not answer whether the organization can operate the implementation for the life of its archive.
Failure rehearsal: the candidate works in browsers but not televisions
Keep the exact failing file and receiver. Compare codec string, profile, level, bit depth, container, audio, dimensions, cadence, and delivery path with a known-good asset on the television. Verify whether decode support is hardware, software, or absent. If the candidate remains valuable elsewhere, test rendition selection and the H.264 fallback rather than silently removing the device cohort.
Make one migration slice
Encode a small live or VOD set, package it through the intended path, and expose it only to the measured receiver cohort. Monitor playback, failures, support requests, encode cost, delivery volume, and rollback.
Choose from a measured receiver and encode trial
Select the codec lanes that satisfy mandatory receivers, quality, delay, production cost, packaging, licensing diligence, and fallback. Gradual rollout is one method, not a universal rule. If implementation then needs live conversion, assess Callaba live video transcoding against the verified codec matrix. No codec, hardware-density, throughput, or savings capability is implied until current product evidence confirms it.
Store source clips, commands and versions, encoded files, receiver rows, visual notes, hardware measurements, delivery observations, licensing review, and rollback result. Reopen the shortlist when audience devices, encoder hardware, packaging, or business terms change.
Give the approved matrix an expiry trigger: a major browser release, device-family change, encoder update, new distribution region, or licensing change. The codec names may stay familiar while the workable combination moves.
