Innovation

Player Web X – A New Player for a New Era

Tom Macdonald
Jacob Arends
. 6 min read
Player Web - Bitmovin

Over the past few months, we’ve given insight into how we were evolving as a team and updating the Bitmovin Player for the future with our past blogs on “Why Structured Concurrency Matters for Developers” and “Developing a Video Player with Structured Concurrency”. In this third and final installment, the moment has finally come to highlight and detail our latest development and welcome the next iteration of our Player’s Web SDK.

Player Web X, or Web Player Version 10, is the newest innovation from the Bitmovin Player engineering team and is already showing promising results compared to other players on the market.

In this blog, we will go into more detail regarding the framework, the Player proof of concept (POC) our team built within just 2 weeks, and our path to making it a minimum viable product (MVP).

Reinventing Playback – Player Web X

The new player was built using a new framework, which was reimagined and built from the ground up using structured concurrency (see previous blog). The architecture of this framework allows for a lot of flexibility and, ultimately, optimal performance.

Because of this, Player Web X is specifically designed to be lightweight and performant. This has the benefit of providing the highest quality of experience for viewers and a great developer experience for those deploying a streaming service.

Notably, Player Web X’s enhanced performance is not limited to high-end devices, as keeping performance optimal on lower-powered devices such as Smart TVs and STBs, where hardware can play a limiting factor, is often more important to ensure a similar experience for all viewers.

In order to validate the performance benefits of this new framework and POC player, we have run some benchmarking experiments against industry-leading open-source web players. We’ll discuss the details further down, but one of the reasons we find Player Web X’s performance impressive and promising is that it’s based on our 2-week POC, which has yet to be production optimized.

Benchmarking – The Results 

For these benchmarking tests, we ran a minimum of 40 tests for each player and stream combination for each metric, using Tears of Steel and Sintel.

Three metrics were measured:

  • Video Seeking: The time taken to resume playback after jumping to a random position in the timeline
  • Video Startup: The time taken to begin playback after loading a new source
  • Source Switching: The time taken to switch between two loaded sources

The three open-source players we used were 

  • Shaka Player
  • HLS.js 
  • Video.js

Each web player was set up with the most basic integration without any additional features beyond basic playback (i.e., no DRM, Ad insertion, etc.). The first set of tests was done on a Chrome browser, and you can see the correlating results below:

Graph of each player’s performance on Chrome

Created with Highcharts 10.3.3 Seeking hls.jsPlayer Web XShaka 0500100015002000

Test for video seeking time taken between the Bitmovin Player Web X, HLS.js, and Shaka Player

Created with Highcharts 10.3.3 Startup hls.jsPlayer WebXShakaVideo.js 2505007501000125015001750

Test for video startup time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player

Created with Highcharts 10.3.3 Source switching hls.jsPlayer WebXShakaVideo.js 5001000150020000 hls.js Source switching Maximum: 1 627.603Upper quartile: 1 366.67625Median: 877.6735Lower quartile: 687.66175Minimum: 657.56

Test for source switching time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player

These box plots show the distribution of the 40 test runs, highlighting the median and interquartile range of the data points.

Test Overview on Chrome

Test 1: Video Seeking 

The Player Web X POC has a larger range (total and interquartile) than both hls.js and Shaka player. However, from the graph, you can see the median seeking time for Player Web X is faster than the median time for HLS.js and Shaka Player. Note that Video.js is not represented in this graph because the seeking data points were far higher than the other three shown, and it wasn’t possible to showcase all of them and make the data easily visible.

Test 2: Video Startup 

HLS.js has a very even symmetrical distribution on startup time, while the other three players have some slower startup times that sit far from their relatively short interquartile range. Also, notably, Player Web X has a larger interquartile range than the open-source players, meaning the start time is not quite as consistent. However, 75% of all startup events observed for Player Web X were faster than the median startup times for all the open-source players. Also, as in the video-seeking test, the fastest startup time for Player Web X is faster than the fastest startup time for all of the open-source players.

Test 3: Source Switching 

The interquartile range for the four players is comparable, showing that source switching is not as consistent as startup, given the handling of two sources instead of just one. Player Web X has a larger overall range, though the slowest source switch is still not as slow as the slowest from the open-source players. And again, like with the other metrics, Player Web X’s median value for source switching outperforms the median values for the other players. 

It also has to be mentioned that for all three test metrics, the fastest Player Web X time is faster than the quickest time for all of the open-source players. 

For the second round of testing, we ran the same three tests on a 2021 Samsung Tizen SmartTV, and the correlating results can be seen below.

Graph of each video player’s performance on Samsung Tizen 2021 SmartTV

For the second round of testing, we ran the same three tests on a 2021 Samsung Tizen SmartTV, and the correlating results can be seen below.

Created with Highcharts 10.3.3 Seeking hls.jsPlayer Web XShaka 2004006008001000

Test for video seeking time taken between the Bitmovin Player Web X, HLS.js, and Shaka Player

Created with Highcharts 10.3.3 Startup hls.jsPlayer Web XShakaVideo.js 1k2k3k4k5k

Test for video startup time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player

Created with Highcharts 10.3.3 Source switching hls.jsPlayer WebXShakaVideo.js 125015001750200022502500

Test for source switching time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player

On this device, Player Web X still performs well compared to the other open-source players. It consistently outperformed Shaka player on average on all tests. However, there is a clear area for improvement for Player Web X when compared to HLS.js on this SmartTV device, as across the 3 different tests, HLS.js performed better when compared to Player Web X. We have identified that this is due to two factors: Player Web X parsing is not yet optimized for devices with less powerful hardware like SmartTVs, and the player architecture is based on a heartbeat (using setInterval). Taken together, this leads to delays that are more noticeable on Smart TVs. Both these factors are to be resolved as we continue to improve our codebase, including the plug-ins used in these tests.

Plug-in Marketplace

Modern services require a large number of features and integrations simply to keep up with the conventional experience modern consumers expect. Many streaming companies often feel they may have to fragment their own service in order to accommodate specific features on different devices.

That’s why for Player Web X, we’re creating a new plug-in system to create a more flexible and expansive framework to help clients using the Bitmovin Player, regardless of their use cases. This system will give development teams more control over what is included in their deployed player bundle, removing the need for any unnecessary bloating.

The plug-in system is an extension of the approach we took in Bitmovin Player Version 8 with the module system. However, it is far more extensive, as rather than having modules that extend the player, the plug-in system is built into the framework that underlies Player Web X, meaning that the player itself is built of plug-ins, which can be overridden or extended. This will allow for far more granular and powerful solutions to various use cases.


Additionally, in order to allow our customers to support their own use cases, we will be releasing an open-source plug-in template. This template will enable our clients, partners, and developer community to create their own plug-ins for Player Web X and enhance their service to achieve an optimal and unique viewer experience. This is particularly powerful for teams that want to have the flexibility of an open-source web player with the performance and stability of a commercial player.

Player Web X’s Current Stage and Next Steps

Player Web X is currently in alpha testing with some of our existing partners to help us on the road to making it an MVP. At IBC2023 in September, we will release more interesting updates on its progression and where we are at in the process. In the meantime, if you’d like to become an early adopter or would like more information about any details in this blog post, please get in touch.

Also, if you’d like to see how Bitmovin’s solution stack can benefit your streaming workflow – sign up for our 30-day free trial.

Tom Macdonald

Tom Macdonald

Tom Macdonald is a Lead Engineer at Bitmovin and is a driving force behind the innovation happening in the web player team. His interests include programming languages, and how they can be used to solve problems in better ways. At home, Tom is known for being the type of DIY enthusiast who owns his own jackhammer.

Jacob Arends

Jacob Arends

Product Manager | Playback

Part of the Product team for Bitmovin Playback, Jacob comes from the high pressure world of live sports which fuels his ability to focus on optimizing the quality of experience for both developers creating streaming platforms and the viewers consuming their content.


Related Posts

Join the conversation