This paper intends to provide an unbiased opinion about the “build vs buy” dilemma for the majority of components in the OTT ecosystem.

 

Why this question (Build Vs Buy)?

One of the simplistic way to measure OTT business success is by measuring customer engagement. And offering a best quality service at most reasonable cost (to end user and service provider) can be considered as one of the prime methods for good customer engagement.

e.g. quality can be treated as a single reference word for literal video quality (with least data consumption), APP UX flows, personalized recommendation, Playback smoothness etc.

And there is a continuous technical advancement in every single example mentioned for the quality aspect above.

And since technology of each of the above explained areas continuously keeps evolving (to offer better results), it is imminent that only those OTT players will stay relevant for longer term who carefully adopt the real advancements (either by developing/implementing these advancements themselves or by buying it from industry partners)..

It is the positive business result driven by new technological innovation, which attracts the input cost to business. Hence the Build vs buy question becomes relevant here.

 

What variable to be looked at while deciding:

There is no “one size fits all” option to choose from, even for the same category of OTT streaming service.

It simply is about the area of focus of an organization. This choice is a combination of:

• Core business (Distributing content or creating technology IP)
• Scale of business (An OTT platform with multi million users or a new one)
• Time to market requirements (time to create the technology for business)

 

Case by case analysis for main OTT components:

Below is an attempt to reach to a build vs buy decision for the major OTT ecosystem components (which can either be developed in-house or bought from 3’^RD party) based on above mentioned organization focus pointers:

Following is a literal mind map of high level components in an OTT ecosystem for this exercise.

MAM/CMS & RMS: (Managing content Ingestion, Rights, Metadata, Subtitles Thumbnails, publishing and triggering transcoding)

Since, these components are the very basic building blocks of the OTT platforms, maturity of these components has reached a level where we can call them commodities now.

i.e. irrespective of the business focus, if an OTT platform already has a fully functional MAM & RMS system built in-house (which does not requires much maintenance and cost), then procurement of a new system must only be looked at in case if, the old system is can not be architecturally scaled to support the growing business and functional requirements  of today.

And if such a platform is required to be procured, then acquiring/licensing a micro services based cloud agnostic product which can offer a perpetual license for use with a minor & optional yearly support cost might prove the best. Since not much innovation in this direction is expected and it might prove economical to get it from outside than investing into resources to build and maintain such commodity type systems.

i.e. “Buy” only if starting a new OTT service (and can get the economic deal (compared to Long term resource cost)) or the existing system are very old and can’t scale beyond a point.

 

Video Encoder & packager:

Though this is also one of the necessary components for any OTT ecosystem; but the quest of providing high quality video with significantly smaller file size is ever continuing. i.e. the video encoding and packaging technology is continuously evolving with major adaptation of codecs e.g. now moving from H.264 to H.265, VP9 and soon towards AV1 and VVC etc. (Where H.265/VP9 proved to be ~30-40% efficient than H.264. and AV1 & VVC is similarly efficient over H.265 and VP9.

Though the higher encoding efficiency will certainly cost higher (since it will be highly resource intensive); but the cost will continuously go down as soon as the chip manufacturers adopt the codec, and the device adoption in the markets increases.

With this in mind, an OTT service is anyway required to be equipped to roll out such advancements to attract users with better quality (and low data cost to him). One such example is netflix’s move to stream content in AV1. This certainly gives netflix the first mover advantage in this.

Considering the technological investments to make the encoding systems ready to deliver streams with such codecs; it is understood that the OTT organization need to commit in such resources to develop/implement such standards in the encoding systems or partner with a suitable organization which is only focused towards delivering these latest technological innovations in the area of video encoding.

For a netflix like organization, who may have large number of teams dedicated only for such technological innovations, the “Build” Option can be suitable (especially since they already are invested into this); for everybody else, it may not be (unless the organization wants to build IP around such technology solutions); since any lag in achieving the implementation of technological Innovations will only leave the company in to “catching up” situation and may not ever be possible to reap benefit of being first mover in this space.

 

Video players: (for all screen types)

Considering 157 million smart TVs sold in year 2019 (Report), it is very clear that the big screen consumption is already on the rise (apart from already prominent OTT consumption numbers on smartphones and web browsers).

And looking at the available number of operating systems for smart TVs, it is very well understood that the technical environment for big screen consumption is anything else but consolidated.

i.e. where the previous focus of OTT service provider was to be able to provide solutions (App, player, DRM etc.) only for android, iOS and browsers; now the complications already increased multi folds since the service providers need to serve to additional platforms to support consumption on big screen such as Smart TVs (Android, Tizen, Web Os, Roku etc.), and connected devices like Firestick TV, Apple TV, Roku, Chromecast (and various other OTT boxes).

And since the end user platforms are very large in numbers, so is the requirement of video and ad playback, DRM integration for security and compliance etc. already requires investment in player solutions for all these platforms.

While it is understood that every platform comes with a native player solution (e.g. android with exoplayer and iOS with AV player) which may be sufficient for many playback use cases, but the complexities related to ad playback and DRM implementation are not to be ignored.

It is also understood that, all of the above complexities can also be solved by the in-house player engineering teams; but by looking at the sheer number of platforms to serve, it again is the question about how big engineering team an OTT providers intends to invest in to (i.e. for dedicated team for first time player integration and continuous technological advancements in player, video encoding standards adaptation in player, growing Ad platform support, and DRM etc.)

One should take the simplistic view on the investment required to build (and timely update) the same solution in-house and to procure the same from a single player provider for all platforms/devices.

E.g. One need to account for at least one engineer for each such platform (i.e. Android, iOS, Browser, Tizen, web OS, Roku (and a few more if required) and at least one architect. And if the same team is utilized for multiple other work directions (e.g. app related functionality etc.) then after the first integration of the native players, the team’s focus will conveniently shift toward addressing the daily APP related requirements. So, the very objective of having a player-centric team to continuously do the technological advancements does not materialize.

Opposite to the above, if the service provider procures an approximately fixed cost solution (which may be very much comparable or even lesser than the human resource cost of the first approach), then they simply have to keep a smaller but focused in-house teams for app integration and not for the player related innovation/developments etc.). Which can give a first mover advantage to many less resourceful service providers as well. This has ultimately proven to be an optimum cost solution especially in case where the maximum screen reach was desirable. However for the limited target screen types, using the native player might prove more prudent.

 

App hardening, Watermarking & DRM: (tools for brand & business protection)

Since production of any content is really an expensive exercise, hence every content provider/creator (which licenses/distributes its content to an OTT service) really wants to make sure the following things:

1. Content must be protected while at rest and while in transition.
2. Content distribution should happen only on the intended target user devices
3. Only the authenticated users should be able to consume the content
4. Content must be protected even after it reaches the client device and is being played or being subjected to output like HDMI, VGA etc.
5. Screen recording on client devices should be controlled.
6. Licensor accepted usage rules for content consumption must be implemented (i.e. Number of devices, number of concurrent/simultaneous streams etc.)
7. Even in case an attacker is able to exploit any new vulnerability, the forensic watermarking solution should be able to detect the rouge device and decommission it.

All of the above requirements are addressed with the combination of app hardening, watermarking, screen recording protection and a multi-DRM solution.

While it is understood that app hardening, forensic watermarking, and anti screen recording solutions are considered good to have (especially if the maximum quality of content distributed is HD); but the DRM solution requirement is mandatory.

DRM technologies and ecosystems had their own path of evolution. i.e. when the main content consumption was around IPTV STBs, any good DRM/CAS provider like Verimatrix, Irdeto, Intertrust, Nagra, NDS, Conax, INKA etc. Were able to put an effort to work with the STB/Chipset partner to certify their DRM to get the acceptance of the IPTV service provider to support HD content distribution on those STB (And additionally on second screen as well (e.g. smartphones)).

However with evolution of android ecosystem and widevine’s acquisition by Google, the Market took a leap towards device ecosystem based DRM solutions, e.g. Google-Widevine for android, Apple-Fairplay for iOS/Mac and playready for multiple devices including smart TVs and microsoft browsers.

This has been a path breaking event in the DRM industry. After this event, the market has migrated from a single DRM solution to multi DRM solution. Since then Google and Apple have started controlling the device certification for their respective DRM. e.g. now only the android devices can get certified with widevine L1 DRM (which is a mandatory requirement by content providers to distribute HD content on android devices). All other DRMs can not get this hardware level DRM support on an android device. Same was the case with Apple as well

I.e. it became mandatory for OTT service providers to implement google widevine and apple fairplay DRM if they wanted to stream HD (And above) quality stream to their end users on these devices.

Playready was added to this list, since many devices (such as Tizen based smart TVs etc.) did not have hardware level DRM support from Google widevine.

This started an unavoidable and complex era of multi DRM solution implementation (Widevine, fairplay and playready) for every service provider which was looking to provide services to the widest device spectrum.

Even though one has to get these 3 mentioned DRM solutions from Google, Apple and Microsoft for an OTT service; build vs buy question is still relevant for multi-DRM implementation.

One can get a license to implement the DRM servers from Google, Apple and Microsoft and do the multi-DRM implementation themselves. But to reach to a fair build vs buy decision, a careful examination of required business & infra scale, infra/scalability cost, Update and maintenance cost, specialized resource cost and finally the DRM fee (to MIcrosoft, Googel and Apple) has to be compared with an offering from a DRM aggregator for same scale.

And since the DRM solution is anyway the same (i.e. widevine, fairplay & playready), there is no possibility of innovation related edge in this direction either by self implementation or by procurement.

Also the problem of keeping the solution updated and providing the renew-ability in case of breach is better addressed by the specialist security solution provider than the generic in-house implementations.

Offering from a DRM aggregator can only become too costly if the scale of business reaches to multiple continents and a mutual consensus on controlled cost based agreement can not be reached by the two parties.

 

Search & recommendation:

Compared to the possible technological advancements in video encoding, player and DRM solutions, the search solutions seem to have already reached maturity. (Since the search needs to be performed on static set of data and there will be a limit on any related advancements there) i.e. Intelligent in-house teams shall be able to stitch-up a potent search solution by utilizing freely available code base etc. (which may not require much maintenance once delivered. So, investing in procuring a search solution shall be considered only if there is no interest in keeping the relevant engineering team. However, this decision shall be considered after build vs buy decision on recommendation system, since many recommendation solution provider offer good ready made solution; So, if the decision on recommendation tilts in favor of “BUY”, then it makes sense to get the search from the same provider as well (as it may not cost much (or may be free))

Journey of recommendation systems has been very different from that of search. Since unlike search , the recommendation can very “dynamic”; i.e. things have moved from simple consumption, genre etc. based recommendations, to AI/ML based complex algorithms which can establish relations between seemingly non related entities. e.g. a famous movie of an actor can be linked to another movie or series, where that actor’s x-wife/wife/kids might have appeared etc.

Implementation of such advanced algorithms may require a fairly intelligent team (mainly on AI/ML/Data-science etc.). If an organization is interested in keeping such resources to fuel future technology based advancements, then the cost of in-house recommendations might be economical with this option (however, the time to market may be dependent on the relevant technology team). Otherwise there are few good solutions available in the market to offer recommendation solutions; however, a major challenge is the ‘cost per transaction’ based recommendation model, which may eventually eat up a significant chunk of the revenue (especially in case of AVOD business).

I.e. procuring an external recommendation system can be thought of in case it can be procured at near fixed cost or on a revenue shared model (at least with the intent of increasing SVOD engagements). For AVOD, either the in-house or a fixed cost recommendation and search looks to be more reasonable.

 

Conclusion:

Yes; unfortunately there is no single silver bullet to address the “Build Vs Buy” query for all of the mentioned components. Since, till now there is no single service provider who offers every single functional component for an end to end OTT service. So, it is very much required for a OTT service provider to first focus on its business objective, time to market and technology/resource investment apatite, experience of technology resources in a given area before deciding for particular components.

While theoretically, everything is possible to build in-house with a very agile and experienced team (experience in all of the different technologies); just looking at the number of components required for an advanced OTT system itself gives away the idea about which kind of investment is one looking at. So, practically,doing mix and match looks to be the best approach. I.e. if one has cost effective engineering expertise in one two or more particular functional areas (e.g. CMS, RMS, Search etc, one should try to develop in house functional components in that area (As long as long-term maintenance is also counted for). For the areas where there is scarcity of experienced resources like video engineering(encoding and playback) then it makes more sense to look for an external partner who can offer better deals at optimal cost.

Services like Multi-DRM are a peculiar case, since it anyway requires a 3’RD party component (which can’t be developed in-house; irrespective of the expertise of resources). This leaves a choice of either keeping a security oriented technical resources for doing the right integration of those three DRM services (in order to avoid any content license violation etc.) or to have a SAAS based Multi-DRM aggregator on board to help with not only the DRM integration but also for taking care of scalability requirements etc.

Careful analysis of spend on required security resources and cloud infra cost for scalability etc. Vs simple transaction based cost (for a smaller number of DRM license transactions) or enterprise model cost (for very high volume) simply answers the query on this front as well.