Finding a Video Player That Works for You and Your Budget
In January 2014, I wrote an article covering five “off-the-shelf" (or OTS) video players that I came across most frequently in my work with clients. Fast-forward to 2018, and it’s amazing to see how the player landscape has evolved, particularly with mobile app development. Four years ago, many vendors were just starting to build their software development kits (SDKs) for iOS and Android development. While this article addresses web players, player technology continues to evolve for multiple targets. As I mentioned in my original coverage, it is still challenging to find a video player that meets specific technical and business requirements, particularly if you’re looking for a low (or no)-cost player implementation.
In this article, I’ll guide you through the questions you should contemplate before you can select a player, and then I’ll review the following players, which many of my clients and collaborators have deployed in their production environments:
Of this list of six, only two are licence-free: MediaElement.js and Video.js. There are many other licence-free player libraries on the market that you can implement into your own custom players, but they won’t likely be as OTS as these are. Many, like Google’s own Shaka.js framework, provide application programming interface (API) hooks that require you to build your own skinning and UI controls to the player.
Perhaps the biggest change to the player offerings since my last review is the absence of and/or dependence on Flash for rendering video. With the advent of Media Source Extensions (MSE) within browser tech stacks, nearly all use cases of video playback can be rendered without the help of Flash. If you’re targeting older browser stacks (pre-Internet Explorer 11 for example), then you should confirm that your OTS player of choice will render your content in legacy browsers.
Another significant change in the player market over the last several years is that all of the major vendors require ongoing subscriptions to their premium players. Gone are the days of buy-once, play-forever with most of the commercial vendors discussed here. Flowplayer is the only exception; it still offers a flat purchase for the self-hosted player. There’s good reason for annual subscriptions: the browser landscape is still evolving, and staying on top of each browser’s implementations (or not) requires resources. What’s increasingly concerning is the monitoring of your player use by commercial vendors; more than a few of my clients have complained that OTS player vendors are wanting to increase subscription rates based on revenue models and/ or usage. If you decide to try any commercial vendor’s player product, be direct with your business strategy and growth plans, and don’t be shy to ask how your subscription may (or may not) change based on how successful your business is. I find it astonishing that many vendors are establishing their role as a silent partner in your business, and with little or no risk on their end.
In my role as video solutions architect, I use JW Player most frequently with my clients, and the reason is a combination of my long history of using the product as well as its popularity. However, there are different features and limitations of each of these products, and a rushed decision to use an OTS player could end up costing you down the line.
Hosted video services such as YouTube, Vimeo, Brightcove, Kaltura, and Ooyala are also not covered in this article. I also did not include players that require specific server implementations or licensing, such as nanoStream, Wowza Player, or any ultra low latency (ULL) player.
Know Your Requirements
When a client engages me to architect a new video player implementation project, a discovery process is invaluable to create the discussions and decisions that will define the optimal viewing experience and to determine the supporting elements of content delivery. These four primary questions will help steer you toward choosing the right player:
- Content: what is the nature of your video?
- Features: what does your player need to do?
- Pipeline: how is your video encoded and deployed?
- Business: what is your budget and timeline?
CONTENT
If you’re a subscriber to this magazine, chances are, you’re working with two types of video content: video on demand (VOD) and live. As you’ve likely experienced since my last coverage, HTML5 web browsers do not consistently handle all of the formats and codecs used to deliver these types of video. Regardless of your player choice, you will likely want to keep your deployed video formats to a minimum. In the past, I have recommended delivering your content in at least two formats to reach more viewers on more devices, but as Apple continues to dictate many choices for my clients, the format with the widest appeal with a wide range of options is HTTP Live Streaming, or HLS. When Flash integration wasn’t as security-ridden as it is now, I often configured RTMP fallback for Flash. Picking video formats is largely a matter of the important targets you want to reach. Figures 1 and 2 illustrate the popular codecs and formats available for online video playback, as well as the support offered by the players covered in this article. As player codebases continually evolve, remember to check each vendor’s support matrix on the respective websites.
Browser and player support for HTTP delivery
Player support for HTTP streaming delivery
Most online video is deployed in some VOD packaging. Each player discussed in this article can play VOD content served as a progressive download over HTTP (content playback can begin when a small buffer has downloaded, without requiring the entire video file to download) or as a byte range request. All current HTML5 browsers can use a range request, in which the browser requests specific fragments of the video file, enabling the player to seek any part of the video and to resume playback very quickly. With respect to live content, the addition of Media Source Extensions (MSE) and Encrypted Media Extensions (EME) has finally given more current browsers the ability to use non-HLS streaming formats such as Dynamic Adaptive Streaming over HTTP (DASH) and Common Media Application Format (CMAF) to flourish.
Low-latency live streams are typically served with RTMP (real-time messaging protocol) or RTSP (real-time streaming protocol) to native smartphone applications, but most offerings for browser-based low latency revolve around modified CMAF or HLS delivery that uses much smaller fragments for faster round-trip times. WebRTC (Web Real-Time Communication) solutions are slowly making more headway in the low-latency live-streaming space, but a consistent WebRTC stack is lacking from one browser to the next. Many media servers, such as Wowza Streaming Engine and Red5 Server, can transmux live streams in more than one format from the same source ingest.
On mobile devices, Apple HLS is the only consistently supported streaming format for live or VOD content. HLS works very well on iOS and usually has no issues on the Android. Because Android’s browser stack is not as limited as Apple’s (browser vendors can deploy their own internals for browser rendering), DASH and now CMAF are gaining traction for streamed content on Android. In my original article, I predicted that MPEG-DASH would likely be the future deployment option for live streaming on Android, and that largely is now the case: the majority of desktop browser and non-Apple mobile browsers support MSE/EME, which means they can support DASH.
FEATURES
The next consideration for choosing an OTS player is making sure it can perform all of the functions you need for your video content. All of the players featured in this article can perform the following tasks:
- Basic playback, including play/pause, seek, and time display
- Poster frame
- Volume control
- Normal and full-screen display
- Skinning via CSS and custom images
- Responsive layout for consistent relative player size
- Casting to OTT devices (Chromecast, AirPlay)
However, not all OTS players will offer the following features, or they may charge additional licensing fees for them:
- Closed captions/subtitles
- Multilingual audio track selection
- Playlists
- Ad insertion
- Watermark/overlay
- VR/360° playback
PIPELINE
The third area of discovery is an examination of your existing video deployment process, looking specifically at how you are encoding and delivering your video formats. Ideally, the OTS player you choose will work with your existing infrastructure, but in some cases, you may need to modify that infrastructure to work with the OTS player.
For example, if you’re only offering promotional video content, or any type of video content that can be freely distributed (e.g., product support videos, informational content), you’re encoding all of your content with a single high-quality bitrate AVC/H.264 MP4 preset, and you’re hosting all of your content on a web server or Amazon AWS S3, so you’ll likely have a wide range of OTS players to use. Every player discussed at the end of this article will work in this scenario.
However, if you’re encoding multiple bitrates for adaptive streaming delivery via HLS, and you’re using a CDN such as Akamai, you may want to use a premium licensed OTS player such as Bitmovin, Flowplayer, JW Player, or THEOplayer.
Likewise, if you’re using any specialty protocols such as RTMP for live streaming, you’ll need to make sure that the OTS player supports the delivery mechanism. Just because an OTS player has a Flash fallback does not mean it can necessarily play RTMP video or ingest an adaptive streaming manifest specifying RTMP streams. Wowza Streaming Engine, for example, can take multiple bitrates of a given video and provide manifests using RTMP, HLS, and DASH formats. Every commercial player discussed here can support one or more of those formats.
BUSINESS
As someone investigating OTS players, one or both of these is likely true: you don’t have the resources or budget to build a custom video player from scratch, or you’re curious if you’re paying too much for a custom video player when an OTS player will suffice. As many of the OTS players featured here are available at prices that most companies can consider, you may find the premium OTS players are worth the annual subscription price.
When you are evaluating premium OTS players against those that don’t require a licensing fee, remember the price versus cost paradigm. Sure, a free player might be able to get you 90 percent of the features you need, but if you’re spending more time and money to finesse that free player to gain 100 percent of the features (and perhaps to a degree below that of a premium player), the result may end up costing you more. The lack of specific skin customisations in a player could also damage your branding efforts. You also have to be prepared to fund ongoing updates to your player stack as new browser developments related to video delivery emerge, as well as to address any customer-reported bugs in your own custom player.
Finally, consider the time and resources necessary to transition from your existing video player to something new. For example, if an OTS player is initialised with a JavaScript Object Notation (JSON)-like data schema, you’ll likely need to make changes to the underlying content management system (CMS). If such a change is necessary, hopefully the parameters that you use for one player can be easily mapped to another player’s parameters.
Evaluating OTS Players
With your requirements defined, you’re ready to look for an OTS player to match your needs. As I’ve mentioned, there is a wide and growing field of player codebases available; this article only covers some of the more popular options. I have performed tests with each of these players, and I would recommend them for a wide range of use cases. I’ve compiled several examples illustrating the usage of the featured OTS players at videorx.com/players.
BASICS OF AN OTS PLAYER
Now, let’s review the standard nuts and bolts that you can expect to see in each of the six OTS players covered here, including format specification, rendering mode, skinning options, and cloud vs. self-hosted code.
Specifying Formats
Each OTS player I’ve included here has the ability to ingest multiple video codecs, including AVC/H.264 and VP8, as well as their respective video formats, MP4 and WebM. The players can also use standard HTML5 <video> and <source> tags to indicate each of the formats you have available for any given piece of video referenced in your code, such as the following:
<video width=”640” height=”360”>
<source src=”sample.mp4” type=”video/mp4”> <source src=”sample.webm” type=”video/webm”> </video>