Transcoding architecture for live broadcast & multiplatform distribution

Transcoding converts a stream from one codec, bitrate, resolution or format to another, and requires a full decode-and-re-encode cycle. Transmuxing changes the container or transport wrapper while leaving the compressed essence untouched. Passthrough changes nothing at all. Deciding correctly between the three at each stage of a contribution and distribution chain is one of the highest-leverage design decisions available, because it compounds: a chain with three unnecessary transcode stages carries three times the avoidable latency and three generations of avoidable quality loss.

This article sets out the decision test, the adaptations that genuinely require re-encoding, and what to protect when a transport stream is rebuilt.

How it works

The decision test

Work through four questions in order at every processing stage. The first “yes” determines the answer.

1. Does the codec or profile need to change? AVC to HEVC, HEVC Main to Main 10, a profile or level the downstream decoder does not support. Codec change requires transcode. There is no shortcut.

2. Does the picture itself need to change? Resolution, frame rate, chroma subsampling, bit depth, or a dynamic-range conversion between SDR and HDR that alters pixel values. All require transcode.

3. Do internal encoding parameters need to change? GOP structure, bitrate, rate-control mode, or a latency-mode change that alters reference structure. These require transcode even when the codec stays the same, because they are properties of the encoded bitstream rather than of its packaging.

4. Is the required change confined to packaging, signalling or routing? Container change, transport wrapper change, PID or service remapping, multiplex restructuring, metadata insertion or conversion. Transmux. No decode, no re-encode, no generational loss, and the added latency is packet-scale rather than frame-scale.

If none of the four applies, the correct action is passthrough.

The test is deliberately ordered so that the expensive answer requires an affirmative reason. In practice, stages that survive this test in real chains are: contribution encode at acquisition, format adaptation at a distribution head-end where the output format genuinely differs from the input, and bitrate adaptation where downstream capacity is constrained. Stages that usually fail it: “normalisation” passes that re-encode already-conformant sources, and re-encodes performed to insert metadata that could have been inserted at the multiplexer.

Adaptation that genuinely requires re-encoding

Where a transcode is justified, the specific adaptation determines its cost.

Codec translation. The dominant case in distribution: AVC to HEVC to reduce transport bitrate on a capacity-constrained link, or HEVC to AVC to serve receivers that predate HEVC deployment. Latency cost is a full decode-encode cycle plus whatever look-ahead the output encoder is configured for. Quality cost depends heavily on the input bitrate — a generously encoded source transcodes far better than one already at its quality floor.

Bitrate adaptation. Reducing bitrate for a constrained onward link. Cheaper than codec translation if the codec is unchanged, but still a full cycle. Worth checking whether statistical multiplexing across the service group achieves the same aggregate saving without touching individual services.

Resolution and frame-rate conversion. UHD to HD for regional or legacy outputs, or frame-rate conversion across regional standards. The conversion itself, not the codec, dominates the quality outcome, and motion-compensated frame-rate conversion is significantly more expensive than simple decimation.

Dynamic-range conversion. HDR to SDR down-conversion for services that cannot carry HDR. This is a pixel-value transform and requires transcode; the tone-mapping approach chosen matters more to the result than the encoder does.

What transmuxing can do without touching the picture

The set of changes achievable without re-encoding is larger than most workflow designs assume:

• Transport wrapper change — MPEG-TS over UDP to SRT, RTP to TS, or the reverse.

• PID and service remapping — renumbering programme identifiers and service information for a downstream head-end’s plan.

• Multiplex restructuring — extracting a service from one multiplex and inserting it into another, or splitting a multi-service transport stream into single-service streams.

• Metadata insertion and conversion — adding or translating service information, EPG data, or conditional-access signalling.

• Null-packet removal and re-stuffing — adapting a constant-bitrate stream to a different transport rate.

• Protection change — adding or removing FEC, applying ST 2022-7 duplication, changing encryption.

Each of these is a packet-level operation. Latency is measured in packet times rather than frame times, compute cost is a fraction of a transcode, and picture quality is bit-identical to the input.

Generational loss and cascade planning

Each decode-and-re-encode cycle discards information the next encoder cannot recover. The loss is not linear: the second generation typically costs noticeably more than the first, because the first encoder’s quantisation artefacts become structure the second encoder tries to preserve, spending bits on coding noise.

Three practices contain it:

Count the generations end to end. Draw the full chain from acquisition to final delivery and mark every decode-encode boundary, including ones inside equipment that presents itself as a single stage. Chains with more than two generations before final distribution encoding should be treated as design faults, not as tuning problems.

Keep contribution generously encoded. A contribution feed carrying visually lossless or lightly compressed video — JPEG XS, or HEVC at a bitrate well above its quality knee — survives downstream transcoding far better than one encoded at distribution bitrates. Bandwidth spent on the contribution leg buys quality across every downstream output.

Align GOP structures where cascade is unavoidable. Aligning the output encoder’s GOP boundaries with the input’s reduces the penalty, because the second encoder is less often forced to make intra decisions mid-way through the first encoder’s prediction structure.

What breaks when a transport stream is rebuilt

The most common production failures around transcoding are not picture failures. They are signalling failures, and they are silent until something downstream depends on the missing data.

SCTE-35 splice information. Ad-insertion and content-splice markers are carried in their own PID. A transcode that rebuilds the transport stream without explicit carriage will drop them, and the failure surfaces as missed ad breaks and lost revenue rather than as a picture fault. Where the transport structure changes, markers must be extracted before the transcode and re-inserted at the multiplexer with their timing relationship to the video preserved.

Closed captions and subtitles. Carried either as ancillary data within the video elementary stream or as separate PIDs, depending on region and format. Captions embedded in the video essence are particularly vulnerable, because a decode-encode cycle destroys them unless the transcoder is explicitly configured to extract and re-insert.

Audio metadata. Dolby and loudness metadata is carried alongside the audio essence. Dropping it produces audio that plays but fails loudness compliance checks downstream, and the failure may not appear until the signal reaches a playout system or regulatory monitoring point.

PIDs and service information. Transcode stages commonly renumber PIDs or restructure service information. Downstream systems — multiplexers, monitoring, conditional-access platforms — address elementary streams by PID. Undocumented changes break those references silently.

The common thread is that these failures are invisible in the video output and surface at integration test or in production, far from the transcode stage that caused them. Treating transcode configuration as a video-only decision, and auditing signalling separately or not at all, is the pattern that produces them.

Why it matters

Avoiding unnecessary transcodes

The cost of a transcode that was not required extends beyond the compute and power budget. Added latency compounds through the chain: a signal path with three avoidable decode-encode stages carries the latency of three encoders’ worth of look-ahead and buffering, which in a live contribution chain can accumulate to seconds. Quality loss is permanent and compounds similarly. And the transcode adds a failure mode — configuration errors, resource exhaustion, codec incompatibilities — to a stage that, as a passthrough or transmux, would have had none.

Treating passthrough and transmux as first-class design options rather than fallbacks from a default transcode architecture removes all of this cost wherever the media itself does not need to change.

Statistical multiplexing as an alternative to bitrate adaptation

Where aggregate bandwidth is the constraint, statistical multiplexing across a service group is frequently a better tool than per-service bitrate reduction. A statmux allocates bits dynamically across services sharing a multiplex, shifting capacity from low-complexity services (news, talking heads) to high-complexity ones (sports, high-motion events) within a fixed aggregate. The services are still encoded — what changes is that the rate-control decision is made across the group rather than per service, so no additional decode-encode stage is introduced. Applying the same idea to streams that are already encoded is a different operation: statistical remultiplexing requantises the existing bitstreams, and that does cost a generation.

The result is that a group of services sharing a statmux consistently delivers better average quality at the same total bandwidth than the same services encoded individually at fixed bitrates. The trade-off is that statmux requires co-location of the encoders or a feedback channel between them, and it adds a layer of system complexity that single-service fixed-bitrate transcodes do not.

Where the requirement is to reduce the bandwidth of a single service in isolation, per-service bitrate adaptation remains the relevant tool.

The OTT packaging boundary

The decision framework in this article applies to contribution and primary distribution chains carrying broadcast transport streams. OTT packaging — ABR ladder encoding, HLS and DASH manifest generation, LL-CMAF segment production, DRM licence acquisition — is a distinct downstream stage with its own design decisions. The contribution feed reaching an OTT origin is typically a single high-bitrate stream; what happens to it inside the packaging tier is outside the scope of this article.

What to do

At each processing stage in a contribution or distribution chain, apply the decision test before specifying a transcode. Transmux where the required change is packaging or signalling, not picture. Passthrough where no change is required at all.

Where transcode is confirmed as necessary, audit the stream’s ancillary content before encoding: SCTE-35, closed captions, audio metadata, and service information. Configure explicit extraction and re-insertion for each. Treat the signalling audit as part of the transcode specification, not as a post-integration check.

For chains where multiple transcode stages are unavoidable, count the cascade generations explicitly and plan contribution bitrates on the assumption that they will each cost quality. A contribution feed encoded at distribution bitrates does not survive a two-generation cascade without visible degradation.

For bandwidth control in service groups, evaluate statistical multiplexing before defaulting to per-service bitrate reduction. Statmux will typically achieve better quality at the same aggregate bandwidth, at the cost of architectural complexity.

How Appear addresses this

Appear builds contribution, processing and primary distribution infrastructure. The decision this article describes maps directly onto how the X Platform is put together, because transmux and transcode are separate functions on separate modules rather than a single processing stage that always decodes.

The IP Gateway handles the packaging and routing changes without touching the essence. It analyses an incoming MPEG-TS, exposes the individual services, and lets them be routed independently — extracted from one multiplex, recombined into another, output as SPTS or rebuilt as MPTS, with PAT, SDT and PMT regenerated and null-packet stuffing applied to match the onward transport rate. The same applies over SRT: an SRT input exposes the services inside the tunnel, and an SRT output builds a multiplex inside it, with AES-128 or AES-256 and ST 2022-7 protection available on the same path. All of this is packet-level work, and the compressed video is bit-identical from input to output.

One constraint worth knowing when planning multiplex restructuring: the 100G interface supports SPTS output only, not full MPTS multiplexing. Where a design needs services recombined into a multiplex, that work belongs on the 10G or 1G interfaces.

Where the decision test returns transcode, that is a distinct application on the ECx modules rather than a mode of the gateway — which keeps the expensive path an explicit choice at design time instead of a default. Two points on scope: HDR and SDR signalling is carried through today rather than converted, with LUT-based conversion on the roadmap, so an HDR-to-SDR down-conversion is not currently something the platform performs. And Appear does not offer statistical multiplexing on the X Platform, so where a service group needs statmux, that sits with other equipment in the chain.

For the compute-platform question — ASIC versus FPGA versus CPU or GPU for transcoding workloads, channels per rack unit, and watts per stream — see Comparing cloud/software and hardware encoding for live video contribution.