HTTP Streaming: What You Need to Know
One example of this is Instant-On, Apple’s patent-pending streaming technology, which offers content that begins to play as soon its link is clicked. This solution has direct bearing on Apple’s HTTP streaming solutions of adaptive bitrate content.
Another piece to this puzzle that has been used in the past to address network inconsistencies is the encoding of multiple bitrates for each video file. The initial playback request included a bandwidth measurement, which triggered the selection of a discrete file that most closely matched the user’s anticipated bitrate (rounded down to the next lowest bitrate).
This solution was effective in some instances, although it assumes that the bandwidth of the initial request is a consistent bandwidth.
Stuttering is the stalling of content delivery that occurs if the streaming bandwidth falls below the stream’s optimal bitrate. Even multiple bitrate streaming was susceptible to this because the initial bandwidth may not equal the sustained bandwidth, meaning that a sustainable viewing experience cannot be maintained.
For on-demand content, stuttering is annoying. Content delivery is momentarily stopped and is later picked up at that point in the stream once the buffer is replenished. For live content, however, this stuttering is deadly, as the video or audio stream continues while the viewer is waiting for his or her network to recover enough to resume the broadcast. Once the network recovers, the broadcast stream skips ahead to pick up the live broadcast in real time.
Yet, as I’ll cover later in this article, the basis of multibitrate streaming is also key to emerging HTTP streaming solutions.
Finally, streaming has some efficiencies in terms of delivery, including the ability to eliminate excessive downloading of long-form content that a user may abandon partway through. When it comes to progressive downloads, users with very fast connections may be able to download an entire video file in less than half the time it takes to view the file. Should a user then choose to abandon the content halfway through the viewing time, the content delivery has "wasted" almost 50% of the bits by downloading much more content than the user watched.
Streaming, on the other hand, only delivers content until the user abandons viewing the content, limiting the number of wasted bits. In recent years, progressive downloads have gained the ability to be throttled, meaning that only a slightly higher bandwidth download is allowed regardless of the user’s possible bandwidth, which also limits the number of wasted bits should a user abandon viewing before the end of a file. The downside of progressive download throttling is that it often limits the ability for viewers to skip ahead by minutes rather than by a few seconds.
This efficiency is also now wrapped into HTTP streaming if adaptive bitrates are used.
One other efficiency in streaming is that files are not saved on the viewer’s hard drive. This is often viewed as primarily beneficial from a rights management or copyright standpoint. But the delivery efficiency is that video length has no bearing on the amount of user hard disk space required to view a video file.
As streaming content has to be restreamed to be viewed a second time, the throttling of progressive download content often also means that this content will be rapidly jettisoned, requiring redownloading for a second viewing of the same content, unless the second viewing is done immediately following the first viewing.
When will the industry jettison HTTP-segment-based streaming and buffer-based playback, both of which hold us back? How about right now, our columnist proposes.
Cloud-based encoding service Encoding.com has added HTTP Live Streaming, with presets for iPhone, iPod Touch, and now the iPad.