WebRTC与CMAF：哪一个最适合您？

与WebRTC不同，CMAF通过分块编码以及分块传输的方式，实现低延迟的视频流媒体服务。本文对低延迟CMAF与WebRTC的工作原理以及交付速度，视频质量，可扩展性等指标进行了对比，帮助了解如何根据不同场景与需求，在两者之间进行合适的选择。

文 / Traci Ruether

翻译 / John

原文 / https://www.wowza.com/blog/cmaf-vs-webrtc

低延迟流媒体的新兴技术

低延迟CMAF是流媒体行业的后起之秀。与WebRTC非常相似，低延迟CMAF的目标是克服业界的一项关键障碍：减少视频捕获和回放之间的延迟。那么究竟哪种更符合您对实时流媒体技术的需求？随着CMAF与WebRTC的竞争日趋激烈，我们将通过这篇文章向您阐述二者之前的差异。

低延迟CMAF与WebRTC对比概览

为什么我们需要低延迟流？

例如当建筑物发生火情时，救援人员可通过建筑内分布的摄像头实时获取建筑内部画面以判断火情并科学指挥疏散与营救行动。虽然视频可以实现更佳直观的信息共享，但在此应用场景下任何滞后与延迟都会造成人员的额外伤亡与灾情的进一步扩大。

当然在如赛马会等场景中时，世界各地的赌客都通过移动设备与计算机参与赛马活动。为确保在线投注的合法性，特别是在发生颇具争议的裁判结果时，实时通讯就变得尤为重要。

而像如在线拍卖这样的应用场景，低延迟的流媒体解决方案是实现这种应用场景的关键。

CMAF与WebRTC各有千秋

延迟是任何基于双向参与和传输的流媒体应用场景都无法完全规避的现象。传统的流媒体传输技术所带来的延迟可以高达几十秒，而低延迟CMAF与WebRTC则正是为了尽可能地缓解这一延迟问题。

这两项技术都代表了加速流媒体传输的最佳策略，尽管从数据上来说WebRTC在延迟频谱方面表现地更为出色，但其也并非完美无缺。

为了进一步研究二者异同，我们会明确两项技术的定义并探索其分别通过什么方式降低延迟。

什么是CMAF？

公共媒体应用格式（CMAF）是一种旨在简化基于HTTP流式传输的流媒体格式。CMAF不是协议，而是DASH和HLS都可以引用的格式。

在加入CMAF之前，任何希望在Apple与Microsoft设备上访问用户数据的内容分发商都必须对这些数据进行两次编码与存储。这是因为.ts格式主要用于向Apple设备传送内容，而Microsoft设备则接受基于ISOBMFF的.mp4格式。这种机制造成服务在iPhone、智能电视、Xbox与PC之间的跨平台使用体验的成本高昂而效率低下。

CMAF通过代替标准化传输容器来帮助简化流程。虽然CMAF 本身只是一种媒体格式，但领先的组织机构为了实现更低延迟，正在将其整合到更大的系统中从而推动行业发展。

什么是低延迟CMAF？

为了符合“低延迟”的要求，CMAF中包含两项必不可少的关键技术：

• 分块编码
• 分块传输

上述过程是将视频以固定的时间连续分成若干小分块以便于其在后续分块仍在进行编码处理时立即传输与发布。无论规模大小，理想状态下基于分块编码与分块传输的CMAF可实现低于3秒的延迟。

低延迟CMAF的工作原理

在传统的基于HTTP的流式传输工作流中，编码器在将数据发送到CDN之前需要等待创建完整的段。对于低延迟CMAF，构成该段的各个块被推出以进行传递，而段本身仍在被编码的过程中。

尽管减少HLS或DASH流的分段大小是降低延迟的一种方式，但低延迟CMAF可完全消除分段大小的延迟。

来源：Akamai，使用分块编码和分块传输CMAF的超低延迟流，2018年

上图将标准CMAF传输与低延迟CMAF传输放在一起对比。我们可以发现底部图形中的每个块都包含一个电影片段框（moof），并附有媒体数据框（mdat）。通过每个块内进行的完整配对，播放器能够在不需要整个分段的情况下将每个编码的块直接添加到其缓冲区。

什么是WebRTC?

WebRTC是标准、协议和JavaScript API的组合，支持实时通信（RTC，因此它的名称）。通过Chrome、Firefox或Safari连接的用户可以通过他们的浏览器直接 启用延迟低于500毫秒的通信。

WebRTC的工作原理?

WebRTC框架利用浏览器之间的点对点连接，在不需要插件的情况下创建几乎同时进行的通信交换。具体来说，WebRTC使用了Chrome、Firefox和Safari内置的三个HTML5 API并允许其直接进行基于浏览器的通信。

低延迟CMAF与WebRTC：交付速度

毫无疑问，WebRTC在延迟竞赛中排在第一位。仅需不到500毫秒的时间就可将视频和音频数据从一个浏览器传输到另一个浏览器，实现名副其实的实时通信。

CMAF以低于三秒的速度交付，但同样只有在使用分块编码和分块传输编码进行部署时才能实现。

低延迟CMAF与WebRTC：可扩展性

低延迟CMAF的可扩展性优势明显。首先，该格式针对任何支持HLS或DASH协议的设备进行单编码传输都进行了优化。这简化了服务器效率，使开发者可以将其覆盖至更多的产品与消费者。

另一方面，WebRTC的设计并没有考虑到可扩展性。这种带宽密集型选项要求每个参与的浏览器通过点对点方式相互连接。为了更好地理解这一点，WebRTC专家Tsahi Levent-Levi 建议开发者不要在WebRTC上使用超过50个并发的点对点连接。

而借助媒体服务器软件从而对 WebRTC流进行转码，我们可以在一定程度上解决 WebRTC可扩展性问题。但此过程会引入延迟，尽管可利用庞大的实时重复服务器网络来抵御会对服务器带来极大风险的流量峰值，但这种策略的成本可能会让银行破产。

低延迟CMAF与WebRTC：广播质量

低延迟CMAF支持4K和高帧率流等高清功能。虽然这些功能会增加编码时间，但CMAF仍然是高质量低延迟广播的最佳选择。

由于WebRTC是为视频会议等应用场景而设计，因此质量不是主要目标。使用WebRTC进行流式传输时的最高分辨率为720p。当WebRTC涉及带宽问题时，限制帧速率也是一个提升流畅度的好主意。

低延迟CMAF与WebRTC：如何选择？

如果您追求传输速度，那么WebRTC将是绝佳的选择；但如果您需要综合考量质量、规模与高并发可承受性等方面，那么低延迟CMAF或许更适合您。因此，我们建议根据这些标准得出最适合您特定使用场景的选择。

下表列出了我们针对多种流媒体方案推荐的技术。

CMAF：

• 一对多的互动流媒体
• 体育与电子竞技直播
• 在线博彩或拍卖
• 大规模的产品演示

WebRTC

• 一对一互动多媒体
• 小组视频会议
• 音视频通话
• 小规模产品演示

以开头所提到的紧急救援的应用场景为例——紧急救援人员通过建筑内的摄像头直播画面与指挥官建立联系：

如果此联系仅限于一个小团队且紧急程度优先于其他任何事情，那么WebRTC将是最佳选项；如果此救援画面需要分发给公众观看那么低延迟CMAF将更加适合；如果救援机构需要通过音视频数据收集救援相关信息，那么可保留高质量音视频细节内容的CMAF无疑是更好的选择。

所以如何在WebRTC与CMAF之间做出选择，这一切都要取决于你最终想要实现的目标。

LiveVideoStack 招募

LiveVideoStack正在招募编辑/记者/运营，与全球顶尖多媒及技术专家和LiveVideoStack年轻的伙伴一起，推动多媒体技术生态发展。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”，或通过微信“Tony_Bao_”与主编包研交流。