As video workflows get more detailed, companies face numerous challenges in delivering a seamless viewing experience to their audiences. One of the biggest hurdles is the ability to make sense of disjointed sets of information from different points in the video delivery workflow. When a client experiences buffering or other playback issues, it can be difficult to pinpoint the root cause within a workflow. Do You rack your brain wondering if it’s a problem with the manifest, the client’s Adaptive Bitrate (ABR) algorithm, or the Content Delivery Network (CDN)? To create a clearer picture for streaming platforms and the CDNs delivering the content, this is where Common-Media-Client-Data (CMCD) comes into play.

What is CMCD and Why is it Important?

CMCD is an open specification and tool developed by the Web Application Video Ecosystem (WAVE) project launched by the Consumer Technology Association (CTA). Its focus is to allow media players to communicate data back to CDNs during video streaming sessions. It provides a standardized protocol for exchanging information between the client and the CDN, bridging the gap between client-side quality of experience (QOE) metrics and server-side quality of service (QOS) data. By providing the transmission of this detailed data and information, CMCD-enabled video streaming services can facilitate better troubleshooting, optimization, and dynamic delivery adjustments by CDNs.

With CMCD, media clients can send key-value pairs of data to CDNs, providing valuable insights into the streaming session. This data includes information such as encoded bitrate, buffer length, content ID, measured throughput, session ID, playback rate, and more. By capturing and analyzing this data, CDNs can gain a deeper understanding of the client’s streaming experience and make informed decisions to improve performance and address any issues.

What data is tracked and how is data sent and processed with CMCD?

The data points for CMCD are thorough, giving you the detailed metrics you need to verify your viewer’s experience along with how to optimize it. The metrics include:

• Encoded bitrate
• Buffer length
• Buffer starvation
• Content ID
• Object duration
• Deadline
• Measured throughput
• Next object request
• Next range request
• Object type
• Playback rate
• Requested maximum throughput
• Streaming format
• Session ID
• Stream type
• Startup
• Top bitrate

There are three common methods for sending CMCD data from the client to the CDN: custom HTTP request headers, HTTP query arguments, or JSON objects independent of the HTTP request. The choice of method depends on the player’s capabilities and the CDN’s processing requirements and could also differ by platform. In browsers, HTTP query arguments are preferred over HTTP request headers as headers would cause OPTIONS requests in addition to see if the CDN allows the usage of these headers, adding additional round-trip times. Other platforms like Android don’t have this limitation.

It is recommended to sequence the key-value pairs in alphabetical order to reduce the fingerprinting surface exposed by the player. Additionally, including a session ID (sid) and content ID (cid) with each request can aid in parsing and filtering through CDN logs for specific session and content combinations.

The Role of CMCD in Video Streaming Optimization

CMCD plays a crucial role in optimizing video streaming by enabling comprehensive data analysis and real-time adjustments. Combining client-side data with CDN logs, CMCD allows for the correlation of metrics and the identification of issues that affect streaming performance. This holistic view empowers CDNs to take proactive measures to address buffering, playback stalls, or other quality issues.

With CMCD, CDNs can segment data based on Live and Video on Demand (VOD) content, monitor CDN performance, identify specific subscriber sessions, and track the journey of media objects from the CDN to the player and screen. This level of insight enables CDNs to optimize content delivery, manage bandwidth allocation, and ensure a smooth and consistent streaming experience for viewers.

Adoption of CMCD in the Industry

Akamai and Bitmovin CMCD Workflow

The adoption and implementation of CMCD in video workflows are still developing. Many in the video streaming industry are evaluating it at the moment but haven’t made significant moves. However, there are notable players in the market who have taken the lead in incorporating CMCD into their platforms. One such example is Akamai, a prominent CDN provider. Akamai has been actively working on CMCD in collaboration with the Bitmovin Player.

Live Demo

Together, Akamai and Bitmovin have developed a demo presenting the capabilities and benefits of CMCD. The demo shows how CMCD data can be sent by the Bitmovin Player to the CDN.

What are the benefits of CMCD and how can it be implemented on the Bitmovin Player?

As listed above, there are clear benefits to implementing CMCD for video playback. Some of the benefits of CMCD that can be achieved with the Bitmovin player are: 

• Troubleshooting errors and finding root causes faster
  • CMCD makes Player sessions visible in CDN logs so you can trace error sessions through the Player and CDN to quickly find the root cause, reducing the cost associated with users experiencing errors on your platform.
    
• Combine Playback sessions and CDN logs with common session & content identifiers 
  • Improve your operational monitoring by giving a clearer view of content requests from Player and how those are handled by the CDN.
    
• Improve the quality of experience and reduce rebuffering by enabling pre-fetching 
  • Through CMCD, the CDN is aware of the Player’s current state and the content it most likely needs next. This allows the CDN to prepare and deliver the next packet the Player needs faster, reducing the time your viewers are waiting.
    
• Integration with Bitmovin’s Analytics
  • Monitor every single user session and gain granular data on audience, quality, and ad metrics that ensure a high quality of experience for viewers while helping you pinpoint error sessions rapidly with CMCD data.

As Bitmovin is continuing to explore CMCD’s capabilities, we’ve made it easy to set up and deploy into video workflows through our Github. If you’re wondering how it should be working or want to see it before taking the steps to implement it, you can check out our Bitmovin Web Player Samples. 

Additionally, if you have any questions or have any feedback on our experience using it, join our Bitmovin Developer community and comment on the running dialog around our CMCD implementation.

Future Implications and Industry Outlook

While CMCD is still in its early stages of adoption, its potential impact on the video streaming industry is significant. As more embrace CMCD, the ability to gather and analyze comprehensive data will become a standard practice and its benefits will become increasingly evident. This data-driven approach will enable continuous improvements in streaming performance and video workflows. This was a major reason that we at Bitmovin took this project on as transparency is key and CMCD makes the issues easier to find and address, increasing viewer and client satisfaction. 

Interest in CMCD will continue to grow with new implementations and use cases, leading the industry to realize the gains from reducing buffering and delivering better, streams to viewers. Our partnership with Akamai is just one step in how we are committed to advancing video streaming technology for content providers and providing a seamless viewing experience for audiences worldwide.

The post Unlocking the Highest Quality of Experience with Common-Media-Client-Data (CMCD) – What Is It and What Are the Benefits appeared first on Bitmovin.

• Background and the “old” MSE
• New Managed Media Source in Safari 17
• Airplay with MMS
• Migration from MSE to MMS
• Next Steps

Background and the “old” MSE

The first internet videos of the early 2000s were powered by plugins like Flash and Quicktime, separate software that needed to be installed and maintained in addition to the web browser. In 2010, HTML5 was introduced, with its <video> tag that made it possible to embed video without plugins. This was a much simpler and more flexible approach to adding video to websites, but had some limitations. Apple’s HTTP Live Streaming (HLS) made adaptive streaming possible, but developers wanted more control and flexibility than native HLS offered, like the ability to select media or play DRM-protected content. In 2013, the Media Source Extension (MSE) was published by the W3C body, providing a low-level toolkit that gave more control for managing buffering and resolution for adaptive streaming. MSE was quickly adopted by all major browsers and is now the most widely used web video technology…except for on iPhones. MSE has some inefficiencies that lead to greater power use than native HLS and Apple’s testing found that adding MSE support would have meant reducing the battery life, so all the benefits of MSE have been unavailable on iPhone…until now.

New Managed Media Source in Safari 17

With MSE, it can be difficult to achieve the same quality of playback possible with HLS, especially with lower power devices and spotty network conditions. This is partly because MSE transfers most control over the streaming of media data from the User Agent to the application running in the page. But the page doesn’t have the same level of knowledge or even goals as the User Agent, and may request media data at any time, often at the expense of higher power usage. To address those drawbacks and combine the flexibility provided by MSE with the efficiency of HLS, Apple created a new Managed Media Source API (MMS).

The new “managed” MediaSource gives the browser more control over the MediaSource and its associated objects. It makes it easier to support streaming media playback on mobile devices, while allowing User Agents to react to changes in memory usage and networking capabilities. MMS can reduce power usage by telling the webpage when it’s a good time to load more media data from the network. When nothing is requested, the cellular modem can go into a low power state for longer periods of time, increasing battery life. When the system gets into a low memory state, MMS may clear out buffered data as needed to reduce memory consumption and keep operations of the system and the app stable. MMS also tracks when buffering should start and stop, so the browser can detect low buffer and full buffer states for you. Using MMS will save your viewers bandwidth and battery life, allowing them to enjoy your videos for even longer. 

Airplay with MMS

One of the great things about native HLS support in Safari is the automatic support for AirPlay that lets viewers stream video from their phone to compatible Smart TVs and set top boxes. Airplay requires a URL that you can send, but that doesn’t exist in MSE, making them incompatible. But now with MMS, you can add an HLS playlist to a child source element for the video, and when the user AirPlays your content, Safari will switch away from your Managed Media Source and play the HLS stream on the AirPlay device. It’s a slick way to get the best of both worlds.

Migration from MSE to MMS

The Managed Media Source is designed in a backwards compatible way. This means that changing the code from creating a MediaSource object to creating a ManagedMediaSource object after checking if the API is available is the first step:

function getMediaSource() {
    if (window.ManagedMediaSource) {
        return new window.ManagedMediaSource();
    }
    if (window.MediaSource) {
        return new window.MediaSource();
    }

    throw “No MediaSource API available”;
}
const mediaSource = getMediaSource();

As the MMS supports all methods the “old” MSE does, this is all to get you started, but doesn’t unleash the full power of this new API. For that, you need to handle different new events:

mediaSource.addEventListener(“startstreaming”, onStartStreamingHandler);

The startstreaming event indicates that more media data should now be loaded from the network.

mediaSource.addEventListener(“endstreaming”, onStopStreamingHandler);

The endstreaming event is the counterpart of startstreaming and signals that for now no more media data should be requested from the network. This status can also be checked via the streaming attribute on the MMS instance. On devices like iPhones (once fully available) and iPad, requests that follow these two hints benefit from the fast 5G network and allows the device to get into low power mode in between request batches.

In addition, the current implementation also offers hints about a preferred, suggested quality to download. The browser suggests if a high, medium, or low quality should be requested. The user agent may base this on facts like network speed, but also additional details like user settings about enabled data saver modes. This can be read from the MMS instance’s quality property and any change is signaled via an qualitychange event:

mediaSource.addEventListener(“qualitychange”, onQualityChangeHandler);

It remains to be seen if the quality hint will still be available in the future as it offers some risk of fingerprinting.

As the MMS may remove any date range at any given time (as opposed to the MSE’s behavior where this could only happen during the process of appending data), it is strongly recommended to check if the data needed next is still present or needs to be re-downloaded.

Next Steps

Managed Media Source is already available in the current Safari Tech Preview on macOS and Safari 17 on iPadOS 17 beta and can be enabled as an experimental feature on iOS 17 beta. Once generally available on iOS, without being an experimental feature, this will finally bring lots of flexibility and choices to Safari, other browsers, and Apps with WebViews on iOS. It would even be possible to finally support DASH streams on iOS, while keeping web apps power efficient. 

Apple has already submitted the proposal of the Managed Media Source API to the World Wide Web Consortium (W3C), which is under discussion and might lead to an open standard other browser vendors could adopt.

Bitmovin will be running technical evaluations to fully explore and understand the benefits of MMS, including how it performs in various real-world environments. We will closely follow the progress from Apple and consider introducing support for MMS into our Web Player SDK once it advances from being an experimental feature on iOS. Stay tuned!

If you’re interested in more detail, you can watch the replay of the media formats section from WWDC23 here and read the release notes for Safari 17 beta and iOS & iPadOS 17 beta. You can also check out our MSE demo code and our blog about developing a video player with structured concurrency.

The post Everything you need to know about Apple’s new Managed Media Source appeared first on Bitmovin.

Google recently contacted companies with a heads-up that the current Widevine Content Decryption Module (CDM) for browsers will stop working soon as they look to push an update.

The CDM is the secure closed-box environment that handles digital rights management (DRM) restrictions and decryption of the content.

Before denying access to the current CDM, Google will start rolling out the new version of it, with Google’s Chrome browser leading the way.

However, other Chromium-based browsers that include the Widevine CDM for DRM-protected video playback, like Microsoft Edge or Opera, still have to wait a few more weeks before receiving the update from Google.

The result of this means that the old version of the CDM will cease to work over the next month or so after all browsers have the updated version.

Updated CDM implementation timeline

We’ve detailed the timeline in our graphic below and added additional context to paint a clear picture of what’s happened already, what’s happening now, and what’s coming over the next few months.

September 29th, 2022
– Google initiated the updated CDM rollout by releasing it on Chrome’s experimental Canary channel

October 25th, 2022
– Chrome 107 will be released in the stable channel and will include the new CDM

November 15th, 2022
– The new CDM will be released on all other Chromium-based browsers like Edge or Opera for M95 and above

December 6th, 2022
– Older CDM versions will be revoked and deactivated and cannot be used any longer

Why does this matter, and which platforms are affected?

To cut to the chase in giving you the plain and simple answer: viewers will not be able to stream their favorite content on the most widely used browser in the world.

After December 6th, your users may come into issues playing any content protected with the Widevine DRM in Chrome and Chromium-based browsers if they have yet to update their browsers.

The good news is that many browsers contain auto-update mechanisms, but it is worth remembering that not all users regularly upgrade if given a choice.

Google indicates that this will affect desktop browsers only, with no mentions of Chrome for Android, Android native apps, or other devices like LG WebOS or Samsung Tizen SmartTVs.

In fact, there have also been hints that this change mainly affects Windows platforms. So this should help you breathe a bit easier.

What can you do to prevent any issues?

It’s our position that we’re all best placed to be aware and prepared.

We are all in a fortunate position as no code changes within your app or player upgrades are needed.

However, depending on your user’s update preferences, you may very well see increased error rates in your playback analytics and possibly more tickets coming into your customer service system than usual.

An additional recommendation to consider is that you ensure your support team is aware of the upcoming potential issue and has pre-written responses prepared well in advance that they can utilize to respond accordingly and quickly.

Additionally, it may be in your best interest to notify your users through multiple channels that are available to you (social, email, in-app).

This way, your audience will be informed of this upcoming change, can make the necessary adjustments if needed, and hopefully won’t feel the need to associate or relate any bad viewing experience to your platform.

Until the next update or if there are more developments on this topic, happy streaming!

The post Google is Deprecating the Widevine DRM CDM appeared first on Bitmovin.

Quietly, without any announcement or updates on support pages, Google fixed a bug in Chrome with a significant implication for the video streaming industry: Support for adaptive streaming of HEVC/H.265 video content has finally been enabled! 

Thanks to Bitmovin (Humble Brag, just kidding), we submitted a bug report about 6 years ago about this very thing. After a “small” bit of waiting, we got the answer that It’s now officially supported for Chrome 104, and with a little investigation also found out that it’s enabled by default for Chrome 105 for all platforms, ready to be used in the wild. 

Why does support for HEVC matter?

High-Efficiency Video Coding (HEVC) provides better compression for files than the ubiquitous AVC/H.264, meaning you will be able to stream the same quality with lower bandwidth and big savings on CDN costs with the added bonus of improving the user experience. 

While HEVC is commonly used for serving content to Smart TVs, set-top boxes, and devices like Roku and Fire TV, its usage on mobile and desktop browsers was limited to just Safari for a long time (after Microsoft changed the Edge browser to being Chromium-based). With Safari’s market share still below 19% globally, the vast majority of users had no choice but to use another codec. However, with this latest change from Google, Chrome’s market share of more than 65% can be “theoretically” added to the HEVC-capable browsers, making it available to 84% of browser users. 

I say “theoretically”, as there’s often a caveat: HEVC is only supported if the underlying device has an HEVC hardware decoder. 

Today’s modern devices should already have that as standard, but reliable global data on this point are scarce. If you are curious to see if your device can play HEVC-encoded DASH and HLS streams, open our stream test page with an HEVC-encoded DASH and HLS URL, or you can use this example URL.

Does is also work with DRM?

That’s where the catch is, unfortunately. The biggest drawback is that HEVC with Widevine DRM is not supported at this point, only clear, unprotected content. It’s unclear whether Google has plans to add support for this in the future or not.

Great feature, but where is the necessary hype!?

While this sounds like a feature Google should be boasting about to the moon over their comms channels, they haven’t really updated their documentation. In fact, Chromium’s Audio/Video codec & container support page was not updated as of the writing of this article, and the popular caniuse.com still lists HEVC as unsupported.

Android already supported HEVC, but Chrome on Android only supported HEVC with progressive files, not via the Media Source Extension (MSE) API, which is used for adaptive streaming like DASH or HLS. After little movement for years from Google, the bug finally got picked up earlier this year and fixed. So despite the original scope being just Android, it was a very positive surprise to see HEVC support enabled and rolled out on all Chrome platforms. Now, we just need to see DRM supported along with it!

The post Google Quietly Added HEVC Support in Chrome appeared first on Bitmovin.

Choosing an appropriate streaming bitrate for a specific resolution, while maintaining an acceptable visual quality is not always that easy. The decision depends heavily on the content, e.g., motion, resolution, video bitrate, frame-rate etc. In adaptive streaming systems like MPEG Dynamic Adaptive Streaming over HTTP (DASH) and Apple HTTP Live Streaming (HLS) the first decision that needs to made is: What is the minimum and maximum bitrate/resolution that the system should serve to the users? This depends of course on the resolution and bitrate of the input content and on the network conditions that most of your users are facing, e.g., mobile networks (3G, 4G) with bandwidth fluctuations from x to y and fixed networks with the same variances but in another range.

As a rule of thumb, the Bitmovin team recommends minimum, average and maximum bitrates for common resolutions visualized through the following graph. The horizontal axis of the graph shows the pixels per second, on a logarithmic scale, that are needed for the resolutions with 24 frames per second and the vertical axis shows the encoding bitrate in Kbps.

Resolution and Bitrate Recommendation

The minimum, average and maximum functions of the previous graph are also visualized in the following table view. This view also contains the bits spend per pixel when encoded with the recommended bitrate. It can be seen that the bits per pixel are decreasing with increasing resolutions due to the fact that H.264/AVC is more efficient for higher resolutions.

Minimum Video Bitrate

Average Video Bitrate

Maximum Video Bitrate

• Did you hear of Per-Scene Adaptation? It helps reducing the bandwidth consumption by adjusting the bitrate stream to the minimum bitrate required to maintain perfect visual quality for every segment within your video. Read more about it here.
• Per-Title Ladder Benchmarking Tool: Test your Content and see a comparison of your existing bitrate ladder (or a standard default ladder) against the optimized Per-Title ladder.
• Video Developer Report 2019: Key insights into the evolving technology trends of the digital video industry

The post Choosing the Right Video Bitrate for Streaming HLS and DASH appeared first on Bitmovin.

Bitmovin Video Player v8 marks the transition to a module-based approach, allowing developers to load only the features they need.

The New Modular Player?

Version 8.0 includes a range of improvements, but one of the most significant is a shift to a modular architecture. While previous versions relied on a fixed structure, which shipped all functionalities in a single package, the scope of features has now been moved to a module-based structure. This way, individual features (e. g. subtitles, DRM, or ad-integration) can be added or removed for each specific build of the player. The modules to be used can either be defined during the building process or dynamically, based on the displayed asset or the displaying device.

Features that are not relevant in a specific use case, are omitted from the package thus reducing the overall size and load time.

This shift unlocks the potential to cut the size of the player application to the absolute minimum and makes a significant difference in the startup speed of the player. Our tests show that with an available bandwidth of ~1.5 Mbit/s, the modular player configurations shown in the diagram above will decrease your player’s startup time by around 900ms, when compared to the standard Bitmovin Player v7.

Optimized loading times to resolve page abandonment

Page abandonment due to excessive loading times is a major concern for any website, large or small. Whether it’s e-commerce, digital distribution or communication services –  the time it takes between when a visitor clicks on a link to when they see the content they are looking for is a key factor in measuring conversions across virtually all industries. Page abandonment rates increase rapidly as load time increases, which in turn, negatively impacts conversion rates and revenues.

If the objective is to optimize loading times, reducing the size of any kind of web-based application should be a priority. Anything that needs to be transmitted on top of the actual content should be kept to an absolute minimum.

Advertising Moved to the API

In line with the changes to our player, we have moved our tried-and-tested advertising features to the player API, giving developers a new level of control. If you are used to running client-side ads on our player, you probably won’t notice much of a difference as we kept the look and feel pretty much the same. For power users, who care about what’s going on under the hood, the shift towards an API-based architecture is exciting news.
While we kept everything in place for ads to run using our best practice implementation, it is now possible for our customers to create customizations running on top of our set of tools. This way, they can add customized ad solutions meeting their exact needs without needing additional infrastructure in place. All that’s required are custom ad modules that connect to our API using the same interfaces. Read our blog post on the changes to our Advertising API to learn more!

Analytics Module Runs Out of the Box

Analytics are key to understanding your audience, optimizing your video delivery workflow and identifying possible bottlenecks. Realizing that early on, analytics have formed an integral part of our products at Bitmovin from the very start. Our Analytics module integrates flawlessly with our player and can be used out-of-the-box with the pre-packaged Analytics Dashboard. Due to our open architecture, it’s also possible to create a dashboard of your own, using customized REST API queries to get the perfect metrics for your specific business cases.
Our Analytics module is easy to integrate, as we design our modules with developers in mind. It’s seamlessly integrated with our software stack and connects to your back-end solutions flawlessly thanks to our open platform philosophy. The concept is as clever as it is simple: We’ll give you an out-of-the-box solution that is a joy to work with, while keeping our module open so you can create your own amazing tools on top of that. Learn more by reading up on our Analytics module.
Besides the most recent improvements, the new player has kept everything that made it great in previous versions. This means it still provides an outstanding level of compatibility and playback quality. It plays on any device or browser, creating an impressively seamless experience for each user – whether they are on a new smartphone or an exotic legacy device.

What’s next for Bitmovin Player?

For the next version of our player, we are going to push the modular approach further. We’re planning to move some modules to open source and provide open interfaces. The goal is to allow our customers to take our player module and customize it independently to their own use cases and workflows. Additionally, we’re looking to increase the level of feature granularity for our modules, so it would basically amount to one feature per module. This will allow the player to be customized even further and it will eventually turn into a tool kit, which can be used by our clients to assemble custom modules. We’re also looking to move our analytics platform to a module of its own, which will make it easier for clients to manage the analytics component.
Can’t wait to see our player in action? Check out our video player demos!
Bitmovin Player v8 could do for your workflows right now, get in touch with one of our experts!

Resources:

• http://www.streamingmedia.com/PressRelease/Bitmovin-Modular- Player-Cuts- the-Wait- for-Video-Playback_46897.aspx
• https://www.cisco.com/c/en/us/solutions/service-provider/vni- network-traffic-forecast/infographic.html
• https://blog.kissmetrics.com/speed-is-a-killer/
• https://blog.kissmetrics.com/loading-time/

The post Bitmovin Video Player v8 introduces a modular architecture boosting flexibility and start-up speed appeared first on Bitmovin.

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.
The post Bitmovin HTML5 Player v7.4: Network API, ad waterfalling and performance improvements appeared first on Bitmovin.
]]>
					
		
		
			
		
		
		https://bitmovin.com/blog/bitmovin-html5-player-v7-2-per-scene-adaptation-vr360-api-performance-improvements-hls-backup-streams/
		
		
		Wed, 12 Jul 2017 14:45:32 +0000
				
		
		http://bitmovin.com/?p=20865

					The 7.2 release is yet another great step forward for the Bitmovin Player team, and among a host of impressive new updates, contains at least one new feature that could be a game changer for the industry. Per-Scene Adaptation Per-Scene Adaptation, as the name suggests, enables the player to optimize the stream based on the...

The post Bitmovin HTML5 Player v7.2: Per-Scene Adaptation, VR/360 API, Performance Improvements and HLS Backup Streams appeared first on Bitmovin.
]]>
										

The 7.2 release is yet another great step forward for the Bitmovin Player team, and among a host of impressive new updates, contains at least one new feature that could be a game changer for the industry.
Per-Scene Adaptation
Per-Scene Adaptation, as the name suggests, enables the player to optimize the stream based on the content of the scene in the video, to either save bandwidth, or increase quality. The player reads quality metadata, that gives each segment in the video a score based on the human eye’s ability to appreciate the level of detail.

The simplest way to grasp this concept is to imagine a scene that is completely black. With no details at all, the scene can be delivered at 320p to a 1080p HD screen, and no one would know the difference. This saves bandwidth.

Conversely, imagine a scene with a lot of detail, and a lot of movement, for example an action scene with a lot of explosions. Sometimes artefacts in these types of scene will be visible. In some cases it could be a benefit to the user to deliver a higher quality to enhance the user experience.



The diagram above compares standard adaptation to Per-Scene Adaptation. The orange and green arrows in the lower half of the diagram highlight opportunities to optimize the adaptation behavior.
Get the Per-Scene Adaptation Datasheet
VR/360 API
Being the first player to deliver 360 video to every device and browser was a landmark milestone for the Bitmovin player team, but it was really just the beginning. The 7.2 release contains a major update to the API, which enables interface customization and analytics which can take both your user experience and your content optimization to the next level.
360 interface customization
360 video is being consumed across a wide variety of devices and platforms, many of which are not designed for immersive content. With the 7.2 API update you can now customize the interface to make your content easier to experience on any device. A simple example might be adding up, down, left, right arrows or a “Reset View to Front” button, for easier desktop viewing. But these are just two simple examples. We are looking forward to seeing how you, our customers use this feature.
360 Analytics
Video Analytics has become a major focus for Bitmovin because we know how important metrics are for your business. Up until now, analytics for 360 was essentially the same as for standard video formats. With 7.2 you can now see deeper into the immersive experience to understand what your users are doing, and where they are looking within the environment.
HLS Backup Streams
This 7.2 release has enabled the possibility to configure your player to utilize multiple backup streams for your HLS content. (We have supported MPEG-DASH streams for some time). This is particularly useful for live streaming, as the content delivery is dependant on the encoder running in realtime. If the encoder fails for some reason, your player can now switch to an alternative encoder before the buffer expires to avoid any disruption in the user experience.



In any video workflow, there is always a possibility that one of the links in the chain breaks, stopping the entire stream. Both the Bitmovin Encoding team and the Bitmovin Player team have always treated stability as a high priority, which is why we have developed solutions such as CDN switching from our 7.1 release. The addition of HLS stream backups is another important step.
Performance Enhancements
More tweaks and enhancements in the 7.2 release have improved our start up times by around 4x the speed for HLS streams. Rendering of VR & 360 content has also received a major performance boost, particularly in Safari 10.1+ on macOS. We achieved this by leveraging a bug fix released by Apple last month which allowed us to remove workarounds for this platform to streamline and speed up several processes.
Support for Chunked webm/vp9 content
Another major development is support for VP9 chunked content. This will pave the way for stream optimization via Multi-Codec Streaming which has enormous potential for cost reductions as well as further improving user experience. In Multi-Codec Streaming, each user’s browser is identified, and a stream is chosen from a variety of options to deliver the most efficient possible file for their system.

For more information about how you can leverage Multi-Codec Streaming in your video workflow, contact our solutions team.
A few other nice enhancements
There were quite a few other smaller, but nonetheless, very important improvements in the 7.2 release, including: support for VAST extensions to further improve your advertising capabilities, changes in the way we deal with Fairplay certificates and the addition of support for the “X” format tag in the SegmentTemplate template string, which further broadens our support for variations in MPEG-DASH manifests.
What’s next?
We keep working on new features all the time. Some of the upcoming include the ability for users to style closed captions and subtitles, SCTE-35 and CUE tag support for ad insertion in HLS, P2P streaming integration and more.

All the best,

Daniel and the Bitmovin Team.
The post Bitmovin HTML5 Player v7.2: Per-Scene Adaptation, VR/360 API, Performance Improvements and HLS Backup Streams appeared first on Bitmovin.
]]>
					
		
		
			
		
		
		https://bitmovin.com/blog/bitmovin-html5-player-v7-1/
		
		
		Tue, 02 May 2017 09:26:32 +0000
				
		
		https://bitmovin.com/?p=19708

					Play on devices including Apple TV, control your Chromecast with built-in cast controls on your Android phone, continue watching when a CDN becomes unavailable, synchronize slides with HLS streams and more! The release of the Bitmovin Player v7.1 is yet another big step forward in usability. We have reworked the handling of remote players and in...

The post Bitmovin Player v7.1: Mobile UI, AirPlay, Picture-in-Picture, Slide synchronization, standardized Chromecast protocol and more appeared first on Bitmovin.
]]>
										

Play on devices including Apple TV, control your Chromecast with built-in cast controls on your Android phone, continue watching when a CDN becomes unavailable, synchronize slides with HLS streams and more!
The release of the Bitmovin Player v7.1 is yet another big step forward in usability. We have reworked the handling of remote players and in the process added support for Apple AirPlay. The UI has been further improved and optimized for mobile devices, we have made sure your DASH stream can still play even if a CDN becomes faulty or unavailable.

Mobile UI
Version 7.0 of the Bitmovin Adaptive Streaming Player introduced a new, fresh UI. We started from scratch and even made it available as open source project on GitHub for full customization options. That version of the UI was already fully responsive and works well for all different screen sizes. However, we felt that there is still need for a dedicated UI on mobile devices. One example for instance is that the volume slider doesn’t make too much sense on mobile because the hardware volume buttons are used most of the time. Another improvement is that we have re-arranged the interface to better utilize the limited space available on a mobile screen. To this end, some elements, such as the fullscreen and settings buttons have been moved to the top right corner and the settings menu has been re-designed and re-positioned to increase usability on touch screens.


AirPlay & Picture in Picture
Chromecast has already been supported by our player for quite some time, but in the Apple eco system AirPlay is more common so adding AirPlay support was a logical step. This enables your customers to enjoy streams on devices such as the latest Apple TV. Unfortunately the options provided by Apple for AirPlay are not yet as mature as those available with Chromecast, so there are some limitations: It can only be initiated via Safari on macOS but not on iOS and doesn’t provide much feedback. As a consequence, no playback events are fired during the AirPlay session.



Another handy feature is the support for Apple’s Picture-in-Picture mode in Safari. It enables you to pop the video out of the browser to continue watching while working in other windows, for example surfing the web in other browser tabs or switching over to other applications.
Slide synchronization
In lots of use cases it is necessary to synchronize external data to the playback position of a stream, both for VoD and live. For example, synchronizing slides to the stream of a presentation so users always see the slide the speaker is talking about while still seeing a video of the whole presentation. Another use case is to synchronize a live stream to it’s electronic program guide (EPG) next to or overlaid on top of the video. This can be achieved with two methods in HLS streams: The timing information can be injected directly into the MPEG-2 transport stream (TS) segments using ID3 tags. This is a bit more complex than the alternative, especially if this information should be added later. The advantage is that this is independent from the manifest file and can also be used for many other types of timed metadata information, such as required tracking information for server side ad insertion. (Download the Server-Side Ad Insertion Datasheet) This method has been supported by our player for some time and also works on iOS devices. The second option is to add timing information using the #EXT-X-PROGRAM-DATE-TIME tag in the HLS playlist. This is easier to manipulate on the server as well as easier to parse at the client. There is, however, one big drawback: Safari’s native HLS implementation does not provide access to this information. With player version 7.1 we have found a way to support this while still leveraging Safari’s HLS implementation. This means it now also works across all devices.


Default Media Control Protocol for Chromecast
Historically we have used a custom, proprietary protocol for the communication between the web player and a Chromecast session. Consequently, default cast clients, such as Chrome, Android phones or the Google Home app, could not control the playback of an existing session at all. Only senders which implemented our protocol were able to do so. With the new v7.1 release, the player is using the default media control protocol making the integration with Android apps much easier, faster and, as a result, cheaper. It also increases the usability and overall user experience as the control works with all the default cast clients customers are already used to.

One of the main advantages of this change is that Google requires compatibility with the default media control protocol for testing, certificating and promoting Chromecast apps. As we already worked on the Chromecast implementation, we added the possibility to provide the player a URL to a CSS file, which is then be used for skinning the Chromecast player.

We have also made our new developer analytics compatible with Chromecast so if you are using our analytics on your webpage, it will automatically work out-of-the-box with our default cast receiver app on the Chromecast as well.
CDN Switching for DASH
Although content delivery networks (CDNs) have a huge uptime, they can still fail as we saw last month. If AWS S3 can fail, so can other global services. To have a solution which still allows your users to watch content and deliver your ad revenue, multiple BaseURL attributes can be provided in DASH manifests, i.e. each CDN is added as a base location. In case the Bitmovin player cannot receive the segments from one location, it will now automatically fail over and try other CDNs.


More
The features outlined above are the main features of this new player version, but it doesn’t list everything we added in this version. There are a lot more features and fixes, like supporting HTTP redirects, the option to set an initial start time for the player, the configuration of the vertical start position for VR/360 streams and many more.
Coming soon
We already have lots of interesting features in our pipeline for our next player releases, like handling HLS backup streams or a comprehensive VR/360 API to fully customize your VR/360 experience and we have just launched native SDKs for Android and iOS.

Last but not least, we are continuing to develop and improve a number of innovations such as multi codec streaming and quality aware streaming which will allow you to further improve quality for users and cut down on your CDN bill.

All the best,

Daniel and the Bitmovin Team.
The post Bitmovin Player v7.1: Mobile UI, AirPlay, Picture-in-Picture, Slide synchronization, standardized Chromecast protocol and more appeared first on Bitmovin.
]]>
					
		
		
			
		
		
		https://bitmovin.com/blog/bitdash-v2-2-customized-video-player/
		
		
		Tue, 05 May 2015 12:31:04 +0000
				
		
		http://bitmovin.com/?p=8587

					Note: Since this post was originally published, the bitdash player has been renamed as the Bitmovin Adaptive Streaming Player. You can sign up for a free account and use the full version of the Bitmovin Player which includes full DRM support, ad server integration, MPEG-DASH and HLS and much more. It has not been too...

The post bitdash v2.2 – A Customized Video Player appeared first on Bitmovin.
]]>
										Note: Since this post was originally published, the bitdash player has been renamed as the Bitmovin Adaptive Streaming Player. You can sign up for a free account and use the full version of the Bitmovin Player which includes full DRM support, ad server integration, MPEG-DASH and HLS and much more.


It has not been too long since our last major release in February, but we have been quite busy since then.

This major update introduces skinning support for bitdash! Not only can you choose from predefined skins, but also create your own custom skin. The new skin generator lets you create your own style easily and creates a JSON-object which can be easily integrated into the player configuration. New styles can also be applied dynamically on-the-fly during playback. Of course, these skins work with both the cutting edge HTML5 and the fallback Flash player!

Find out more about skinning the Bitmovin Adaptive Streaming Player.

All the best,

Daniel & the bitdash Team

Follow us on Twitter: @bitmovin
The post bitdash v2.2 – A Customized Video Player appeared first on Bitmovin.
]]>