How does IPTV work?

Understanding and refreshing yourself on the technologies that we network engineers use is critical, especially for troubleshooting when the tech is not working as expected. IPTV is no different.

In this post, I’ll explain the fundamentals of an IPTV system, starting from the origination of the content to its delivery on the viewer’s screens.

What happens in the studio?

TV content typically originates from a broadcast studio. Such content could be pre-recorded videos stored on disks. In some cases, such as news channels, it could be a live video feed from the ground via a Real-Time Messaging Protocol (RTMP) over an IP network. In either case, the content is pushed through a playout system (Figure 1).

A playout system is one of the most critical elements of a broadcaster’s studio because it is responsible for all the scheduling of the content as well as on the fly editing such as overlay graphics, tickers, and ad insertion. Such a system could be dedicated hardware, or it could be a piece of software installed on a generic computing machine, similar to routing software installed on generic off-the-shelf hardware.

The playout system may support one or more modes for content output such as User Datagram Protocol (UDP) multicast, RTMP, or Serial Digital Interface (SDI) / High-Definition Multimedia Interface (HDMI). In an ideal setup, the playout system will output the content via an SDI interface and dedicated equipment is placed to transcode the stream into IP. The transcoder will ingest the stream via SDI and output a UDP multicast transport stream.

There are multiple options available when it comes to choosing the codec for transcoding the content. However, three are most commonly used in the linear TV industry: MPEG2, MPEG4, and HEVC. A complete blog post can be written explaining these codecs, but for now, let’s stick to the topic. The key takeaway is MPEG2 is the oldest of these three, HEVC is the latest, and MPEG4 is the most widely used due to its content quality, bandwidth use, and client support.

After transcoding, the content is packaged into a UDP multicast transport stream on output.

From here, there are two different paths followed by free-to-air (FTA) channels and paid channels. As the names imply, FTA channels are free (and unencrypted), so these are sent directly to the modulator. Paid channels are first passed through a scrambler to scramble to content with the help of a Conditional Access System (CAS) so that it is viewable by the authorized users only.

The CAS system is similar to the one deployed in the control rooms of Multi-Service Operators (MSOs). After the paid channels are scrambled these, along with the unencrypted FTAs, are sent through a modulator for uplinking to the satellite. Each channel has its allocation of frequency and bandwidth.

What happens in the MSO control room?

The process in the MSO’s control room starts with downlinking various frequencies from multiple satellites (Figure 2).

Since this is radio frequency (RF), the signal is carried using RG6 cables. The RG6 cable will go through multiple splitters depending on how many frequencies are available on any given satellite with set antenna polarization. The endpoints of these RG6 splitters are terminated on Integrated Receiver and Decoders (IRDs).

The IRD is responsible for demodulating the received signals and unscrambling paid signals with the help of a Conditional Access Module (CAM) provided by the broadcaster. The output is an IP UDP multicast stream.

In some cases, broadcasters may not offer you a CAM. Instead, they will provide a set-top box (STB) with a decryption key built into the hardware. Since STBs have the output of SDI/HDMI, we also need an encoder that will take the HDMI input and encode it back into an IP UDP multicast stream.

At this point, we have unencrypted IP multicast streams of FTAs as well as paid channels. Following that, it is the responsibility of the MSO to scramble/encrypt the content again to ensure only authorized users can watch the content. But there are two possible ways to deliver the content to the users…

Multicast IPTV vs Unicast IPTV

Before we get into the operational difference between these two, let’s try to understand their pros and cons first:

Multicast advantages

• Low computing power: The biggest advantage of multicast IPTV is the very low resource requirement. You could stream a multicast channel from a Raspberry Pi and serve millions of users from it, without any additional hardware. This is because the number of viewers does not affect the hardware requirement at the origin level; it could be one viewer or one million, or even a billion for that matter.
• Low bandwidth consumption: Similar to the hardware consumption, multicast is light on the bandwidth front as well. The bandwidth requirement per channel on the origin node is equivalent to the bandwidth requirement of one stream. For example, if a channel (a multicast stream) is optimized to stream at 2Mbps you will only always need 2Mbps of bandwidth on the origin network interface, no matter how many users are watching the same stream simultaneously. This could feel awkward to someone who deals with unicast all the time. But that is the basic nature of multicast — packets are duplicated on each exit interface in a multicast network.

Multicast disadvantages

• Requires end-to-end multicast: Technically this is not a disadvantage. But in the unicast-dominant world that we live in today, ensuring multicast is supported and enabled on each node in the network is one more thing to worry about. By multicast support, I mean having multicast specific protocols configured such as Internet Group Management Protocol (IGMP) and protocol-independent multicast (PIM) on every device in the path including switches, routers, Optical Line Terminals (OLTs), and Optical Network Terminals (ONTs).
• Not so friendly with Wi-Fi: Most Wi-Fi devices used in our homes are not multicast-aware. And any device that does not have support for multicast will treat multicast traffic as broadcast traffic. This means packets will travel out of every interface on the device, including the ones that have not requested it. And you certainly don’t want that to happen in your network. Essentially, you will need a wired connection to the consuming device. This means mobile phones are excluded unless you want your customers to connect their mobile phones to an Ethernet cable via an on-the-go (OTG) adapter.
• Network-specific STBs: If you plan to stream only FTAs, this doesn’t apply to you. But if you plan to include paid TV channels as well, you’ll need STBs manufactured specifically for your subscribers with the decryption key (provided by the CAS vendor) in the STB hardware.
• No support for Adaptive Bit Rate (ABR): ABR allows for the same content to be made available to clients in multiple resolutions and bitrates. The player in the client is smart enough to switch among those streams depending on the available bandwidth on the client, avoiding buffering delays.
• No support for catch-up TV: Catch-up TV is when you’re able to watch a recording of a previously aired show/episode. Catch-up TV requires a caching mechanism to store the content for later. In multicast, however, there is no support for caching the content.

Unicast advantages

• No special configuration required: Unlike a multicast setup, you don’t need any special configuration or protocol support in your network. Unicast IPTV is delivered over HTTP, so a live TV stream is another bunch of HTTP packets for your network. This is the biggest advantage from a service provider’s point of view.
• Full Wi-Fi support: Because you’re dealing with HTTP packets, streaming over Wi-Fi is no issue.
• Supports ABR: In a typical unicast IPTV system, we’d transcode the content before pushing it through the network. While transcoding the content we have the option to transcode the content into multiple profiles (multiple resolutions and bitrates). Therefore, ABR is fully supported.
• Supports catch-up TV: Again, since the content is delivered via HTTP, we can easily cache it, store it, and deliver it as and when required. So, an IPTV system can be configured to keep a copy of the content for a certain period and that will be streamed when requested by users.
• Supports off-the-shelf hardware: Unicast IPTV can be viewed on an Android STB, Apple TV, smart tv, or even mobile phone. Since a unicast IPTV system is technically similar to an over-the-top (OTT) platform, the content can be viewed on any smart device capable of playing content from any OTT provider.

Unicast disadvantages

• Very resource-heavy: The biggest advantage of a multicast IPTV setup is the biggest disadvantage of a unicast IPTV setup. It requires a lot of computing power to transcode 100s of channels in real-time.
• Bandwidth heavy: Unlike multicast, unicast means every time a client requests content, a fresh/parallel TCP connection is opened between the server and client. And a parallel stream of content is sent to each client, even if multiple clients are consuming the same content. A Content Distribution Network (CDN) can be introduced to deal with high bandwidth demands but still, the benefit is minuscule when compared to multicast. And building a CDN will also bring its own set of challenges.

Now that we know the advantages and disadvantages of both possible mediums of content delivery on the last mile, we also need to understand what it takes to build each one before making a final decision as to which way to go.

Building a multicast delivery system

Compared to a unicast setup, a multicast IPTV setup is relatively simple to deploy.

Since we already have a UDP multicast stream, any sort of transcoding or encoding is not required. A transcoder may be placed for optimization purposes, such as reducing the bitrate or achieving a Constant Bit Rate (CBR). Reducing bandwidth may feel unnecessary in a local network, but it makes sense when the content is to be carried to distant locations over long-distance circuits. As a service provider you’re supposed to carry 100s of channels, so saving bandwidth on each channel adds up.

The unencrypted multicast stream is sent through the scrambler (Figure 3), which scrambles the stream with the help of a CAS. The CAS is connected to a subscriber management system (SMS). The SMS is nothing but a web-based user interface that is used to create subscriber accounts and assign service packages to them.

The scrambled content is pushed into the multicast-capable network. It is generally advised to carry the IPTV stream in a dedicated VLAN for easy segregation purposes on the client-side, so that the VLAN is untagged on any one interface of the ONT connecting the STB, without affecting other unicast-based services.

Building a unicast delivery system

In comparison with multicast, a unicast IPTV system is more complex to set up and requires way more resources.

If we plan to offer ABR support, the very first step is to transcode the stream into the desired number of profiles. Since a TV channel is a live feed, transcoding happens in real-time. And transcoding is one of the most resource-hungry processes.

Once transcoded, the video feed goes through the packager. The packager will then divide the live video into 3 – 10 second chunks, and package those chunks into appropriate container types such as HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH). It will also encrypt the content with the encryption keys received from the DRM and send it to the client.

The DRM is directly attached to a middleware. Middleware is where you create user accounts and assign service packages to them, similar to SMS from a multicast setup.

And if catch-up TV is also enabled, a copy of the transcoded content (before packaging and encryption) is also stored locally for access later in time. Technically, the content can be delivered directly to the clients from the packager itself. But in an ideal situation, you should adopt the idea of ‘separation of concerns’ and put another node between the packager and the clients, which will also act as a cache responsible for delivering the content to clients. The client application will then communicate with the middleware to get decryption keys and finally, the content is played on the client’s device.

If you would like to dive deeper into how content protection works in multicast IPTV and unicast IPTV, please leave a comment below and I will be happy to do a follow up post comparing multicast scrambling and unicast DRM encryption.

Multicast? Unicast? Or both?

Hopefully, you now have a greater understanding of the differences between multicast and unicast IPTV systems.

If you are not concerned about the heavy resource requirements, including computing as well as bandwidth, unicast is the obvious choice because it offers more features.

But if you want an efficient setup and are not concerned about fancy features, then multicast makes more sense given your network gears are multicast aware.

Or, a combined approach can also be adapted delivering linear TV over multicast and using unicast for other features such as catch-up TV.

Let me know if you have any further questions in the comment section below.

Rahul Makhija is a network engineer and web app developer who is either pushing bits or flipping bits, so is in-between bits all the time.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.