Need to Get the Message Out to a Variety of Viewers? Read On...
Whether desk-bound or mobile, Android or Apple, laptop or tablet, your end-user community demands quality viewing of your content on every screen. But how do you guarantee equal delivery to all?
Over the past year, a number of technologies have been honed, tweaked, and updated to deliver streaming content to almost every current smartphone, tablet, desktop, laptop, and in-flight entertainment screen you or your users come into contact with.
Okay, maybe we’re stretching it a bit to suggest you’ll be able to stream your content to a plane’s IFE on your next cross-country flight, but here are five key points to consider as you move towards on-screen ubiquity of delivery.
1. Use H.264
Today’s best-known, most widely-used compression scheme goes by three names: Advance Video Coding (AVC), H.264, and MPEG-4 Part 10. Regardless of the name used—and whether it’s used for videoconferencing, Bluray Disc deliver, or even just for simple streaming—this all-purpose codec can scale from low-bandwidth mobile viewing to higher-end 720p and 1080p delivery.
H.264 comes in a three standard profiles (Baseline, Main, High) each having benefits and drawbacks for particular use cases. However, it’s much easier to sort through which profile to use than to decide between H.264 and another codec for delivery ubiquity.
Born of a videoconferencing heritage, H.264 is equally at home in today’s multi-screen world, powering everything from over-the-air (OTA) broadcast to the latest iPhone’s video player.
2. Use MP4
If H.264 is the codec of choice, what’s the file container format of choice to house the streaming file?
I’d love to say MP4 and stop there. Unfortunately it’s not that simple today, but wait about 18 months and I suspect we’ll find that MP4 is the single file container format that engulfs all others. After all, MP4 has been around for a decade, was championed first by Apple and is the basis for everything from movies you download from the iTunes store to the Netflix hits you watch on your living room set-top box.
While it would be ideal to have every version of a streaming file in your content library emanate from one master MP4 mezzanine file, it’s not always possible to do so, for two major reasons.
One reason is the size difference and aspect ratio difference of end-user delivery screens. There’s an (almost) exhaustive list of pixel sizes and aspect ratios, ranging from 160x120 all the way up to Ultra 4K (3840x2160). The list runs into the hundreds of options.
The other reason is that some servers, including well-known streaming servers such as Adobe Media Server (once called Flash Media Server), rely on different file container formats to stream their content. AMS uses the F4V extension, which contains the same file structure as an MP4 file but other servers don’t know what to do with the proprietary F4V extension. The good news is that AMS understands an MP4 file structure, so MP4 is my choice for storage of mezzanine files.
3. Pick a delivery protocol
We’ll dive into this more deeply in AV Technology’s next issue’s article titled “MANAGE, PUBLISH, DISTRIBUTE: A Primer for Tech Managers,” but the quick version is that you have the choice of one proprietary or two standards-based streaming protocols.
The proprietary one has been partially released for open-source use, although you’d not know that to be the case from a court battle being waged between the two most popular streaming server companies. The standards-based solutions are RTSP (Real-Time Streaming Protocol) and HTTP (Hypertext Transport Protocol).
The latter should sound familiar, as it’s the core transport protocol for web pages, even on those “plain vanilla” servers run using Linux and Apache. HTTP is very good for two reasons, the least of which is the lower cost of using an HTTP-equipped server to stream content through port 80, thereby eliminating firewall issues that plagued legacy streaming servers and protocols. The other compelling reason is the fact that HTTP servers are designed to serve up a variety of content in little chunks, rather than deal with one big continuous file.
There is an art and science to streaming flawlessimages to every screen.While that might seem odd to recommend the use a single MP4 file to serve from, it turns out to be a blessing in disguise, for a reason we’ll tackle in next month’s “Primer” article.
What about RTSP? Here it my take, simply put: Do not use RTSP for multi-screen, multi-platform delivery. It doesn’t work consistently across platforms, and anyone who tells you otherwise is selling something. Five years of white papers and countless tests back up this statement, almost all of which are available for public viewing.
4. Adapt to your user’s bandwidth
HTTP serves up a long MP4 file that has been segmented on-the-fly into as a series of small (2-10 second) transactions, just the kind of thing an HTTP server does well. Most Apple products require the MP4 file to be segmented (aka fragmented, chunked) beforehand into thousands or tens of thousands of small files, but newer HTTP stream protocols eliminate that need.
As long as the segmentation contains the exact same content in at least three different bitrates, these small segments can be served up in sequential order at any of the pre-defined bitrate. The use of multiple bitrates allows your content to adapt to your user’s current bandwidth, ideally eliminating buffering by keeping the content flowing. Viewers who are on a quality network connection see the best quality, while those who are on a mid- or lower-quality connection see middling or lower quality, respectively.
Choose an ABR scheme that’s best suited to your audience’s most ubiquitous devices or use a media server to create ABR-based content across multiple ABR schemes.
5. Consider Flash (Player)
Flash is dead! Long live Flash! Various articles on the topic of Flash say contradictory things, so keep this in mind: The Flash Player is not dead even though proprietary Flash content is on its way out.
Adobe realized it couldn’t keep up with mass fragmentation (no pun) in the Android handset market; Apple wasn’t going to let Flash Player anywhere near the iOS triumvirate of iPads, iPhones, and iPod touch devices. Adobe thus shifted gears to work within the browser on Android devices.
We’ll cover all the new ABR schemes in next month’s article—from HLS to DASH—but for now just know that every test we’ve done where Flash Player is used, whether on a mobile device via the browser or a stand-alone app, the results using the underlying Flash Player architecture are much more consistent. Oh, and it’s also the most consistent way to view RTSP (if you absolutely must use it).
The Bottom Line
What’s the main takeaway? Using the H.264 codec, housed in an MP4 container file format, delivered via HTTP, using adaptive bitrate via a robust player (or players) will get you close to the goal of ubiquitous delivery to all your end-users’ mobile, desktop, and living room screens. Happy streaming.
Tim Siglin covers AV and streaming media trends for Streaming Media and AV Technology magazine.
