Choosing a Video Player: Features and Specs for the Top Five

The most important aspect of skinning is its responsiveness, or how the skinning model translates across all of the rendering modes of the player. The default OTS players shown in Figures 4–8 use the same graphics and styling specifications to render HTML5-based controls as well as Flash-based controls, with the exception of jplayer.org, which only presents an HTML control layer.

This parity means that a viewer sees the same player user interface from one browser to the next. The primary reason that controls need to be rendered by the plug-in rendering the video is that full screen playback from a plug-in will not work unless the command to initiate full screen is issued by a mouse click within the plug-in’s active area -- you cannot initiate full screen in Flash Player, for example, from a JavaScript event on a webpage. This security feature is by design, preventing any arbitrary action to make your browser content go into full-screen mode. (Think of the chaos that would ensue if any banner ad could go full screen without your intervention.)

Note: Many smartphone browsers won’t allow a custom player skin to be utilized, as video does not play “inline” on the page as it would on a desktop browser. Rather, the video opens full screen on the smartphone device, and the smartphone browser renders the control layer.

Cloud vs. Self-Hosted Code

When integrating a new video player into your content management system (CMS), you usually download the resource files of the OTS player and copy the files, including JavaScript, HTML, CSS, and skin files, to a location on your web server. Your site’s code then references those resource locations. Some OTS video player vendors offer their core player files (mainly the minified JavaScript source) on a shared public URL, usually hosted on a CDN or on a cloud-based network. Of the five OTS players discussed here, only Video.js and JW Player offer hosted versions of the player code. Even when the source is hosted elsewhere, you still need to put any customized CSS or skin files on your own web server.

Why is the distinction between cloud or self-hosted player code important? The primary benefit to hosting all of the player files on your own site is that you can be assured that the player will work as expected after you’ve integrated the player and tested the site on your target browsers. However, if a new browser release or update suddenly breaks the player code, it’s beholden on you to grab any updates to the player source code and fix your site. Alternatively, if you employ a cloud-hosted player, you will benefit from any updates and revisions to the player, which will automatically be inherited in your implementation. It’s true as well that such revisions could potentially break any customizations you’ve made. Either way, you will want to keep abreast of any player changes announced by the OTS player vendor you’ve selected.

Note: If your job is to deploy a selected OTS player across multiple sites and businesses, you may very well want to use a cloud-hosted version of an OTS player or create your own shared public URL for the player code you use. In this way, you can more easily maintain player code across a large number of sites.

MediaElement.js

Now part of the WordPress core codebase, MediaElement.js (mediaelementjs.com) is a popular open source video player, at version 2.13.1 as of this writing, started by John Dyer (@johndyer). This player’s code has been compartmentalized, available as a unified API to audio and video elements or to a player controller user interface, as well as an “all-in-one” API with controller.

One of the unique aspects of MediaElement.js is that it features both Silverlight and Flash renderers, in addition to HTML5. So, for standard HTTP delivery (range request or progressive download), MediaElement.js can cover nearly every mobile and desktop target, including Windows Phone. The Silverlight renderer can also enable video formats such as WMV and WMA on desktop browsers. MediaElement.js also provides support for a <track> tag to provide captions. For live streaming content, you can use RTMP (via Flash) and HLS (via HTML5 where supported). However, it doesn’t yet have adaptive RTMP, Smooth Streaming, or Adobe HDS playback.

Video.js

Developed by Steve Heffernan (@heff), the co-founder of Zencoder.com, Video.js (videojs.com) is an open source video player that provides a quick and easy way to deploy video content via its cloud-hosted player codebase and CSS styles. From the homepage, you can customize the colors of the player user interface (UI) and get the embed code for your own webpages. Just edit the URLs to the poster image, video sources, and the dimensions, and you have a player ready to go.

More impressively, you can customize a player with the “designer” at designer.videojs.com. The player is also available as a WordPress plug-in. The player supports a wide range of options, from closed captions and subtitles to chapters. The 4.3.0 release now supports 26 plug-ins that enhance its capabilities. I’m incredibly impressed by the sheer volume of clear and precise documentation for this free player that Steve and his contributors have provided on github.com. (I’m not fond of the label “plug-in” in the Video.js lexicon. Specifically, its plug-ins are additional JavaScript modules that extend the feature set of the player.)

The Video.js player can handle stream URLs delivered by RTMP and HLS as of version 4.2.0, but its UI hasn’t yet been updated to automatically handle live streams (e.g., live streams don’t require a seek bar). Adaptive RTMP and HDS manifests are not compatible with this player.

jPlayer

jPlayer 2.5.0 (jplayer.org) -- not to be confused with JW Player, discussed next -- is a jQuery-based video player built as an open source project started by Happyworm, an Italian web agency. I first discovered jPlayer when seeking a simple video player that I could quickly use for demonstration purposes. For web developers looking to build their own control layers, jPlayer can get you up and running with a chromeless video player. (It also includes its own control layer if desired, but the graphics are not as polished as other OTS players.)

The jPlayer codebase relies exclusively on an HTML-based control layer. As such, any Flash-based rendering requires an HTML5 browser that has the full screen API available to view video in full-screen. So, for example, Internet Explorer 8 would not be able to view videos in full screen mode, as it lacks HTML5 capabilities. jPlayer can play RTMP and HLS streams, but it cannot play adaptive RTMP or HDS streams.

JW Player

By far one of the most popular video players since the advent of Flash video, JW Player (jwplayer.com) is perhaps the most widely used OTS player. The JW stands for Jeroen Wijering (@jeroenw), the creator of the player. Now in its sixth major release, JW Player showcases its Flash roots by enabling a powerful set of features in HTML5. As a media server developer, I’m a big fan of JW Player’s support of adaptive streaming manifest support. It can ingest live and VOD streams in adaptive RTMP and HLS, as well as render HLS streams via Flash for browsers that don’t natively support HLS. Wowza Media Server, for example, can provide JW Player SMIL manifests for live and VOD content delivered over RTMP.

Live streaming to Android is still problematic -- regardless of the OTS player -- but JW Player enables you to disable the fallback support and render an alternate HTML display for Android. For example, instead of seeing a full-featured video player on Android, you can direct JW Player to load an alternate display (such as a poster frame) that links to an RTSP stream playable in an external media player. While JW Player 6 does not natively support Adobe HDS playback, Akamai has built a module for JW Player that enables HDS playback through their CDN services. Therefore, if you’re using Akamai, you can deliver VOD and live streams via HLS and HDS to JW Player.

Unlike the free or open source OTS players discussed here, JW Player requires a commercial license (noncommercial usage is free). This fee is now issued as an annual subscription and no longer available as a one-time upfront license. HLS playback in Flash is only available as a feature in the more expensive Premium subscription, at $299 per year. The Premium subscription also enables you to use the player on 10 different web domains, and it can support external Google Analytics data gathering. For a player on just one site, you can opt for the Pro subscription at only $99 per year, but you lose the HLS rendering in Flash feature.

Flowplayer

Flowplayer (flowplayer.org) shares many characteristics with JW Player. Flowplayer originally started as a Flash video player, but it now has an HTML5 version of the product. Flowplayer still sells the Flash-only video player on its site, but the HTML5 version features a Flash fallback renderer that can be stylishly configured on its site with the “Designer” link.

One of the interesting features I’ve found is the splash screen, which enables the player to only display the poster frame and not fully initialize the HTML5 or Flash rendering mode. I find this mode useful for players that use time-stamped secure signed URLs with a CDN such as Amazon CloudFront. You can then generate the video URL(s) when the user initiates playback.

RTMP and HLS streaming is supported in Flowplayer, but adaptive RTMP and HDS are not. There is a commercial license required, payable as a one-time fee for perpetual use starting at $99.

Moving Forward

Any of these players provide a working solution to a wide range of online video content. The more specialty features you need, the more likely you’ll end up picking a license-based player. There’s still plenty of room for improvement in the OTS player market, especially for better playback over mobile networks using adaptive streaming. I’d also like to see better cascading support for priority formats. For example, most OTS players allow you to pick a preferred rendering mode (HTML5 or Flash), a priority in formats (MP4 over WebM), and even a priority in protocols (RTMP, HLS, and then HTTP). But, being able to specify a complex matrix combining all three priorities is difficult if not impossible. If, for example, I wanted to designate adaptive RTMP (Flash) as the top priority, followed by Apple HLS (HTML5), followed by an HTTP-delivered H.264 Main profile MP4 (HTML5), and then ending with an HTTP-delivered H.264 Baseline profile MP4 (HTML5), I’d be hard-pressed to find an OTS player to do it.

Every project has a unique set of priorities and constraints, but with a wide range of players to use, you will likely find one that will meet your needs. Start with a clear understanding based on the four primary questions of content, features, pipeline, and business. If you’ve read this far, you’ll probably agree that there’s no such thing as “just press play” for a solutions architect. If we do our job right, that’s all our audiences will have to do, no matter their platform or browser.

This article appears in January/February 2014 issue of Streaming Media magazine as "Press Play: Video Players That Just Work."

Video player image via Shutterstock.

How to Create Interactive HTML5 Video

Turning a basic HTML5 video player into one with enhanced playback features is surprisingly simple. Here's the code to add chapter markers, captions, and more.

05 Jun 2014