Insights · Explainer

IPTV vs OTT: the difference, and why operators stop choosing

3 August 2026 · 9 min read

"IPTV or OTT?" is one of the most-searched questions in television delivery, and for a working operator it is usually the wrong one. They are not competing products — they are two ways to move the same channels to a viewer. The useful questions are which one reaches a given subscriber, what each one costs, and whether you can avoid choosing at all.

The one-sentence difference

IPTV delivers television over a managed network — the operator's own broadband or cable plant — usually by IP multicast to a set-top box, with quality of service the operator controls end to end. OTT delivers the same television "over the top" of the public internet, by unicast HTTP streaming (HLS or DASH) to any device, over a connection the operator does not control.

Same content. Same codecs, often. The difference is the road it travels and who owns that road.

The difference that actually matters

 IPTVOTT
NetworkOperator's managed networkPublic internet
TransportIP multicast (UDP), DVBUnicast HTTP — HLS / DASH
Bandwidth modelOne stream serves all viewers (flat)One stream per viewer (scales with audience)
Quality of serviceOperator-guaranteedBest-effort; adaptive bitrate absorbs the rest
DevicesSet-top box, managed CPESmart TV, mobile, web, STB — anything
ReachOn-net subscribers onlyAnyone with internet, anywhere
LatencyLow (near-broadcast)Higher (segment buffering), tunable
The same channel can be delivered both ways at once — the split is transport, not content.

IPTV: efficient, controlled, bounded

On a managed network, multicast is the decisive advantage. One multicast stream reaches every viewer of that channel — a thousand subscribers watching the same match consume the same bandwidth as one. The operator controls the whole path, so quality is guaranteed and latency is close to broadcast. This is why IPTV is the natural fit for a telco or cable operator serving its own footprint through a set-top box.

The bound is exactly that footprint. IPTV reaches the subscribers on your network and the devices you provision. It does not, on its own, reach a customer's phone on the train or a smart TV in a house you don't wire.

OTT: universal reach, per-viewer cost

OTT inverts both properties. It reaches any device on any connection — Samsung, LG, Android TV, iOS, web — which is how you serve subscribers beyond your network and the second screen inside it. Adaptive bitrate (the player switches renditions as the connection varies) hides the fact that you don't control the last mile.

The cost of that reach is that OTT is unicast: every viewer pulls their own copy. Bandwidth and origin/CDN cost scale with the audience, not with the number of channels. A popular live event that costs a fixed amount to multicast can cost a great deal to stream to ten thousand unicast sessions.

IPTV cost scales with the number of channels. OTT cost scales with the number of viewers. Real operators have both problems — because they have both kinds of subscriber.

Why the "versus" dissolves

Frame it as a technology war and you'll pick one and strand half your audience. Frame it as reaching subscribers and the answer is obvious: most operators need both. On-net homes get IPTV to a set-top box — efficient, high quality, low latency. The same subscribers' phones and tablets, and any customer outside the network, get OTT to an app. It is one line-up, two transports, one bill.

The problem was never choosing IPTV or OTT. The problem is that bolting a separate OTT stack onto an existing IPTV headend — a second set of encoders, a second packaging chain, a second operations burden — is where the cost and the complexity actually live.

Deliver both from one encode

This is where the architecture matters more than the acronym. In Emiton, a channel is encoded once on the GPU, and a TEE muxer feeds every output from that single encode simultaneously: UDP multicast and MPEG-TS/DVB for the IPTV side, HLS and DASH for the OTT side, plus SRT or RTMP for contribution — all from one NVENC session. You are not running two platforms; you are running one, with many outputs.

On the IPTV side, statistical multiplexing packs those channels into a handful of fuller muxes — we measured the quality that buys you, and it is the worst channel in the bouquet that gains most. On the OTT side, the same encodes are packaged for every device your subscribers own. One signal in, both worlds out — on hardware you own, not a per-subscriber hosted bill.

What this means for the decision

  • If you serve your own network, IPTV multicast is the efficient core — don't give it up.
  • If you want reach beyond it, or the second screen inside it, you need OTT — and you'll pay per viewer for it, so control that cost with your own delivery.
  • If you're specifying a platform, the right requirement isn't "IPTV" or "OTT" — it's "one encode, every output," so a channel added once appears on the set-top box and the app without a second pipeline.

Stop choosing between IPTV and OTT. Choose a platform that treats them as two outputs of the same system — and prove the quality with numbers, not adjectives.

See it running

The 28-channel VMAF figures above are embedded live from the production encoder on the statmux page — they update themselves from the running system.