When choosing between a commercial player and building out an open-source option, there are many factors to consider. Cost is always the major driving factor, but it doesn’t always reflect the resources required for development. In this blog, we will discuss some recent findings from the Bitmovin engineering and integrations teams on what it takes to build a playback solution fit for modern streaming services. We will be focusing on the engineering time required for building such a solution in-house, using open-source and native technologies, versus leveraging a commercial player where many of the necessary items are pre-built. It’s important to understand the short and long-term effects of the decision as it can have a very high and lasting impact on development teams, either keeping them snowed under with necessary maintenance or freeing up time to create unique value for the service.
To get right into it, let’s take a look at the pros and cons of both choices.
Pros & cons of choosing an open-source player:
Pros:
- It’s free; open-source players have no license fees
- Offers flexibility to create your own plugins and integrations
- The in-house team is in full control over the player development
Cons:
- Requires large initial investment (developer time and costs) to get up and running to the standards of modern streaming services
- Requires in-house team to have or gain video streaming expertise
- Restricted by the limitations inherent in the open-source player’s architecture
- Only have community support available to help the in-house team should any issues arise
Pros & cons of choosing a commercial player:
Pros:
- Speeds up the deployment time while providing robust performance and feature-set
- Player maintenance and new market trending feature development as part of the package
- Leverage a team of technical video player experts rather than hiring in-house
- Frees up time to focus on core business value
- Access to existing pre-integrations with a wide Partner ecosystem
Cons:
- It’s not free; commercial players have license fees
- Usually has less flexibility for creating integrations for the player
- Restricted by the limitations inherent in the open-source player’s architecture
As can be seen from the breakdown above, there are strong reasons to go with either option. So, ultimately, the decision comes down to a trade-off between cost and flexibility.
Spoiler: At the end of this blog, we’ll discuss how Bitmovin is addressing this decision by offering customers the performance of the Bitmovin Player with the flexibility of open-source, but more on that later.
TCO: Comparing open-source to commercial players in 3 scenarios
When it comes to cost, it is important to understand the break-even point: At what point does licensing a commercial player become more cost-effective in terms of development resources and delivery time than building an in-house system based on open-source?
Below, we will discuss 3 streaming service scenarios of increasing complexity: browser-based, Multi-platform, and enterprise. For each, we will explore how Bitmovin’s Player integrations compare to building in-house solutions by focusing on ‘Time to Market’ and ‘Annual Maintenance’.
Person-Months definition:
As an industry standard, we will use Person-Months to reference how much time it would take a single engineer working full time to complete a project, i.e., 6 PMs = 1 person working full time on a project for 6 months. Note that we will not assume that tasks could be done in parallel by multiple engineers, as in many cases this is not possible; therefore, 6 PMs does not necessarily mean the same work could be achieved in 3 months by 2 engineers, and even less likely in 1 month by 6 engineers.
Scenario 1: Browser-Based Streaming Service
Estimated time showing the difference between what is saved scenario 1 by deploying the Bitmovin Player compared to open-source players – 60% to 90%
Factor 1 – Time to Market – Feature Aspects:
In this scenario, we focused on browser-based streaming only, which requires the fewest devices and features to satisfy viewers of the 3 scenarios. Here the playback experience includes no additional integrations like Ad insertion or content protection, though there may, however, be other feature requirements needed to satisfy the audience and maintain a higher user experience, such as
- Accessibility standards
- Closed caption handling (formats, rendering, styling, metadata)
- Player user interface modifications
- Graphic overlays
- Additional metadata parsing
Just for these features alone, when developing on an open-source player, our team estimates this feature work to take up to 1 person-month.
Factor 2 – Time to Market – Adding QA and Event tracking:
Depending on the size of the audience, services will want to consider both:
- Player test suite for release automation
- Simple analytics/statistics to monitor usage and engagement metrics
For both of these items, our team estimates that it will take about 4 person-months to get a basic test suite and an event-tracking analytics service up and running.
Altogether, we estimate it will take up to 4 person-months just to get up to speed with the experience viewers expect and a service level internal engineers can work with. This is in contrast to the estimated up to 1 person-month to complete an integration of Bitmovin’s Playback solution, freeing up 3 person-months.
Factor 3 – Annual Maintenance:
Whether it’s adapting to changes or edge cases in different browsers, improving the test suite or simple bug fixes as they’re reported, we estimate this collectively to cost an engineering team between 2-4 person-months each year. In comparison to the less than 1 person-month a year required for just reporting issues to Bitmovin and updating to the latest Player versions once the Bitmovin engineers have resolved them.
Total time saved by utilizing Bitmovin’s Playback solutions
- Time to Market: 3 person-months
- Annual Maintenance: 1-3 person-months per year
Scenario 2: Multi-platform Streaming Service
Estimated time showing the difference between what is saved in scenario 2 by deploying the Bitmovin Player compared to open-source players – 60% to 80%
Factor 1 – Time to Market – Additional devices:
In addition to the work required to create the browser-based experience, multi-platform streaming services will also be required to reach their viewers on mobile devices. Video playback on Android and iOS devices is a different beast to web browsers; for one thing, there isn’t the option of having multiple open-source players to choose from, in-house solutions will need to be based on the native players:
- ExoPlayer on Android
- AVPlayer on iOS
While having lots of low-level video logic handled by the native player has its advantages, engineers are still required to develop non-base features and customizations on top, all while being restricted by what’s possible in the Android and iOS environments.
Factor 2 – Time to Market – Monetization:
With a multi-platform streaming service having a large enough user base, it will likely mean these services are thinking about other ways to monetize, such as advertising. Without having the pipeline to encode the ads themselves, client-side ad insertion (CSAI) is the first option for streaming services, with Google’s IMA SDK being the standard way to integrate CSAI into a streaming workflow (read more on our blog about CSAI and SSAI). Interactive Media Ads SDK handles the ad playback by using a separate video element, leaving streaming services to focus on controlling the main content. However, while integrations for this SDK exist for open-source players, there are still features that aren’t available out of the box, such as ad scheduling, which will require extra development work.
Another consideration aside from monetization is protecting content from unauthorized viewing or distribution using technologies like DRM (Digital Rights Management). Additional integrations like DRM will require configuration on the player to set up, with use cases like multi-DRM being more complicated than others.
Our engineers anticipate up to another 6 person-months, with Mobile and CSAI integrations accounting for most of that time, bringing it to a total of 10 person-months to get to market with the expected viewer experience of a multi-platform streaming service. This is in contrast to the total of 3 person-months required to integrate Bitmovin’s dedicated SDKs for Web, iOS, and Android platforms into the various websites and applications, as well as make use of the pre-integrated IMA SDK for Ad insertion; or use the dedicated Bitmovin Advertising Module for more control over the ad playback experience.
Factor 3 – Annual Maintenance:
On a recurring basis, mobile platforms require lots of maintenance to ensure security and compatibility requirements are met, otherwise other library dependencies may fail, or worse, the app may not be accepted into the Google Play or Apple App Store. Our engineering team estimates they spend over 600 hours annually on just baseline maintenance for both iOS and Android together. In addition, any updates to the IMA SDK or Google’s ad workflow in general will need to be accounted for. Including the maintenance required for the browser-based streaming service, we estimate an in-house solution to collectively cost an engineering team 4-6 person-months per year.
This is in contrast to the less than 1 person-month a year required for just reporting issues to Bitmovin and updating to the latest Player versions once the Bitmovin engineers have resolved them.
Total time saved by utilizing Bitmovin’s Playback solutions
- Time to Market: 7 person-months
- Annual Maintenance: 3-5 person-months per year
Scenario 3: Enterprise Streaming Service
Estimated time showing the difference between what is saved in scenario 3 by deploying the Bitmovin Player compared to open-source players – 70% to 80%
Factor 1 – Time to Market – Additional devices
Building on the work required for a multi-platform streaming service, the enterprise streaming service use cases are far more complex, and so are where the most amount of engineering time can be saved. Viewers using the largest streaming services on the market will expect to be able to stream on every device, particularly focusing on the Living Room, i.e., SmartTV and other connected TV devices such as game consoles and set-top boxes (STBs). A standard set of such devices would include:
- LG WebOS TV
- Samsung Tizen TV
- Hisense TV
- Vizio TV
- Playstation 4 & 5
- Xbox
- Comcast STB
- Sky STB
- Roku
Of these 10 devices, besides Roku, all make use of browser-based playback, meaning an HTML5 player could be used. However, unlike browsers, these connected TVs and devices can have varying hardware and software specifications that will inevitably cause issues with the playback experience. An example of this is Hisense and Vizio TVs, which have a lot of fragmentation in the specification of their TVs (even those released in the same year), meaning different issues could appear on two seemingly similar models. Additionally, different devices could have different browser implementations, like in the Managed Media Source (MSE) API; differences in the MSE implementation could mean services may need to have multiple DRM technologies or separate delivery pipelines for specific devices. Also, as mentioned, Roku is not browser-based and requires its own native implementation.
All in all, our team estimates about 5-14 person-months to add support and integrate with a set of the aforementioned devices. One important note to add to this is that these estimations do not include adding this set of devices to any sort of test automation system for physical device testing.
Factor 2 – Time to Market – Additional Features
With enterprise-level device coverage comes the expectation of enterprise-level features, which are likely only possible due to the necessary backend/pipeline created during a streaming service progression to this size. These use cases may include implementing Server-Side Ad Insertion (SSAI), which can cause many complications on Smart TV devices in particular; such as switching between DRM-protected content and clear (no DRM) content, as well as buffer management, simply due to non-standardized native API implementations and/or the absence of proper logging. Our team goes into more detail about SSAI and its challenges in this blog.
Another example of an enterprise use case is low latency streaming, which again not only comes with its own implementation challenges but also a lot of work to understand platform-specific limitations. For example, lower-end devices, such as STBs or pre-2018 TV models with less processing power, could struggle to keep a stream at the live edge without stalls, not having a large enough buffer to stabilize playback. For this feature development and additional troubleshooting per platform, our team estimates somewhere between 6-12 person-months to achieve a functional enterprise player solution.
Given the 10 person-months required for the multi-platform streaming service, the additional work to achieve an enterprise workflow with an in-house solution is at least another year. However as not all devices or streaming workflows are crucial to every service in the first few years, we estimated an additional 14 months is sufficient to add a few connected TV devices and implement SSAI on these platforms.
All in all, we estimate a total of 24 person-months to get to market with an in-house enterprise playback solution that meets the expected viewer experience. This is in contrast to the 8 person-months required for integrating Bitmovin’s Player SDKs with dedicated modules for specific devices and intuitive APIs to abstract away the nuances of the native platform APIs. Not to mention removing the learning curve; all the browser-based devices would use Bitmovin’s Web SDK and, therefore, a single set of APIs, whereas an engineer for an in-house solution would need to have very in-depth knowledge of each platform’s unique properties and APIs. On top of all this, streaming services can leverage the expertise of Bitmovin’s solutions and integrations teams, who can offer expert advice on best practices / industry trends, and even get hands on with assisting streaming services to get to market as quickly and painlessly as possible.
Factor 3 – Annual Maintenance:
Like most consumables nowadays, manufacturers are launching new device ranges every year (or more), meaning that viewers are getting newer TVs, smartphones and game consoles every year. This creates a requirement for continuous testing on both new and existing platforms to ensure compatibility and an uninterrupted experience for all viewers across all devices. Device testing can be especially challenging with regional devices or devices with high fragmentation in hardware and software, where debugging and reproducibility can be difficult. Given the complexity of the enterprise workflow and how many moving parts there are in the delivery chain at any one time, integrity maintenance can be very time consuming, and as such, our engineers estimate it to be an additional 8+ person-months per year. This doesn’t include any additional feature maintenance that may come up; in the examples of Low Latency and SSAI workflows, there are new protocols, metadata and managing technologies being added to the industry standards all the time which may want/need to be implemented by enterprise streaming services to remain competitive.
On top of the multi-platform streaming service annual maintenance, our team estimate up to an additional 12 person-months per year for enterprise services.
In comparison to the estimated 1 person-month per year in annual maintenance for using the Bitmovin Player, where all the device stability testing is done as part of the service, along with handling all the nuances of updated protocols and standards in the industry. This time is mainly just for reporting issues to Bitmovin and updating to the latest Player versions once the Bitmovin engineers have resolved them. Services can further save time by getting weekly stream health reports from Bitmovin’s Stream Lab, where customers can submit streams to be tested on physical devices like Smart TVs, game consoles, browsers and STBs.
Total time saved by utilizing Bitmovin’s Playback solutions:
- Time to Market: 16+ person-months
- Annual Maintenance: 11+ person-months a year
Summing up the scenarios
In conclusion, these numbers are now a valuable tool for any streaming service to consider and make sure they’re choosing the best option. However, these numbers are only a guide constructed from our collective experiences at Bitmovin and so aren’t going to apply to every use case strictly. They can, however, at least spark the right questions when it comes to the ROI of ‘build-or-buy’. Namely, to use the enterprise use case as an example, the question is: does getting to market 16+ months sooner, and so 16+ months generating ad and subscription revenue, outweigh the cost of a commercial player license?
If you have any questions about the contents of this article, please feel free to get in touch.
A solution that fits the best of both worlds
In addition to the cost/resource-focused rationale behind the decision to use open-source vs. commercial, the other large factor we hear in the market is the desire for flexibility. Traditionally and by nature, the open-source model allows engineers full control and flexibility over their system, while commercial solutions tend to be more closed off. Until now.
At Bitmovin, embracing the benefits of open-source, we’re resolving the flexibility aspect of a commercial player with our next Web Player SDK, Player Web X. This new Web Player benefits from a completely new architecture, which most notably has an open-source plugin system. It gives engineers the performance of the Bitmovin Player with the flexibility of open-source. You can see more about Player Web X on our dedicated Player Web X page.
