IPTV works by turning a TV channel into compressed digital video, cutting it into short segments and sending them over the internet to a player app. The player downloads the segments in order, decodes them and shows the picture, while a separate TV guide file supplies the listings. Your login decides which channels and features the server sends you.
Key takeaways
- A channel is compressed with a codec such as H.264 or HEVC, then cut into short segments listed in a playlist.
- Your player downloads those segments over ordinary HTTP, which is why live IPTV runs some seconds behind broadcast.
- Telco TV uses multicast on a managed network; internet IPTV sends each viewer their own unicast stream.
- The TV guide is a separate XMLTV file, matched to channels by an ID.
- Most problems can be placed at one stage: your network, the player, the guide or the stream itself.
The journey at a glance
A live channel passes through the same stages on its way to every screen. The table follows one channel from start to finish, with the standard involved at each step and what you notice when that step has a problem.
| Stage | What happens | Typical standard or format | What you notice if it fails |
|---|---|---|---|
| 1. Source | The channel’s signal arrives at the head end | Broadcast feeds, often MPEG-TS | Channel off air, frozen picture on every device |
| 2. Encoding | The picture and sound are compressed | H.264/AVC, H.265/HEVC, AAC or Dolby audio | Blocky picture, wrong audio, drifting sound on one channel |
| 3. Packaging | The stream is cut into segments and listed in a playlist | HLS (RFC 8216), MPEG-DASH, MPEG-TS | Stream won’t start, or stops every few seconds |
| 4. Delivery | Segments travel from origin servers through edge servers | HTTP over TCP, content delivery networks | Buffering for many viewers at once |
| 5. Access | The server checks your login and builds your channel list | Xtream Codes API, M3U playlist, portal login | Login errors, “max connections”, missing categories |
| 6. Guide | Listings are downloaded and matched to channels | XMLTV | Empty guide, wrong times |
| 7. Home network | The data crosses your router and Wi-Fi | DNS, Wi-Fi, Ethernet | Buffering on every channel, on one device or all |
| 8. Player | Segments are buffered, decoded and sent to the TV | Hardware or software decoder, HDMI | Stutter, black screen, sound out of sync |
The rest of this guide walks through each stage in order. The last section shows how to use the table when something goes wrong.
Step 1: the signal arrives at the head end
Every TV system, whether cable, satellite or IPTV, starts at a head end: the place where channels are received, checked and prepared for delivery. Wikipedia’s article on IPTV describes the head end as the part of the system that encodes and distributes live channels.
Channels reach a head end in several ways: from satellites, over dedicated fibre links, or as streams over IP networks. Each arrives as a continuous flow of already-compressed video and audio, often in the MPEG transport stream format described later.
At this stage the signal is checked and, where needed, converted. A channel might arrive in one format and leave in another, or arrive at one quality and be prepared in several. If a channel’s source drops, every viewer sees the same thing at the same time: a frozen frame, a black screen or a “no signal” card.
That last point is useful at home. If a channel is frozen on your TV, check it on a second device. If it is frozen there too, the problem is upstream of you, and nothing on your router or player will fix it.
Step 2: encoding squeezes the picture
Raw video is enormous. A Full HD picture is 1920 × 1080 pixels; at 60 frames per second and a typical 12 bits per pixel, that comes to roughly 1.5 gigabits every second. No home connection could carry several of those, so the video is compressed by a codec before it travels.
The most common codec in live TV is H.264, also called AVC, first approved in 2003. Its successor, H.265 or HEVC, was published in 2013, and Wikipedia’s article on High Efficiency Video Coding puts its gain at 25% to 50% better compression at the same quality. That is why 4K channels often use HEVC. Older broadcast systems used MPEG-2, which needs far more data for the same picture.
Codecs save space by sending a complete picture, called a keyframe, only every so often. In between, they send just the changes from one frame to the next. That is why a channel change can take a moment: the player has to wait for the next keyframe before it can draw a whole picture.
Fast motion is hard for codecs, because more of the picture changes from frame to frame. A crowd, confetti or a snowstorm on the field can turn a clean picture blocky for a second. That is the codec running short of data, not your connection failing.
One channel, several versions
A channel is usually encoded more than once, at different resolutions and bit rates. A 4K version might need 25 Mbps, a Full HD version about 10, and an SD version a few megabits. Our guide to internet speed for IPTV lists the figures for each quality.
Streaming systems can use these versions in two ways. With adaptive bitrate streaming, the player switches between them on its own, stepping down when your connection slows and back up when it recovers. Many IPTV channel lists instead show each version as its own entry, marked 4K, FHD, HD or SD, and leave the choice to you.
The second approach is common for live TV because it is predictable. A sports fan who picks the FHD version knows the picture won’t suddenly drop to SD mid-game; if the connection can’t keep up, the stream buffers instead, and the fix is to choose a lower version.
Sound is encoded separately, often as AAC or Dolby Digital, and a channel can carry several audio tracks: different languages, described video, or stereo and surround. The player picks one, and you can change it in the audio menu during playback.
Step 3: packaging the stream
A codec produces compressed video; a container wraps that video with the sound, timing information and anything else that has to travel with it. Think of the codec as the language and the container as the envelope.
The classic container for TV is the MPEG transport stream, or MPEG-TS. It cuts everything into small packets of 188 bytes, each tagged with an identifier that says which stream it belongs to: the video, one of the audio tracks, or subtitles. Tables inside the stream, called the PAT and PMT, list which identifiers make up each programme.
MPEG-TS also carries a program clock reference, a timestamp sent at least every 100 milliseconds so the decoder can keep sound and picture in step. It was designed for broadcast systems where packets can be lost, which is why it is still used in satellite, cable and IPTV today.
Newer systems also use fragmented MP4, a version of the familiar MP4 file cut into pieces suitable for streaming. Both formats carry the same H.264 or HEVC video; only the envelope differs.
HLS: playlists and segments
The most widely used way to deliver live video over the internet is HTTP Live Streaming, or HLS. It is described in RFC 8216, published in August 2017. HLS cuts the stream into segments a few seconds long and lists them in a plain-text playlist file ending in .m3u8.
A simplified live playlist looks like this:
#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:2681
#EXTINF:6.0,
segment2681.ts
#EXTINF:6.0,
segment2682.ts
#EXTINF:6.0,
segment2683.tsThe first line marks the file as an extended M3U playlist. The target duration says no segment is longer than six seconds, the media sequence numbers the first segment listed, and each EXTINF line gives the length of the segment that follows. As new segments are made, they are added at the bottom and old ones drop off the top.
A second kind of file, the master playlist, lists several versions of the same stream at different bit rates, which is how a player switches quality on its own. RFC 8216 allows segments in MPEG-TS or fragmented MP4, and allows each segment to be encrypted with AES-128, so a segment copied from the network can’t be played without the key.
How a live playlist moves, and why you’re behind
For a live channel, the playlist keeps changing. RFC 8216 tells the player to reload it whenever more than one target duration has passed since the last load. With six-second segments, the player checks for new segments roughly every six seconds and downloads each one as it appears.
The same standard tells players not to start closer than three target durations from the end of a live playlist. That keeps a cushion of segments in hand, so a small network hiccup doesn’t stop the picture. With six-second segments, the cushion alone is 18 seconds.
Add the time to encode and package each segment, and the player’s own buffer, and a live internet stream naturally runs some seconds behind the same channel on cable or satellite. Shorter segments and smaller buffers reduce the delay, at the cost of less protection against hiccups. Our guide to IPTV buffer size settings explains that trade-off from the player’s side.
When a stream ends, as with a recording or a movie, the playlist gains a final tag, EXT-X-ENDLIST, and stops changing. The player then knows it has the complete list and can let you skip anywhere in it.
MPEG-DASH and continuous streams
HLS isn’t the only option. MPEG-DASH, standardised as ISO/IEC 23009-1 and published in 2012, works on the same idea of segments over HTTP. Its playlist is an XML file called a Media Presentation Description, or MPD, and it is codec-agnostic, so it can carry H.264, HEVC and others.
DASH is common in on-demand apps and some live services. For IPTV player apps, HLS and MPEG-TS are the formats you’ll meet most often, and most players handle both without you noticing.
Some IPTV services can also send a channel as one continuous MPEG-TS stream over a single long HTTP connection, instead of separate segments. It starts quickly and has little overhead, but the player has less to work with if the connection stutters.
Some players and services let you choose between the continuous stream and HLS. If one format buffers on your device, trying the other is a reasonable test, because they recover from network problems in different ways.
Unicast and multicast: telco TV versus internet delivery
There are two quite different ways to send live TV over IP. Telephone and cable companies that sell TV with their own internet often use multicast on their managed network. The multicast method sends one copy of each channel into the network, and the network copies it only toward homes that asked for it.
Your set-top box asks for a channel with a protocol called IGMP, joining the channel’s multicast group, and leaves the group when you change channels. It is efficient, because a thousand viewers on one channel don’t need a thousand copies. But multicast generally isn’t routed across the public internet, so it only works inside one provider’s own network.
Internet-delivered IPTV uses unicast instead: every viewer gets their own copy of the stream over ordinary HTTP. That uses more server capacity, but it works on any internet connection, with any provider, on any device that can run a player.
| Feature | Telco IPTV | Internet-delivered IPTV |
|---|---|---|
| Network | The provider’s own managed network | The public internet, any provider |
| Live delivery | Multicast, one copy shared by many homes | Unicast, one copy per viewer |
| Changing channel | IGMP join and leave | The player requests a new playlist or stream |
| Equipment | Usually the provider’s set-top box | A player app on a stick, TV, phone or computer |
| Where it works | Only on that provider’s internet service | Anywhere with a good internet connection |
CDNs and edge servers
Sending a separate stream to every viewer from one place would overload that place. Content delivery networks, or CDNs, solve this with servers spread across many locations, called edge servers, that keep copies of popular content close to viewers.
HLS segments suit this well. Each segment is an ordinary file fetched over HTTP, so an edge server can fetch it once from the origin and hand it to every nearby viewer who asks for it next. For a live channel, the edge refreshes the playlist and fetches each new segment as it appears.
For you, a nearby edge server means a shorter path, fewer chances for something to go wrong along the way, and faster channel starts. It doesn’t remove problems inside your home: a weak Wi-Fi signal in the basement is just as weak whatever server the video comes from.
The first viewer on a quiet channel sometimes waits a moment longer, because the edge has to fetch the segment from further back. Popular channels during a big game, ironically, can start faster than obscure ones for the same reason.
Step 5: the login and API layer
Before any video flows, the player has to sign in. The server checks the username and password, the plan’s end date and how many screens are already playing, then sends back the list of channels, categories and on-demand titles your account can open.
IPTV players use one of three main sign-in methods. An Xtream Codes login uses a server address, username and password, and lets the player ask the server for channels, the guide and catch-up separately.
An M3U playlist packs the whole channel list into one long link. MAG and Formuler boxes use a portal address and the box’s own hardware address. Our guide to Xtream Codes and M3U logins compares them in detail.
This layer is also where the screen count is enforced. When you start a channel, the server counts it as a connection; when every connection on your plan is in use, the next request is refused with a “max connections” message.
Errors from this layer usually arrive as HTTP status codes or short messages, such as 401 for a rejected login or 404 for a stream that isn’t there. Our reference of IPTV error codes explains what each one means and which side it comes from.
The TV guide: XMLTV
The programme guide travels separately from the video. Most IPTV systems use XMLTV, an XML file format for TV listings introduced in 2002. The file lists channels, each with an ID and a display name, and programmes, each with a start time, an end time, the channel ID and at least a title.
A single programme entry looks roughly like this:
<programme start="20261007190000 -0400" stop="20261007200000 -0400" channel="news.example">
<title>Evening News</title>
<desc>The day’s headlines.</desc>
</programme>Times include an offset from UTC, here four hours behind, so the player can convert them to your own time zone. That is why a wrong time zone on your device shifts the whole guide, and why the guide can be an hour off around daylight saving changes.
The player matches each programme to a channel by its ID. If the IDs don’t match, the channel plays but its guide row stays empty. Our guide to fixing an IPTV EPG that isn’t loading covers that and the other common guide problems.
Catch-up and on-demand
Catch-up works by keeping recent segments on the server instead of throwing them away. For channels that offer it, the server stores the stream for a period of time, and the player asks for a slice of it by channel and time, usually by selecting a past programme in the guide.
To the player, a catch-up programme looks like a finished recording: a complete playlist with an end, which you can pause, rewind and skip through. The video is the same as it was live, at the same quality. Our guide to catch-up TV and timeshift explains how to open it in common players and why availability varies by channel.
Movies and series in the on-demand library are simpler still: each one is a file, or a set of segments, encoded once and stored. They use the same delivery path as live channels, which is why they count as a connection while they play.
Comparing this with on-demand apps is a topic of its own. Our article on IPTV vs streaming apps looks at what each model is good at.
Step 8: the player and the decoder
The player app does the final work. It downloads the playlist, fetches segments, keeps a few seconds in a buffer, then separates the video and audio and passes each to a decoder.
The decoder rebuilds the pictures from the compressed data. Most streaming devices have a hardware decoder built into their chip, which is fast and efficient. Players can also decode in software on the main processor, which is more flexible but works harder. Our guide to hardware vs software decoding explains when to switch between them.
The player keeps sound and picture together using the timestamps carried in the stream. When those drift, you see lips moving before or after the words. It then sends the finished picture over HDMI to the TV, at a resolution, frame rate and dynamic range the TV has said it supports.
4K and HDR add requirements at this last step: the device, the HDMI cable and the TV input all have to support them. Our guide to 4K and HDR requirements covers each link in that chain.
Your home network: the last stretch
Between the edge server and the player sits your home network. First, the device looks up the server’s name to find its address, using DNS. Then the segments travel through your modem and router, across Ethernet or Wi-Fi, to the device.
DNS affects how quickly a stream starts, not how fast it plays; our guide to DNS for streaming explains what changing it can and can’t do. Wi-Fi is the most common weak point, because walls, distance and neighbours’ networks all reduce the steady speed that reaches the TV.
Live streams are less forgiving than downloads. A download can pause for a second and catch up; a live player that runs out of buffered segments has to stop and wait. That is why a steady 15 Mbps on a wired stick often plays better than a jumpy 100 Mbps on distant Wi-Fi.
If every channel buffers on one device while others play well, the problem is almost always here. Our list of buffering fixes works through it in order.
Using the chain when something goes wrong
Knowing the stages makes troubleshooting faster, because each symptom points to one part of the chain. A few quick tests place most problems:
- One channel fails on every device: the source, encoding or packaging stage. Report the channel name.
- Every channel fails on one device: the player or your home network near that device.
- Every channel fails on every device at home, but works on mobile data: your router or internet connection.
- Login or “max connections” errors: the access layer, usually a typing mistake, an ended plan or screens in use.
- Channels play but the guide is empty: the XMLTV stage, which runs separately from the video.
When you contact Online Support, tell us which of these patterns you see, the channel and device involved, and when it started. That places the problem in the chain before we start, and usually saves several messages. Our setup guide covers the device side, and the same chain sits behind every channel on our IPTV Canada service.
Questions people ask
Why is IPTV a few seconds behind cable?
Internet streams are cut into segments a few seconds long, and players are told to stay at least three segments behind the newest one so small hiccups don’t stop the picture. Encoding and the player’s own buffer add more. Cable and satellite don’t need that cushion, so they run ahead.
Does internet IPTV use multicast?
Generally no. Multicast isn’t routed across the public internet, so it is used by telephone and cable companies on their own managed networks. Internet-delivered IPTV sends each viewer their own unicast stream over HTTP, which works with any internet provider and any player device.
What is an M3U8 file?
It is a plain-text playlist in the extended M3U format, saved as UTF-8. HLS uses it to list the segments of a stream, or the different quality versions of it. For live channels the player reloads it every few seconds to find new segments as they are added.
What format is the IPTV TV guide in?
Most IPTV systems use XMLTV, an XML format for TV listings. It lists channels with an ID and a display name, and programmes with start and end times, a channel ID and a title. The player matches programmes to channels by that ID.
What is the difference between HLS and MPEG-TS?
MPEG-TS is a container that packs video, audio and timing into small packets. HLS is a delivery method that cuts a stream into segments and lists them in a playlist. HLS segments are often MPEG-TS files, and some services also send MPEG-TS as one continuous stream.