FOSDEM 2023|融合两个领域:WebRTC 与广播

摘要:广播行业对毫秒级实时流媒体的拍摄和交付越来越感兴趣,现在已经在其工作流程中纳入了特定的标准,例如SRT或NDI。WebRTC 和这些协议技术的耦合对于 WebRTC 的未来发展前景是十分重要的。其中 WHIP 和 WHEP 技术起到了非常关键的作用。在此次会议上,我们将了解当今广播行业的可用性以及将这些与世界上先进开源技术合并的挑战。

来源:FOSDEM 2023
视频链接:https://fosdem.org/2023/schedule/event/om_webrtc/
内容整理:尹文沛

WebRTC 简介

Web Real-Time Commnunication 具有很多优势,我们在这里做一个简要介绍:

  1. WebRTC 传输数据是自动加密的
  2. 具有毫秒级别的端到端时延
  3. WebRTC 代码是开源的
  4. 双向通信
  5. 不需要特别定义信令
  6. 要求开源的编码方式
  7. 能够嵌入任何浏览器
  8. 可以使用你自己开发实现的编码方式
  9. 使用 UDP 协议传输
  10. 使用 ICE 技术协调网关
  11. 很多 libwebrtc 库都是独立可用的

Secure Reliable Transport (SRT) 简介

SRT 是一种安全可靠的传输协议,它是开源的,且被广泛应用在广播行业中。SRT 同样也是基于 UDP 传输的,但它需要本地的应用程序协助才能使用,没有被集成到浏览器中。传输过程中的加密对于 SRT 来说是可选的。但是编码方式对于开发者来说是不可知的。SRT 可以做到毫秒级的传输,但是大多数情况为了可靠性,其传输延迟通常都有几秒。SRT 也可以在广域网中进行分发。

Network Device Interface (NDI) 简介

NDI 不是开源的,而且具有很多不同形式,如 NDI, HX, HX2 还有 HX3。NDI 的设计仅适用于局域网,它虽然不是开源的,但它可以免费使用。同样也是使用 UDP 协议。当然现在你可以在互联网中使用 NDI,但那并不是真正的 NDI,只不过是使用 Webrtc 来实现的一些 NDI 功能。NDI 的使用许可获取相较于其他协议来说也是很复杂的。但总体来说 NDI 仍然是非常受欢迎的。

Reliable Internet Stream Transport (RIST) 简介

同样的,RIST 是开源的,基于 UDP 的,加密的,基于 RTP 传输的,相较于其他协议来说还很新颖,可以在互联网或者局域网中使用。

WHIP 和 WHEP

除了上述协议,其他形式的流媒体传输都不是真正意义上的实时传输了。在过去的十年里,广播和 WebRTC 并没有真正走到一起发展。但是现在,广播和 WebRTC 可以实现很好的融合。让我们来看看 WHIP 和 WHEP。

WHIP 的全称是 WebRTC HTTP Ingestion Protocol。图 1 是 WHIP 的工作流程。根本上就是 HTTP 请求与应答,然后再进行流媒体传输。

图片
图1 WHIP 工作流程

WHEP 的全称是 WebRTC HTTP Egress Protocol。图 2 展示了 WHEP 的工作流程,和 WHIP 很相似。

图片
图2 WHEP 工作流程

WHOA

还有第三种形式叫做 WHOA,全称为 WebRTC HTTP Offer Answer Protocol。WHOA 并不能实现如 WHIP 和 WHEP 一样的功能,在我看来它不过是一个信令协议而已。

WebRTC 缺乏一个默认的信令协议说明在这一块,其缺乏工业界的支持。即我们即使拥有可以通信的设备,但却不知道如何与其他人交流。

当每一个流媒体提供商使用不同的 API 时,你该如何使用 WebRTC 去传输媒体?这个问题很难回答,因为广播行业与 WebRTC 融合不仅仅只是没有匹配的信令系统这么简单,牵扯到方方面面,最终还是看要看 WHIP 和 WHEP。

再谈 WHIP 和 WHEP

WHIP 和 WHEP 目前都还是 IETF drafts。所以 WHIP 和 WHEP 到底是什么呢?

WHIP 通过 HTTP Post 发送 SDP Offer,然后以 HTTP Response 来获取 SDP answer。做完上述两步就可以将流媒体发送至服务器。

WHEP 也是通过 HTTP Post 发送 SDP Offer,然后以 HTTP Response 来获取 SDP answer。做完上述两步就可以从服务器接收流媒体。

那如何将硬件编解码或者软件编解码集成到 WHIP 和 WHEP 上去呢?Talon 硬件编解码器已经支持 WHIP 了,其他的软件编码器如 OBS 也已经支持 WHIP,对我们而言这已经是一个历史问题了。

更深入地讨论软件编码器对 WHIP 的支持,Gstreamer 是绕不开的。Gstreamer 现在支持成为 WebRTC 可用的 sink 备选项。Dolby, Broadcast Bridge 还有 Cloudflare 等平台都支持带 Gstreamer 的 WHIP。

这样做的话,使用 WebRTC 来摄取和分发内容就变得简单起来。而且 WebRTC 还支持 Simulcast 和 SVC。协商使用不过就是通过 HTTP 请求来传送 SDP 信息而已。SDP 其实就是用来存储通信终端各种信息的文本。只要通信双方协商一致,你甚至可以添加你自己定义的新编码方式。

音频编码如何呢?Opus Red 有希望成为浏览器中新的标准。使用 Opus 编码音频,然后发送冗余 RTP 包来防止丢失(需要额外的带宽开销和启用额外的 RTP 头部扩展),这就是 Opus Red 的大概工作原理。

当然 WHIP 和 WHEP 融合 WebRTC 和广播的方式并不是开创性的,甚至可以说有一点点无聊,它其实就是使用 HTTP 来传输 SDP offer 和 Answer 而已。但不可否认,这些工作是极好的。它给每个人都提供了两个相同的协议去发送和接收流媒体数据。并且引出了很多创新和有意义的开源项目。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论