使用WebRTC作为RTMP的替代方案

WebRTC影音探索

2020年，Adobe宣布停止对 Flash播放器的支持。Flash历经多年终于走向终结，虽然是众望所归，但它的退出却对存在于许多流媒体工作流程中的一项重要技术——RTMP（ Real-Time Messaging Protocol）影响重大。RTMP最初设计用于向Adobe Flash播放器传输音频、视频和其他数据。在全盛时期，RTMP曾是互联网上传输视频的最主要技术。它可以用于端到端，并能确保快速的实时传输。然而与过去相比，现在越来越多的设备和浏览器都不再支持RTMP。

虽然在编码器和服务器之间传输视频方面，RTMP仍然是一个可靠的视频传输协议，但是对基于RTMP的播放来说，却并非如此。Adobe也表示[1]：”鼓励直播厂商将现有的Flash内容迁移到新的开放格式中去。”

在2020年的Streaming Media的一期杂志中，Robert Reinhard（流媒体视频顾问）曾警告：“如果你正在使用Flash进行低延时实时流媒体传输，那么你还有一年的时间（或者更短）将其迁移到WebRTC上。这意味着什么？意味着你在基于Flash的媒体服务器上所使用的的任何代码都需要迁移到WebRTC（而非RTMP）上。”

然而，许多内容发行商仍然在竭力将RTMP替换为用于视频播放的实时格式。为什么？因为虽然HLS和MPEG-DASH支持不同设备的高质量流媒体传输，但是延迟超过30秒是这些基于HTTP技术的标准。确实存在这些协议的低延迟扩展（LL-HLS和DASH的LL-CMAF），但是它们都无法达到很多公司追求的次秒级传输速度。除此之外，播放器、CDN和各种设备对于LL-HLS和LL-CMAF（用于DASH）的支持还处于早期阶段。

对于实时视频传输来说，WebRTC是你的唯一选择，这也是它在最近几年备受关注的原因。这项基于HTML5的技术为互联网上的实时视频传输提供了最快的方法。更重要的是，像RTMP在其全盛时期一样，WebRTC也可以端到端使用。

但是WebRTC也有自己的局限，它被设计用于基于浏览器的编码和小规模的流媒体传输，而这两个特点都使它无法适用于某些直播场景。

WebRTC会是替代RTMP的最佳方案吗？在开发者中，这句话已经成为了流行语。正如我将在下文所解释的那样，它取决于你所使用的支持部署的技术和你想达成的目标。

RTMP vs. WebRTC: 对比

对比RTMP，WebRTC有以下几个优势：其一，它是一种新型、由IETF和W3C进行标准化的开源技术。所有的主流浏览器无需插件即可支持WebRTC，消除了由专有流媒体技术所带来的互操作上的挑战。除此之外，软件开发者社区不断为WebRTC的开发贡献代码，也使它受益匪浅。

其次，在传输速度低于500毫秒的情况下，WebRTC是目前延迟最低的协议。它也由此成为创建交互式视频体验（从实时拍卖到直播购物）的首选解决方案，同时对于那些想要超越竞争对手的体育直播厂商来说，它也是一个非常具有吸引力的选择。

向数目众多的观众进行大规模直播对于WebRTC来说还存在困难。视频聊天框架本来就不是为规模化而设计的。幸运的是，我们已经开发了一种解决方案来克服这种局限，我将在下文详述。

在视频生产方面，WebRTC仅使用Web浏览器就可以进行简单的直播，但是对于希望使用硬件或者软件解决方案控制编码设置的直播厂商来说，基于浏览器的编码并不理想。同样，当涉及到使用定时元数据的字幕和广告标记等功能时，RTMP也比WebRTC更具优势。

WebRTC工作流程

所以，当涉及到实时视频流媒体传输时，RTMP到底在哪里可以替换成WebRTC? 作为一种端到端技术，WebRTC可分别用于推流、拉流或同时用于推、拉流。下面让我们看下WebRTC工作流程两端的优势，以及它是如何在确保规模化的同时应用于编码到传输的整个过程。

WebRTC在推流时替换RTMP

RTMP仍然是第一英里视频贡献的标准，这其中有以下几个原因。第一，RTMP获得了来自直播编码软件和硬件的广泛支持，同时许多社交媒体平台也在使用它。编码厂商已经开始向SRT等开源协议添加支持，但是WebRTC一直仅限于基于浏览器的内容发布。对于任何想要使用Web摄像头和麦克风直接在浏览器上进行直播的人来说，WebRTC非常有用。但是对于想要使用专业编码器进行实时流媒体内容传输的内容发行商来说，就无法使用WebRTC推流。

因此Millicast的技术团队设计了WHIP（WebRTC HTTP Ingest Protocol）来解决这个难题。在与媒体服务器通信时，WHIP提供了使用标准信令协议的编码软件和硬件，这样就可以实现跨厂商的WebRTC推流。WHIP在实现WebRTC推流的同时，还保留了WebRTC的低延迟优势（与RTMP相比），同时移除了编码器和媒体服务器之间的连接障碍。

当用于推流时，WebRTC可以确保低延迟、强制加密并提供对于Opus和VP9等高级编解码器的支持。因为有了WHIP，WebRTC也正在成为一种可用于硬件和软件编码的格式。直播流程对编码设置（包括码率、编解码器和编解码器参数等）有更多的控制需求，而WHIP的出现使WebRTC可以直接和RTMP竞争。

WebRTC在拉流时替换RTMP

浏览器不再支持RTMP导致播放端无法再使用它。当今大部分直播厂商都在使用HLS进行“最后一英里”的交付，但HLS的延迟要超过30秒。

目前你在传输视频时正在使用哪些流媒体格式？

来源：Wowza的2021视频流延迟报告[3]

当涉及低延迟协议的替代方案，WebRTC是众多协议中传输速度最快的。因此，如果你需要真正的交互（我们这里讨论的是用于紧急响应和远程监控等场景的低于一秒的视频传输），那么WebRTC将是你的最佳选择。LL-HLS和用于DASH的LL-CMAF同样也是不错的选择，但是它们无法实现像WebRTC一样的实时传输。

也就是说，WebRTC最初并不是为大规模直播场景设计的。我们过去曾鼓励内容发行商在向大量观众直播交互性内容时使用调整后的HLS或者LL-HLS，但现在我们为了解决这个问题，已经改进了产品。

具体来说，我们开发了一个新的特性：该特性可以在自定义的CDN上部署WebRTC，从而提供近于无限的规模。这个解决方案可以实现面向全球大规模观众的次秒级视频传输[2]。

如图中所示，当以这种方式传输视频时，WebRTC可用于广泛的工作流程中，包括WebRTC端到端，或者从RTMP到WebRTC。

在实现WebRTC时需要考虑的事

如果你正在考虑使用WebRTC代替RTMP，你需要将如下问题纳入考量：

1. 你是否需要双向视频或实时交互？

交互式实时流媒体解决方案和WebRTC密不可分，缺一不可。只要你使用WebRTC进行内容发布和播放，就能实现低于500毫秒的流媒体传输。更重要的是，使用次秒级流媒体传输的应用场景还可以利用RTMP到WebRTC的工作流程。同时还存在混合模型，其中交互视频参与者可以观看WebRTC视频流，而被动观众可以观看由HLS传输的具有更高延迟的视频流。

2. 你希望视频内容获得大范围传播吗？

所有的内容发行商都希望他们的流媒体应用大获成功，拥有成千上万或者数百万的观众。然而，过多用户可能使你的基础设施不堪重负。传统的WebRTC部署因无法利用自定义创建的CDN而限制了它的扩展能力。所以如果你的目标是触达大量观众，一定要确保拥有稳健的基础设施。

结语

由于WebRTC被设计用于视频聊天应用，所以有两个障碍阻碍了它在实时直播工作流程中的广泛采用：

基于浏览器编码的限制，以及在编码软件和硬件中缺少WebRTC能力。

规模化的挑战：导致WebRTC在向成千上万（或更多）观众直播时很难使用。

幸运的是，行业已经为以上问题找到了解决方法，使WebRTC成为了RTMP的强大替代方案（无论是在推流时还是在播放端）。

在我们的2021视频流延迟报告中，我们发现WebRTC已成为用于推流的第二流行的格式，用于传输的第三流行格式。在各厂商为实现实时视频直播而努力提高WebRTC可用性的前提下，我预计WebRTC的采用率将继续增长。

审核编辑 ：李倩