‘Transcode everything’ and ‘copy everything’ are both wrong — they break at scale in opposite ways. The right answer is specific, and at 500 channels it’s the difference between a few servers and a rack of GPUs.
Ask ten IPTV operators how they ingest 500 channels and you’ll get two wrong answers and one right one. The two wrong answers — ‘transcode everything’ and ‘copy everything’ — each break at scale in opposite ways. The right answer is boring and specific, and it’s worth understanding because at 500 channels it’s the difference between a few servers and a rack full of them.
Copy (pass-through / remux) takes the incoming compressed stream and re-containers it for delivery — MPEG-TS in, DASH/HLS segments out — without re-encoding the video. The CPU cost is near zero because you never touch the pixels. For a clean source, it’s the cheapest, lowest-latency, highest-quality path there is.
Copy mode is the right default. At 500 channels it can be the difference between a handful of CPU servers and a rack of GPUs. But it only works on clean sources — and ‘clean’ is doing a lot of work in that sentence.
Copy assumes the source is well-behaved: consistent H.264/H.265 video, AAC audio, a sane GOP structure, one video track. Real broadcast feeds are not always well-behaved, and when they aren’t, the packager or player rejects the stream and the channel simply doesn’t play. The usual culprits:
The failure is confusing precisely because most channels copy perfectly — so when one or two won’t play, it looks like a mysterious per-channel bug rather than a codec-shape problem.
Transcode decodes and re-encodes, normalising anything into a clean, consistent output — and it’s also what you need if you want an ABR ladder for OTT. The cost is real: roughly a CPU core (or a slice of a GPU) per channel. Transcode everything and your 500-channel headend becomes a transcode farm. Transcode nothing and the awkward 5% of channels never play.
The correct design isn’t a global switch — it’s a per-channel decision made by probing the source. Probe each feed, and if it’s a clean single-profile H.264/AAC stream, copy it; if it carries multi-SPS, SCTE-35, an odd codec or multiple video tracks, transcode just that one. You copy the clean 95% for almost nothing and spend transcode cycles only on the awkward few.
| Source shape | Decision | Why |
|---|---|---|
| Clean H.264/H.265 + AAC, single track | Copy | Near-zero CPU, best quality/latency |
| Multi-SPS / AVCC quirks | Transcode | Player can’t initialise on raw copy |
| SCTE-35 / timed-ID3 present | Transcode | Splice/timing metadata breaks remux |
| Non-standard codec / profile | Transcode | Normalise to a deliverable profile |
| ABR ladder required (OTT) | Transcode | Multiple renditions must be encoded |
HySky’s onboarding probes every source and auto-selects copy or transcode per channel, so the operator never has to think about codec shapes — they add a channel and it goes live in the right mode. A small but important detail learned in production: HLS-origin sources need their read/write timeouts tuned up, otherwise a normal live-playlist refresh looks like a stream drop. These are exactly the sharp edges that only show up when you actually run channels, not just diagram them.
For the national, copy-mode delivery model — where the whole point is to avoid a transcode farm — this per-channel discipline is what keeps the design honest: copy the clean catalogue, quarantine the awkward channels to a tiny transcode path, and keep the hardware bill where it should be.
Talk to a team that runs a live operator, not just sells software.
