Download Complete Introductory Guide to IPTV and Video Networking
Introduction
For many applications, it is very desirable to deliver video content, either stored or live, through the Internet. Internet bandwidth available to end users has steadily increased over the last few years, and many enjoy connections that are capable of support even High Definition services.
However, the traditional IPTV delivery protocols are not suitable for the Internet:
- The one-to-many delivery solution for traditional IPTV is based on IP Multicast. While this is the right technology for a closed managed network, it is not supported by the Internet.
- Traditional IPTV delivery assumes that the network infrastructure absolutely guarantees the bandwidth to all end users:
- Only one bit rate for each stream is available, and all users are assumed to be able to receive it. If there are different access levels in the IPTV network, operators normally set their bit rate (quality) based on the lowest access level.
- Protocols do not handle packet losses well (in most cases, there are no mechanisms to handle this, since the network infrastructure is expected to deliver all packets without any drops).
These assumptions are not true for the Internet.
- Traditional IPTV protocols are not very suitable for traversing firewalls (although proprietary solutions exist). In the Internet, virtually all users today are behind some sort of home gateway/firewall.
The Internet today is geared to delivering Web content. The problem of scaling a web server to millions of users is well understood, the TCP protocol used on the HTTP connections is capable of dealing with lost packets, and every firewall out there can handle access to a web site. Therefore, an ideal video delivery solution should be based on Web/HTTP technologies. It should also automatically adapt to each user’s individual Internet bandwidth, so that every user can have the best viewing experience afforded by their connection.
Adaptive Streaming Protocols
The primary objective of Adaptive Streaming is to provide the user the best possible viewing experience given his/her instantaneous available Internet connection capacity. The key ideas are as follows:
- Make available to the playback device multiple versions of the same content at different bit rates. Obviously, the higher the bit rate, the better the quality of the content. The lower bit rate versions can be at reduced resolution.
- Let the playback device decide what version of the content to use based on its detected network conditions (rather than trying to manage this at the server side).
- Organize the content in such a way that the playback device can switch from one quality level to another on-the-fly, in a seamless fashion, again without involving the server.
This idea, combined with HTTP-based delivery, provides an excellent mechanism for delivery of content over the Internet. The server provides multiple copies of the same content at different bit rates; the playback device chooses one to start, and monitors the network performance. If the playback device detects that it is falling behind, it switches to a lower bit rate stream; if it detects that is downloading faster than real-time, it switches to a higher bit rate stream. The content has well-defined (and signaled) transition points where this switch can happen in a seamless fashion. Since this process is managed at the playback device (without the need for upstream communication with the server), this architecture is very scalable, and can be implemented with unmodified traditional web servers.
Currently, the two main Adaptive Streaming protocols available are:
- Microsoft Silverlight.
- HTTP Live Streaming (HLS), proposed by Apple. The protocol is documented as an Internet Draft in draft-pantos-http-live-streaming.
Fundamentally, both protocols work the same. As an illustration, we summarize here the HTTP Live Streaming operation.
The basic idea of the protocol is to divide the live stream into file segments, which are placed in a web server. As the encoder produces bitstream, new files are created (and optionally the older files are deleted). A playlist file is also placed in the server, pointing at the segments. As new segments are added (and old ones removed), the playlist file is recreated. Clients obtain the playlist file and refresh it as required, as they play the segments.
The same content may be offered at multiple bit rates. It is up to the client to decide what bit rate it can accept, based on the current conditions of its Internet access. Multiple bit rates are offered through a playlist, which point to the dynamic playlists for each bit rate. As long as the set of bit rates does not change, this top playlist can remain static.
Playlists are text files, using an extension the “m3u” format. The overall process is depicted below. The client is given a link to the “Main Playlist”, where it learns the URLs of each of the individual playlists for that content, and their bit rates. The client will select one of the individual playlists based on its knowledge of its current Internet speed. The client can also switch to a different bit rate playlist on the fly, if its connection speed changes.
HTTP Live Streaming Use Case
HTTP Live Streaming is supported on the current versions of most Apple devices (iPhones, iPads, iMacs, and iPod Touch), as well as on a number of IP Set-Top boxes. On the generation side, the VidOvation VEN-5000/2000 encoder is capable of generating single-profile HLS streams and populating a standard Web server with all the relevant files, in real time, using either FTP or SFTP. For a small deployment, a standalone web server can be used; for a larger deployment, the files can be uploaded to a CDN. The diagram in the next page illustrates this use case.
VidOvation can supply the encoder and compatible IP set-top boxes for this application.
Download Complete Introductory Guide to IPTV and Video Networking
