This is an installment of our ongoing State of Play series, designed to offer insight into new evolutions and significant issues in the online video industry.

In this post, we'll try to give you an overview of the main methods and protocols which are currently employed to stream online video (for instance, we are not covering Peer-to-Peer streaming since it is still being considered as experimental in a CDN context). In our next post, we will look into more detail at the advanced technique of adaptive bitrate streaming (a.k.a. bitrate switching) which is quickly gaining popularity.

HTTP Pseudostreaming

HTTP Pseudostreaming is not 'true streaming', but a form of progressive download that allows viewers to seek to not-yet downloaded parts of a video. The delivery protocol is regular HTTP, combined with a mechanism that allows the player to include a start time parameter in the HTTP request's query-string. Using this mechanism, the client can do random seeking to any part of the timeline at any time.

Pseudostreaming has some advantages over true streaming:

• It leads to fewer hassles with firewalls and proxy servers (corporate environments).
• The initial loading time is usually shorter.
• It results in a better viewing experience if the local connection is below average.

There are also a number of drawbacks:

• In contrast to 'true streaming', pseudostreaming results in your digital files being downloaded to the physical drive on the end user's device.
• It leads to higher bandwidth consumption, since the client will try to download the file in its entirety (as opposed to true streaming where only the parts that you actually watch are being delivered).
• When seeking in large video's (> 15 minutes), pseudostreaming causes relatively long wait times before play is being resumed.
• For high-bandwidth videos, it may slow down (or even crash) a viewer's browser.
• Progressive download results in less precise/detailed statistics, since not all downloaded data has necessarily been viewed.

Stateful Streaming

In 'true streaming' protocols, the file is being sent to the end-user in a (more or less) constant stream and the user watches it as it arrives. For this purpose, traditional video streaming protocols maintain a persistent client-server connection that allows for real-time communication. The actual video and audio streams are being delivered via a dedicated streaming protocol built on top of TCP or UDP.

The main problem with this approach is that streams are frequently blocked by (mainly corporate) firewalls, since they are not being sent over HTTP (port 80). To circumvent this problem, protocols have been extended to allow for a stream to be encapsulated within HTTP requests. However, this technique - called 'tunneling' - comes at a performance cost and is therefore often only deployed as a fallback solution. Most of these protocols also have secure variants that use encryption algorithms to protect the stream.

Well known stateful streaming protocols include:

• Real Time Streaming Protocol (RTSP) : developed by the IETF and published in 1998 as rfc 2326. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, which supports a range of multimedia formats (such as H.264, MPEG-4, MJPEG, MPEG, etc.). Client applications include QuickTime, Skype and Windows Media Player. Most smartphone platforms (e.g. Android, Blackberry, but not iOS) also include support for RTSP as part of the 3GPP standard.
• Real Time Messaging Protocol (RTMP) : developed by Adobe Systems, which has recently released the specification for public use. RTMP is primarily used to stream audio and video over the internet to Adobe's Flash Player client. Due to the success of Flash Player, the bulk of streaming videos on the internet is currently delivered via RTMP or one of its variants (RTMPT, RTMPS, RTMPE, ...).
• MPEG transport stream (MPEG-TS) : a mechanism, defined in the MPEG-2 protocol, which controls the transmission and storage of audio, video, and data. It is mainly used in broadcast systems such as DVB and ATSC and enables connectivity with many of the conventional IPTV set-top boxes.

HTTP Streaming

HTTP streaming is a recent technology which is still maturing and would benefit from a widely accepted standard. Currently, separate solutions have been instituted by different vendors, which all use the same mechanism but are incompatible. From a client perspective, they all require the vendor's own software or platform:

• Apple HTTP Adaptive Streaming : an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of their QuickTime X framework and iOS 3.0 system. Apple has submitted its solution to the IETF for consideration as an Internet standard.
• Microsoft Smooth Streaming : an IIS Media Services extension that enables adaptive streaming of media to clients over HTTP. Microsoft provides Smooth Streaming Client software development kits for Silverlight and Windows Phone 7.
• Adobe's HTTP Dynamic Streaming : Adobe released their own version of HTTP streaming (requires Flash Player 10.1) in June 2010 and is now trying to catch up with Apple and Microsoft. Since Flash Player is the main client platform targeted, this is also being referred to as HTTP Flash Streaming.

Streaming over HTTP works by breaking the overall stream up into a sequence of small HTTP-based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. By using HTTP as the stream transfer protocol, firewall issues are generally avoided. Downsides of this approach are a lesser (default) security and the absence of metadata, which makes it harder to ensure quality of service.

All flavors of HTTP streaming include support for adaptive streaming (a.k.a. bitrate switching) which allows clients to dynamically switch between different streams of varying quality and size during playback, in order to adapt to changing bandwidth conditions and available CPU resources. While mainly associated with HTTP streaming, Adobe has also included support for adaptive streaming into the RTMP protocol.

Another would-be advantage of HTTP streaming is that it allows the HTTP chunks to be cached within ISPs or corporations, in contrast to video streamed via RTMP. This would reduce the overall bandwidth required to deliver HTTP streams. However, research by Streaming Media concluded that "practically speaking, it appears that the benefit of cache servers is so unquantifiable that it is irrelevant".

Recently, the Motion Pictures Experts Group (MPEG) has started work on a specification for Dynamic Adaptive Streaming over HTTP (DASH) in an effort to standardize video streaming over HTTP. However, lots of preliminary issues still need to be resolved - including legal ones (patent claims) - before DASH can become a widely used standard.

A Client Perspective

Whereas most clients allow video's to play via (progressive) download, support for streaming protocols varies strongly depending on your choice of player, device and/or platform.

• iOS 3.0+ devices (iPhone, iPad, iPod touch) support Apple HTTP Adaptive Streaming.
• Windows Phone 7 client libraries support Microsoft Smooth Streaming.
• Most smartphones (3GPP) support RTSP.
• Flash Player supports RTMP and, starting with version 10.1, also Adobe's HTTP Dynamic Streaming
• QuickTime supports RTSP, QuickTime X (OS X 10.6) also supports Apple HTTP Adaptive Streaming.
• Silverlight player (3.0 or later) supports Microsoft Smooth Streaming
• ...

This fragmentation has to be taken into account when streaming to multiple platforms (e.g. in case of a live-stream, where it is impossible to fall back to progressive download). As a Rambla customer, you can opt for a mix of different techniques to reach your target audience. Our CDN supports all streaming methods described in this post, both for on-demand and live-streaming. Moreover, it suffices to publish a single .mp4 file (H.264/AAC) on the CDN to make it accessible to all players and devices mentioned here. For more details, see our documentation or contact us.