学习 WebRTC 的最佳工具和 Demo

在这篇文章中，作者 Vadim Beskrovnov 将分享对实际理解 WebRTC 至关重要的关键工具、演示应用程序和开放项目。本文将不提供有关 WebRTC 任何部分的教程或详细解释，而是提供有助于您更好地理解该主题的资源摘要。如果您已经使用该技术一段时间，您不太可能在这里找到新东西。以下为全文：

WebRTC 基础知识：您需要了解的内容

如果熟悉视频通话在浏览器中的工作原理，请跳过本节。

大多数流行的视频通话平台（Zoom 除外）都使用 WebRTC 技术在浏览器中实现其产品。它已成为创建实时通信服务的事实标准，并得到所有现代浏览器的支持。

WebRTC 由几个主要组件组成：

• Media Capture API：它允许从设备的摄像头和麦克风捕获音频和视频流。
• Connection Establishment API：它包括在浏览器之间建立直接连接的协议和方法，以便实时传输媒体和数据。这包括交换网络信息、选择最佳数据路径和连接管理。
• 编解码器和媒体处理：WebRTC 支持各种音频和视频编解码器，用于编码和解码媒体流。此外，还有用于媒体处理的工具，包括回声消除、噪音抑制和自动增益控制。
• 安全性：WebRTC 对所有传输数据和媒体流进行加密，以确保网络的保密性和安全性。

WebRTC 如何工作：

• 信令： 要在对等方之间开始交换媒体数据，必须有一个信令过程。WebRTC 规范中没有直接包含这一过程，因此开发人员可以自由选择信令方法（通过 WebSocket、REST API 等）。信令用于交换元数据，如媒体类型、编解码器参数、网络地址和建立连接所需的端口。
• 建立连接： 交换初始信息后，使用 STUN（NAT 会话遍历工具）和 TURN（NAT 周围中继遍历）服务器应用 ICE（交互式连接建立）机制，绕过 NAT（网络地址转换），在对等设备之间建立直接连接。
• 数据传输： 连接建立后，对等体之间通过安全连接开始传输流媒体数据，媒体使用 RTP（实时传输协议），数据使用 SCTP（流控制传输协议）。
• 适应和处理： 在传输过程中，WebRTC 可通过调整流质量来适应不断变化的网络条件，从而优化性能。此外，还可进行媒体处理，包括噪音过滤、回声消除和其他功能，以提高通信质量。

接下来，我将分三个部分讲述帮助我学习这项技术的实用工具/服务和演示。然后，我将与大家分享开源产品，让大家详细了解 WebRTC 在大型产品中的实际应用。

工具

Chrome 浏览器工具

Chrome 浏览器为分析 WebRTC 提供了多种功能强大的工具：

• chrome://webrtc-internals
• chrome://webrtc-logs

1. Webrtc-internals

让我们从 chrome://webrtc-internals 开始。这可能是人们在开始使用 WebRTC 时最基本的工具。它提供了大量有关当前连接的信息，有助于调试和逆向工程其他产品。

在这里，您可以找到现有视频通话服务使用的编解码器。例如，加入 Google Meet 上的通话并打开 chrome://webrtc-internals，就可以看到 Google Meet 使用的是 AV1 视频编解码器。

或者，可以查看每秒发送的帧数及其分辨率

其主要限制是，数据只能在通话过程中获得（或者如果事先启用了录音功能），这意味着无法使用该工具解决突发问题。

更多信息请访问：https://getstream.io/blog/debugging-webrtc-calls/

2. Webrtc-logs

该部分的使用频率要低得多，因为它包含更详细的信息，是对复杂问题进行更透彻分析所必需的。不同于 chrome://webrtc-internals，它包含有关以前会话的文本格式日志。因此，您可以查看已完成调用的日志，这是 chrome://webrtc-internals 无法做到的。

您可以在其中找到有关视频通话开始和结束、媒体流参数、编解码器、视频分辨率、帧速率和其他媒体流质量指标的信息。

这些日志中的某些信息可用于构建与 chrome://webrtc-internals 中类似的指标。遗憾的是，Chrome 浏览器不提供此类功能，不过有一个开源产品可以帮助解决这个问题：https://fippo.github.io/dump-webrtc-event-log/。

如果在实际通话过程中出现问题，而又无法进行实时分析，该工具是理想之选。默认情况下，这些日志保存在 …/Google/Chrome/Default/WebRTC Logs/.gz目录下，这样就可以从愿意帮助分析问题的非技术用户那里收集这些数据。

TestRTC

来自 testRTC 服务的 analyzeRTC 目前处于测试阶段。整个平台都是付费的，但你可以完全免费地分析你的转储。一般来说，您不会在 chrome://webrtc-internals 之后发现任何新内容，因为它们的数据源是一样的。不过，analyzeRTC 对这些数据的展示要好得多。

例如，视频流信息的呈现方式就特别方便：

这里，还可以查看整体通话评级和音频质量：

分数是场景的总体评分，从 0 到 10，考虑所有通道的音频和视频。它有助于评估服务性能，并需要根据应用程序经验进行主观解释。MOS（平均意见得分）仅评估场景的音频通道，以 1 到 5 的等级表示声音的主观质量，其中 3 以上被认为质量良好，2 到 3 被认为是满意的，而低于 2 则被认为是差的。

Demo 示例

官方 DEMO

接下来是使用 WebRTC 的官方示例。在这种情况下，它不是我上面描述的工具，而是一套工作示例。这些示例涵盖了广泛的功能，从基本的对等连接建立到数据交换和媒体流管理等更复杂的场景。

每个链接都包含一个工作演示和 GitHub 上的源代码链接。只需使用这些示例，就能了解如何开发具有视频通话功能的相当复杂的网络应用程序。总之，这些示例有助于在实践中更好地理解 WebRTC 的各个方面，巩固理论知识。

SDP 说明

接下来，让我们来谈谈 SDP–用于在开始通话前建立连接的协议。其格式在 RFC 8866 中有所描述，目的是在通话前协商媒体流参数，如编解码器格式、视频分辨率以及建立连接和交换媒体数据所需的媒体类型（音频、视频、数据）。

协议的设计一方面是为了便于人类阅读，另一方面是为了占用尽可能少的内存。因此，要在第一时间了解特定信息的内容非常困难。这个工具正是用来解决这个问题的。

在交互模式下，你可以阅读 SDP 协议中的每一行内容，从而节省在 RFC 中搜索解释的时间。

Media test

除了建立连接和传输媒体流外，任何视频通话应用程序的一个重要组成部分就是处理这些媒体流。该工具有助于了解如何处理视频。

在这里，可以尝试处理视频流的各个方面，例如从头开始创建流或从摄像头创建流，选择视频分辨率和帧频。还可以对帧进行转换，例如改变颜色、转换为黑白、以 H.264 编码/解码，以及在<video>元素中添加用于跟踪显示时间的覆盖层。

实验结束后，可以了解处理结果，包括不同阶段的处理时间（如转换为 RGBX、添加背景和叠加）、帧显示时间、从开始到结束的总处理时间以及排队时间。每个指标都包括已处理帧的数量、平均处理时间、中位数、最短处理时间和最长处理时间。这些数据有助于评估应用程序中视频处理的性能和效率，并了解每项操作的成本。

Simulcast Playgrounds

地址：https://orphis.github.io/webrtc-sandbox/simulcast-playground.html

又一个演示，这次是非官方的，但仍然是开源的。在这里，我们重点介绍 Simulcast。这是一种允许不同网络带宽的与会者以不同分辨率（带宽越高，分辨率越好）接收来自您的视频的方法。

为了避免占用服务器资源，每个与会者都会发送多个不同分辨率的视频流。本示例模拟了这种算法。它允许您配置视频传输参数，包括选择分辨率、帧频、编解码器和 Simulcast 的特定设置，如添加和删除层、更改优先级和配置编码器设置。

如果您从未听说过 Simulcast，最好先花点时间学习理论知识，然后再深入了解这个演示。

Pagination Demo App

地址：https://github.com/daily-demos/track-subscriptions

这是一款出色的工具，可帮助了解传入视频流的显示情况并管理其使用的资源。遗憾的是，在撰写本文时，扩展演示并不工作，但无论如何也不会有太大帮助，因为本产品的主要价值在于其源代码。

在源代码中，您可以了解如何正确管理来自其他通话参与者的视频/音频流。这一点在有大量参与者时尤为重要，因为此时屏幕上无法容纳所有参与者，因此有必要添加其他页面。在其他页面上接收与会者的数据流毫无意义，必须正确处理。

最有趣的组件是 “components/PaginatedGrid.js”，它几乎包含了管理渲染和数据流管理的所有逻辑。有关源代码和整个应用程序的说明，请参阅官方文档。

WebRTC 开源应用

Jitsi Meet

开发基于浏览器的视频通话最流行的开源产品之一。事实上，Jitsi 不仅包括网络客户端，还包括构建整个产品所需的所有其他部分。它是深入研究 RTC 主题的绝佳资源，但需要花费大量时间，因为 Jitsi 非常灵活，而且是一款拥有庞大代码库的老产品。

由于其规模和年代久远，该工具的入门门槛通常相对较高。有相当详细的文档，但同样非常广泛： https://jitsi.github.io/handbook/docs/category/developer-guide

Janus

Janus Gateway 是一款开源 WebRTC 服务器，可解决类似的问题。不过，与 Jitsi Meet 不同的是，Janus 专注于提供管理媒体流的底层 API，这使得它更灵活，但对初学者来说可能更复杂。该产品也更适合那些对服务器端而非客户端感兴趣的用户，而 Jitsi Meet 能更好地帮助他们。

Janus 附带了非常详细的文档和一大堆单独的演示（顺便说一下，上一节没有包括这些演示，但我仍然建议您查看一下）。

Mediasoup

MediaSoup 是另一款 WebRTC 服务器。与 Jitsi Meet 和 Janus Gateway 不同，它解决的问题与 Janus Gateway 相同，不同之处在于 MediaSoup 同时拥有服务器和客户端组件。

其他产品

事实上，有一大堆开源产品可用于构建视频通话；我提到的是我认为对学习 WebRTC 技术和方法最有用、最方便的产品。

推荐阅读：2023 年 WebRTC 100 大开源项目

不是结论

文章中没有讨论或创新，这意味着无法得出结论。我只是描述了我使用过的所有工具，我相信这远不是一份详尽的清单。

作者：Vadim Beskrovnov
译自：https://hackernoon.com/learning-webrtc-in-practice-best-tools-and-demos