csperkins.org

Adaptive Media Transport Workshop

I attended the Adaptive Media Transport Workshop held at Cisco in Issy Les Moulineaux, Paris, on 18-19 May 2015, and organised by Ali Begen. The goal of the workshop was to bring together those in industry and academia working on adaptive video streaming over the Internet, with a focus on technologies relating to MPEG DASH.

Adaptive Media Transport Workshop

A key feature was scale. Deployments serving tens of millions of clients are commonplace. A large US provider described their CDN infrastructure. This delivers content from ten data centres, for different regions, heavily loading 100 gigabit Ethernet network infrastructure in each. They use a three layer CDN caching hierarchy, with the mid-tier having total capacity on the order of hundreds of terabytes, and the edge cache layer holding around 10 petabytes (this excludes caches in set-top boxes within subscriber premises, which are hundreds of megabytes per device). Typical object lifetime in the cache was noted to be around 30 seconds, but the distribution wasn't given. While this is clearly a relatively large deployment, I didn't get the sense that its scale was a surprise to the attendees.

There seems to be a strong industry push to move towards solutions based on MPEG DASH for cross-platform interoperability, but with a large installed base of HLS clients. As would be expected, there are compatibility concerns around DASH, with various different profiles and subsets in wide use. This manifests itself in problems building clients that work with multiple operators deployments. It's also an issue for operators that need to ingest and aggregate content from different sources, who have to deal with a mixture of DASH variants as well as legacy non-IP based content.

Latency is a significant concern. The overall latency of the system is high, but expected due to encoding delays, profanity filtering, and so on. There are issues because latency is higher than for other delivery mechanisms, and because channel change latency is high. A particular concern, that was raised multiple times, is synchronised play back of content on multiple devices, and the lack of synchronisation between content delivered via DASH and that delivered using legacy mechanisms. This is very visible if customers run multiple devices within a home. There are known solutions for synchronised playback of DASH content on multiple devices, and to reduce latency starting streaming before each chunk has been encoded, but they require significant engineering effort to deploy. Many of these mechanisms move the system closer to the model adopted by RTP-based systems, but running over HTTP transport rather than over UDP. There are also experiments with running HTTP over UDP (e.g., Google QUIC transport) to reduce latency, and making use of active queue management and ECN. The developing model is very much a content-centric network, deployed incrementally using HTTP as the narrow waist of the protocol stack.

Concern was expressed over the state of smart TV infrastructure. These devices are built to tight deadlines, and the vendors have only limited experience in Internet-connected software development, and generally make no provision for software updates after deployment. This causes compatibility issues, but there are also significant security concerns around such devices.

There was also much discussion of quality of experience monitoring, what infrastructure is needed, and what are appropriate metrics to capture viewer satisfaction. Other topics included mobile video, how to predict available capacity for model users to optimise content delivery, and congestion control for mobile delivery.

Opinions expressed are my own, and do not represent those of my employers or the organisations that fund my research.