The chain, in five steps
The same five steps apply whether the broadcast comes from a telecom operator or from a service on the open internet. What differs is who owns which step.
- Reception. The original broadcast is received — from satellite, over fibre, or direct from the rightsholder.
- Encoding. The picture is compressed to a manageable size, in practice always with H.264 or H.265. This is where bitrate is decided, and so both how good it looks and how much data it uses.
- Segmentation. The stream is cut into pieces, typically 2 to 6 seconds each. Every piece becomes its own file, and a playlist keeps track of the order.
- Distribution. The segments are placed on servers, often in several countries, so that each viewer fetches from the nearest one.
- Playback. Your app reads the playlist, fetches the next segments, decodes and displays. Then it starts again.
Step five repeats roughly every three seconds, all evening. It is not a broadcast in progress — it is thousands of small downloads in quick succession.
Why the stream is cut into pieces
It would be simpler to send one long stream. Segmentation exists because it solves three problems at once.
| Problem | What segments solve |
|---|---|
| The network hiccups for a second | Only one segment is lost, and the app already holds the next few. The viewer notices nothing |
| The connection fluctuates | The same channel exists at several qualities, and the app switches between them segment by segment — which is why the picture can go soft for ten seconds and then sharpen again |
| Networks and firewalls block unusual protocols | Segments are fetched over ordinary HTTP on port 443. To the network it looks like web traffic, because it is |
The format is HLS, HTTP Live Streaming, specified in RFC 8216. Originally developed by Apple for the iPhone, it now underpins most video delivery on the internet.
The quality switching in the middle row has a name: adaptive bitrate. It is one reason IPTV rarely stops outright and instead degrades gradually. The service trades sharpness to avoid pausing.
The delay, and why it cannot be removed
The player must hold a couple of segments before it starts. Otherwise every small interruption would be a black frame. That buffer costs time.
Shorter segments mean lower latency but more requests and more fragile playback.
This margin is what keeps a dropped segment invisible.
It is why you hear the neighbours celebrate first. Not a fault, and no setting fixes it.
Some services run low-latency HLS and get down to a few seconds. It costs stability, and for most viewers a steady picture twenty seconds behind is the better trade.
M3U, EPG and Xtream Codes
Three formats appear the moment you configure anything, and all three are simpler than they sound.
| What | What it is | What it is not |
|---|---|---|
| M3U / M3U8 | A text file listing channels and the address of each stream | Contains no video. Not a service. Not encrypted |
| XMLTV | The programme guide as an XML file: what is on, when, on which channel | Unrelated to the channel list — they often come from different sources |
| Xtream Codes | An API. You give a server address, username and password, and the app fetches everything | Not a file format, and not a company you buy from. Just an interface |
The practical difference: an M3U file is a snapshot that goes stale. Xtream Codes refreshes when the line-up changes, without you doing anything. That is why nearly every subscription service uses the latter, and why most apps ask for three fields.
Look at a typical M3U address and you will find the username and password in plain text inside it. Anyone who has that URL has your subscription. Do not paste it into a forum, a chat, or a support ticket.
Where the chain actually breaks
| Where | How often | What it looks like |
|---|---|---|
| Wi-Fi between router and TV | Most common by a distance | Worse in the evening, better near the router |
| The playback device | Second most common | Only motion breaks up. Dialogue scenes are flawless |
| Load at the source | Happens | Every channel at once, always the same hours |
| Your ISP | Uncommon | Other internet use is slow too |
| A fault in the TV | Almost never | It is not the TV |
The one worth memorising is the second: a network problem degrades everything; a decoding problem degrades only motion. If dialogue looks perfect while a camera pan turns to mush, the fault is in the device, not the connection.
Frequently asked questions
How does IPTV work technically?
Why is there a delay compared with broadcast TV?
What is an M3U file?
What is the Xtream Codes API?
Where in the chain do problems usually occur?
Sources
- RFC 8216 — HTTP Live Streaming — IETF
- XMLTV — the EPG file format