Use the new low-level network API to influence all network requests for advanced use cases and maximize your ad fill rates and increase your revenue with ad waterfalling.
Network API
The new network API provides methods to fully customize each and every request to the network. It allows the the preprocessing of every request before it is actually sent like adding HTTP headers, specify whether cookies should be sent along with cross-origin requests or even changing the URL of a request.
Besides the ability to modify all outgoing requests, this new API also lets you access all metadata of the response, such as the HTTP response HEADERS. As if this wasn’t enough, now the response data, such as manifest files, audio or video segments can also be accessed. Both, the metadata and the response data can be modified before passing it back to the player.
As you always get the type of content of the request, such as DASH manifest, HLS variant playlist or Widevine DRM license request, it’s pretty easy to create a custom logic for all the different requests.
This enables lots of use cases, especially in context of DRM. In fact it actually renders most configuration options and callbacks in the player’s DRM configuration obsolete, such as headers, withCredentials, prepareMessage or prepareLicense. It further enables the dynamic creation of license acquisition URLs (LA URLs). One such use case would be where the license server URL is returned as HTTP header in the manifest request. This was simply not possible in older player versions.
Last but not least it’s also possible to fully customize the retry behavior of the player. Instead of only changing the amount of retries for failed requests it’s possible to change the timeout between the attempts, dynamically decide on a per-retry basis if another attempt should be made or change all the properties of the request up to trying another URL.
The player team is working on adding even more features to the Network API in future player releases. We are eager to see which use cases and problems we can solve for our customers using this new API!
Ad Waterfalling
Ad tags often don’t provide a 100% fill rate. This essentially means that whenever an ad tag doesn’t return an ad, an opportunity to generate revenue in this ad break is lost. The solution for this problem is ad waterfalling. It make sure to not lose any revenue potential by using a list of ad tags. If one ad tag is unable to provide an ad the player will automatically cascade to the next ad tag and so on.
Until now one simply provided a single URL when scheduling an ad:
player.scheduleAd(‘https://adTagUrl.example.com’, ‘vast’);While this is still supported in version 7.4+, it is now also possible to provide an array of ad manifest objects:
player.scheduleAd([{ url: ‘https://adTagUrl1.example.com’ }, { url: ‘https://adTagUrl2.example.com’ }], ‘vast’);We decided to not simply use an array of ad tag URLs. So far ‘url’ is the only supported attribute but we plan to further enhance the available options in upcoming player versions.
Subtitles & Closed Captions
As of today there are two relevant competing specifications for sidecar subtitle formats: WebVTT and TTML. Web Video Text Tracks or short WebVTT format is basically the successor of the simple text-based open source SRT format and still in the status of a W3C Working Draft. TTML stands for Timed Text Markup Language (TTML), earlier referred to as DFXP (Distribution Format eXchange Profile). It leverages an XML-based structure and is a W3C Recommendation.
While subtitle files are straightforward for on demand content it is a bit more challenging for live streaming as a player needs to update the subtitles and make sure the timing is correct. There is a standard solution for HLS: an additional playlist with links to segmented WebVTT files, i.e. a WebVTT file is split into several plain text files so you can easily add another file for the new parts of a live stream. Unfortunately, there is no such clear definition in the MPEG-DASH specification. Therefore an industry standard evolved. Instead of the plain text files the subtitle files are wrapped in fMP4 segments. Originally, TTML was used for this scenario but recently WebVTT subtitles wrapped in fMP4 segments are getting more and more traction. As a consequence, you can now use not only fMP4 wrapped TTML but also such segmented WebVTT subtitles in the Bitmovin Player!
Furthermore it’s now possible for an user to fully customize the closed captions using the player’s default UI, which is a requirement of the Federal Communications Commission (FCC) in the United States.
Performance Improvements
The player team always has an eye on performance and how it can be improved. The 7.4 release comes with an improved startup time for HLS live streams. The ABR logic has been improved for HLS streams by taking HLS specifics into account. Last but not least the player now has preloading enabled per default for on demand content, which improves the video start time for an end user.
Misc
The 7.4 release includes a variety of changes to improve stability and robustness, such as gracefully handling segments not carrying any data and handling single-track timestamp rollover in MPEG-2 TS segments with muxed audio and video data. It also supports additional HLS tags for timed metadata, namely EXT-X-CUE-OUT, EXT-X-CUE-OUT-CONT, EXT-X-CUE-IN and EXT-X-SCTE35 tags. They are often used for client-side ad insertion. Furthermore it is now possible to exclude technologies, such as Flash or progressive videos from the player’s fallback routines. The player now also provides information that DRM playback was restricted, for example because of the enforcement of HDCP but an user had non-HDCP enabled parts in the video pipeline such as an VGA monitor. As more and more browsers block autoplay and autoplay policies become more and more complex, the Bitmovin Player will now provide feedback abuot whether or not playback really started or if a user interaction is required.
What’s next?
In addition to the many timed metadata formats already supported by the Bitmovin Player, like ID3 tags, EMSG boxes, SCTE-35 tags or CUE tags, the player team is working on DASH EventStream support as well. In the context of VR/360, we will add support for different field of views, other formats like 180 degree content as well as spatial audio. Besides that we will further improve our platform coverage, so stay tuned!
All the best,
Daniel and the Bitmovin Team.
