How IPTV actually works: the full signal chain

A live channel goes through a dozen distinct stages between the broadcaster and the screen. Understanding the whole chain is what separates an operator who can fix a black screen from one who can only reboot and hope.

The chain, stage by stage

• Source — the feed arrives, usually via satellite (IRD) or IP contribution, as compressed video.
• Encoder / transcoder — if needed, the stream is normalised or re-encoded (or, in copy mode, passed through untouched).
• Mux / packager — video, audio and metadata are containerised into the delivery format (MPEG-TS for STB, DASH/HLS for OTT).
• CAS / DRM — the stream is encrypted and access rules attached, so only entitled devices can decrypt it.
• Origin — the authoritative source the edge fills from.
• Edge / CDN — caches and serves segments close to the viewer.
• Player / decoder — the STB or app requests the key, decrypts, decodes and renders to the screen.

Two paths diverge at the packager

The same channel splits into two delivery paths: MPEG-TS multicast for on-net set-top boxes (efficient, but only inside a supporting network — see why multicast can’t cross the IXP), and DASH/HLS unicast for OTT apps served from the edge. Different transport, different DRM handling, same source.

Where each stage breaks

Why the chain view matters

A black screen isn’t one problem — it’s a dozen possible problems at different stages. Operators who know the chain diagnose by where the stream stopped (does audio play? does the manifest load? does the key arrive?) instead of guessing. This is also why observability per stage matters.

Lessons

• A live channel passes through a dozen distinct stages; each can fail differently.
• The channel splits into multicast (STB) and unicast (OTT) at the packager.
• Diagnose a black screen by where the stream stopped, not by guessing.
• Knowing the chain is the difference between fixing and rebooting.