How to build a Netflixlike multiscreen OTT service.docx

1、How to build a Netflixlike multiscreen OTT serviceWith the fall of Megaupload, legal VOD sites are quickly gaining back popularity as consumers are eager to watch fresh video contents on all their connected devices. If you are a content owner, a TV channel or a telco, it may be the right time to (re

2、)launch you Multiscreen OTT VOD offer. This post intends to start from the reference tech choices in this game Netflixs ones explain the major challenges of such type of service and the associated DRM issues, and finally drive you throughout the different market options you have to setup your own se

3、rvice on a close basis(this part is covered inpart 2 of the post). Everything would have been easier if Netflix did sell its solution as a white label platform, but its not (yet) the case, so this leaves fun territories to explore !As a background information, this post is based on the authors exper

4、ience of deploying a Multiscreen OTT service for a major French broadcaster while relying on SyncTV as solution provider, as well as other studies for telco use cases.Learning from NetflixTo make a long success story short, Netflixs one relies on several key technological choices :Netflix API Device

5、 Endpoint principle-API reign: their API, launched in 2008, is the foundation of all their platform, the alpha & the omega of service reusability and agile development on a maximum of heterogenous client platforms. They got clever API architecture with dedicated endpoints by devices (read latestAPI

6、architecture redesignstory here) to optimize the data exchanges, API degradability strategies Watch presentationby Daniel Jacobson, Director of Engineering, API This is definitely the major key of Netflix success and the reason why their API generates the most traffic in the US for a single service.

7、 API development shall definitely be on your top priority list-Wide cross-platform client support: Netflix is now available on hundreds of different client platforms (PCs, smartphones and tablets, game consoles, connected TVs and BluRay players, connected media players) allowing to start and finish

8、playback everywhere the consumer wishes. If you dont provide multiscreen support, your service is bound to fail, so you must invest heavily on this topic and hire a crew of bleeding-edge frontend dev ninjas.Netflix PS3 UI-HTML5 mutualization: while not (yet) all of their client applicationrely on HT

9、ML5as a the UI medium, Netflix made a substantial investment on this technology as it conveys a definitive advantage as regards developments mutualization and flexibility of UI repackaging. They proved that on controlled environments, the HTML5 user experience has nothing to envy to native apps. Giv

10、en the fact that consumers are increasingly facing HTML5 frontends, their tolerance to less-shiny UI experiences tends to raise, and thats a good point for you. It gets complicated currently if you cant deploy your own engine and have to rely on various HTML5/video/DRM combos but still its a good ta

11、rget for keeping the dev budgets low.-Custom Webkitengine: to achieve the cross-platform reusability of their custom developments and optimizations, they went for building their own flavor of Webkit+QT engine and use it as basis for the SDK they propose device manufacturers to integrate. This may be

12、 the impossible target to reach for you, as this requires a leveraging power that few brands apart from Netflix do have on the market today.-Streaming secret sauce: Netflix relies on acustom DASH subset+PlayReady DRM(with a confirmed pinch of Widevine DRM for the Wii) bundle that they embed in their

13、 SDK and use on (almost of) their client deployments. It allows them to produce the strict minimum of packaged streams variants and therefore to minlimize their storage needs. While this combo might not be available as a standard on your various target platforms SDKs, its a good objective for your p

14、roject on the long run. Additional DRMs might be required to cover the whole clients range, though.-Cloud hosting &transcoding: bymigrating their platform to the cloudduring the past year, Netflix has achieved an incredible jump towards scalability and failover. While this might be overkill for a me

15、dium size OTT project, it gives a good clue of how you can achieve dimensioning for both content preparation/service and massive API service. This is also one of the most rocket science topics in the panorama, so youll need sharp backend/workflow talents to achieve a similar deploymentOTT service co

16、mponents and decision criteriasTo build your Netflix-like service you will need to develop or integrate a wide range of service components (see following diagram for required blocks). Here is an insights list on key points to evaluate when choosing or building a solution.Multiscreen OTT Service Refe

17、rence ArchitectureGeneral points Time to market: this will be the key difference between technology options. Building everything from scratch results obviously in the longest TTM and highest challenge. With the most packaged market solutions, 6 months is typically the minimum delay to get deployed o

18、n the first devices and the delay gets higher if the starting point for client apps is only the service API and not full-fledge reference apps. DRM coverage: choosing the right technical partners or recruiting experts in this domain is a key success point as DRMs are mandatory and there is a good ch

19、ance that several of them will be used to cover all the target devices. This implies making sure from the beginning that adding new DRMs on the platform will not highly impact backend architecture thats the role of DRM umbrella servers (Netflix licensed IrdetoActiveCloak) who provide a unified backe

20、nd interface to all DRM servers flavors and mutualizedbusiness rules : see specific DRM chapter below. Deployment model: whether your API platform will be deployed fully in the cloud, on a SaaS mode or on-premises/self-hosting, this will impact the planning and change the level of difficulty. While

21、cloud deployment seems to be the most straightforward, its also a source of concern over redundancy. Not-in-the cloud SaaS brings concerns about SLA/scalability and self-hosting requires time to reach the required failover and dimensioning levels. Automation: it may sound trivial but no one should u

22、nderestimate the need to perform automated tasks in OTT platforms, ranging from sending targeted emails upon very specific customer situations to triggering backup plan when media ingests fail or increasing platform availability dynamically when load gets higher. UltraVioletcompliance: while it may

23、not yet be a topic today, there is a chance that UltraViolet finally manages to become a new standard in digital media business as BluRay did for physical media, which means that your platform will have to integrate with other service providers using this interoperability method. Being compliant sin

24、ce the beginning thus means being right on time when the market confirms its choices. Second-Screen support: this subject being ahighly popular feature nowadays for live (and soon for on-demand contents), your chosen solution must allow linking of complex and various metadata to the programs (the ac

25、tual datas being hosted somewhere else) as well as their synchronized display on smartphones and tablets. This means integration with the rightwatermarking or fingerprinting technologieson the backend and support for the synchronization inside the frontends.Content preparation (transcoding/DRM) Depl

26、oyment model: for transcoding and DRMization, you can meet several types of deployment models. Theon-premises modelis the old-fashioned one where you transcode and DRMize contents with your own processing farm : good thing about this one is that you know how it performs and that you can adjust workf

27、lows more easily. The bad thing resides in the fact that its not quick to scale and that it can require tricky engineering to integrate all needed DRMs or produce exotic stream format+DRM combinations, depending on which transcoding farm you are using. TheSaaS modelis interesting because it offloads

28、 the engineering charge and the scalability issue on the service provider you choose, but this probably wont be a dedicated platform with instant scalability, so your contents will be processed alongside or after other clients ones, meaning long hours of wait until the packaged contents gets availab

29、le in the catalogue. Finally, theCloud modelallows to benefit from scalability and recent evolutions towards GPU acceleration of EC2 instances, but few providers are already offering the right combination of speed, security and DRMization flexibility youll need. It might be more suited to use the Cl

30、oud to offload jobs when on-premises capacity has been reached. Assets mutualization: here the game is to minimize the number of assets that you will have to produce in order to deliver to all your target devices. Thats not an easy task for the moment as PC and mobiles/tablets are a bit ahead of con

31、nected TVs as regards ABR streaming support and DRM support but situation is evolving quickly and, given the fact that PlayReady for HLS has not been normalized as expected by Microsoft (instead, they did put all their efforts behind DASH support), the HLS+PlayReady combination can just be considere

32、d as a quick-win before a general migrationto a DASH-based combinationin 2013. As of now, the panorama is a bit puzzled, and you have to provide monoblock and fragmented formats with different DRMs in order to support the current devices generations and brands. So the platform you choose must support current chaotic requirements and allow smooth&quick migration to more federating standards like DASH combined with PlayReady or Marlin. ABR support:HLS/SMOOTH/HDS/DASH. Thats what you need to support to deliver to current and upcoming devices whi