As an online video provider, your player is a huge part of your product. It facilitates and enhances the user experience, and like a good basketball referee, if it does a good job, no-one thinks about it. If it does a bad job, then the complaints will never end.
With the recent developments in HTML5 and a universal move away from Flash and other third party plugins, we have seen some big steps towards improving cross-browser compatibility. In fact, with these improvements, specifically in HTML5 video browser support, when it comes to simply playing a video, it has never been easier. In a few lines of code, the <video> tag will allow you to play a video in every major browser and across almost every platform.
The problem is that there is a lot more to playing a video than just,… well, making it play…
But at the same time video has become easier, the industry around it has become more complicated and the peripheral requirements for delivering video have increased both in number and in complexity. Consumers have come to expect higher and higher quality video, advertising has become more complex, content creators have demanded better protection and regulators have demanded better accessibility).
Minimum requirements and feature list for a modern HTML5 Video Player
With all of the demands on your video platform, the list of requirements that your player needs to meet is growing, and the solutions that need to be implemented can require a considerable investment in time and money, not only in development, but also in ongoing QA testing and maintenance. The following paragraphs will take you through anatomy of an HTML5 player, and discuss some of the challenges you will face as you build it.
As the title of this blog post suggests, HTML5 is not optional. The days of forcing the viewer to download plugins is well and truly over. HTML5 is the environment in which your video player will operate, and it will form the building blocks of your player.
Adaptive Streaming in an HTML5 Player
Arguably the largest contributing factor to the recent growth of online video has been the adoption of adaptive streaming technologies. Adaptive Streaming has greatly improved the online video experience by allowing each individual device to control the size and bitrate of the video it streams. The result has been videos that play smoothly without interruptions or “buffering”.
In 2012 the MPEG-DASH standard was published as ISO/IEC 23009-1:2012 by the Moving Pictures Expert Group. Many of the world’s leading experts in adaptive streaming technology contributed to the project, including Bitmovin, and it’s release has greatly accelerated the uptake of online video by making adaptive video much more accessible. Netflix and Youtube were amongst the first to exploit this new standard.
The technology that allows a website to play an adaptive video is broken into two parts. The first are the video files themselves, which are created by your encoding service. The second is the adaptive logic that is built into your video player. This adaptive logic can be written in a variety of different ways to achieve the same goal, but the basic function is as follows:
- Monitor the rate at which the video is being downloaded to the player.
- If the video is coming down too slowly, switch to a smaller video file to avoid buffering.
- If the video is coming down too fast, switch to a larger video file to improve the quality.
A well coded player will keep the video playing regardless of the user’s internet connection or screen size. This can be achieved by monitoring the download speed or by monitoring the size of the buffer. The Bitmovin Player uses the latter because it has proven much more reliable.
Branding and styling the interface
Your video player is likely to be the most important touch point with your customer and as such, it needs to represent your brand. Furthermore it will need to have a skin that can be updated when required, either with a logo revision, or colour changes, or even a special promotion. These updates require control over the colours, icons, fonts, as well as the way the control panels behave as they are adjusted.
Over the last few years accessibility regulations have become tighter in many countries, and this has driven the need to create more comprehensive player skins, to provide more control to users. Multi-language, subtitles, Closed Captioning and 360° video settings are just a few of the functions that your player’s skin will need to accommodate to serve a US or international market.
Advertising is a very important part of online video. Whether you are generating revenue by displaying ads, or just advertising your other videos, the ability to integrate a variety of advertising options is a must. Pre- roll, mid-roll, post roll and interactive ads with the option for a “skip ad” button are very common at the moment. In the future there are likely to be new trends that your player will need to support to keep your business competitive.
Depending on your business model, your player might need to support a number of advertising standards such as VAST and VPAID. This will require both backend integration and front end design to display the various outputs and options that these systems can generate.
DRM and multi DRM
Digital Rights Management (DRM) has become a large part of the video landscape because it is required by just about every major content provider. One of the biggest challenges in DRM is that there is very little standardization between the different browsers.
To deliver MPEG-DASH and HLS adaptive video to every browser, you will need to encode your video with multi-DRM encryption using a combination of technologies such as; Google Widevine, Microsoft PlayReady, Adobe Primetime, AES-128 or Apple FairPlay. Before playback, your player will need to de-encrypt those files by exchanging license keys with your DRM provider.
Luckily this process has been somewhat simplified by a number of DRM providers who are offering services that combine multiple DRM technologies on the license server side, but your player will still need to be aware of the different DRM systems, check what’s supported in the current browser, choose the right system, communicate the license service in the DRM system-specific protocol, accept those keys and run the decryption for each technology.
The main challenge here will be maintenance. With so many DRM technologies required to deliver complete browser coverage, keeping them all up to date is a challenge, and will be a considerable part of the budget you will need allocate to your player team. (WEBINAR: DRM Basics with Irdeto & Bitmovin)
CC, Subtitles and languages (multi-audio)
Many online videos support closed captioning, subtitles or offer multiple languages. This is being driven in part by accessibility laws, and in part by user demand. In the vast majority of cases, a new online video player should support all three. The solutions behind achieving these important features revolve around your player having the ability to switch between audio tracks in the case of multiple languages, and for subtitle and closed captions, support for reading, synchronising with and switching between a data stream such as CEA-608/708 or other closed captioning standards.
These systems are already fairly well established and documented, so once they are set up, they will not require maintenance to the same level as DRM, but browser updates will always need monitoring and testing.
As a commercial enterprise, or even as a well run community or volunteer organization, you need to give some thought to how you are going to guide your business, at least to some extend, by the feedback you get from your customers. One of the easiest ways to do this is to implement a good analytics system into your player, so you can see how and where your product is being viewed.
Analytics can be implemented via a number of third party systems, or you could attempt to build your own. As a minimum you should be able to see the browser and operating system that your visitors are using, and a good analytics system will provide geo location, average play times,information about the video profiles that are being played and more.
A comprehensive analytics system will become an invaluable part of your business planning. It will help you to keep your customers happy and also give you the information you need to optimize your encoding stack and reduce costs.
To create a genuinely manageable solution, your player will need an API. Some of the benefits of an API include speeding up the implementation of front end features, simplifying your project by providing a framework for future development.
Cool features like thumbnail seeking
There are a number of other features that you should consider implementing just to keep up with modern standards. Thumbnail seeking is close to the top of this list because it provides such a visual and useful method for searching through a video files.
Some other features that you might consider include:
- Google ChromeCast and Apple AirPlay support
- Variable playback speeds
VR and 360° controls, and whatever comes next
VR and 360° video is a fast growing industry, so supporting the basic stereo and mono 360° settings are advisable, but it is still such a young technology that it is hard to tell which direction the industry might go. 360° video may well drive us down a new branch of encoding technology, which in turn could force us all the rebuild or at least modify our video players.
VR and 360° is the hot topic at the moment, but there are many facets behind the technology of video, as outlined in the paragraphs above. Anyone of them could be revolutionized at any minute, so the future proofing of your video player will require constant monitoring of trends, and a team with the depth of knowledge to keep you cutting edge.
As mentioned at the beginning of the article, browsers are generally getting better at supporting HTML5, so in some regards things are getting easier, but there are a lot of components in your player that are not built in HTML.
Every browser release poses a threat to your players ability to function, which in turn creates the potential to lose customers. Part of maintaining your own HTML5 player is constant testing. To make this easier, all of the major browsers provide pre-release beta versions that allow you to stay ahead of the game. By being vigilant it is possible to avoid train wrecks, but it requires a lot of regular work, and resources will need to be committed to this process.
Here are links to the pre-release browser versions for two of the major browsers. These packages can be used to test your player before the next release of each browser.
Cross-browser streaming technologies
A player that can play MPEG-DASH and HLS can deliver complete browser support across all devices, so these two technologies are the two that I would suggest you plan to support.
Another recent announcement from Apple has made it possible to play fragmented MP4 in HLS. This opens up the possibility of encoding your videos into Fragmented MP4 and simply offering the two manifest files, DASH and HLS to achieve complete coverage. This option could theoretically half your encoding costs by removing the need to encode into HLS.
Using an Open Source HTML5 Player
Using an open source player can offer you a huge shortcut to getting your player up and running. In most cases you start with a working product, and in a best case scenario, you have a team of developers keeping it up to date for you. If you are a community organisation, or have a group of volunteers or students driving your development team, then it might be a perfect fit, as it will provide a central code base and help you to deal with the likelihood of needing to find new developers on a regular basis.
As a commercial enterprise, there are some major pitfalls, and I would strongly recommend against attempting to build a business on an open source player. I will explain my reasoning below.
Open source should be an all or nothing decision
Open source, all the way or not at all
If you are going down the open source path, then you need to go all the way, meaning that you become a contributor to the project. As you modify your player and add to the code base, you should feed your work back into the project. Apart from the good karma, this will hopefully ensure that your work will be supported by future updates in the open source player project.
On the other hand, if you take an open source project and work on it in isolation (I.e. do not feed your work back into the project), there is the likelihood that the open source project eventually creates an update leaves you with features, or even an entire player that is no longer compatible with the core project. This can leave you open to security vulnerabilities and errors that may be very difficult to troubleshoot.
If you decide to contribute your changes back, it is still possible that the community rejects your updates because it wants to move in a different direction. If this happens, it will result in rejected pull requests and you will be forced to choose between sticking with your code or reverting to a solution that works within the communities code. Depending on your choice at this point, you will either waste a lot of development time, or move to an unsupported situation and probably need to increase the size of your development team.
Maintaining the systems
Once the system is build, maintenance and enhancements are going to be the name of the game. Each of the components that I have mentioned above will require constant monitoring and regular updates, some much more often than others. The QA / testing process is a very resource intensive part of the process, and
DRM for example is one of the more complicated parts of the puzzle because it has a lot of different technologies, and to be completely cross-browser compatible, you need to be using several systems. Other components, such as ad servers tend to change when new ad technologies are developed. Interactive ads are all the rage at the moment, and when they hit the market, every commercial player on the market rushed to develop a solution to support it.
At this time in history, online video is one of the fastest moving industries on the web. We are a long way from settling into a standard set of technologies, so building a commercial online video player is an enormous endeavour, that will require a considerable investment.
Outsourcing your HTML5 Player – Fixed costs vs cost per sale
For the majority of business models this is by far the most cost effective solution. An externally hosted player will charge on impressions. As your customer base grows, you will generate more revenue via ads or subscriptions. This aligns your expenditure with your revenue, so you can easily predict and manage your cash flow. It effectively replaces your fixed costs with a “cost per sale” equation.
Find out more about removing the costs of Player development and improving the quality of your HTML5 Player and Customer experience by contacting our team for a demonstration or by testing our player with a fully featured free plan.
You might be also interested in one of the following articles:
- HTML5 Guide for Broadcasters: DRM and Advertising in a Flash-Less World
- HTML5 Video Player – Build vs Open Source vs Hosted