Over the past several years, the video streaming industry has been working on solutions to achieve low-latency OTT delivery in order to compete with traditional broadcast of live content. This was initially achieved with the MPEG DASH format, using CMAF, standardized in January 2018 by MPEG, followed in October 2019 by DVB delivering the low latency update of its DVB DASH specification. In June 2019, Apple announced during its Worldwide Developers Conference that the HLS protocol is being updated to support low latency, (the “Apple way,” of course).
The challenge: Two separate ecosystems exist today for the delivery of live content in DASH and HLS, the most popular delivery formats. In order for OTT to scale, we have to rationalize the two approaches and find a common groundwork for low latency.
CMAF: A FOUNDATION FOR CONVERGENCE
As a solution to possible convergence, Common Media Application format (CMAF), an ISO media format standardized in January 2018, provides a promising framework. When Microsoft, Apple and other industry players came together to propose the CMAF standard, many believed convergence was a done deal.
But this was not and is still not the case, and there are still some missing pieces to the puzzle. Service providers that wish to distribute their content in both formats (i.e., HLS and DASH) still need to have separate workflows at some points and duplication of media file caching in the network, which increases their overall costs; it also increases complexity and puts more stress on the OTT business model and therefore slows down OTT deployments.
WHY ISN'T THERE A SINGLE WORKFLOW FOR LIVE CONTENT DELIVERY?
Low-latency delivery is an essential feature for highly valuable content such as premium sports, which also drags the largest audience for live. Therefore, now more than ever, it is important for the industry to figure out a way to produce and cache a single set of media files in the network to optimize processing, caching and storage costs. This was the promise of CMAF from its onset, but hurdles with regards to low latency delivery methods need to be removed to make it a reality.
Indeed Low Latency DASH, also called “DASH LLC” (Low latency Chunk), and Low latency HLS, as proposed by Apple in June 2019 (LL-HLS), rely on different sets of tools and protocols for delivery, despite both using CMAF (including CMAF chunks) for the media file format. The former uses HTTP chunk transfer encoding while the latter (which is still an Apple draft specification) uses HTTP/2 and the more problematic HTTP/2 push method (not widely deployed or even supported), creating a lot of pushback from the CDN industry.
As a result, for the delivery of low latency services, the OTT industry is still grappling with two sets of media files, duplicate caching and high costs while fighting to find a profitable business model.
THE LATEST UPDATE ON LOW LATENCY
The end of 2019 brought about positive changes to the OTT industry. Apple and other industry players, including technology solution providers for encoding, packaging, origin, CDN and OTT players, expressed the willingness to find a compatible mode between DASH and HLS for low-latency content delivery.
It would be beneficial for the industry to see some evolutions on the current draft LL-HLS proposal to finally achieve the initial promise of having a real common format for media files and a common delivery workflow.
CONTENT PROTECTION: DRM AND AD INSERTION
For service providers, content needs to be monetized, so DRM and ad insertion tools are therefore critical to ensuring that service providers can take advantage of the abundant revenue opportunities in the OTT environment. As part of the global workflows for content delivery, there should also be a way to build common methods for these features.
There is now unified support for the CBCS encryption scheme by all of the major DRM systems such as Apple FairPlay for HLS, and Google Widevine and Microsoft PlayReady for DASH. With this approach a single media file can be encrypted in the CBCS format and distributed to any player, no matter what DRM system is in use. This fulfills the initial promise of CMAF. Detailed discussions still need to take place around DRM, but the industry is headed in the right direction.
Ad insertion—in particular dynamic and targeted ad insertion—is increasingly being used by OTT service providers to make ads more relevant. Through dynamic ad insertion solutions, service providers can dramatically boost their OTT revenues by creating more value for advertisers and improving the end-user experience.
For targeted ads to be successful, service providers need to ensure a seamless video experience, with smooth dynamic ad insertion. Both DASH and HLS Low Latency specifications are currently scrutinized to make sure the industry practices used in legacy workflows can be used or slightly adapted to take into account the additional constraints brought about by the shorter delivery path. Guidelines for both HLS and DASH will have to be updated to properly use the timing information for inserting ads in the low latency streams. It is still a work in progress but there is hope this can be achieved to enable a common workflow.
At Harmonic, we believe that the industry has to develop a unified CMAF based, Live OTT streaming system that supports: common encryption (already done with CBCS), ad insertion and low latency for both delivery formats (HLS and DASH).
Under this approach, media files are only stored once, which saves processing, storage and delivery costs. And, of course, there are two different HLS and DASH manifests that can always be cached separately.
This will create an optimized delivery scheme that will enable all of the key features OTT operators are looking for. Failing to accomplish this will fragment the market, make OTT less profitable and slow down its development.
Patrick Gendron is director of innovation at Harmonic.
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Technology. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.