How Does IPTV Work? | OTTFast

Knowing and renewing your knowledge of the technologies that we network engineers utilise is vital, especially when troubleshooting when the technology is not performing as planned. IPTV is no exception.

In this essay, I’ll go through the principles of an IPTV system, from content creation to content distribution to viewers’ displays.

What happens in the studio?

TV material is often created in a broadcast studio. Pre-recorded videos kept on discs might be used as such content. In certain circumstances, such as news stations, it might be a live video feed from the ground transmitted over an IP network using the Real-Time Messaging Protocol (RTMP). The content is sent through a playout mechanism in either instance (Figure 1).

A playout system is one of the most important components of a broadcaster’s studio since it is in charge of all content scheduling as well as on-the-fly editing such as overlay graphics, tickers, and ad insertion. A system like this might be specialised hardware or software installed on a generic computer machine, comparable to routing software installed on general off-the-shelf hardware.

The playout system may handle one or more content output modalities, such as UDP multicast, RTMP, or Serial Digital Interface (SDI) / High-Definition Multimedia Interface (HDMI). In an ideal design, the playout system will output the material over an SDI interface, and specialist equipment will be installed to transcode the stream into IP. The transcoder will take in the SDI stream and produce a UDP multicast transport stream.

When it comes to selecting the codec for transcoding the content, there are several alternatives accessible. Nonetheless, three are widely employed in the linear television industry: MPEG2, MPEG4, and HEVC. A full blog entry describing these codecs could be created, but for now, let’s stick to the topic.The main takeaway is that MPEG2 is the oldest of the three, HEVC is the most recent, and MPEG4 is the most extensively utilised because to its content quality, bandwidth consumption, and client support.

On output, the material is packed into a UDP multicast transport stream after transcoding.

There are two avenues that may be taken from here: free-to-air (FTA) channels and paid channels. Because FTA channels are unencrypted and free, they are transmitted straight to the modulator. Paid channels are initially routed via a scrambler, which scrambles the material with the help of a Conditional Access System (CAS) so that only authorised users can see it.

The CAS system is comparable to that used in Multi-Service Operator control rooms (MSOs). When the paid channels have been scrambled, they are routed through a modulator for uplinking to the satellite, along with the unencrypted FTAs. Each channel has its own frequency and bandwidth allotment.

What happens in the MSO control room?

The procedure begins in the MSO’s control room with the downlinking of numerous satellite frequencies (Figure 2).

Because this is radio frequency (RF), the signal is sent over RG6 wires. Depending on how many frequencies are accessible on any one satellite with fixed antenna polarisation, the RG6 cable will pass through many splitters. The RG6 splitter terminals are terminated on Integrated Receiver and Decoders (IRDs).

The IRD is in charge of demodulating received signals and unscrambling paid signals using a Conditional Access Module (CAM) supplied by the broadcaster. The output is a multicast IP UDP stream.

In rare situations, broadcasters may refuse to provide you with a CAM. Instead, they will supply a set-top box (STB) with an embedded decryption key. Because STBs offer SDI/HDMI outputs, we also require an encoder to convert the HDMI input into an IP UDP multicast stream.

We now have unencrypted IP multicast streaming of FTAs and pay channels. Following that, it is the MSO’s obligation to scramble/encrypt the material again to guarantee that only authorised users may view it. Yet, there are two options for delivering material to consumers…

Multicast IPTV vs Unicast IPTV

Before we go into the operational differences between these two, let’s first try to comprehend their advantages and disadvantages:

Multicast advantages

Low computational power: The most significant advantage of multicast IPTV is its low resource consumption. Without any additional gear, a Raspberry Pi could stream a multicast channel and serve millions of users. This is due to the fact that the number of viewers has no bearing on the hardware requirements at the origin level; it may be one viewer, one million, or even a billion.
Low bandwidth consumption: Similar to hardware usage, multicast consumes less bandwidth. On the origin node, the bandwidth need per channel is identical to the bandwidth requirement of one stream. For example, if a channel (a multicast stream) is optimised to stream at 2Mbps, you will always require 2Mbps of bandwidth on the origin network interface, regardless of how many users are watching the same video at the same time. Someone who works with unicast all the time may find this awkward. But, it is the fundamental essence of multicast – packets in a multicast network are replicated on each exit interface.

Multicast disadvantages

End-to-end multicast is required: Theoretically, this is not a drawback. Nevertheless, in today’s unicast-dominant environment, making sure multicast is supported and enabled on every node in the network is just one more thing to worry about. By multicast support, I mean having multicast-specific protocols like Internet Group Management Protocol (IGMP) and protocol-independent multicast (PIM) set on every device in the path, such as switches, routers, Optical Line Terminals (OLTs), and Optical Network Terminals (ONTs) (ONTs).
Wi-Fi isn’t so friendly: Most Wi-Fi devices in our houses aren’t multicast-aware. Any device that lacks multicast capabilities will regard multicast traffic as broadcast traffic.This indicates that packets will be sent from every interface on the device, including those that have not requested them. It is something you do not want to happen on your network. Fundamentally, a wired connection to the consuming device is required. Mobile phones are thus prohibited unless you want your consumers to connect their phones to an Ethernet wire using an on-the-go (OTG) adaptor.
STBs that are network-specific: This does not apply if you intend to stream exclusively FTAs. But, if you intend to incorporate premium TV channels, you’ll require STBs made expressly for your customers, with the decryption key (supplied by the CAS provider) included in the STB hardware.
There is no support for Adaptive Bit Rate (ABR): ABR allows clients to access the same material in multiple resolutions and bitrates. The client’s player is clever enough to switch between those streams based on available bandwidth, eliminating buffering delays.
There is no support for catch-up television: Catch-up TV is when you may view a previously aired show/episode that has been recorded. Catch-up TV necessitates the use of a caching technique to save programming for later viewing. Nevertheless, there is no capability for caching material in multicast.

Unicast advantages

No special configuration required: In contrast to multicast, you do not require any particular network settings or protocol support. Unicast IPTV is supplied over HTTP, therefore a live TV broadcast is an additional set of HTTP packets for your network. From the perspective of a service provider, this is the most significant benefit.
Full Wi-Fi support: Because you’re working with HTTP packets, streaming over Wi-Fi is no problem.
Supports ABR: In a conventional unicast IPTV system, we would transcode the material before distributing it over the network. We have the option of transcoding the content into several profiles while transcoding it (multiple resolutions and bitrates). As a result, ABR is completely supported.
Supports catch-up TV: Again, because the material is given through HTTP, we can simply cache, store, and deliver it as needed. As a result, an IPTV system may be designed to maintain a duplicate of the material for a set length of time and broadcast it when consumers want it.
Supports off-the-shelf hardware: Unicast IPTV may be accessed via an Android STB, Apple TV, smart television, or even a mobile phone. Because a unicast IPTV system is essentially equivalent to an over-the-top (OTT) platform, the content may be seen on any smart device that can play content from any OTT provider.

Unicast disadvantages

Very resource-heavy: The main benefit of a multicast IPTV configuration is also the main downside of a unicast IPTV setup. Transcoding 100s of channels in real-time necessitates a significant amount of computational power.
Bandwidth heavy: As contrast to multicast, unicast means that each time a client requests material, a new/parallel TCP connection is established between the server and client. And, even if numerous clients are viewing the same material, a concurrent stream of content is supplied to each client. A Content Distribution Network (CDN) can be implemented to meet high bandwidth needs, although the gain is negligible when compared to multicast. Building a CDN will present its own set of issues.

Now that we understand the benefits and drawbacks of both alternative last-mile information distribution media, we must also understand what it takes to develop each one before deciding which route to go.

Building a multicast delivery system

A multicast IPTV configuration is less complicated to deploy than a unicast one.

We don’t need to do any transcoding or encoding because we already have a UDP multicast stream. A transcoder may be installed for optimization purposes, such as lowering the bitrate or attaining Constant Bit Rate (CBR). Reduced bandwidth may seem needless on a local network, but it makes sense when material is being sent to distant places over long-distance lines. When you’re meant to transport 100s of channels as a service provider, saving bandwidth on each channel adds up.

The unencrypted multicast stream is routed to the scrambler (Figure 3), which scrambles it using a CAS.

The scrambled content is broadcast across a multicast-capable network. It is often recommended to transport the IPTV stream in a dedicated VLAN for easier client-side segregation, such that the VLAN is untagged on any one interface of the ONT connecting the STB without interfering with other unicast-based services.

Building a unicast delivery system

A unicast IPTV system is more difficult to set up and requires significantly more resources than a multicast IPTV system.

If we intend to provide ABR support, the first step is to convert the stream into the required number of profiles. Transcoding occurs in real-time since a TV channel is a live feed. And one of the most resource-intensive procedures is transcoding.

The video stream is packaged once it has been transcoded. The packager will then break the live video into 3 – 10 second chunks, which will be packaged into appropriate container types such as HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH). It will also encrypt the material with the DRM encryption keys and deliver it to the client.

The DRM is linked to a middleware directly. Middleware is where user accounts are created and service packages are assigned to them, comparable to SMS in a multicast arrangement.

In addition, if catch-up TV is enabled, a copy of the transcoded programme (before packaging and encryption) is saved locally for later access. Theoretically, the packager may provide the material straight to the customers. But, in an ideal circumstance, you should use the’separation of concerns’ concept and place another node between the packager and the clients, which will also operate as a cache responsible for providing the material to clients. The client application then communicates with the middleware to get decryption keys before playing the material on the client’s device.

If you want to learn more about how content protection works in multicast and unicast IPTV, please leave a comment below and I would be delighted to write a follow-up post comparing multicast scrambling and unicast DRM encryption.

Multicast? Unicast? Or both?

You should now have a better knowledge of the distinctions between multicast and unicast IPTV systems.

If you don’t mind the high resource needs, such as compute and bandwidth, unicast is the logical choice because it has more functionality.

But, if you want an efficient configuration and aren’t bothered with fancy features, multicast makes more sense, as long as your network gear is multicast aware.

A mixed strategy, delivering linear TV over multicast and employing unicast for other services such as catch-up TV, can also be used.

Please leave any further questions in the comments area below.