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
Test for video seeking time taken between the Bitmovin Player Web X, HLS.js, and Shaka Player
Test for video startup time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player
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.
Test for video seeking time taken between the Bitmovin Player Web X, HLS.js, and Shaka Player
Test for video startup time taken between the Bitmovin Player Web X, HLS.js, Video.js, and Shaka Player
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.
