Experience HLS Live and VoD 360º playback on all devices and monetize your content more efficiently with server side ad insertion, in Bitmovin’s 7th major player release. A new skin with new possibilities for customization, improved performance and the possibility to apply custom adaptation decisions, make our HTML5 Player version 7 faster and more versatile than ever!
The Bitmovin team has worked hard in the past few months and, based on customer feedback, have built a lot of minor and major features that have now been integrated into the Player 7 release. Among the most exciting updates are four new major features, VR/360 playback on iOS with HLS for Live and VoD, server side ad insertion, custom adaptation logic and a complete new customizable skin.
VR/360º Live and VoD Streaming on iOS with HLS
360° and VR streaming has received a lot of attention this year but the technology, as well as the workflows are still in their infancy. Most 360° videos are still delivered through progressive download or RTMP, which is especially painful as 360° videos typically have high resolutions like 4K, as well as high bitrates. 20Mbps and higher is not uncommon. What you usually get is a download and play experience because the videos are slow to start due to the high bitrate. This causes them to buffer very frequently, so most of the time you would simply wait until the video is loaded completely (download) and play it afterwards. That’s obviously a long way from the streaming experience that we have come accustomed to from Netflix and YouTube, as both use adaptive streaming technologies like MPEG-DASH and HLS to deliver their high quality videos. Unfortunately, that is not so easy for 360 videos. They need special treatment on the client side as the equirectangular frame (shown in the figure below) needs to be transformed into an immersive view. This is especially tricky on iOS which only supports HLS, but the Bitmovin team has solved that problem, and because we support HLS and MPEG-DASH you can now stream your 360 videos with Netflix quality to all major devices and platforms.
To achieve a smooth and steady playback of VR and 360º content, we utilize the browser’s built-in HTML5 Media Source Extensions (MSE), or its native video capabilities (e.g., for iOS). However, the player will detect and automatically choose which streaming technology and configuration works best. Besides the different rendering modes, for desktop, mobile and VR headsets, additional parameters, like the start position, or an initial rotation can be set via the HTML5 player configuration. How to enable VR and 360º playback, as well as more detailed information on which content can be used and how it should be encoded, can be found in our end-to-end VR & 360° Video tutorial.
Prevent your Ads from Getting Blocked, using Server-Side Ad Insertion
Monetizing content via advertising is a common tactic in today’s online video streaming industry. The list of abbreviations and acronyms in this area are as long as they are obscure: VAST 3.0, VPAID 2.0, IMA, VMAP, to name just a few. Depending on the level of interactivity required, one can choose the standard that fit’s the targeted use-case best. All the specifications listed above are well supported in our player and are described in the related tutorial, setting up Ads with our player is easy to do.
Considering there is already such a large choice in advertising standards, is there really a need for yet another approach?
The simple answer to this question is: Yes. Without going into too much detail, nowadays most commonly used standards share one major disadvantage: They can be detected and blocked by the client. Although ad providers have come a long way in skillfully disguising ad content, the ongoing race between them and the manufacturer of ad-blockers has given content publishers many sleepless nights. From their perspective every unplayed ad corresponds to a potentially loss of ad-driven revenue. Keeping in mind that the usage of ad-blocking software is not limited to a small number of geeks (anymore), but is increasingly utilized by “normal” users, this can be a big threat for ad driven businesses.
In contrast to the approaches mentioned above, which stitch together the ad and non-ad content on the client side, server side ad insertion intercalates ads on a CMS level. Therefore the client receives a continuous stream with a smooth and broadcast like transition between ad and content video. In practice this can be done using mechanisms called Multi-Period and Discontinuities in adaptive streaming technologies, like MPEG-DASH and HLS. These concepts enable you to split up one stream into different parts (called periods), e.g., ad and non-ad content. Our most recent player version is capable of interpreting such periods and plays different content types in a smooth manner without visual transitions.
New Skinning Possibilities and Performance Improvements
Much like the smell of a (good) wine, the skin is the first impression a user gets from the player. But the player user interface has to be more than “just” good looking. It should be intuitive and enable interaction in a simple manner. Usually more functions than play/pause are needed. Besides simple things, like seeking or time-shifting and changing the volume, subtitles and multi-audio selection or playback speed may be required. For a modern online video player, there are many feature requirements. Another challenge is multi-device compatibility and consistency, in other words, the player has to look (and “feel”) the same on different devices, such as desktop, mobile, TVs, etc. As discussed in our post on building a modern HTML5 video player, all these aspects need to be considered when choosing the right player.
Within our new v7.0 release we have made several major changes regarding skinning. First, and maybe most prominently, the default user interface has been changed. The new and open source available skin, does not only have a fresh look, it also comes with various enhancements and additional features, like a recommendation screen, title and asset information placeholders, a playback speed control and many more. But the changes are more than just visual. The new skin is entirely built using TypeScript.
Not only has the user interface received a major update but the core player has also been refactored to some extent, with low startup delay and performance improvements in mind. In this regard we have been able to reduce the time between hitting the play button and when the first frame of the video is displayed (startup time) by another 250ms. This is especially important, because with each incremental delay of 1 second the abandonment rate increases by 5.8%.
There has also been a change in the basic structure of the player framework itself. Up until now, the player bundle included five physical files (neglecting the two files related to the skin). The bitmovinplayer(.min.js) – loaded first – and was responsible to check device and browser capabilities, user configuration, etc. to decide which player (HTML5/JS based or Flash), as well as which plugins (e.g., VR) need to be loaded. Due to the ongoing movement away from Flash, in the vast majority of cases, the HTML5/JS based player is chosen. In v7.0 we have decided to remodel our design and have removed two unnecessary files and therefore the computational and timing overhead of additional requests.
Custom Adaptation Logic
Creating an adaptation logic that fits all use cases for all of our customers is impossible – trust me we tried it ;-). As we learned that we cannot make every customer happy with a single adaptation logic we started to draft ideas around extending the flexibility of our players adaptation process. At first we added special parameters that you can use to tune the startup behavior of the player (i.e., setting a preferred startup quality), setting a minimum and a maximum bitrate, restricting the adaptation to the current window size, etc. This in itself helped a lot of our customers, but it was still not flexible enough for some. Therefore we decided to give our customers full control over the adaptation logic through a callback based interface. This means that before we download a segment a callback called onVideoAdaptation/onAudioAdaptation will be triggered where our users can register their own functions. This callback provides the current decision of the adaptation logic, i.e., which bitrate and resolution should be downloaded next. In the function that you register you could now overwrite this decision and basically decide for each and every segment which bitrate should be downloaded.
This allows you to create your own adaptation logic and we will also provide several different ones that can be used and also configured or rewritten through JavaScript. An example could be the following buffer based logic:
var currentQuality; var sameRepCount = 0; ... adaptation : { desktop: { onVideoAdaptation: function(param) { var qualities = player.getAvailableVideoQualities(); currentQuality = currentQuality || qualities[0]; var nextBitrate = currentQuality; var bitrates = qualities.map(function(quality) { return quality.bitrate; }).sort(function(a, b) { return a > b; }); if (player.getVideoBufferLength() > 20 && sameRepCount >= 5) { // get next better quality if buffer is full (> 20 s) and played the same representation 5 times nextBitrate = bitrates[Math.min(bitrates.indexOf(currentQuality.bitrate) + 1, bitrates.length - 1)]; sameRepCount = 0; console.log('switch up to bitrate ' + nextBitrate); } else if (player.getVideoBufferLength() < 10 && sameRepCount >= 1) { // get next lower quality if buffer is less than 10s and keep that for at least another segment nextBitrate = bitrates[Math.max(bitrates.indexOf(currentQuality.bitrate) - 1 , 0)]; sameRepCount = 0; console.log('switch down to bitrate ' + nextBitrate); } else { // keep the same quality console.log('keep same bitrate (' + currentQuality.bitrate + ')'); sameRepCount++; return currentQuality.id; } currentQuality = qualities.filter(function(quality) { return quality.bitrate === nextBitrate; })[0]; return currentQuality.id; } } }This buffer based logic is very conservative. It will switch only to the next higher quality if the buffer is filled with at least 20 seconds of video and if the current quality has been downloaded 5 times. This will make the adaptation process very smooth as there will be fewer switches and no buffering, because 20 seconds is in the buffer in case the decision was wrong. On the other hand if the buffer contains less than 10 seconds of video the logic will switch down to the next lower quality and keep that quality for at least another segment. This will work nicely if there are no rapid bandwidth changes, as you would expect on fixed access connections. However, it could potentially yield problems in mobile scenarios where you need to switch down more aggressively to prevent buffering. BuFor those cases you could design your own mobile logic. If the buffer is in between 10 and 20 seconds the logic will simply download the current quality and stay at its current quality level.
Although this might not be the most sophisticated example, it illustrates how easy our default ABR algorithm can be modified, or customized entirely. So, if you have ever thought about applying different adaptation schemes on different devices, or for a different user-base, etc. Bitmovin’s new player enables it.Coming soon
For beginning of 2017, we already have more interesting features planned, like a handy debug mode for development, updates to the Chromecast version of our player, and MPEG-DASH and HLS backup stream handling, which enables switching between different stream sources in an error case. Furthermore, we planned to integrate means for slide synchronization, making use of the EXT-X-PROGRAM-DATE-TIME attribute of HLS playlists. So, stay tuned!
All the best,
Reinhard and the Bitmovin Team.
