It’s Not Just About HTML 5: Why Flash Can be a Better Solution for Streaming Video on the Web

by Jason Thibeault, Sr. Director,
Technology Alliances and Cloud Strategy, Limelight Networks

There is an unmistakable trend in the video delivery and content publishing industry right now: HTML5.

When HTML5 hit the market, the video industry immediately jumped on it as the proposal of a <video> tag that was part of the native HTML, which meant no more specialized players (like Flash) and easier delivery as video could be provided through HTTP (circumventing more expensive, licensed media servers like Windows Media Server or Flash Media Server, as well as using standardized ports, 80 and 443, open on 99% of corporate firewalls). What’s more, HTTP streaming posits a “single video format” workflow for content publishers. No longer do publishers need to encode video in multiple formats (i.e., FLV for Flash, WMV for windows, MOV for Quicktime, etc.), they can just create a single .mp4 or equivalent container and deliver everywhere. All in all, the combination of HTML 5 and HTTP video promised a utopia for video publishers.

Unfortunately, that is not exactly the case. Although HTML 5 supports the direct consumption of HTTP streams, there are a number of shortcomings:

1.    Security. There is no inherent security in the HTML 5 video tag. So that means there’s no way to decrypt a secured video stream without the use of a browser plug-in or specialized player.

2.    Decoding. Unfortunately, there are many codecs by which to create an HTTP-compliant video package. There’s what most would argue is the industry standard, h.264, but there are also others like WebM (formerly VP8, purchased and open-sourced by Google) and Ogg. In order for a browser to be able to display and play a video within a <video> tag in HTML 5, it must have the right codec. So if a publisher encodes a video using one codec, it may not be playable in certain browsers (at the time of writing this post, publishers must encode three different version of their video and utilize javascript in their HTML page to tell the browser which version to fetch).

3.    Interactivity. As a “vanilla” video player, the <video> tag doesn’t provide anything other than the ability to play the stream. Because of that, there is little interaction available with the stream itself. No way to really get access to key frames (which help for bitrate switching), video metrics, etc.

4.    Advertising. Without a way to interact with the video, there is little that can be done to offer dynamic ad insertion. Coupled with a “dumb” server, any ad insertion has to happen at the time of encoding the stream, making for fixed ads, not dynamic. Additionally, because there’s no way for the browser (or web page) to know where the user is in the video, there is also no way to offer dynamic in-page advertising either (where the ads would reflect the point in the video).

5.    “Dumb” server. One of the primary benefits of serving HTTP video is that it doesn’t require a specialized media server. It can be delivered from an Apache or Tomcat webserver, for example, on Linux. Completely open source and completely free. This is because it’s just standard web traffic. The magic is in the <video> tag within HTML 5 and the browser’s interpretation of that tag. But that is a drawback as well. Because the web server is dumb, there’s no way to interact with the playback: either the browser nor the stream.

Even though the industry is riding the HTTP swell doesn’t mean that publishers have to opt for a pure HTML/HTTP solution. Many of the industry media-delivery heavyweights like Adobe and Microsoft have openly committed to supporting HTTP delivery through their servers. In fact, Adobe’s soon-to-be-launched FMS 4.5 will enable the delivery of Adobe HTTP Dynamic Streaming (HDS) and Apple’s HTTP Live Streaming (HLS) format. Furthermore, the latest versions of both the Adobe Flash player and the Microsoft Silverlight player support playback of HTTP streams.

What does this mean? It means that video publishers can still enjoy some of the benefits of HTTP streaming (i.e., an open, standard port and a single content format container like .mp4) but they get to leverage an end-to-end video delivery solution that provides a significant number of advantages. Take the following example:

1.    Publisher creates video content in .mp4 format
2.    Publisher creates a stream in FMS 4.5 from the content
3.    A user requests the stream from an old Flash player

• The FMS 4.5 “Just-in-time-Packager” converts the .mp4 to .flv and delivers it out via RTMP (not HTTP). User is happy.

4.    Another user requests the stream from their iPhone

• The FMS 4.5 “Just-in-time-Packager” converts the .mp4 to HLS format and chunks it up, delivering it to the iOS device. User is happy.

5.    Another user requests the stream from a webpage that has a <video> tag

• The FMS 4.5 server pushes the content to an Apache web server where it can be delivered. User is happy.

6.    Another user requests the stream from the latest Flash player

• The FMS 4.5 server delivers the video straight to the player

In each of these instances, the Flash Media Server is delivering the same content (.mp4) to multiple user types. But that’s not the only advantage here. Because the video is being delivered in each instance from FMS (which is a very intelligent, powerful media server with lots of capabilities for reporting, stream management, and interactivity), the publisher can take advantage of the server’s functionality, especially when it is being delivered into a Flash player. And that’s where delivering HTTP through an end-to-end platform solution like Flash provides the most benefit. When the user is employing a newer version of the Flash player (that can handle HTTP streaming), the publisher can employ a customized player (skinned, branded and ad-integrated) with any number of specialized elements coded and integrated via Actionscript (the Flash player’s native programming language). In addition, unlike the FMS 4.5 server pushing content to an iOS device or to a web page with a <video> tag, pushing to a Flash player enables client-side reporting and other video interactivity that a “player-less” environment doesn’t offer.

There are definite benefits to HTML 5 and, more importantly, to HTTP streaming. With Adobe and Microsoft’s support of HTTP streaming, it is only a matter of time before it becomes the de-facto standard for all video delivery. But there don’t seem to be a lot of benefits to delivering HTTP traffic into a HTML 5 <video> tag other than development cost. It doesn’t cost a publisher anything to include a <video> tag in their web pages. What they lose, though, in abandoning the end-to-end solution approach is a host of interactivity, potential revenue/monetization opportunities, and any chance at understanding their end-user’s experience with the video.

Perhaps the HTML 5 <video> tag will become more powerful as the specification isn’t even ratified yet. But even then, companies like Adobe and Microsoft build media delivery solutions. They devote time, energy and resources to creating functionality that video publishers need. And with a penetration rate of over 90% of the world’s desktop computers by Flash (no, they aren’t on iOS devices but perhaps that will change in the future), there is little chance of marginalizing end-users who want to watch the video. Chances are, they’ll have the player.

Whatever you choose to do around your video delivery, take heed. Understand what the trade-offs are between “going native” (HTTP + HTML 5) and an end-to-end solution like FMS + Flash player and how those tradeoffs will impact your business.

This entry was posted on Thursday, August 25th, 2011 at 12:11 pm and is filed under Uncategorized, Video Publishing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.