OTT实时流：统一的DASH和HLS工作流是神话还是现实？

在过去的几年中，视频流媒体行业一直在致力于实现低延迟OTT传输的解决方案，以便与传统的现场直播广播竞争。最初是通过使用CMAF的MPEG DASH格式实现的，CMAF在MPEG中于2018年1月标准化，随后在2019年10月DVB提供了其DVB DASH规范的低延迟更新。在2019年6月，苹果公司在其全球开发者大会上宣布，正在对HLS协议进行更新以支持低延迟（当然是“ Apple方式”）。

面临的挑战：目前存在两个独立的生态系统，用于以最流行的交付格式DASH和HLS交付实时内容。为了扩展OTT，我们必须合理化这两种方法并找到低延迟的共同基础。

CMAF：融合的基础

作为可能融合的解决方案，通用媒体应用格式（CMAF）是2018年1月标准化的ISO媒体格式，提供了一个有希望的框架。当微软，苹果和其他行业参与者共同提出CMAF标准时，许多人认为融合已经成为现实。

但是事实并非如此，现在仍然不是，而且仍有一些遗漏的难题。希望以两种格式（即HLS和DASH）分发其内容的服务提供商仍然需要在某些时候具有单独的工作流，并且需要在网络中复制媒体文件缓存，这增加了它们的总体成本；这也增加了复杂性，并给OTT业务模型带来了更多压力，因此减慢了OTT部署的速度。

为什么没有实时交付内容的单一工作流程？

低延迟传送是高价值内容（如高级体育节目）的基本功能，它也吸引了最大的听众观看。因此，对于业界而言，现在比以往任何时候都更重要的是找到一种在网络中生成和缓存一组媒体文件以优化处理，缓存和存储成本的方法。从一开始，这就是CMAF的承诺，但是必须消除低延迟传递方法方面的障碍，以使其成为现实。

实际上，Apple在2019年6月提出的低延迟DASH（也称为“ DASH LLC”（低延迟块）和低延迟HLS）（LL-HLS）依赖于不同的工具和协议集进行交付，尽管两者均使用CMAF （包括CMAF块）用于媒体文件格式。前者使用HTTP块传输编码，而后者（仍然是Apple草案规范）使用HTTP / 2和问题更大的HTTP / 2推送方法（未得到广泛部署甚至不被支持），从而使CDN行业

产生了很多回退。

结果，为了提供低延迟的服务，OTT行业仍在努力寻找两组媒体文件，重复缓存和高成本，同时努力寻找可盈利的业务模型。

低延迟的最新更新

2019年底为OTT行业带来了积极变化。苹果公司和其他行业参与者，包括编码，包装，原产地，CDN和OTT播放器的技术解决方案提供商，表示愿意在DASH和HLS之间找到兼容模式以实现低延迟内容交付。

对于业界来说，看到当前的LL-HLS提案草案有一些改进，以最终实现最初的承诺，即拥有真正的媒体文件通用格式和通用的交付工作流程，将是有益的。

内容保护：DRM和广告插入

对于服务提供商而言，内容需要货币化，因此DRM和广告插入工具对于确保服务提供商可以利用OTT环境中的大量创收机会至关重要。作为内容交付的全局工作流的一部分，还应该有一种为这些功能构建通用方法的方法。

现在，所有主要的DRM系统（例如适用于HLS的Apple FairPlay，适用于DASH的Google Widevine和Microsoft PlayReady）都对CBCS加密方案提供了统一支持。通过这种方法，无论使用哪种DRM系统，单个媒体文件都可以CBCS格式加密并分发给任何播放器。这实现了CMAF的最初承诺。仍然需要围绕DRM进行详细的讨论，但是行业正朝着正确的方向发展。

OTT服务提供商越来越多地使用广告插入，尤其是动态和有针对性的广告插入，以使广告更加相关。通过动态广告插入解决方案，服务提供商可以为广告商创造更多价值并改善最终用户体验，

从而显着提高OTT收入。

为了使目标广告取得成功，服务提供商需要通过流畅的动态广告插入来确保无缝的视频体验。目前正在仔细检查DASH和HLS低延迟规范，以确保可以使用或略微修改遗留工作流中使用的行业惯例，以考虑到较短的交付路径带来的其他限制。必须更新HLS和DASH的指南，以正确使用时

间信息在低延迟流中插入广告。这项工作仍在进行中，但是希望可以实现通用的工作流程。

结论

在Harmonic，我们认为行业必须开发一个基于CMAF的统一Live OTT流系统，该系统支持：通用加密（已使用CBCS完成），广告插入和两种交付格式（HLS和DASH）的低延迟。

在这种方法下，媒体文件仅存储一次，从而节省了处理，存储和交付成本。而且，当然，可以始终分别缓存两个不同的HLS和DASH清单。

这将创建一个优化的交付方案，使OTT运营商正在寻找的所有关键功能成为可能。未能做到这一点将分散市场，使OTT的利润减少，并拖慢其发展。