Say hello to Reinhard Grandl, who oversees Bitmovin’s product department, and develops the company’s product strategy and ensures it is optimized for customers. 

Discover his insights into the big trends at NAB 2023 and how to enjoy the show.

This year will be the 100th year of NAB!  What are your favourite memories from NAB?

My favorite memories always occur at the parties!

The video streaming industry has undergone significant changes in the last few years. Which trends do you expect to dominate discussions on the show floor?

The only constant in the industry is change. Macroeconomic factors have influenced the most recent changes, requiring companies to become more nimble and quickly respond to economic fluctuations. I expect this to be a dominant topic at the show.

Sustainability in video streaming will also generate a lot of discussions. The industry must take responsibility for its carbon footprint and collectively develop strategies to mitigate negative consequences for future generations.

Which Bitmovin innovations are a must-see for NAB attendees?

There are definitely some I wouldn’t want to miss. The first is Player Web X, our next-generation video player, which defines a new standard for playback performance, especially for more challenging platforms such as SmartTVs. Smart Chunking is a major advancement for our VOD Encoding, which significantly impacts video quality by optimizing chunk lengths and bitrate distribution, improving visual quality throughout the asset faster than before.

Last but not least is StreamLab. It’s a hugely exciting, innovative automated stream testing solution; it allows video developers to test and guarantee the quality of experience for their audience across more devices & platforms. In a world where more and more devices are entering the consumer market, StreamLab truly helps solve the issue of device fragmentation and ensures flawless playback on every device.

Bitmovin has been exhibiting at NAB Show since the company’s early days, what tips would you give to other startups looking to make the show a success? 

For young companies, tradeshows are a great way to meet industry peers and develop a good understanding of the market and its dynamics. For most startups going to a big show like NAB means a major investment, even more so when having a booth. So, make sure you set up the right meetings on and off the show floor and book them well in advance to maximize your chances of success. Last but not least – have fun!

Describe NAB in three words.

Impressive. Technology. People.

The post NAB Preview [2023]: 5 minutes with….Reinhard Grandl, VP Product, Bitmovin. appeared first on Bitmovin.

Say hello to Reinhard Grandl, who oversees Bitmovin’s product department, who develops the company’s product strategy and ensures it is optimized for customers. 

Discover his insights in the big trends at IBC 2022 and how to enjoy the show

Why are shows like IBC necessary for the media and entertainment industry?

Business is, ultimately, based on building trust and the best way to do this is with human interaction. Things are starting to change due to the rise of SaaS companies, but there’s no doubt that in-person meetings are still valuable. Shows like IBC are vital because they bring all of our customers, partners and prospects together in one place and provide multiple opportunities to connect with them, from giving them a demo on the stand to going out for dinner later. Last but not least, it’s a forcing function for vendors to announce new products and thus helps propel the industry forward.

The last IBC Show was in 2019; how has the video streaming industry changed since then?

It’s changed massively. Part of it is due to the pandemic, but some technical and business trends were already emerging. One significant difference is the range of streaming services available. Almost all major US conglomerates have built streaming services to compete with the likes of Netflix and AppleTV. Furthermore, many sports leagues are trying to monetize their content for fans or via sports-focused streaming services like DAZN. 

All of this creates a fragmented market for viewers who need multiple subscriptions to watch their favorite content. Without a doubt, there will be some market consolidation, but from a technological perspective, it’s creating a huge demand for technologies that can offer a superior viewing experience. At IBC2022, I expect we will see many product launches that focus on offering an optimal viewing experience while simultaneously reducing costs. 

What significant trends do you expect to see at IBC this year?

We will see the next steps in the evolution of technology; 5G, the VVC codec or new cloud-hosted services, to just name a few. I am particularly interested to see how much they’ve evolved since the last IBC in 2019. Of course, sustainability will be high on the agenda. It’s been inspiring to see so many projects emerge with the sole intention of helping the media and entertainment industry reduce its carbon footprint.

The post IBC Preview [2022]: 5 Minutes with… Reinhard Grandl appeared first on Bitmovin.

Since the  release of player version v5.2, Bitmovin has improved support for HLS streams, including playback on Chromecast and enhanced DRM handling. This support carries across to the latest implementation –  Web SDK v8

Chromecast HLS Playback

After introducing HLS streaming to our HTML5 based player, we took the next step and ported it to Chromecast making our HLS streams Chromecast compatible. We have been supporting MPEG-DASH on Chromecast for a while and it has been very well adopted by our customers. Why did we go the extra mile to port our own HTML5/JS-based implementation of an HLS player to Chromecast instead of using the existing Media Player Library (MPL)? Features! Using the HLS support of Chromecast’s MPL might be sufficient for some use-cases, but we wanted to empower our customers to make use of all of the great features from the desktop and mobile player, such as support of separated audio and video tracks, subtitles, and comprehensive API just to mention a few.

Enhanced Configuration Options for DRM

Player version v5.2 also features some important improvements to our DRM support. The player is now capable of interpreting DRM initialization information, usually present in the PSSH box of a segment, given in the manifest file instead. This makes our support for DRM-protected content even more versatile and increases our encoder compliance further.
In addition, we introduced a configuration object that allows the specification of advanced options of the DRM key system, such as distinctiveIdentifier or persistentState. More information about possible configuration options can also be found in our HTML5 Player configuration documentation.
We also introduced the support of HLS segments, not starting with key-frames, improved the startup performance and added additional events and API calls.

What’s Next?

For the next player version, we have planned another major step in the area of increased subtitle support with full WebVTT enablement. The latest improvement to the v8 Web Player includes better Edge browser support. As we see advertising capabilities getting more and more important for many of our customers, we will also extend our VAST support and introduce VPAID to the Bitmovin Video Player. So stay tuned.
To learn more about the Bitmovin Video Player please check out the following pages

• Bitmovin Video Player
• Web Player SDKs

The post Player Version V7 & V8 is Chromecast HLS Compatible with Enhanced DRM Support appeared first on Bitmovin.

Finding and communicating meaningful and actionable insights about your video delivery workflow and user experience just got a lot easier

In an effort to make Bitmovin’s powerful analytics components even more accessible to our clients, we are happy to introduce our all new Analytics Dashboard, an out-of-the-box solution to view key metrics on your video delivery workflows from one single place.

The Analytics Dashboard is easy-to-use and allows you to access statistics on your video delivery performance, potential bottlenecks and your viewers’ demographics. The new feature will be available to all clients using Bitmovin Analytics immediately upon release.
We have had our focus set on gathering those metrics from the early stages on – that’s why our powerful Analytics API has been a popular and essential part in Bitmovin’s line of solutions. With the new dashboard completing the picture, we’re proud to be able to offer an even more complete package with straightforward usability.

Meaningful metrics, easily accessible

Content delivery is a tricky business with a multitude of variables in place, all of which may influence the viewing experience directly. The challenge lies in pinning down the exact factors that are holding back your video delivery workflow. Thanks to the set of pre-selected metrics available on the dashboard, it’s simple to get a quick overview of a range of essential factors.

Out-of-the-box you can use the dashboard to:

Review which browsers perform best with your type of content by filtering and sorting the audience according to the browser used and average startup times. Match those statistics against your user demographics to optimize the delivery workflow for each browser by selecting the right configuration for a multi-codec-streaming setup.
Identify bottlenecks by checking rebuffering percentages to see how often the stream has to pause during playback due to the content not loading fast enough. While in many cases such issues may lie on the viewer’s end, high rebuffering percentages may be an indicator to start looking to optimize bandwidth usage, for example by exploring per-title encoding.
Monitor key performance metrics like startup times and error percentages to keep tabs on your viewer experience and see which content delivery networks perform best.
Understand your audience: Which browsers and operating systems are they using? Where are they viewing your content from? How do they respond to advertising? What time of day do they watch video? Which devices do they prefer?

Easy A/B comparison thanks to smart filtering options

Of course, if your goal is to determine whether a specific metric requires a deeper look and possibly some troubleshooting, it is key to compare that figure against a reference value. In order to allow that, our dashboard offers the possibility to easily filter and compare metrics with one another. Simply select the metric you would like to compare and add it to the graph view.

Certain statistics can be drilled down to reveal more detail. For example, you could filter rebuffering percentages by country to see in which regions viewers are more likely to face interruptions through rebuffering. Then you can break that down further to show percentages on a per player basis. Add a comparison view and you’ll be able to pinpoint which players are underperforming within which areas.
Stats are shown in easily comprehensible graphs using clear color-coding, making our new dashboard a valuable tool when it comes to working with and communicating analytics between teams and departments.

What’s on the horizon?

Our engineers have a couple of awesome comfort features lined up for future releases of the Analytics Dashboard. The option to view stats on a per video basis is one of the major features coming up, giving our clients even more options to track the performance of their videos and optimize the delivery process. Another upcoming feature is a tabular drilldown as an alternative to viewing stats as graphs. This option will be a great addition for complex comparison scenarios, for example when reviewing the performance per video over multiple regions.
Care to learn more about our Analytics Dashboard? Sign up now or request a demo with one of our experts!

The post High End Video Analytics Straight Out-Of-The-Box appeared first on Bitmovin.

The Per-Title Bitrate Ladder Tool allows you to generate a perfect bitrate ladder for each title in your library. This reduces bandwidth and increases quality.

Used by top SVOD providers Per-Title Encoding has been a standard technique in modern video encoding workflows for a few years and is still a key driver in raising the bar in high definition video delivery. Netflix was one of the earliest adopters, back in 2015, relying on per-title encoding to enable high-definition content delivery with reduced bitrate demands. The technology uses a complexity analysis of the assets to calculate a bitrate ladder, which is basically a table containing the optimized bitrate/resolution combinations. This optimization is different for every single video and thus has to be performed for every asset.
Per-title Encoding is an out-of-the-box feature in our Bitmovin Encoder and has been a staple in our highly successful video delivery workflows, effectively making the technology available to a wider user base. As we’re always looking to push the boundaries of what’s possible, we have kept busy refining the Per-Title Encoding process to offer even better results. We identified the bitrate ladder as a key aspect in doing so: Most video-related services use static bitrate ladders without applying content-based optimizations. We improved the way our algorithm calculates the bitrates for each level of quality and created our own way of building content-specific bitrate ladders.

Better quality at lower bitrates through optimized analyses

The challenge lies in finding the best possible correlation between perceived picture quality and bitrate. Our algorithm was optimized to work along the optimal ratio between PSNR (an objective quality metric) and bitrate/resolution.
Our solution is capable of encoding using a significantly reduced bitrate while making no compromises in regards to image quality, when compared with standard encoding profiles. In the example above, our encoder reduces bitrate by 48% and storage by 60% while still increasing the perceived quality by 7,5%.

Check out our tool and see for yourself

Want to see what the encoder can do? We’ve recently released a web-based Per-Title Ladder Benchmark Tool, which allows users to upload assets and receive an analysis of the selected bitrate ladder from a standard selection versus our optimized content-specific bitrate ladder.

New users can try out our tool for free up to 20 times.

Feel free to test different types of video assets. The tool highlights the estimated percentages for bitrate reduction, storage reduction and quality improvement. You can view the process in detail, see how long each individual step takes and get an easy comparison between the standard profile and the per-title profile at a glance.

The post Using a Per-Title Bitrate Ladder to Optimize Encoding – Try our new Benchmark Tool! appeared first on Bitmovin.

Adaptation Based on Video Context or “Per-Scene Adaptation”, reduces bandwidth consumption by adjusting the bitrate stream to the minimum bitrate required to maintain perfect visual quality for every segment within your video.

Since Netflix began customizing their encoding ladder in order to optimize each of their titles individually, the idea of “Per-Title Encoding” has been quite well understood. To put it simply, videos with low levels of complexity are encoded with a lower bitrate, and those with higher levels of complexity, at a higher bitrate. This either saves on bandwidth or improves visual quality, and can be an effective method of reducing bandwidth consumption. But what if this concept could be applied to individual scenes within a single title? With any given video, visual complexity varies from scene to scene. These variations create an opportunity to optimize a video based on the content of each scene. For example, many low complexity scenes can be streamed at a lower bitrate without any noticeable loss of visual quality. This provides the opportunity to significantly reduce bandwidth without any perceivable loss of quality.

A Plea for Quality

Anyone working in video knows that along with fast startup and avoiding stalls (buffering), video quality is a key factor in satisfying your audience. Meeting these three requirements has been a frontline topic in video development for many years and has led to the development of a range of approaches.
A common example that illustrates these challenges is bitrate ladders, or more specifically the bitrate/resolution combination used for encoding and how they are defined. Based on various studies and user acceptance tests, encoding profiles are defined to provide “good” quality for every single video. But the question “Is 5800 kbps enough to deliver excellent 1080p encodes?” can and should(!) not be answered with a simple “Yes” or “No”. Due to a complexity mismatch of different content types (e.g., Cartoons vs. action movies) the encoding recipe has to be adjusted accordingly, as “One-size-fits-all” bitrate ladders are not sufficient. One arising method to deal with this is called “Per-Title Encoding”. Without going into too much detail, by using “Per-Title Encoding” the encoding settings will be adjusted and optimized depending on the content and its encoding complexity.
Although using “Per-Title Encoding” is a step in the right direction and can increase QoE or help publishers save bandwidth, we asked ourselves the questions if a similar approach can also be applied on every individual scene?

Per-Scene Adaptation

Although the encoding profile can be adapted to the content, even the most action-packed movie contains scenes that are less complex. So in virtually every video there are many low complex scenes that can potentially be streamed with a lower bitrate, without decreasing quality. To enable a context based optimization for every scene, we developed an approach where the client is aware of the video content (and it’s complexity) in addition to its bitrate.
Commonly used adaptive video players utilize various information to make adaptation decisions. This might include (but is not limited to) connection data, like current throughput, buffer fill states, history information, or even user preferences.

As it can be seen in the above graphic, in addition to those traditional metrics, Per-Scene Adaptation adds quality metadata which is extracted during the encoding process. Using this important information the client and its adaptation component will be able to make more precise and efficient decisions.

How it Works

To establish a successful Per-Scene Adaptation setup a few steps need to be accomplished on the server as well as on the client-side. First of all quality information has to be extracted during the encoding on a per-chunk basis. The goal of such information is to illustrate perceptual quality as accurately as possible. Various different metrics like PSNR, SSIM, VMAF, etc. exist. We at Bitmovin make use of a combination of different metrics and derive a so called “quality index”, which will be encapsulated and delivered with the content itself. For delivery, different options are available, including: i) use a sidecar file ii) add the information in the playlist/manifest or iii) embed it directly in the a/v container.
At the streaming client the quality metadata is extracted, processed and forwarded to its adaptation logic component. With the help of this extra piece of information, the adaptation algorithm is now able to “replace” low complexity scenes by lower bitrate segments, while maintaining the same perceptual quality. The below graph illustrates this behavior.

While a traditional algorithm (without content quality information) would maintain the 2.0 Mbps quality (see above graphic) even for “simple” scenes, the quality aware algorithm can switch down to 1.0 Mbps. This behavior allows the player to save bandwidth, without decreasing the QoE of viewers.
The below bandwidth graph, recorded during playback of high motion sports content, highlights this behavior even further. As you can see, the standard adaptation logic maintains a high quality level during the entire sequence and across all scenes. In contrast, using quality metadata, it is possible to make use of lower bitrate segments for certain scenes and still deliver the same perceptual quality.

Saving Potential

As already stated, the saving potential of such an adaptation approach is highly coupled to the complexity of the scenes of a video and thus the content itself. To get a better understanding of the potential savings, we performed an evaluation with three different content types: sports, nature and animation.
As representative of the sports category, we used a 3:30 long clip of a parkour (Freerunning) competition. Characteristic for this kind of videos, are high motion scenes and frequent cuts – complex to encode in general. In contrast to that, we also used a 2:08 minutes shot of an abandoned town in the desert, with less camera movement and only a few cuts. The third short clip was an animated video with 2:30 minutes length and contains both, high as well as low motion scenes.
To ensure a fair comparison we used the same bitrate ladder for all three content types, containing 8 SD and 3 HD quality levels, with bitrates from 240 kbps to 7 Mbps. The average bandwidth consumption has been recorded over three consecutive runs, which have been performed in a stable bandwidth environment. It comes as no surprise that the saving potential for the sport content is very limited and around 3% in total (exactly 3.11%). Whereas the animated content shows decent savings, namely 14.06%, our per-scene based adaptation approach is able to save up to 30% (27.80%) when streaming the nature video without any perceptual loss of quality.

Additional Benefits

Besides the advantage of providing the same or better quality while consuming less bandwidth – using quality metadata for ABR decisions avoids stalls, as high bitrate scenes can be predicted well in advance. Clients which are not able to read the quality information can still playback the content – of course without the named benefits.
Our context based approach enables the usage of Per-Scene Adaptation without restrictions on dedicated codecs and/or container formats.

Conclusion

In today’s online video streaming scenarios, we see a shift away from pure “One-size-fits-all” bitrate ladders, which do not distinguish between different types of content. Since Netflix started using “Per-Title Encoding” the concept of optimizing the encoding recipe based on content and its encoding complexity is on the increase. By introducing Per-Scene Adaptation, we even made one step further: Save bandwidth for every single scene. Our client-based approach takes quality metadata, gathered during the encoding process, into account to make smarter adaptation decisions. While maintaining the same perceptual quality for the viewer, it consumes up to 30% less bandwidth and avoids stalls.

The post Per-Scene Adaptation: Going Beyond Bitrate appeared first on Bitmovin.

Bypassing adblocking software with Server-Side Ad Insertion and increase ad revenues by up to 25%.

For the past five years, there’s been a massive improvement and growth pattern in online video advertising towards an encoding or server-side approach to inserting ads, also known as Server-Side Ad Insertion (SSAI) to bypass adblocking software. In contrast to the traditional client-side techniques, like VAST and VPAID, which stitch together the ad content and non-ad content on the client-side, server-side ad insertion intercalates ads on a CMS level. The benefit of applying SSAI is that the client receives a continuous stream arriving from a single source which creates a broadcast-like transition between ads and content.

Read Next: CSAI vs SSAI: Client-Side Ad Insertion and Server-Side Ad Insertion Explained

The concept of inserting ads on the server-side is also aiming to improve video service monetization, as traditional ad-blocking software is no longer able to bypass playback of ad content. As of today, ad-blockers are used by about 27% of users and therefore have a significant negative impact on ad-driven businesses.

The disadvantages of Client-Side Ad Insertion

Monetizing content via client-side ad insertion (CSAI) is a common tactic in today’s online video streaming industry. There are a number of standards used including 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 Bitmovin’s Adaptive Streaming Player and are described in the related tutorial, setting up Ads with our player is easy to do.

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 potential loss of ad-driven revenue.

The use of ad-blocking software has grown steadily in recent times and it is no longer limited to a small number of “geeks”. More and more average internet users are adopting ad-blocking technology and this is a big threat to ad-driven businesses. The common strategy of detecting blocked ad content and asking consumers to whitelist certain sites relies on the goodwill of users and is far from a satisfactory solution.

Besides the blocking issue, there are other shortcomings when ads are ‘stitched’ to the content at the client-side. Changing the source from the content videos to ad clips leads in most cases to resolution changes and a loss of the playback buffer and therefore a decrease in quality of experience. Although the named disadvantages can be overcome by using efficient pre-buffering strategies, at least to a certain extent, latency-related problems, due to additional calls to (multiple) ad routers and then the ad asset itself, will still be present.

Also from a development point of view, CSAI increases effort and expenses. It is not uncommon to make use of ad SDKs, like Google’s IMA SDK, which has to be integrated and tested on every target platform. Achieving common functionalities across all devices can be costly and managing the different versions across platforms increases complexity.

In summary, it can be said, that CSAI approaches come with major disadvantages, which makes the Server-Side alternative even more attractive.

Server-Side Ad Insertion

The general concept behind SSAI, as already indicated by the name, is stitching together the content and ad clips on the server side during the encoding phase. This is in contrast to CSAI, where the client application handles the ad insertion. As the ads are part of the content video stream itself and proxied from the same server/CDN, there is no obvious indication to the client that the video content has been replaced by an ad. For traditional ad-blocking software, it will be impossible to detect and prevent playback of the ad clips.

As ads and content video are one continuous stream, latency problems and rough transitions between ads and content will be avoided. From a developer’s perspective (speaking only about the playout application), handling advertising scenarios will be much easier, as only ad tracking has to be covered by the client. Of course, there are many optimizations available to further enhance the viewer’s experience, such as disabling seeking or trick modes. In general, SSAI tends to move complexity from the client to the server/encoding side. Clearly, this step introduces new challenges for encoding systems, as addressed later on. (Download the Server-Side Ad Insertion Datasheet)

How are Ads Inserted Into the Content?

As stated in SSAI scenarios, advertisement clips are stitched to the content video itself. The below figure shows an overview of the involved components and their interaction.

The content video is fed into the encoder either from a content store or a live ingest. The ad break markers—e.g., inband SCTE-35 triggers or programmatically inserted triggers via the API—are recognized by the encoder, and the information is forwarded to the manifest service. The encoded segments are then written to storage or to a CDN directly, and stored alongside the ad content.

When a client starts a streaming session, the manifest file is requested from the content storage or CDN. The request contains personalized custom data about the viewer and is forwarded to the manifest service. Based on this information, gathered from cross-site tracking and other personalization techniques, the manifest service creates the appropriate playlist (including ad content) for the specific streaming session.

Once playback starts and an ad break is reached, the ad content is presented to the viewer in a smooth and transition-free manner. Using signaling mechanisms, like ID3 tags in HLS, or EMSG data and MPD Events in case of MPEG-DASH, ad-related reports (e.g., ad started information, 10% played, etc.) will be sent to tracking servers from the player.

Bitmovin’s SSAI Solution

Bitmovin enables SSAI, using Bitmovin’s Cloud Encoding System and Bitmovin’s Adaptive Streaming Player in combination with third-party ad providers, in an end-to-end scenario. For video delivery, both MPEG-DASH and HLS, as well as progressive download, can be used, as shown in the below demonstration. The content video is interrupted by a short mid-roll ad sequence, starting at around 30 seconds.

As it can be seen, ad assets are presented with Bitmovin’s Adaptive Streaming Player in the same way as the video content itself to ensure smooth and transition-free playback. Therefore user experience will be improved and thus engagement will be increased.

To signal ads to the encoder, ad markers can either be set using inband techniques like SCTE-35 triggers or via a RESTful API. For ad tracking, inband as well as out of band events are detected by Bitmovin’s Adaptive Streaming Player and can be sent to tracking servers.

SSAI: A Solution for Everything?

Although the concept of SSAI eliminates the thread of client-side blocked ads, there are other challenges to face. One of them is interactivity. Nearly every third ad in today’s online video ecosystem is delivered as rich interactive media or executable ad (well-known as VPAID standards). These kinds of ads are usually small applications themselves (either based on JavaScript or Flash), allowing user interaction with the aim of more engagement. If and how to enable similar possibilities with SSAI will be an upcoming challenge.

Looking at live scenarios, it is obvious that the demand for SSAI will vary over time. To cope with these fluctuations, a highly scalable architecture that handles just-in-time ad insertion is required. As manifests must be created according to the inputs (around personalization) from ad providers, a virtualized solution (hosted either in cloud infrastructure or in a managed on-premise setup) capable of immediate auto-scaling will be needed.

Conclusion

Nowadays commonly used ad standards are built on the concept of inserting ad clips into content video purely on the client-side. So-called, Client-Side Ad Insertion does not seem to meet the requirements of online video streaming anymore and especially the increasing number of blocked ads is a major disadvantage. A novel approach, called Server-Side Ad Insertion, or SSAI promises to overcome these issues and even increase user experience and engagement of viewers. Download the Server-Side Ad Insertion Datasheet
Request a demo

The post Bypass Adblock with Server-Side Ad Insertion appeared first on Bitmovin.

This June Google will cease development of Flash in the IMA SDKs ending support for the IMA SDK for Flash and Flash VPAID ads in the HTML5 SDK

Google has recently announced that as of June 1, 2017, they will cease development of Flash in the IMA SDKs. This will not only end support in the IMA SDK for Flash, but also support for Flash VPAID ads in the HTML5 SDK. Google is strongly encouraging all publishers that still use Flash based ads to switch to HTML5.
Moving away from Flash is a major theme in today’s web ecosystem and in the field of online video, the move is particularly important, which is why Bitmovin has reported all the significant deadlines and changes as they have been announced.
At Bitmovin we have always been in favour of a plugin free environment, so we designed our HTML5 Adaptive Streaming Video Player to leverage the media source extensions (available in most modern web browsers) for native HTML5 playback rather than relying on plugins. Having said that we still provide our customers the possibility to support legacy systems with our Flash based fallback.

How will this change affect your website?

When we think about Flash, one might only think about little applications and media players from “the good old days”, but Flash based ads have been (and in many cases still are) very common as well. Dropping support for Flash has the potential to cause problems on many ad serving platforms, and chances are, that if you have not prepared for the change, you are in danger of experiencing these problems first hand.
For ad driven businesses, not being able to serve ads due to outdated technology, means a direct loss of revenue. Publishers need to work with future proof, stable and reliable platforms that can deliver ads to reach viewers across all devices and platforms and increase engagement as much as possible.
Bitmovin’s ad interfaces (VAST, VPAID, IMA) are designed and built to serve ads natively in the browser, without the need for plugins.

Deprecating Flash in the IMA SDKs

Most recently, the IMA SDK team announced that they will cease development of Flash in the IMA SDKs. This step will end support for the IMA SDK for Flash, as well as for Flash VPAID ads in the HTML5 SDK.
The announcement effects the publishers, who now are encouraged to migrate to the HTML5 based SDK on the one hand side, but also advertisers, still using Flash based VPAID ads. The latter have to port their ads to JavaScript, to stay compliant. Although using the Flash based SDK will not actively be prevented, bug fixes or technical support will no longer be given, after June 1st. Furthermore, serving Flash based ads will not be supported in the HTML5 SDK and lead to errors.
Our support of IMA based ads has already been built with this change in mind. Using the Bitmovin Player to serve ads without Flash, natively in HTML5 and JavaScript is a great solution and is already being done by many Bitmovin customers .

How to Ensure Ad-Playout Without Flash

As mentioned above, still delivering Flash based ads to users comes with the danger that viewers, using a browser without or deprecated Flash support (quite common these days), can’t be reached anymore. To ensure ad-playout without Flash and across all devices and platforms, we summarized some key points, which need to be considered:

• You should use a web video player, which does not rely on Flash anymore (or other plugins, like Silverlight, etc.)
• The player should be based on standardized technologies, like HTML5
• Ad playback should also be implemented without Flash by the player
• In case the IMA SDK is used, make sure that it is the HTML5 based one
• Make sure that your advertiser(s) deliver JavaScript based VPAID ads instead of Flash ones

Your solution should at least offer these features so that successful advertising without Flash can continue. A comprehensive list, of what else should be considered, when choosing an appropriate online video player is addressed in our recent article on building an HTML5 Player.

What Changes for Bitmovin Customers?

As Bitmovin was one of the first movers focusing on online video streaming without plugins the short answer is: Nothing. In more detail, our player used an HTML5 first approach since its first version. Although this default behavior can be changed, using the relevant player configuration, it is only recommended to favor Flash based playout in very specific cases. The same approach holds for our Ad support, nevertheless if one uses the player’s VPAID interface, or the in-build IMA SDK, smooth playout is ensured due to the independency from plugins.

Conclusion

Deprecating Flash in the IMA SDKs aligns with the goal of achieving a plugin-free web. The recent announcement from the IMA SDK team is another trigger for publishers as well as advertisers to move away from Flash based content. We at Bitmovin have always been in favor of pure HTML5/JavaScript based playout, and our Adaptive Streaming Player is the right tool for it.
On the topic of ads, I also jump at the chance to point our readers to a novel concept of serving ads, called server-side ad insertion. This approach, recently added to our player, relies on stitching together content and ads on a CMS level, rather than within the browser. How advertisers, publishers and even viewers can benefit from server-side inserted ads will be discussed in one of our upcoming articles – so stay tuned!
All the best
Reinhard & The Bitmovin Team

The post Google IMA & Video Advertising is Dropping Flash appeared first on Bitmovin.

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.


The post Bitmovin HTML5 Player v7: 360° playback with HLS on iOS, server side ads, custom adaptation, new skin and more appeared first on Bitmovin.
]]>
					
		
		




			
		
		
		https://bitmovin.com/blog/lighter-faster-interactive-ads-cross-platform-vr-bitmovins-latest-major-player-version-6-0/
		
		
		Thu, 13 Oct 2016 10:00:08 +0000
				
		
		http://bitmovin.com/?p=11360

					In our latest major release of the Bitmovin Adaptive Streaming Player we have introduced interactive video ads using VPAID 2.0, enhanced our VR and 360° video support to cover all major browsers and further improved performance relating to startup and switching times. Interactive Advertising with VPAID 2.0 Besides conventional playback, handling of advertisements is one of the most...

The post Bitmovin Player Version 6.0 is Lighter & Faster with Interactive Ads & Cross-Platform VR appeared first on Bitmovin.
]]>
										

In our latest major release of the Bitmovin Adaptive Streaming Player we have introduced interactive video ads using VPAID 2.0, enhanced our VR and 360° video support to cover all major browsers and further improved performance relating to startup and switching times.
Interactive Advertising with VPAID 2.0
Besides conventional playback, handling of advertisements is one of the most important parts of a web player in many online video scenarios. After introducing the support for VAST based advertising in player version 4.1, enhancing the player with interactive ad capabilities, using VPAID, was the next logical step.

In contrast to VAST, which is limited in regard to the extent of interaction, allowing in-stream video ad formats, VPAID allows rich user interaction. VPAID enables compliant video players to display interactive media ads (sometimes also called executable ads), which enhances the user’s experience. Furthermore, VPAID captures and reports how the user interacts with the ad, which can be used to improve creatives and therefore engagement.
VR and 360° Video in all Major Browsers
We are proud to say, that by using Bitmovin’s v6.0 Adaptive Streaming Player, VR and 360° video playback is possible on all major browsers, including Chrome, Firefox, Internet Explorer, Edge and Safari (Mac OS + iOS). Another prominent change with regard to our VR and 360° video plugin is the new icon in our default skin. It enables the user to easily toggle between the rendering modes for VR headsets and desktop/mobile usage. But there is lots more that has been improved!

We have also added the support of 180 degrees and side-by-side 3D content, as well as improving the detection capabilities of such videos and error handling to the cross-platform enhancements.

Improved Performance While Reducing File Size
Within v6.0 we have been able to further reduce the startup time – the time between hitting the play button and when the first frame of the video is displayed. You can read about why this is of major importance to your streaming application and how it can help you keep your subscribers in our post 3 reasons users leave a video website. We also performed an extensive re-factoring of our Flash based fallback player, (which is now only used as a rendering engine) and major parts of our JavaScript code base. It resulted in a significant reduction (approx. 65%) in the entire player size.

As well as that, we have enhanced the player with additional analytics capabilities, improved error handling, and introduced the possibility to setup the player without a source stream. A detailed migration guide from v5.x to v6.0 can be found in our support section.
What’s Next?
For our next release, we have already started working on the support for MPEG-DASH Multi Period and HLS discontinuities, which can be used for scenes or chapters, or to separate ads from program content. Stay tuned.

All the best,

Reinhard & the Bitmovin Team
The post Bitmovin Player Version 6.0 is Lighter & Faster with Interactive Ads & Cross-Platform VR appeared first on Bitmovin.
]]>