special report IPTV@IBC2010


delivering video that adapt automatically to the viewers’ network and playback conditions. As mentioned, that could be inconsistent network bandwidth, or even whether the viewer’s PC can keep up with decoding and playing the video. From a viewer perspective, HTTP- based adaptive streaming behaves a lot like traditional streaming protocols such as RTSP, but is really based on a series of short HTTP progressive downloads of small media segments. Even in the case of live content, the so-called ‘streams’ are really a series of small file downloads.


At a high level, the path content takes for HTTP adaptive streaming is the same as the path it takes for non- adaptive delivery. Source video feeds or files go into an encoder or transcoder, which transforms the content into the required output formats. The outputs are sent to a server or CDN, from which they are delivered to the viewing audience. This simplified view ignores valuable aspects such as DRM and ad insertion, but represents a minimal flow (See Figure 1).


With HTTP adaptive streaming, the encoder or multiple encoders create several outputs at different bit rates and frame sizes from the same source. These outputs are divided up into a series of short, precisely aligned pieces of up to a few seconds in length. Depending on the particular adaptive streaming technology being deployed, these pieces might be called ‘chunks’, ‘fragments’, or ‘segments’, and the segmenting might be done directly within the encoder or with external tools. The segmenting occurs only at GOP (Group of Pictures) boundaries within the outputs, enabling each segment to be decoded independently of the others. In addition to the segmented media itself, manifest or index files are created to keep track of the various outputs. The client player learns which bit rates are available for the given piece of content through its manifest. These segments are downloaded by the client player from the server or CDN over HTTP similar to a traditional progressive download, and played back in order. To adapt to varying conditions, the client changes which of the multiple outputs it is downloading segments from, effectively switching bit rates at the segment boundaries.


A visual example will make this clearer. Figure 2 represents a piece of content that has been encoded at


multiple bit rates, with the highest bit rate at the top, and the lowest bit rate at the bottom. Each thumbnail represents a segment, not an individual frame. The segments in this example are two seconds in duration, but the segment length is typically configurable and may vary between technologies. All of these segments are perfectly aligned, which we’ll discuss shortly.


A viewer with consistently great network and playback conditions will be watching the highest bit rate segments throughout the content, while a viewer with low bandwidth or a very slow PC will be watching the lowest bit rate segments. For a viewer who has inconsistent conditions, the adaptive streaming technology will automatically select segments of the different outputs. In this exaggerated example, the viewer’s bandwidth started out great but then suffered considerable network congestion, so the player switched to the lowest bit rate. As the network conditions improve, the player begins selecting higher bit rates again.


Encoding for adaptive streaming


Support for adaptive streaming technologies including Adobe HTTP Dynamic Streaming, Apple iPhone adaptive streaming, Microsoft IIS Smooth Streaming and more is integrated throughout Digital Rapids’ encoding and transcoding product lines, including the StreamZHD Live ABR adaptive streaming encoder, StreamZHD multi-purpose encoding system, TouchStream portable streaming appliance and Transcode Manager high-volume transcoding software. Encoding for adaptive streaming involves many more considerations than encoding for traditional streaming, some of which we’ll touch briefly on here. One of the most important things from an encoding perspective is that


Figure 2: Adaptive streaming technologies


effectively ‘switch’ between bit rates by downloading segments of multiple outputs based on current conditions.


Adaptive streaming technologies have evolved to play an essential role in bringing Internet TV a step closer to the quality and reliability of dedicated television services.


the multiple outputs must be perfectly synchronised and aligned, from timecode down to the GOP alignment within the compressed bit streams. That’s critical - if they’re not precisely aligned, there can be jumps in the playback when the adaptive technology switches between bit rates. That’s fairly straightforward within a single encoder, but if multiple encoders are being synchronised to increase the number of outputs or for fault tolerance, external timecode and reference sync should be used. Of course, encoding for live adaptive streaming is more demanding than encoding for on- demand delivery, as all of these perfectly synchronised outputs must be created simultaneously in real time. The number of different bit rates offered for each piece of content is up to the content provider, and each technology has its own recommended practices, but live web events to date have typically offered six or seven different bit rates.


Encoding those six or seven outputs in real time previously required multiple encoders synchronised and encoding the same input source. Today, those streams and more can be created concurrently in real time within a single StreamZHD Live ABR or StreamZHD unit. Even so, users may still want to deploy multiple synchronised encoders for fault tolerance.


Wrapping it up


Adaptive streaming technologies have evolved to play an essential role in bringing Internet TV a step closer to the quality and reliability of dedicated television services. Beyond the viewer benefits, content owners benefit from the resulting increased viewer engagement, while infrastructure providers such as CDNs benefit from the scalability, capacity and cost savings available by leveraging existing HTTP infrastructures.


www.ibeweb.com l OFFICIAL GUIDE TO IPTV@IBC2010 september/october 2010 l ibe l S25


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32