Europe looks like leading the world into DASH streaming, with concerns over interoperability and availability of clients holding broadcasters and operators back elsewhere. Even in Europe lack of client availability was cited as a significant concern by nine of 13 major broadcasters in a recent survey by the DASH Industry Forum. But most broadcasters considered that the promise of a single standard for HTTP Adaptive Bit Rate Streaming made it worthwhile pushing for DASH as soon as possible, with all but two of the 13 broadcasters planning to have deployed DASH within just over a year, by mid-2014. One has done so already, six plan to in the second half of 2013 and four in the first half of 2014, with only one having no plans at all at this stage.
Enthusiasm for DASH among European broadcasters reflects partly the wide level of catch up distribution and associated streaming costs incurred, along with the incorporation of DASH within Version 1.5 of the HbbTV hybrid TV specification, being widely deployed in continental Europe, spearheaded by Germany and France. Much of the DASH adoption identified in the survey will take place under the covers of HbbTV rather than as a specific action. France has gone furthest by virtually compelling its broadcasters to adopt DASH by mandating its use in clients as part of the country’s TNT 2.0 HbbTV connected TV scheme.
While concern over lack of clients is well known it is really only a temporary handicap given the industry momentum behind the standard. A greater worry for US broadcasters is the degree of interoperability, or lack of it, which was surprisingly not even cited in the DASH Industry Forum survey. This is being addressed by the DASH 264 profile, which is supposed to achieve a similar objective to H.264 for encoding, in providing an agreed stripped down profile that all vendors can develop to. There had been fears that DASH was another case of a standard becoming bloated by covering all the bases at the expense of interoperability. In particular it was attempting to incorporate all the strengths of the existing big three proprietary ABRS standards, Apple’s HLS, Microsoft’s Smooth (MSS) streaming and Adobe’s HDS, while avoiding their pitfalls.
The three have much in common, above all using HTTP streaming as the underlying delivery method, relying on standard HTTP Web servers instead of dedicated streaming servers. This ensures that the apparatus of the Internet can be used, including existing firewalls. All three use a combination of encoded media files and manifest files that identify the main and alternative streams available for a given client player, along with the respective URLs. Then by monitoring either buffer status or CPU utilization, the players switch streams as necessary to optimize quality, locating the alternative streams from the URLs specified in the manifest.
But all three are closed commercial platforms with their own formats for the manifest providing the essential details of the content such as the DRM, as well as different encryption methods and streaming protocols, making interoperability out of the question. The three also require somewhat different tuning for optimum performance, with HLS for example requiring a download of a manifest file every time a new chunk is available. This makes it desirable to run the system with chunks of longer duration to minimize the overhead of repeated manifest downloads, but at the expense of slower dynamic response to changing network conditions, with slight implications for quality.
Some of the differences are at a higher level with distinct implications for broadcasters and content owners, such as the lack of a defined way to append subtitles to video in HLS. Of course Apple is constantly improving HLS, but that gives rise to another complaint, which is that there is no other source of input and in some cases backwards compatibility with older versions is lost.
At the same time HLS is well attuned to Apple’s own ecosystem and devices, which is one of the commercial factors behind the company’s reluctance to embrace DASH despite having originally been one of its main contributors. Apple’s strategy appears to be to continue milking the advantages of HLS across its own ecosystem for now while being in a position to hit the ground running with DASH with a robust implementation if and when the time is deemed right.
Meanwhile European broadcasters are citing two other advantages of DASH, one not surprisingly being support for CENC (Common Encryption) in the DASH 264 profile, which will greatly reduce encoding costs and increase the efficiency of caching, by avoiding the need to hold multiple versions ready to serve different clients.
Another positive factor not directly related to DASH is the ratification of HEVC (High Efficiency Video Coding) early in 2013, halving the bit rate required to deliver video at a given quality compared with H.264. DASH is supposed to be codec agnostic, but in practice there are efforts from both sides to make implementation easier ‘ for example DASH bit stream switching modes are now supported in HEVC. The two are likely to converge further into a common packaging framework for IP delivery. In the DASH-IF survey 10 of the 13 broadcasters cited HEVC as one of the formats they would support within their forthcoming DASH deployments.
The support in DASH for the concept of periods has also been welcomed, as this enables insertion of material such as targeted ads, even if they are formatted and packaged in a different way from the rest of the stream, again bringing encoding and asset management efficiencies. But in a sense such facilities highlight the continuing fluid nature of DASH and the fact that adaptive streaming as a whole has some way to evolve. This means that attempts to nail down a profile in DASH 264 are aiming at a moving target and will not immediately deliver the dream of a common standard for packaging and delivering content over unmanaged IP networks. But DASH 264 does at least signal intent and should give operators confidence that MPEG DASH does represent the future for multiscreen deployments, even if for the present they cannot rely on it for interoperability and will still have to support more than one adaptive streaming protocol.