视频直播RTMP、HLS、WebRTC注意事项

如今，当人们谈论“直播”时，他们可能在谈论三种截然不同的底层技术。

• RTMP 广泛用于将视频发送到实时会话中，但很少用于查看视频流。
• HLS 是 Twitch 等平台向大量观众提供直播的方式。
• WebRTC 旨在支持视频通话等互动式用例，是 Google Meet、Microsoft Teams 视频和 Discord 视频等应用程序中的基础技术。

为什么要有三个标准？

好吧，部分这些标准随着时间的推移而发展，并且仍在发展。我们的计算机、电话和网络继续变得更快，人们不断想出用更快的计算机和网络做的新事情，并且创建了越来越好的技术构建块来支持我们正在做的这些新事情。

但同时，大规模提供互动视频也是一种挑战，工程上的权衡也很多。HLS和WebRTC是解决一个问题（视频流）的两种方法的很好的例子，它们对该问题的不同方面进行了优化。

从RTMP到HLS：直播的二十年进步

RTMP 已有 20 年历史，最初由 Macromedia 为 Flash 服务器和播放器开发。在互联网视频方面，这是相当古老的技术。但由于 RTMP 已经存在了很长时间，它作为一种将实时视频从一台计算机系统发送到另一台计算机系统的方式得到了广泛支持。

例如，如果您是 Twitch 主播，您几乎肯定会使用 RTMP 将视频从您的游戏机/音乐工作室/vibe 实验室发送到 Twitch 的云基础设施。

另一方面，如果您正在观看 Twitch 上的直播，您并不是在观看原始的 RTMP 直播。Twitch 使用更新的标准 HLS 向每天观看直播的数以百万计的人传送视频。

HLS 有很多优点，但与 RTMP 相比有两个优势。

首先，HLS 支持多种码率，并允许观看客户端在多种码率之间动态切换。这对于大规模传输视频通常很重要，对于直播尤其重要。如果我在手机上通过不太好的蜂窝数据连接观看视频，与在互联网连接（通常）非常快的家中观看同一视频相比，我的可用带宽要少得多。

这意味着如果我使用蜂窝数据连接而不是使用家庭互联网，我实际上需要观看不同编码的视频。在我的手机上，我只想看视频，而且我知道质量不会很好。在家里，我想要最好质量的视频。

另一个问题是，当我观看视频时，我可用的带宽可能会发生变化。我的手机可以靠近手机信号塔并提供更快的服务。或者在家里，我的笔记本电脑可能会决定下载一个大的系统更新，这可能会减少一半的视频可用带宽。

为了支持动态播放比特率，HLS 视频被打包为一系列短时间块。每个块都以几种不同的比特率进行编码。今天一个典型的 HLS“比特率阶梯”将包括五种编码，范围从高端的每秒约 6 兆比特到底部的每秒约 250 千比特。（更高的比特率提供更高的视频质量。）

支持 HLS 的视频播放器能够持续监控大约有多少带宽可用，并切换到下载较小比特率或较大比特率的块。

关于块的元数据存储在清单文件中，通常命名为.m3u8。如果你打开 Chrome devtools 并开始在 Twitch 上播放视频，你可以在网络面板中查找 .m3u8 文件片段的提取，并看到一堆关于 HLS 编码的有趣信息！

站在巨人的肩膀上

HLS 相对于 RTMP 的第二个优势是 HLS 块可以通过 Cloudflare、Fastly、Akamai 和 Cloudfront 等 HTTP CDN 高效地交付。

“HLS”是扩展为“HTTP Live Streaming”的首字母缩写词。HLS 块和清单大多看起来像文件。播放器使用正常的 HTTP 请求获取清单和块。因此，HLS 受益于现代 CDN 的惊人功能。

另一方面，RTMP 是它自己的 TCP 级别的东西。它是一个面向流的协议，而不是像 HLS 那样的面向请求的协议。要通过 RTMP 连接发送视频和音频，您需要打开一个 TCP 套接字，然后开始通过该套接字推送 RTMP 格式的数据。

大量的基础设施工程工作已经投入到使 HTTP 在世界各地变得快速、可扩展且具有成本效益。HLS 的 CDN 友好特性是一个核心设计目标，而且意义重大。

但有一个问题——延迟，这将使我们看到WebRTC。

但首先……关于延迟的一个插曲

让我们做一些手势并将我们感兴趣的直播延迟定义为“视频发送者和视频查看者之间的端到端延迟”。

这是视频比特从视频发送者到观众的阶段的示意图，通过媒体服务器中继：

1. 捕获（例如，网络摄像头）
2. 编码（转换为像 AVC 这样的压缩视频格式）
3. 传输到媒体服务器（以某种方式在网络上移动这些字节）
4. 处理媒体服务器上的视频
5. 传输给查看器（再次通过网络移动这些字节）
6. 回放（解码、解压缩，最后在屏幕上显示视频）

对于其中的每一个步骤，都需要在视频质量、可靠性、成本和延迟之间进行复杂的权衡。

借助当今快速的计算机和精巧的视频编解码器，可以以相当高的质量压缩视频，而延迟只有几十毫秒。同样，一般来说网络速度非常快。我们已经擅长在 Internet 上路由数据包。步骤 1-6 通常加起来介于 50 毫秒和 300 毫秒之间。

除了……我们选择编码、打包和传输视频数据的方式可能产生的连锁反应。（上面的第 2 步到第 4 步。）HLS 的分块、面向请求的方法在几个阶段强制产生大量额外延迟。

六秒是典型的 HLS 块长度。稍微简化一点，这意味着在我们对每个块进行编码、打包和上传时，管道会增加 6 秒的延迟。然后我们的 CDN 必须获取并缓存这些块。最后，在观看者方面，大多数玩家会下载两个完整的块并将它们缓存在本地，然后再开始播放视频，而第三个块正在下载。

我们的延迟现在介于 12 到 20 秒之间。

可以通过使用更短的块大小、将块上传流式传输到我们的 CDN 源服务器、扩展我们的 CDN 的低级机制以便数据可以在块运行时开始传播以及优化播放端的缓冲来降低 HLS 延迟。

所有这些变化都降低了回放的弹性，并削弱了 HLS 核心的核心工程权衡：优化视频以通过 HTTP 基础设施交付。

低于大约一秒的块大小，我们将失去通过 CDN 传送视频的大部分优势。因此，像 HLS 这样的面向请求的方法在最好的情况下可以将延迟降低到大约两秒，在典型情况下可以降低到四到五秒的延迟。

如果我们的目标延迟低于该值，我们将需要采取不同的方法。

WebRTC——低延迟音频和视频的行业标准

WebRTC 是一种面向流的标准（如 RTMP），支持自适应比特率，并在当今的网络浏览器（如 HLS）中得到原生支持。低延迟是 WebRTC 的主要设计目标。

使用 WebRTC，视频编码发生在发送端，视频作为连续流发送。WebRTC 媒体服务器通常不会对视频进行转码。如果可能，WebRTC 连接是 UDP 而不是 TCP，这样可以降低网络开销和延迟。最后，在接收端，典型的播放缓冲区是 30 毫秒，而不是 HLS 典型的多秒缓冲区。

所有这些加在一起意味着 WebRTC 端到端延迟通常在 50 毫秒到 200 毫秒之间。这足够低，可以很好地满足两个人的对话，并且符合典型的电话呼叫延迟。

WebRTC 的低延迟伴随着两大权衡。

首先，保持视频质量的方法必须不同于 HLS 所依赖的方法。其次，使用 WebRTC 更难支持大量受众。

带宽和丢包

从网络工程师的角度来看，视频质量取决于两个简单问题的答案：

1. 您可以通过网络连接推送多少个视频数据包？（这通常称为“带宽”。）
2. 这些数据包在特定延迟窗口内到达的可靠性如何？（这是数据包丢失和抖动的组合。）

这两个指标都很重要，由于网络堆栈是一个复杂的协议层蛋糕，因此它们以有趣且有时令人惊讶的方式相互交互。但是，在所有情况下，“更差网络”的最终用户体验都是相同的，因为视频堆栈只有两个自由度可用：视频在播放器缓冲（或重新缓冲）时暂停，或者用户看到视频的低质量（低比特率）版本。

非常近似地，随着数据包丢失或抖动的增加，连接的有效带宽会下降。但是，公平地说，在中等程度的丢包情况下，如果您不太关心延迟，则可以缓冲大量数据包，而不必过多考虑丢包和抖动。

缓冲大量数据包——很多秒的数据包——是 HLS 在面对真实网络行为时保持视频质量的方法。

微波炉和延迟预算

假设您正在使用家庭 wifi 连接在 Netflix 上观看电影。你决定用微波炉加热一些爆米花。您的 wifi 连接使用的是 2.4ghz 频段之一，因此一旦微波炉打开，网络上的数据包丢失就会急剧上升。

HLS 可以很好地处理这个问题。已经缓存了几秒钟的视频，因此视频可以继续播放。玩家会注意到正在进行的块下载需要更长的时间。如果数据包丢失峰值短于几秒，TCP 重试可能只会补偿数据包丢失，玩家根本不需要做任何事情。如果数据包丢失继续存在，播放器有足够的时间来决定是否切换齿轮并开始下载较低比特率的块。

WebWebRTC的延迟预算非常紧张，这使得情况完全不同。

WebRTC的播放缓冲区通常不能容纳超过50ms左右的视频数据包。如果有一个大的丢包高峰，播放器不能只是继续渲染缓存的视频数据。而且重新请求一个丢失的数据包的往返时间往往很慢，不值得要求服务器向我们发送我们错过的数据包。最后，播放器必须很快做出跳转到较低比特率的决定。

所所有这些都意味着，典型的WebRTC丢包的失败模式只是跳过该数据包，尽可能地继续播放视频。

在实时视频通话中，视频质量问题看起来像小的帧率故障，如果错过了视频关键帧，就会恶化为视觉损坏或长时间冻结。为了补偿丢包，媒体服务器和播放器可以合作选择较低的比特率流。但这可能不会很快发生，以避免视觉伪影的出现。为了补偿这一切，WebRTC的实现通常默认比HLS的实现低一些的比特率。

HLS 对网络问题更具弹性，但延迟比 WebRTC 高得多。

WebRTC 可以在平均情况下提供低于 200 毫秒的延迟（并且几乎总是低于 400 毫秒的延迟），但平均视频质量略低。

如果交互式延迟（低于 400 毫秒的延迟）是目标，WebRTC 的权衡显然是正确的。

并非所有英雄都披着斗篷（他们中的一些人携带传呼机）

HLS和WebRTC之间的另一个重大区别是，支持大量观众的直播流和大量用户的服务或应用是多么困难。

HLS 将扩展分发的大部分复杂性卸载到 HTTP CDN。这很好，因为现代 CDN 非常好。

WebRTC 比 HTTP 更新，与 HTTP 相比，为 WebRTC 大规模构建基础设施所花费的工程时间要少得多。

然而，越来越多的工作正在进入 WebRTC 基础设施，因为低延迟视频的使用越来越广泛。许多公司现在提供可扩展的 WebRTC 基础架构即服务。越来越多的开源项目为部署生产基础设施和试验新方法提供了极好的构建块。

改进 WebRTC 基础设施

构建“WebRTC CDN”所涉及的重大挑战是：

• 媒体服务器需要复制传入的 UDP 视频和音频数据包，并将副本路由到直播流的每个观众。这必须快速完成。从计算的角度来看，这种复制和路由作业的成本相对较低，而且在概念上也相对简单。但在实施层面，有许多棘手的组件，例如估计每个观众可用的带宽并根据需要切换到不同的比特率。在某些时候，需要路由的数据包数量超过了单机的限制。所以有必要在服务器之间实现级联或网状组网。相关地，现在水平扩展 HTTP 和其他面向请求的工作负载的标准构建块并不真正适用于 WebRTC 服务器。因此，要扩展一个应用程序或服务（许多并行的实时会话）需要编写自定义的扩展/扩展逻辑、实施适当的服务发现、创建新的监控和可观察性工具等。
• 连接到附近的服务器时，数据包丢失和抖动通常比连接到远处的服务器要低得多。因此，如果实时流媒体的观众在地理上是分散的，那么拥有媒体服务器的分布式基础设施就很重要，并且（再次）有必要实现网状或级联服务器到服务器媒体传输。
• 实时编码流以使用非常小的缓冲区进行播放是一项挑战。当前的技术水平是编码为三种比特率（而不是像 HLS 那样编码为五种或六种）。

如今，WebRTC 已经足够成熟，对于拥有 15,000 名观众的直播流，通常更倾向于使用 WebRTC 而不是 HLS。低延迟允许将观众带到“舞台”以参与直播、互动观众功能（如民意调查和表情符号反应）以及现场拍卖中的实时竞价等功能。

随着 WebRTC 基础设施的不断完善，越来越大的低延迟直播流很可能会得到越来越广泛的使用。

源自：daily | 作者：Kwindla Kramer