How IPTV works, from the broadcast to your screen

The five stages at a glance

1. Capture and encoding

A live channel starts as a broadcast feed. An encoder compresses it, because uncompressed HD video would need far more bandwidth than a home connection has. The video codec (usually H.264 for SD and HD, HEVC for 4K) and the audio codec (usually AAC, sometimes Dolby Digital) are chosen here.

The encoder also sets the bitrate: how much data each second of the channel uses. A higher bitrate keeps more detail, especially in fast motion, but needs a faster, steadier connection. That’s why two HD channels can look different. See video and audio codecs.

2. Packaging

The compressed stream is packaged for delivery in one of two main ways:

• MPEG transport stream (TS): one continuous stream per channel, which the player shows as it arrives.
• HLS: the stream cut into short segments listed in a small .m3u8 playlist that the player keeps re-reading. See HLS explained.

Packaging is also where multiple qualities can be prepared, so a player can switch down on a slow connection. The choice between TS and HLS is one you can often make in your app; see HLS vs MPEG-TS.

3. Delivery

Servers send each stream to every viewer who asks for it. On the open internet this is unicast: a separate copy of the stream for each viewer. Popular services spread the load across many servers and often across a content delivery network, so viewers connect to a server close to them.

Managed TV networks run by broadband providers can use multicast instead: one copy of each channel travels across the provider’s network, and each home joins the channels it’s watching. That’s efficient, but it only works on networks the provider controls. See multicast vs unicast.

This stage explains evening buffering: when many people watch at once, both the servers and the networks between you and them are busiest.

4. Access and middleware

Before a player can show anything, it needs to know which channels you can watch and where they are. That’s the job of middleware, the software that handles logins, channel lists, film and series libraries, the TV guide and catch-up. It’s what your app talks to when you enter:

• an Xtream Codes login (server, username and password), which the app uses to request each part separately,
• an M3U playlist link, which delivers the whole channel list as one file, or
• a portal address with a registered MAC address, as used by MAG boxes.

Xtream Codes explained compares the three. The TV guide usually comes from a separate XMLTV file, which is why guide problems and channel problems have different fixes. See the IPTV TV guide explained.

5. Playback

Your player app, on a Fire TV, Smart TV, box, phone or computer:

1. requests the stream,
2. keeps a few seconds in a buffer to smooth out small delays,
3. decodes the video and audio, ideally with the device’s hardware decoder,
4. sends the picture and sound to your TV at the right resolution and frame rate.

Each step can go wrong in a recognisable way: an empty buffer means buffering, a decoder that can’t cope means freezing or a black screen, and a frame-rate mismatch means choppy motion.

Why IPTV is behind live TV

Every stage adds a little delay: encoding, packaging into segments, travelling across the network, and the player’s buffer. With HLS segments of several seconds each, and a player holding a few segments before it starts, internet streams are often tens of seconds behind the broadcast. Shorter segments and low-latency formats reduce this at the cost of more sensitivity to connection hiccups. See why IPTV runs behind live TV.

Where to go from here

• New to IPTV altogether? Start with what is IPTV.
• Want the network side? See the IPTV network guide.
• Setting up? Follow how to set up IPTV on any device.