IPTV is a service that provides to subscribers access to a wide selection of TV channels via an IP connection network.
IPTV is a competitor to television broadcasting (DVB-T in digital format), cable TV (DVB-C) and satellite TV (DVB-S). Satellite TV, telecast and cable are relatively simple to set up and affordable, but offer less flexibility in terms of channel selection. IPTV allows to increase the quantity of channels — for instance, by including those not available in the user's geographical location through other broadcasting means.
The classical example of IPTV service is that offered by an Internet service provider. IPTV's great advantage in comparison to DVB-T an DVB-S (that is, to signal antenna and satellite TV) is a wider selection of channels. If someone has a sat provider XYZ's dish installed on the roof, this person gets to watch only the XYZ programming. There aren't too many enthusiasts who would have 3 or 4 dishes from different sat providers, so a telephone company can offer a wider selection of channels to beat satellite.
However, quite often DVB-C (cable TV) is offered by the same telecommunications operator that provides Internet access. In this case, the channel selection is the same, but IPTV also allows for services like video on demand (movies) and aired shows archive.
IPTV OTT (over the top) is an IPTV service provided by an entity other than the subscriber's ISP. For instance, video capture of programming takes place in Italy, enabling the subscriber to watch Italian channels at her house in Brooklyn, New York. All the while her ISP in Brooklyn may have no clue about which channels are available through IPTV.
The quantity of IPTV channels today may vary from country to country and reach 1000.
Traditionally, the term ‘IPTV’ denotes a specific set of technological solutions for capturing TV channels and rebroadcasting the video to subscribers. Classical IPTV structure looks like this:
The content of TV channels is captured from satellite broadcasts, descrambled (that is, deciphered; more on that later) and multicast "as is" to all subscribers.
In the simplest case, IPTV service is made up of a sat dish, a head-end system and an array of set-top boxes. In fact, its functionality is not that different from a standard television set.
You might ask, why then should IPTV be better than a simple sat dish (DVB-S), if the operator installs a dish anyway? First of all, IPTV provides a wider selection of services, second, the operator installs not one but 5, 6 or more dishes to capture all channels within the reach. Third, a sizable percentage of apartment building residents are unable to have a standard sat dish due to their windows facing north. TV satellites are placed into geostationary orbit over the equator, so from the Northern hemisphere they appear on the south.
Most IPTV operators use sat dishes to capture content because satellite broadcasting has a significantly lower cost than its Internet counterpart. Roughly, capturing one channel using professional equipment should cost from $100 to $1000 at a time. A dedicated Internet TV channel with a guaranteed quality costs about the same, but monthly. For this reason, often Internet TV is provided without quality guarantees.
If the budget allows, sometimes a channel is captured via SDI, a cable transmitting raw original video. This is convenient, reliable, and extremely expensive.
The term ‘head-end system’ designates a satellite receiver that is able to capture content from a high number of TV channels at once. A head-end system carries out three important tasks: turning DVB signal from the dish into bytes, descrambling it, and sending the resulting stream via UDP multicast over the network.
Multicast is a way of data transfer where the source provides the data to all destinations on the network without «knowing» them, while the receiver has the option to ask the router to accept or refuse data as desired. Multicast is similar to broadcast except for the fact that clients on the network are able to select the traffic they receive. To provide this ability, a client's network router must be able to process multicast traffic and support IGMP.
A more complex kind of network structure with many routers is a multicast traffic delivery tree: the router closest to the end subscriber can deliver the IGMP request for multicast traffic to the next router in order to get the desired traffic from it. Note that this type of routing complications always add more latency during channel switching.
Multicast has ultimate scalability as it frees the provider from the need to consider the prospective number of subscribers when designing the head-end system: even with hundreds of thousands of subscribers, the traffic output will always be only as high as the number of channels.
Multicast is implemented as a transmission of UDP packets to 239.x.x.x address group, which is called a multicast group. When a host on the network wants to get multicast traffic, it sends a request to join the multicast group. Multicast delivers MPEG-TS packets inside UDP packets, usually in 1316-byte payloads: 7 packets 188 bytes each in one standard, 1500-byte Ethernet MTU.
Possible issues and alternatives of multicast delivery will be discussed later.
A set-top box (STB) is an electronic device that receives video from the local IP network and sends it to the TV screen. An STB is commonly controlled with its remote control, yet another one in the growing pile of remote controls in every modern household. (See below how today's manufacturers attempt to reduce that pile.)
Some STBs can record or pause the programming. An issue to be aware of is that recording of television programs may lie in the legal gray zone. It took decades for content providers' lawyers to come to terms with the existence of such a spawn of copyright hell as VCR. It is mainly due to this issue that modern set-top boxes often still feature the inconvenient and pointless functionality of scheduled, one-channel recording. The user has to set the STB to turn on the recording mode at a specified later time. This is truly cumbersome, but it's out there, and the right way to do this will be discussed below.
First STBs were quite primitive and could only switch channels based on a preloaded playlist. Modern STBs often feature a web browser (old Opera or Webkit-based) modified for working with a remote control and video-specific tasks. Using a web browser allows for easier interface modifications and addition of new services (like purchasing content by pressing just one button on the RC). However, since STB processors are not too powerful, web browsers typically run on them more slowly than dedicated applications, and browser-less STBs do exist.
Looking for something more attractive than the plain old 300-channels-long list that you need to scroll beginning to end? Meet middleware, another layer of the IPTV structure that provides additional services to subscribers via set-top boxes. Note that even today not all IPTV services use middleware, so in some cases all an STB can get is a fixed channel list.
Middleware enables quick channel list changes, channel grouping (by genre, etc.), access to pre-recorded programming and VOD (movies), displaying info widgets like weather or currency rates, and so on.
Today IPTV operators may encounter certain issues, which did not exist 5-10 years ago.
The conventional way of multicast delivery has to deal with interference caused by home Wi-Fi. With wide popularity of the HD signal (6-15 Mbit/s, compared to the old SD's 1-3 Mbit/s) and home Wi-Fi, classical multicast starts having problems: an expensive TV set shows the tell-tale green squares instead of a crystal clear picture.
OTT delivery is another problem. Multicast cannot be used for video delivery over the Internet: video must be sent to every client individually.
Both of these problems entail considerable packet loss on the way from the head-end system to the set-top box. Traditional IPTV may deal with losing a few packets per hour. In case of Wi-Fi interference or delivery via public Internet, packet loss increases by orders of magnitude.
Even within classical local networks the traditional multicast becomes problematic.
Satellite equipment is notoriously resistant to technology updates. The implementation of H264 to satellite broadcasting has been going full-throttle for years. And most likely will continue going for years. Historically, sat TV uses the MPEG2 video and, so to speak, MPEG2 audio codecs.
iPhone and other modern devices support neither one. Moreover, the H264 that is sent from satellite today cannot be rendered on the iPhone screen due to using the Intra Refresh technology (encoding without big keyframes).
The MPEG2 codec can be reliably replaced with H264 to achieve 3-4 times more bitrate efficiency and, consequently, traffic economy.
When HD signal is captured from satellite and delivered to users over a non-local network, bandwidth limitations will prevent most users from getting the content as is, so the signal should be encoded in different bitrates to enable adaptive quality switching.
In the end, video and audio coming from satellite needs to be transcoded to H264/AAC, since iPhone doesn't support it, it hogs users' bandwidth, and HD signal needs multi-bitrate conversion.
More on capture and transcoding.
As it's been mentioned earlier, historically set-top boxes feature recording just one channel's programming on demand. This approach doesn't work well, since people often forget to set the recording timer and then get frustrated: why buy this expensive STB if it's no better than any old VCR?
The modern approach to providing the archive of aired shows is to record the entire programming and enable subscribers to view preceding programs (or "rewind" currently aired ones) in the TV schedule's order (EPG, electronic program guide).
In order to provide this service, integration of the streaming layer with middleware might become necessary.
As the number of an IPTV service's subscribers grows, sooner or later the provider faces the situation when delivering content from one central server becomes difficult or outright impossible.
Typical examples are the provider opening a branch office in another city or a massive influx of new subscribers in another country as a result of an ad campaign.
In a situation like these, delivering video from one central server may become impractical, especially if there appear entire clusters of users located close to one another and watching the same channel.
In order to save on traffic, local retranslator servers are used: the channel's content is delivered from the central repository to the local retranslator and then transmitted to the end users located nearby.
This architecture may grow increasingly complex as the numbers of retranslators and channels rise, since if every channel must be set up manually, the administrator has to deal with each of a vast quantity of channels.
Also, geo-distributed video delivery sets its own limitations to archiving. It is not feasible to store the past content of all channels on each local server. In fact, the content of channels with narrow audience should be stored on one central server. And yet, every subscriber must be able to access this archive.
The Flussonic server offers an array of tools that make solving these problems easier.
Thus, the structure of modern IPTV service may look like this: