使用DASH-IF简化大规模的直播
和其他一些合作伙伴一起, 统一的流一直致力于一个DASH-IF项目，以形成一个实时摄取协议的新规范. 几年前，它开始作为一个内部项目与其他几个供应商, 此前，一家欧洲广播公司强调需要记录实时编码器应该产生的内容. 该规范现在已经发布，可以使用了. 在本文中，我将概述新协议的必要性和开发过程中需要考虑的一些主要因素.
这个项目的合作伙伴是从整个流频谱中招募的，以确保在设计规范时对工作流有一个完整的视图. 包括微软, Hulu, AWS Elemental, Akamai, Comcast, Bitmovin, Qualcomm, Media Excel, Harmonic, atme和CenturyLink.
该项目解决了大规模的OTT直播, 这是出了名的难以支持的，因为有太多的活动部分.
特别是，我们认为有四个方面可以改进:
- Timed metadata: 我们希望简化获取编程信息和其他元数据到fMP4表示. 我们还想考虑信号拼接信息，以实现及时包装和广告插入.
- Reliability: 提高容错性和冗余性, 我们希望OTT工作流能够使用多个实时编码器, 以实现端到端故障转移支持.
- Low latency: 这是在工作流程中建立起来的. 拥有正确的规范和避免额外的转换将有助于OTT提供商达到他们的延迟目标.
- 优于广播质量: 支持高质量视频流，质量与广播相当或更好.
通过解决这些问题, 我们已经创建了一个适合现代流媒体需求的协议，并创建了一个更有效的工作流程, 最终节省成本和百家乐软件. 低延迟已经是业界的一个大话题，它将为吸引观众和最大化广告收入开辟宝贵的新机会. 但重要的是，工作流要尽可能高效地实现这些潜力.
而不仅仅是标准化播放器格式, 我们着手创建一个更高效的整体工作流程. 我们首先确定了一些可以从标准化中受益的接口, 我们特别关注自适应比特率编码器和原始服务器的输出, or packager, 正在向内容分发网络(CDN)发展.
活动编码器通常会将其内容推出，因为它需要将其百家乐软件集中在对内容进行编码上. 换句话说，它没有能力处理来自客户机的大量请求. Instead, 实时编码器倾向于生成帧或片段并将其推送到原始服务器, 这反过来又使客户可以使用它. 对于这个用例，MPEG-DASH和HLS都是很好的协议.
但是在DASH和HLS中没有指定的推送内容的行为:它主要是关于HTTP GET将内容拉出. 因此，我们为fMP4和CMAF开发了一个配置文件，以便稍后进行包装.
我们已经开发了两个概要文件或接口. 如果你有一个工作流程，其中有一个单独的编码器和包装或源服务器，那么你可以只是发送CMAF轨道没有清单和做即时包装, 然后将其推送或链接到CDN. 第二个接口只允许您发布, or push, DASH directly, 所以在这种情况下，你会推送片段和清单. 这两种情况都使用HTTP POST.
这当然是对CMAF摄取的一个非常简化的概述. 在第一个界面, 没有舱单, 你只是使用不同的TCP连接并发布一个CMAF音轨，所以它实际上是一个fMP4文件, 但是没有多路复用, 所以每首曲目都是一个单独的文件，你只是发布它们. 我想明确的是，它不是强制性的使用长时间运行的帖子:你可以使用长时间运行的帖子与块传输，或者你可以单独发布每个片段.
重要的是接收器在接收到碎片的时候能够检测到它们. 它是由这个触发的，所以这在低延迟的情况下也很有效，因为你可能有小块. 接收器可以检测到数据块并动态地生成输出清单. 你在这里看到的是不同的视频和音轨被发布到原始服务器. 我们使用CMAF轨道的视频和音频, 但我们也用它来做程序元数据, 这是相对较新的东西吗.
该协议的一个优点是，断开连接并稍后重新连接非常容易. If, for example, 源下降，然后再次启动，它将在预定义的段边界恢复post. 可以使用第二个双冗余编码器, 所以如果CMAF头和最后一个片段不能发送, 接收端仍然可以从冗余编码器获得完整的存档流.
我们希望通过新规范实现的另一件事是低延迟的即时封装. 在CMAF规范中可以做的一件事是插入顶级框, 称为DASH事件消息框, 它可以携带元数据. 在我们的新协议之前实现快速封装, 需要扫描整个媒体文件才能找到那些盒子, 但是我们定义了一个单独的轨道，这样一个支持ISO bmff的设备可以很容易地看到元数据轨道并找到正确的信息.
CMAF容器格式的使用允许使用最新的视频编解码器，如支持高动态范围(HDR)和分辨率高达4K的高效视频编码. CMAF容器格式很流行，许多新的编解码器都绑定到CMAF容器格式. 因此，CMAF摄取协议可以无缝地支持新的和新兴的编解码器, 无需对协议进行任何修改, 以及高质量的视频. 这种对新编解码器的支持是我们发现其他不基于CMAF的协议所缺乏的.g. WebRTC, RTMP etc.).
通过这些方式，我们实现了项目的三个主要目标:改进定时元数据, reliability, 低延迟和视频流质量.
随着同时观看人数的增加，需要提供更好的服务，直播将变得越来越难以大规模交付, 为观众提供更有吸引力的流媒体. 随着争夺观众注意力的竞争加剧, 依赖于定时元数据和低延迟的特性将变得更加重要. 支撑这些特性的是对更好的可靠性的需求，而新的摄取规范应该在解决这一问题上走了很长的路.
[编者注:这是来自 统一的流. 流媒体接受供应商署名完全基于它们对我们读者的价值.]
Related Articles
提及的公司及供应商