HTTP Live Streaming

HTTP Live Streaming is a standard implemented Apple, to support streaming of video on the iPhone, iPad and iPod touch. Apple has submitted the specification to the IETF as IETF Internet-Draft of the HTTP Live Streaming specification.

HTTP Live Streaming competes with the current incumbent, RTMP, Real-Time Messaging Protocol from Adobe. While recently Adobe has published the standard for RTMP, it has been proprietary for years but had been reverse engineered by several groups including the Red5 server. RTMP requires the Adobe Flash Player on the client, which has a reputation as being buggy on many platforms causing high cpu usage and fast battery drain. Apple has not included support for Adobe Flash on their mobile platforms.

HTML5

The server side of video delivery is only part of the story, the other piece is the client, which until now has primarily been the Adobe Flash Player. Video delivery over the Internet is finally becoming a first class citizen with the introduction of HTML5. HTML5 defines a standard way to embed video in a web page, using a <video> element. Apple Safari, which is the native browser on Apple’s mobile devices, provides Video playback through the HTML5 Video element. This native support allows the browser to optimize the Video Decoder for the platform being used, this can include offloading video decoding to specialized video chips such as Nvidia, reducing the CPU load on the main processor. This should result in full definition 1080P HD content playback right from the browser. There is no way at present for the video to be shown fullscreen, since it’s inside the browser and not running as a plugin like the flash player.

HTTP Live streaming has many advantages over RTMP, the main one being that it’s a pure HTTP solution so common HTTP servers can be used to deliver Video. This also means that streaming is automatically supported by nearly all edge servers, media distributors, caching systems, routers, and firewalls. Many internal networks are behind firewalls and proxies that could interfere with video delivery using different protocols, these devices do not cause a problem with HTTP Live streaming.

HTTP Live streaming has support for multiple bit rate encoding, also know as adaptive streaming. This helps when the throughput of downstream client is not known, so faster clients can get high quality, high bit rate encoding but a slower client can get a lower quality, lower bit rate encoding. Over the open Internet or mobile network this is the only way to reliably deliver a live stream. There is also support for Encryption using AES-128, with key management over HTTPS and session-based authentication.

Encoding

The media encoder takes a real-time signal from an audio-video device, encodes the media in h.264, and encapsulates it for transport. Encoding should be set to a format supported by the client device, such as H.264 video and HE-AAC audio. Currently, the supported delivery format is MPEG-2 Transport Streams for audio-video.

MPEG-2 transport streams should not be confused with MPEG-2 video compression, MPEG-2 transport streams is the container format and is the standard for ATSC broadcast delivery and can be used with a number of different compression formats. Only MPEG-2 transport streams with H.264 video and AAC audio are supported at this time for audio-video content.

The file is then cut into segments using a segmenter program, the size of the segments are determined by the duration and bit rate, a typical duration is 10 seconds. The segmenter also creates an index file containing references to the individual media files. Each time the segmenter completes a new media file, the index file is updated. The index is used to track the availability and location of the media files. The media files are stored as .ts files and index files are saved as .M3U8 files, an extension of the .m3u format used for MP3 playlists.

I think the time is right for a new standard to emerge in the live video streaming space and I believe this is it. With the momentum of the iPhone, Apple carries a lot of weight in this space, and developers want easy standards based solutions, HTTP Live streaming wins on both accounts. RTMP had it’s day, but it’s hard to implement and was really designed for a different era, one in which multiplexing information across one socket was needed. This is not the case anymore, even inside a browser window there can be many events going on, with Javascript coordinating the information flow. HTML5 provides a general purpose websocket interface which defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface. Between these HTML5 Video and HTML5 websocket the functionality that RTMP provided is no longer needed,

There are still issues to overcome, for one this is an Apple standard and is not supported by other browsers except Safari. There are issues in general around the Video player in HTML5 because different browsers support different encoding formats and containers. While h.264 is recognized as a great encoding format, there are licensing issues around the technology so open technologies like Theora video, which is free, were introduced. There are other formats like Dirac for video encoding and Matroska-MKV as a container, that are gaining ground. In the end once a Open Source, license free video encoding and container format are agreed upon the industry will move towards that. The licensing corporation around h.264 may realize that and come up with a solution, but they have a built in monopoly with OTA and other broadcast uses.