Update: JW7 is now available. Check it out here.
Consolidation has begun in the mobile video space. In early November, Adobe announced it would stop developing its Flash Player for mobile devices (read: Android). Going forward, HTML5 will be the only method to play back videos on mobile phones and tablets. This is a big win for Apple, the company that most strongly opposed Flash in the last few years
According to Adobe, Android 4 (Ice Cream Sandwich) will be the last mobile platform to get a Flash plugin. The OS is launching without one, though. Given the terrible track record of Flash for mobile, we shouldn’t be surprised if it never arrives. Ergo, video publishers should ensure their video works in HTML5 on Android today.
Apple is winning under the hood as well. The H.264 codec is baked into the CPU of every single mobile phone today, while WebM is still confined to a software-only (and non-HTML5) implementation on some Android devices. Google is working on hardware, but the path from reference designs to integration in phones and, eventually, market share is a long one.
Until WebM hardware decoding is supported by a decent slice of mobile devices, video publishers will continue to focus on H.264. Seeing this, Google continues its support for H264 in Chrome, despite the announcement to drop it “soon” almost a year ago. For all intents and purposes, H.264 is the baseline codec for HTML5 video at present.
Completing its hat trick, Apple is well on its way to providing the de facto streaming protocol for mobile video: HLS. Built on top of HTML5, this protocol allows publishers to deliver their videos securely with high quality. I should note that this is relevant only to roughly 10 percent of all publishers, but these publishers account for 90 percent of all mobile views.
What Is HLS?
The acronym HLS stands for HTTP Live Streaming. It is a protocol that allows publishers to stream video using plain HTTP web servers, as opposed to often expensive and hard to scale dedicated streaming servers. This streaming is achieved by chopping up the video hosted on the server into small (usually 10 seconds) fragments, stitching them together again in the browser. The browser only requests the next fragment in line, instead of loading the entire video and wasting bandwidth, as happens in vanilla HTML5. See diagram below for a single fragmented stream:
A video streamed through HLS is usually encoded into multiple qualities, ranging from a mere 180px to full-blown 720px and beyond. Every time the browser returns to the server to load the next fragment, it decides which quality level to load. The browser thus continuously adjusts the quality of the stream to best match the available bandwidth. This is hugely important in mobile, with devices perpetually swapping between 2G, 3G, 4G and WiFi connections. See diagram below for an adaptive fragmented stream:
In addition to this, the fragments of HLS streams can be encrypted for secure delivery. Users who intercept these fragments will not be able to play them at all. This is a big security advantage over plain HTML5 video, where every savvy user can find the URL of a video and download it for his own use.
Why Use HLS?
Today’s wide usage of the HLS protocol is a result of the success of iOS. Apple designated the protocol as the one and only way to stream video to the iPhone and iPad. No Flash, no Silverlight, no RTP or RTSP. On top of that, HLS is required for in-app video. Even simple MP4 downloads, which do work for in-browser playback, are not allowed in iOS apps.
Every major publisher therefore needs to use the HLS protocol, and every major encoding tool (e.g. Encoding.com or Sorenson Squeeze) and streaming server (e.g. Flash Media Server or Wowza Media Server) supports it nowadays. This broad ecosystem, in turn, now has many devices that support the protocol as well. Nearly every popular set-top box can play HLS (Xbox, PS3, Roku, Apple TV, Boxee), as will Android phones running the new Ice Cream Sandwich release.
Wondering if there are any competing protocols? Absolutely. Smooth Streaming from Microsoft is one, but it requires the non-mobile Silverlight plugin. There is also Dynamic Streaming from Adobe, which requires the soon to be retire? Flash plugin. HLS is built on top of HTML5, which makes it easy to implement by both browsers and devices.
A standardization effort is on its way as well, in the form of MPEG DASH (Dynamic Adaptive Streaming over HTTP). Supported by many companies (including Apple) and boasting a rich set of features, DASH may well become the single video streaming protocol to replace HLS, as well as RTMP and RTSP. However, as things go with standards, progress is slow and broad support is years away.
The Apple Standard
So, for the foreseeable future, we’ll watch our mobile video the Apple way: embedded using HTML5, encoded using H.264 and streamed using HLS. Any platform that wants broad support for quality video (Windows Phone?) must implement HLS and any publisher that wants many mobile viewers must leverage HLS.
Now, is this a bad thing? Quite the contrary. The alternative to a central protocol is fragmentation: multiple plugins, multiple codecs and multiple protocols. Which is bad for large media corporations, as it reduces their bottom line. Even worse for smaller video publishers though, since they lack the resources to even make their video available at all. And that, in turn, is a detriment to mobile video at large. The key to mass adoption is broad-reaching availability across a wide variety of content.
This blogpost is a modified version of our article first published on Mashable. Read Full Article Here.