Short answer: IPTV replaces a broadcast signal with a file transfer. The video is compressed, chopped into short segments of a few seconds each, and placed on web servers. Your player downloads them one after another and stitches them into continuous playback, choosing a quality level each time based on how fast the last one arrived. There's no channel being transmitted to you — there's a list of files, and a player working through it. Everything distinctive about IPTV follows from that: why it buffers, why quality shifts mid-programme, why it's seconds behind broadcast, and why one popular match can overwhelm a service.
This is the delivery chain. For what happens inside the encoder, see how encoders work.
The chain
| Stage | What happens |
|---|---|
| Source | Camera, satellite feed, or file |
| Encoder | Compresses to several quality levels at once |
| Packager | Chops each into segments, writes a manifest |
| Origin server | Holds the segments |
| CDN | Copies them to servers near viewers |
| Player | Downloads segments in order, picks quality, plays |
Six stages, and a fault at any one looks identical to the viewer: it stalls.
Segments and the manifest
The packager cuts encoded video into chunks — typically 2 to 6 seconds — and writes a manifest: a text file listing what's available and where.
For live TV the manifest keeps updating. Your player re-fetches it every few seconds to learn which segments now exist, then downloads them. A live "channel" is that loop, running continuously.
This explains the delay. A segment can only be published once it's complete, so a 6-second segment means at least 6 seconds behind reality before anything else is counted. It also explains why live streams can't simply be rewound: only the recent segments are still listed.
Adaptive bitrate, the clever part
The encoder doesn't produce one version. It produces a ladder — the same content at several quality levels, say 480p at 1.5 Mbps, 720p at 3, 1080p at 6.
Every segment exists at every rung, cut at identical boundaries. So your player can switch rungs between segments without interrupting playback.
The decision loop: download a segment, measure how long it took, estimate available bandwidth, pick the rung for the next one. Congestion mid-programme means the next segment comes from a lower rung — the picture softens but doesn't stop.
That's why quality drifts during an evening rather than failing outright. It's the system working. Buffering happens when even the lowest rung can't arrive fast enough, or when the player misjudges and reaches for a rung it can't sustain. Diagnosing which is a different job from guessing.
Unicast, and why popular events break things
Here's the structural weakness.
Broadcast is one-to-many: a transmitter sends one signal, and a million receivers pick it up at no extra cost per viewer. Internet delivery is unicast — one-to-one. A million viewers means a million separate streams.
So cost scales with audience, exactly inverted from broadcast. A channel nobody watches is cheap; a cup final is expensive. This is why services fail during big matches specifically: capacity is provisioned for typical load, and a final isn't typical.
CDNs mitigate rather than solve it. Copies of each segment are cached on servers close to viewers, so the origin serves each segment once per edge location rather than once per viewer, and the traffic travels a shorter path. Still one connection per viewer at the edge, but far more of them are servable.
Multicast is the exception. Within a single operator's network — your telco's own IPTV product — one stream can be sent to many subscribers simultaneously, which is why Bell Fibe or Telus Optik handle a national broadcast efficiently in a way an internet service can't. It only works inside a network under one operator's control. ATSC 3.0 and B2X are attempts to bridge that gap.
The EPG is a separate file
The channel guide isn't part of the video. It's a separate document, usually XMLTV, that your player fetches and matches to channels by ID.
Which is why guide problems are independent of stream problems. Channels play with an empty guide when the EPG is missing; the guide shows the wrong programme when IDs don't match or times are offset. Two systems, two failure modes.
DRM, where it applies
Licensed services carrying premium content encrypt segments and hand out decryption keys to authorised players — Widevine, PlayReady, FairPlay, depending on platform.
Practical consequences: a device without the right DRM module can't play protected content whatever the player; a stream may be capped at lower resolution if the device only supports software-level DRM; and DRM is why some content plays on one device and not another with identical network conditions.
Free-to-air and unencrypted streams skip all of this.
Why a player matters
Given that the player is doing segment selection, buffer management and rung-switching, players differ substantially. One may hold a larger buffer and ride out congestion that stalls another. One may switch rungs aggressively, another conservatively. Same stream, same network, different results — which is why testing a second player is a real diagnostic step.
Quick answers
Is IPTV the same as streaming? Yes, technically. IPTV usually implies live channels; streaming usually implies on-demand. Same mechanism.
Why is it behind live TV? Segments must be complete before publishing, and players buffer. Several seconds minimum.
Why does quality change mid-programme? Adaptive bitrate reacting to your available bandwidth. Working as designed.
Why does it fail during big matches? Unicast delivery — every viewer is a separate stream, and capacity is provisioned for normal load.
What's multicast? One stream serving many subscribers, possible only inside a single operator's network. It's what telco IPTV uses.
Why does the guide break when the channels work? The EPG is a separate file matched by channel ID.