Distributing Video Content
Sep 15, 2014 9:37 AM, By Jan Ozer
Some video platforms for your customers to consider
Whenever you post an on-demand video to a website, your obvious goal is for that video to be played on all possible platforms, from the lowliest smartphone to the grandest living room TV. Like many grand goals, however, this is easier said than done, and many companies have spent millions in pursuit of this vision. Well, you probably don’t have millions to spend, and neither does your customer or employer. Can you spare a few hundred? If so, here you’ll learn how to capture a big chunk of these platforms for less than $1,000.
Figure 1. The streaming market pyramid. Click here to see a larger image.
Let’s start by setting expectations. The pyramid in Figure 1 represents all potential targets for your video with the broadest markets on the bottom and the narrowest markets on top. OTT stands for “Over The Top,” or devices that connect your television set to the Internet. Retail OTT represents the Rokus and Apple TVs of the world, while OEM OTT represent custom set-top boxes for cable channels and similar markets.
How much of this pyramid you choose to support is purely a function of budget. As you go up the pyramid, development costs increase and the number of users drops, so the cost per additional user skyrockets. If you’re adept at monetizing your video, such as Netflix, Hulu, YouTube, and the like, this makes sense. If you’re not, you should focus on the bottom two classes: desktop and notebooks, and mobile. For the few hundred dollars that I mentioned, you’ll be able to effectively serve these two markets and create files you can distribute to retail OTT devices and some smart TVs.
DEVELOPMENT APPROACHES
Before diving in, let’s cover the various developmental approaches for delivering streaming video. When delivering to desktops and notebooks, you have multiple options. You can choose an approach that relies on technologies that exist in browsers, like HTML5, though that approach will only work on HTML5-compatible browsers—now about 85 percent to 90 percent of the total market. This means that 10 percent to 15 percent of potential viewers won’t be able to play your video. You can rely on Adobe Flash, which will deliver about 97 percent of viewers, but then you have to use Flash-compatible technologies.
If you want to go beyond the basics and add support for branding and other features, you’ll need to create your own player. You can do this with an off-the-shelf player, such as the JW Player I’ll discuss below, for around $300, with minimum additional development expense. Or you can go completely custom, like most larger websites, and spend a fortune. One advantage of the last approach is that you can use any technology that you would like. For example, if you want to use MPEG DASH for adaptive playback (more on this below), you can. The more you spend, the more technology options you have.
The mobile market has a similar dynamic. It’s easiest to simply distribute media that plays natively on the platform you’re targeting; total development expense for playback is $0. But you’re limited to media and technologies that play natively on that platform. Or you can develop apps for each target platform, which costs a lot more but frees you to use whichever technology you would like. Again, if you want to distribute MPEG DASH to iOS devices, you may be able to, but you’ll have to develop an app.
Figure 2: Follow these recommendations from Apple Technical Note TN2224. Click here to see a larger image.
Finally, with Retail OTT and Smart TV, you’ll have to develop your own channel, which costs some bucks. All platforms support some streaming technologies natively, and it’s simplest and cheapest when you use these. On some platforms, it may be possible to use technologies that aren’t supported natively, but that will jack up your development costs.
THE COMPRESSION RULES
If you want your videos to play on all platforms, you have to encode with the H.264 codec. If you’re producing a single file for playback everywhere, encode using the Baseline profile, which has the broadest possible playback profile.
If you’re producing an adaptive group of files for playback in the pyramid, follow the recommendations presented by Apple in Technical Note TN2224 (Figure 2). You don’t need to follow the recommendations to the number, just use the profiles shown on the extreme right for files of those resolutions. That way, the four lowest-quality files should play on all lower-end mobile devices.
Distributing Video Content
Sep 15, 2014 9:37 AM, By Jan Ozer
Some video platforms for your customers to consider
SINGLE FILE STREAMING VIA HTML5 WITH FLASH FALLBACK
Figure 3. The HTML code that implements HTML5 playback with Flash Fallback. Created in SorensonSqueeze. Click here to see a larger image.
The most basic approach is to distribute a single file to computers and mobile devices using HTML5 with Flash fallback. What is HTML5? It’s a schema introduced in the last major rev of the hypertext markup language that is the lingua franca of the Web. Basically, all HTML5-compatible browsers, now at about 85 percent to 90 percent penetration, include their own video players. Simply encode the video file and include the correct HTML code, and the video file will play within the browser.
What about the 10 percent to 15 percent of viewers not running HTML5-compatible browsers? That’s where Flash fallback comes in. As shown in Figure 3, when you create your HTML, you present alternative paths; if the browser is HTML5 compatible, it plays the video via HTML5. If not, it falls back to Flash. What about mobile? Since smartphones and tablets are all so recent, they all play HTML5 video natively, so you get 100 percent coverage.
There’s one more wrinkle; in some versions of Windows, the Firefox and Opera browsers don’t support H.264 playback. You can encode using the WebM codec, which these browsers do support, or simply fallback and use Flash to play the H.264 encoded video.
The HTML code is shown in Figure 3. The first few lines say, “Hey, here’s the MP4 file, if you can play that, play it.” The second line effectively says, “No? OK, here’s the WebM, we good?” If not, the last chunk says, “OK, use the Flash Player to play the MP4 file.”
What does all of this cost? If you can hand code the HTML necessary to implement this approach, which isn’t rocket science, and you don’t mind using free encoders such as the very capable Hand- Brake, this approach is completely free. If you want to simplify the operation, you can spend $549 for Sorenson Squeeze standard edition to do all the hard work and produce the H.264 and WebM files, plus the HTML code shown in Figure 3.
While HTML5 with Flash fallback is the closest thing to a free lunch that you’ll get in the streaming space, there are some notable limitations. First, it’s single file only; there is no simple HTML5 schema for adaptive streaming. That means you’ll have to send a single file to all viewers, which involves the following fundamental tradeoff.
If you make the file small enough to deliver to viewers on a cellular connection, it will look pretty average on a computer. In contrast, adaptive streaming, which we’ll discuss next, encodes the source file to multiple iterations that it delivers according to the power of the viewing device and connection speed. Those watching via smartphones will get one file, but those watching in their living room will get a much higher-quality file. You can glance back at Figure 2 to get a sense of what I mean. Five years ago, when virtually all streaming video was viewed on computers, you could get away with single-file delivery. Now that smartphones and living room TVs are in the mix, adaptive is vastly preferred.
Figure 4. Costs and development burden for the five adaptive streaming technologies. Click here to see a larger image.
Finishing up on the deficits of HTML5, there’s also no simple digital rights management (DRM), so you can’t protect your files. There’s also no captioning, live streaming, or true streaming, which means all files are delivered via progressive download. That’s probably not a concern if bandwidth isn’t a major expense for your organization, but if it is, you definitely want to consider the approach discussed in the next section.
ADAPTIVE STREAMING VIA HTTP LIVE STREAMING (HLS)
Sold on adaptive? Well, you should be, because the technologies that bring you adaptive streaming also address the other major deficits of HTML5, including DRM, live and true streaming, and captioning. Of course, there are multiple adaptive streaming technologies, including two from Adobe (RTMPand HTTP-based Dynamic Streaming), as well as HTTP Live Streaming (HLS) from Apple, Smooth Streaming from Microsoft, and Dynamic Adaptive Streaming over HTTP (DASH) from the Moving Pictures Expert Group (MPEG). All have their strengths and weaknesses, so why am I pushing you towards HLS? Well, it comes down to the predominance of green in Figure 4.
Remember when I mentioned that you could use any technology that you wanted, pretty much anywhere, if you had the development dollars? Figure 4 puts color coded detail to that concept. Basically, any item in green is inexpensive and easy. Any item in orange is a bit of a problem but surmountable. Anything in red is flat out expensive. Since HLS has the most green slots, this means that it’s the simplest and cheapest technology to implement across the five platforms shown in the table.
Let’s walk through the HLS row. Though HLS isn’t natively supported on any Windows computers, you can use the $300 version of the JW Player to play HLS streams on any computer with Flash installed. HLS does play natively on iOS devices, and natively, but with flaws, on the Android platform. That’s why it’s in orange. The approach most producers use for Android is to send a single MP4 file via HTML5 (the fallback to single file option), which is easy and cheap. Sure, it’s not adaptive, but it should play without any problem, and it is the best you can do without spending big bucks.
Distributing Video Content
Sep 15, 2014 9:37 AM, By Jan Ozer
Some video platforms for your customers to consider
Windows Phone doesn’t support HLS natively, so you’ll need an app if you want to distribute HLS to these phones. At this point, though, the Windows phone penetration is so low that most distributors simply ignore it. Finally, if you are targeting retail OTT platforms, HLS files play natively on virtually all of them; you’ll have to create a channel, but you won’t have to re-encode your files.
How much does it cost to support this option? In addition to the JW Player, you will have to create specially formatted files for HLS (and all technologies except for Flash – RTMP), but if you’re on the Mac, Apple Compressor can do this for $49.99. If you’re an iOS developer, which costs $100, you can also get a command line encoder, Media Stream Segmenter, which can create the files. Or you can use Sorenson Squeeze . And, as you’ll see below, you don’t need to be a programmer to use the JW Player; if you can embed a You- Tube video into a webpage, you can deploy the JW Player.
Looking at the other technologies, though both versions of Flash are supported natively on computers, you’ll need apps for iOS and Android, which will likely cost several times more than the cost of supporting HLS, and you’ll have to convince your target viewers to install the apps. Smooth Streaming is even iffy on computers because the penetration of the Silverlight Player is modest and shrinking. If you really want to use Smooth Streaming, you can spend the money to create a player that relies on the Flash plug-in to decode Smooth Streaming, but you’ll also need apps for iOS and Android devices.
Before we look at implementing HLS, I’ll describe one other solution. Rather than using HLS to serve all platforms, you can create one set of files in HLS or RTMP-Dynamic Streaming format and use a server such as the Wowza Streaming Engine to convert that to the different formats needed for the various platforms. This is called “transmuxing.”
Figure 5. Squeeze’s customizable templates make it easy toencode for HLS. Click here to see a larger image.
Transmuxing is a lightweight operation that involves changing the container format for each file, not re-encoding it, and creating the necessary metadata file. Products that support this function can perform it in realtime. Besides Wowza, the Adobe Media Server, Real Network’s Helix Server, and other servers and platforms can also transmux. Obviously, using this approach involves acquiring and configuring the server, which is almost certainly more expensive than the $300 you’ll spend for the JW Player, and you’ll need an encoding tool for either approach.
IMPLEMENTING HLS
To use HLS, you have to convert your source file into two types of files: media files in a special segmented format, and metadata files that tell the player the location of the various file iterations. The procedure for creating these files will depend upon the program that you use. I like Squeeze because it offers customizable HLS specific presets that really simplify the operation. You can see this in Figure 5, where I’ve customized the Sorenson template with the values from Apple TN2224. Just input your source file, apply the preset, press the magic Go button, and Squeeze does the rest. You can watch a YouTube video detailing this operation at bit.ly/Sqze_HLS.
Once you have the encoded segments and metadata files, you upload them to any web server and deploy them within the JW Player using the simple wizard shown in Figure 6. Identify the source .m3u8 manifest file, a poster image for the video, and a title. Then you configure your video player and get the embed code, which you paste into your webpage. You can see a YouTube video documenting this operation at bit.ly/JWP_HLS. In the video, you’ll also see how you can designate the single MP4 file to send to Android devices that click the link.
Figure 6. JW Player’s publish wizard makes it easy to publishyour HLS streams. Click here to see a larger image.
Apple Compressor can also serve the same purpose, though it’s not available on Windows computers, and the interface isn’t as mistake-proof. Similarly, JW Player isn’t the only off-the-shelf player enabling HLS playback on desktop computers, though it is a very prominent player and it makes it very simple to accomplish. You can also create a custom Flash Player yourself with this functionality.
Overall, the combination of the two appealed to me because they simplify an essentially complicated technical task. They deliver the bottom three rungs of the target market shown in Figure 1.
WHERE MPEG DASH FITS IN
What if you want to grab the whole enchilada, er, pyramid? That’s where things get complicated and expensive. Most of the devices in the top two rungs are built around DASH. To deploy on the platforms, you’ll have to develop a channel or the equivalent that uses DASH for playback, and you’ll need a DASH-enabled encoder. Again, Sorenson Squeeze has a single MPEG-DASH template, though the standard is so new that there hasn’t been a lot of interoperability testing. As a result, it’s unlikely that the template will work as is; you’ll likely have to tweak the parameters for each target playback device.
All that said, the vast majority of video producers have focused their efforts on grabbing viewers in the bottom two or three rungs. As you’ve seen, you can reach these simply and inexpensively with either single file delivery via HTML5, or adaptive streaming using Apple’s HLS.
