Codec migration and comparison for live contribution and production workflows

How it works

Codec roles in the signal chain

Different stages of a live broadcast chain impose different demands on the codec in use.

Contribution (camera to transport): Codecs at the ingestion point prioritise low latency, robustness to packet loss, and edit-friendliness. JPEG 2000 and JPEG XS are common intra-frame or near-intra-frame choices; HEVC is used where denser, longer-haul links justify its complexity.

Transport and transcoding (edge/cloud): Stream consolidation and format normalisation require real-time transcoders capable of accepting multiple input codecs and producing the renditions downstream systems expect. This stage is where mixed-codec coexistence is most visible during a migration.

Distribution and playout: At the distribution edge, the priority shifts to device reach and delivery efficiency. H.264 remains the universal baseline; HEVC and AV1 deliver meaningful bitrate reductions where client decode support exists. Distribution-side coexistence mechanics sit downstream of contribution and are outside the scope of this article.

Understanding where each codec sits in the chain is the first step in any migration plan — changes at the contribution tier have different risk profiles and operational consequences than changes at the distribution tier.

Basic codec mechanics relevant to migration

Three codec characteristics shape every migration decision: temporal structure, the compression-versus-latency trade-off, and complexity requirements.

Temporal structure determines error behaviour and editing flexibility. Inter-frame codecs such as H.264, HEVC, and AV1 exploit motion prediction across frames, achieving lower bitrates but increasing sensitivity to packet loss and complicating multi-generation encode/decode cycles. Intra-frame or line-based codecs like JPEG XS and JPEG 2000 encode each frame independently, virtually eliminating error propagation and simplifying editing, replay, and re-encoding.

Compression versus latency is an inherent tension. Greater motion prediction and multi-frame analysis improve compression efficiency — fewer bits for the same perceived quality — but increase encoder delay through longer GOPs, look-ahead buffers, and deblocking filters. Low-latency modes disable or limit these tools, reducing delay at the cost of higher bitrate for equivalent quality.

Complexity and acceleration govern how many channels can be encoded in real time and at what power budget. Modern inter-frame codecs rely on dedicated hardware — ASICs, SoCs, GPUs, or FPGAs — for real-time multi-channel encoding at acceptable power draw. Software-only AV1 or high-profile HEVC encoding is feasible but demands substantial CPU resources and may not sustain real-time throughput at UHD resolutions. The broader hardware-versus-software platform decision is covered in depth in Comparing Cloud/Software and Hardware Encoding for Live Video Contribution.

Coexistence during a phased migration

Every migration passes through a period in which two or more codec generations run side by side, and the contribution tier is where that coexistence must be engineered deliberately.

Transcoding cascades place low-latency contribution codecs (JPEG XS or low-latency HEVC) at the ingestion edge and transcode centrally to whatever downstream formats distribution requires. This architecture lets contribution and production retain their low-latency, edit-friendly characteristics while the distribution tier optimises independently for device reach — and it means contribution-tier migration is invisible to end users, which is why phased plans usually start there.

CMAF fragmented MP4 packaging allows HLS and DASH to share segment assets, reducing storage duplication and easing adoption of low-latency chunked delivery without maintaining entirely separate packaging pipelines.

Codec signalling and fallbacks at the manifest level — the codecs parameter in HLS and DASH manifests, combined with HTTP routing rules — map clients to the correct MIME and codec variants, enabling incremental rollouts without hard cutover dates.

Why it matters in broadcast

Codec migration is not an academic exercise. It has direct, measurable impact on four operational dimensions.

Bandwidth and cost. Migrating from older codecs to more efficient alternatives reduces per-stream bitrate and operational bandwidth expenditure. The savings are most pronounced where large numbers of UHD or 4K feeds traverse long-haul managed links or satellite capacity, where every megabit per second carries a tangible cost.

Latency-sensitive production. Remote production (REMI), live switching, and interfacility feeds require deterministic, low glass-to-glass latency. Codec choice directly determines achievable round-trip times and whether operational workflows for live graphics insertion, talkback, and comms remain viable.

Operational resilience and editing. Contribution codecs that are intra-frame or near-intra-frame simplify multi-generation encode/decode cycles — editing, replay, re-encoding — by reducing artefact accumulation. This simplifies workflow automation and preserves visual quality through complex production chains.

Device and regulatory reach. Distribution codec support across set-top boxes, mobile devices, and broadcaster head-ends, combined with conditional access and licensing constraints, determines when and where denser but less ubiquitous codecs like HEVC and AV1 can realistically be deployed.

Technical specifications and trade-offs

When comparing codecs for migration, six technical dimensions matter most: compression efficiency (bits required for a target visual quality, often expressed via PSNR, SSIM, or VMAF), encoding and decoding latency, hardware acceleration availability, resilience to packet loss, computational complexity and power per channel, and licensing and ecosystem maturity.

Comparison of codec alternatives

The following table summarises practical, deployment-level trade-offs across four codec alternatives. Numbers are indicative engineering thresholds typical of production choices; exact results vary with encoder implementation, presets, and content type.

Dimension	H.264 (AVC)	HEVC (H.265)	AV1	JPEG XS
Typical bitrate vs H.264 baseline	Baseline	~40–60% of AVC at similar perceptual quality (profile-dependent)	~30–50% of AVC; software encoders often slower to converge	Not directly comparable — visually lossless at much higher bitrates; designed for contribution, not distribution
Real-time software encode at 1080p50	Feasible on moderate servers	Feasible but CPU-heavy; may require high-end presets	Often impractical in real time without specialised hardware	Trivial — very low computational complexity
Hardware encode support (2024–2026)	Ubiquitous	Widely available on modern SoCs and professional encoders	Increasing; hardware encoders limited but emerging	Available on professional encoder cards and IP equipment
Encoder complexity / power per channel	Medium	Higher than AVC	Highest (software) / medium-high (hardware)	Very low
Typical encoding latency (glass-to-glass)	Low with low-latency configs (GOPs of 1–2 frames)	Low with tuned low-latency modes; encoder tuning required	Higher unless tuned for low-latency hardware	Ultra-low: sub-frame to a few ms per frame
Error propagation	Inter-frame; present	Inter-frame; present	Inter-frame; can be larger with long prediction chains	Frame-independent — minimal propagation
Best operational fit	Universal distribution, legacy device reach	Distribution with bitrate reduction, UHD streaming, satellite	Forward-looking distribution where royalty-free client decode exists	Contribution and production requiring visually lossless quality, ultra-low latency, multi-hop editing
Adoption risk	Minimal	Moderate — device support gaps, licensing complexity	Moderate-high — encoder maturity, client support breadth	Low for contribution; requires compatible equipment across the chain

When evaluating migration cost, include infrastructure conversion (edge encoders, decoders, CDN packaging modules) and downstream client upgrades or fallback provisions. A phased approach — starting with contribution-tier changes that are invisible to end users — often reduces overall risk.

Related approaches and standards

Codec migration does not happen in isolation. Several adjacent standards and protocols shape the migration landscape.

• SMPTE ST 2110: Defines packetised professional media over IP and is commonly used for uncompressed or lightly compressed contribution and production switching. It provides the transport framework within which codec choices at the contribution tier operate.

• JPEG XS (ISO/IEC 21122): An ultra-low-latency, low-complexity, visually lossless codec designed specifically for contribution and production. It supports frame-accurate workflows and professional signalling, making it a natural fit for interfacility links and camera-to-production transport.

• ITU-T H.264 and H.265: The de-facto distribution codecs, with extensive device support and well-understood operational modes across satellite, cable, IPTV, and OTT delivery.

• AV1 (AOMedia Video 1): Targets next-generation compression with an open, royalty-managed licensing model. It is growing in distribution — particularly web and mobile OTT — but hardware encoder and decoder support trails legacy codecs.

• CMAF and LL-CMAF: Common Media Application Format with chunked and low-latency profiles converges HLS and DASH packaging workflows, reducing overhead when maintaining multiple codec renditions during migration.

• SRT, RIST, and RTP with FEC: Transport protocols for contribution over managed and unmanaged networks. The choice of transport affects expected packet-loss tolerance and the required codec error resilience, making transport and codec decisions interdependent.

• NMOS (AMWA IS-04/IS-05): Provides discovery and connection management for IP-native devices, enabling automated management of flows, streams, and codec configurations in ST 2110 environments.

How Appear addresses this

On the X Platform, codec migration is a slot-level change rather than a fleet-level one. The chassis and the module stay in place, and the software image loaded onto the module determines which codec it runs.

The platform covers the contribution and production codecs described above: AVC and HEVC on the ECx modules — ECx110 for SDI I/O, ECx210 for ST 2110 and ST 2022-6 — JPEG XS on the SIx family, and JPEG 2000 on SIx300. That last pairing is the one that matters most mid-transition. A JPEG 2000 estate and a JPEG XS estate can run in the same chassis, so a contribution tier can change codec generation progressively instead of in a single cutover. The transcoding cascades described above map to the ECx transcoder images, which puts central format normalisation on the same estate as the edge encode rather than on a separate fleet.

One practical constraint to plan for: changing a module’s codec role means loading a different software image onto it, so a role change is a scheduled maintenance action rather than a live reconfiguration. That fits phased migration, which is planned around maintenance windows in any case, but it is not a runtime switch.

FAQ

When should an organisation migrate from H.264 to HEVC?
Migrate when bandwidth cost or capacity constraints justify the increased encoder and decoder complexity, and when a sufficient portion of distribution endpoints — set-top boxes, apps, device fleets — can decode HEVC natively, or when you can maintain an H.264 fallback for remaining legacy clients.

Is AV1 ready for live contribution?
AV1 hardware encoders and low-latency profiles are emerging, but AV1 is currently more common for VOD and distribution where encoding latency is less critical. For live contribution, AV1 generally requires purpose-built hardware acceleration to be practical.

Where does JPEG XS fit in a production workflow?
JPEG XS targets contribution and production — camera transport, interfacility links, centralised production switching — where visually lossless quality, minimal per-frame latency, and resistance to repeated encode/decode cycles are essential. It is not designed as a bandwidth-minimising distribution codec.

How do I support legacy clients during migration?
Run parallel ABR ladders or implement server-side transcoding that produces legacy H.264 renditions alongside HEVC or AV1 for capable clients. Use client capability detection and manifest-level codec signalling to route each session to the appropriate rendition automatically.

What KPIs should I measure during codec migration?
Track perceptual quality metrics (VMAF, SSIM) at target bitrates, encoder and decoder latency in milliseconds, packet-loss impact (rebuffering rate, visible error rate), CPU/GPU utilisation and watts per channel, and end-user playback success rates segmented by client type.

How does low-latency mode change codec efficiency?
Low-latency settings — reduced look-ahead, smaller GOPs, fewer B-frames — decrease compression efficiency, meaning higher bitrate is needed for the same perceptual quality. The precise penalty depends on content motion characteristics and encoder implementation.

What operational risks increase when adopting HEVC or AV1?
Key risks include device support gaps, licensing costs and complexity for HEVC, encoder and decoder maturity variations, higher per-channel compute demand, and increased CI/CD complexity for multi-codec packaging and testing.

Do I need specialised hardware to encode HEVC or AV1?
For high-channel-count, low-latency, real-time encoding at UHD resolutions, hardware acceleration (ASIC, SoC, or FPGA) is strongly recommended. Software-only encoders are viable for low-channel-count or offline/near-real-time scenarios but may not sustain production-grade throughput.

How should contribution links be architected during a phased migration?
Keep latency-sensitive, production-critical links on intra-frame or low-latency codecs. Deploy centralised transcoders to produce distribution codecs. Use gateway modules to handle protocol and format conversion alongside packet-loss protection mechanisms such as FEC or SRT.

How does CMAF help during codec migration?
CMAF standardises chunked segment formats for both HLS and DASH, reducing asset duplication and simplifying packaging when maintaining multiple codec renditions for different client populations during a transition period.

Can JPEG XS be used across unmanaged networks?
JPEG XS is optimised for low-latency, low-complexity encoding, but over unmanaged public networks it still requires packet-loss mitigation — FEC, SRT, or RIST — and appropriate bandwidth provisioning to maintain its visually lossless quality target.

What test plan should I run before switching a production feed?
Run a staged pilot: begin with lab-based A/B visual quality tests (VMAF, SSIM) at target bitrates, then move to a live trial with monitored KPIs covering latency, packet loss, and rebuffering. Complete a client compatibility sweep, conduct failover and rollback drills, and validate operational runbooks before full cutover.