目前,WebRTC.org 是最流行且功能丰富的 WebRTC 实现。它在 Chrome 和 Firefox 中使用,并且在浏览器中运行良好,但是原生 API 和实现存在一些缺点,使其不太适合浏览器之外的用途,包括原生应用、服务器应用和物联网 (IoT) 设备。
去年,我们公司 (Centricular) 在 GStreamer 1.14 中提供了一个独立的 Native WebRTC API 实现。此实现比 WebRTC.org Native API 更易于使用且更灵活,与 WebRTC.org 透明兼容,已通过所有浏览器的测试,并且已在生产中使用。
什么是 GStreamer 和 WebRTC?
GStreamer 是一个开源、跨平台的多媒体框架,是实现任何需要跨各种设备和产品(包括嵌入式设备(物联网、车载信息娱乐系统、手机、电视等)、桌面设备(视频/音乐播放器、视频录制、非线性编辑、视频会议、VoIP 客户端、浏览器等)、服务器(编码/转码场、视频/语音会议服务器等)和 更多)播放、录制或转换类似媒体数据的应用程序的最简单和最灵活的方式之一。
GStreamer 成为许多人首选多媒体框架的主要功能是其基于管道的模型,它解决了 API 设计中最困难的问题之一:满足从最简单的一行程序和快速解决方案到需要数十万行代码才能实现其完整功能集的各种复杂性的应用程序。如果您想学习如何使用 GStreamer,Jan Schmidt 的教程 (来自 LCA 2018)是一个很好的起点。
WebRTC 是一组草案规范,它建立在现有的 RTP、RTCP、SDP、DTLS、ICE 和其他实时通信 (RTC) 规范之上,并定义了一个 API,用于使用浏览器 JavaScript (JS) API 访问它们。
人们已经使用 WebRTC 构建的协议通过 IP 进行实时通信 数十年了。WebRTC 的真正创新是通过定义浏览器可以向不受信任的 JavaScript 代码公开的标准且灵活的 API,在原生应用程序和 Web 应用程序之间架起了一座桥梁。
这些规范 正在不断改进,再加上浏览器的普及性,意味着 WebRTC 正迅速成为所有平台和大多数应用程序视频会议的标准选择。
一切都很棒,让我们构建令人惊叹的应用!
没那么快,还有更多故事!对于 Web 应用程序,PeerConnection API 无处不在。有一些浏览器特定的怪癖,并且 API 不断变化,但 WebRTC JS 适配器 处理了大部分问题。总的来说,Web 应用程序体验大多是 ?。
不幸的是,对于需要比沙盒 JavaScript 应用程序所能实现的更大灵活性的原生代码或应用程序,还没有很多好的选择。
Libwebrtc(Google 的实现)、Janus、Kurento 和 OpenWebRTC 传统上一直是主要的竞争者,但每个实现都有其自身的不灵活性、缺点和约束。
Libwebrtc 仍然是最成熟的实现,但它也是最难使用的。由于它嵌入在 Chrome 内部,因此它是一个移动目标,并且该项目 非常难以构建和集成。这些都是原生或服务器应用程序开发人员尝试快速原型化和试验事物的障碍。
此外,WebRTC 不是为多媒体构建的,因此较低的层会妨碍非浏览器用例和应用程序。除了默认的“设置原始媒体,传输”和“从远程接收,获取原始媒体”之外,做任何其他事情都非常痛苦。这意味着如果您想使用自己的过滤器或特定于硬件的编解码器或接收器/源,您最终将不得不 fork libwebrtc。
OpenWebRTC(由 Ericsson 开发)是纠正这种情况的首次尝试。它建立在 GStreamer 之上。它的目标受众是应用程序开发人员,并且作为一个概念验证非常适合——即使它使用了自定义 API,并且一些架构决策使其对于大多数其他用途都非常不灵活。然而,在项目周围最初的活跃之后,势头逐渐减弱,该项目未能聚集社区,现在实际上已经消亡。完全披露:Centricular 与 Ericsson 合作,在项目公开发布之前立即对其进行了一些润色。
GStreamer 中的 WebRTC
GStreamer 的 WebRTC 实现为您提供完全控制权,就像它对任何其他 GStreamer 管道一样。
正如我们所说,WebRTC 标准建立在服务于类似目的的现有标准和协议之上。GStreamer 一直以来都支持几乎所有这些标准,因为它们被用于实时通信、直播和许多其他基于 IP 的应用程序。这促使 Ericsson 选择 GStreamer 作为其 OpenWebRTC 项目的基础。
结合在 OpenWebRTC 开发期间编写的 SRTP 和 DTLS 插件,这意味着该实现建立在一个坚实且经过良好测试的基础上,并且实现 WebRTC 功能并不像人们可能认为的那样涉及那么多从头开始编写代码的工作。但是,WebRTC 是大量标准的集合,达到与 libwebrtc 的功能对等是一个持续的任务。
由于在架构 WebRTCbin 内部结构时做出的决策,该 API 非常密切地遵循 PeerConnection 规范。因此,几乎所有缺少的功能都涉及编写可以插入明确定义的套接字的代码。例如,自 GStreamer 1.14 版本发布以来,以下功能已添加到 WebRTC 实现中,并将在下一个版本的 GStreamer WebRTC 中提供
- 前向纠错
- RTP 重传 (RTX)
- RTP BUNDLE
- 通过 SCTP 的数据通道
我们相信 GStreamer 的 API 是目前最灵活、通用且易于使用的 WebRTC 实现,并且随着时间的推移,它只会变得更好。将基于管道的多媒体处理能力引入 WebRTC 为有趣、独特和高效的应用程序打开了新的大门。如果您想演示该技术并使用代码,请构建并运行 这些演示,其中包括 C、Rust、Python 和 C# 示例。
Matthew Waters 将在 1 月 21 日至 25 日在新西兰基督城的 linux.conf.au 上展示 GStreamer WebRTC—基于网络的媒体的灵活解决方案。
评论已关闭。