1200字范文 > 【WebRTC研究（2）】Kurento作为IPC的WebRTC网关（译）

【WebRTC研究（2）】Kurento作为IPC的WebRTC网关（译）

时间：2021-05-11 23:38:13

快速阅读本文

如果将WebRTC仅仅作为协议转换，而不进行编解码，简直是杀鸡用牛刀，更是对如此复杂框架的亵渎，因为转码能够实现：

适配不同的接收者的编码格式需求。

自动调整码率，以适应不同的网络带宽，并且不需要重新请求。

如果发生丢包，能够自动重发关键帧。

Kurento服务器能够实现：

能够根据接收者的要求，创建不同的编码格式（比如VP8和H.264）。并且，相同的编码格式能够分发给不同的观看者——即相同格式只编码一次，以降低性能消耗。

性能测试

转码方式，性能消耗会随着数量的增加而直线上升。透传方式，数量增加对性能影响很小。

VP8使用的内存量是H.264的两倍，同时也使用更高的CPU。同样，VP8使用的CPU似乎随着比特率的提高而略有增长，而H.264的CPU使用率似乎不受输出比特率的影响。

码率自动调整：VP8波动更大，好处是短时间提供更高的视频质量。H.264更加稳定，同时需要花更多的时间达到最好的视频质量。

视频源的质量必然会影响服务器解码性能，应该根据理想情况下用户最低可接受的视频质量做出选择。

向多个用户提供同一路码流是，CPU和内存的性能消耗几乎没有变化。

以下为原文

有关将IP摄像机与基于WebRTC的流解决方案集成的主题是本博客之前涉及的一个主题：互操作性WebRTC和IP摄像机。从那篇文章开始已经有一段时间了，所以在这篇文章中，我们想对上一篇文章中处理过的所有基本概念进行某种回顾，以及对人们在做出更多技术决定时的新观点。设计一种架构，其中IP摄像机通过Kurento Media Server作为WebRTC端点发布。

WebRTC传输

尝试将IP摄像机与WebRTC应用程序集成时，首先要担心的是视频和音频流之间的兼容性。WebRTC规范对支持哪种视频编码格式（也称为编解码器）非常明确，并且浏览器通常也符合标准所说的内容：任何符合标准的实现都必须能够同时支持VP8和H.264视频编解码器（参见 RFC7742 / 5. Mandatory-to-Implement Video Codec）。

因此，符合WebRTC的浏览器将能够识别以VP8或H.264编解码器编码的视频。幸运的是，这两个编解码器几乎是行业中的事实上的标准，因此大多数（即便不是全部）IP摄像机已经支持它们（特别是H.264，这是很多视频中最常见的编解码器）。

听起来不错，不是吗？

从理论上讲，这可能意味着大多数摄像机生成的H.264视频应能够作为WebRTC流直接传输，如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t8QjRC24-1574416259698)(/5m4LfgrkS1VVUi3QgvlVIxOzqxNx7ZcaEMtKojJ6BuibJMm-9X13TJi_UZvy794_EUxlnsXQrQKu2rANJK4SSwYxWlwBFdw1WPGfij-biql1owZXcrbtzo5PwAqVjX276jyoFDOo)]

图1：IP Camera到WebRTC媒体网关的最简单配置

这看起来不错，并且实际上这样的网关的资源消耗将是最小的，因为它将只是传输之间的转换，而不做任何编解码的处理。

但是，这种简单的设置存在一些隐患：如果有些接收者不支持IP Camera的编码格式，该怎么办？如果网络不可靠并且观看者没有足够的带宽观看视频，该怎么办？

WebRTC不仅仅是一个“透传”的功能。如果真是这样，那么该标准的复杂性就没有多大意义了！我们也可以直接将RTSP流发送给观众。实际上，WebRTC的重点是能够以安全，可靠和有效的方式提供视频，这必须包括能够在网络连接不稳定且遭受各种现实问题的情况下做出适当的响应，例如网络拥堵，数据包丢失以及其他类型的网络异常行为。

因此，WebRTC支持多种反馈机制，允许任何观看者向发送者“汇报”当前的网络状况：

[img)(/yR5CsJMnOJJax8aVcel81tURfM4F1bNnHh4Cp5smQiYKpiN8NNmhtnl6ssW2cedBfcXWp8_HQHAXWIoLO6Ml_1TwLxFWUvGwd8aHJgXbVfcppeCyiNUvzLgn-5SAj3aJ2VHuUEXN)]

图2：完整的媒体网关配置，允许转码并对不良的网络条件做出反应

通过引入一对解码器和编码器——通常称为转码，网关能够解决编解码器兼容性和网络可靠性问题。然后，中间编码器可以根据反馈信息做出相应的反应：

当网络拥塞时，接收器将SRTCP控制数据包发送回网关，其中包括REMB消息。这些消息包含可用于视频接收的实际带宽的估计，网关相应地调整其编码比特率。

当某些数据包丢失时，接收器还会发送包含PLI消息的 SRTCP数据包，要求网关重新发送视频关键帧，以使其从丢失的视频数据中恢复。

例如，常见的情况是网络变得拥塞，（通过REMB消息）指示视频编码器降低比特率并生成质量较低的视频作为响应。因此，该视频会更小，可以更好通过拥塞的网络进行传输。

WebRTC带来的反馈方法对于大多数典型的现实世界网络来说都可以很好地工作，但是它要付出代价：现在媒体网关需要做更多的工作——转码。这通常是一个值得折衷的选择。

使用Kurento Media Server

到目前为止，我们已经描述了将视频从摄像机（或任何其他视频源）传输到WebRTC用户（例如Web浏览器）的典型场景以及相关的困难。陈述的问题是所有解决方案共有的，任何网关都必须以一种或另一种方式处理它们。

Kurento Media Server提供了涵盖所有上述要点的综合解决方案。PlayerEndpoint可以执行从各种来源获取视频流以及可选的媒体转码的操作。然后，与WebRTC通信相关的所有内容都由WebRtcEndpoint处理。仅通过这两个组件，可以涵盖上一章讨论的所有重要细节，并且您将拥有一个适用于IP摄像机的完全正常工作的WebRTC媒体网关：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IPW1KWb4-1574415825353)(/zKuJHewlHdRieE6AnfuXexvj1exclqE3o4MNXrwbclJJbjLqEGOL6hKPawaZ0Ti9A6gxRIJb8rPW-tAjeS_JgOV_e2VZOLDry6ktwckV5NhXps0V9LEskj8rDrQlMdsHO6-yUxDm)]

图3：使用Kurento Media Server实现IP Camera到WebRTC媒体网关

该图中的关键元素是Agnostic转码，在Kurento中是由称为agnosticbin的组件执行的。该组件封装了转码操作，如前所述，在该处处理SRTCP数据包，从而支持比特率调整（基于REMB消息）或重新生成视频关键帧（基于PLI消息）。

同样在agnosticbin元素中，将根据接收者的要求，选择最佳的视频编码器。比如，原始视频为H.264编码，但是接收方仅支持VP8，则此时视频将被转换为VP8。

另一个有用的功能是，WebRtcEndpoint可以调整最大和最小视频比特率。这样，自动调整比特率时将被限制在我们设定的范围内。

Agnosticbin编码树

在实现我们的应用程序时，我们可能希望同一条流具有多个接收者。这是否意味着每个观看者都需要独立的转码过程？

这是一个好问题，答案并不绝对。每个观看者使用独自的转码过程确实是理想的解决方案，因为它允许每个人根据自己的需要调整比特率。但是，副作用就是过大的资源浪费，以至于根本无法承受大量的观看者。

Kurento实施了一种折衷解决方案，其中每种编解码器类型都执行一次代码转换过程，然后将所得视频分发给所有使用者——前提是相同的编码格式。Kurento内部的agnosticbin元素实现了该功能，该树涵盖所有使用者的编解码器要求，而无需两次执行相同的工作：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DQVOAmOO-1574415825353)(/yerHuLogvPMHDzm1vKHBiH0n-ofalgCtZ7GA0S0S7C-AQRMkzF3q1Yt_cGX_Orgl9LdWp7FMT1ygd0psGD7oJushVAOq0MrktyNeaqdGM-WmVuDUzkcdQDIfi4NpROqsJcuJVPoO)]

图4：2个VP8和2个H.264消费者的Agnosticbin编码树

最终的结果是您的服务器将不会使用比实际需要更多的CPU。就CPU使用率而言，对视频进行编码是一项非常昂贵的任务，但是一旦完成，每个其他WebRtcEndpoint使用者都会增加很少量的额外资源使用量。

性能比较

在将WebRTC应用于商业项目时，我们往往会遇到下面一些问题：

在性能上，使用VP8或H.264编码的视频之间是否有实际区别？在WebRTC网关中执行转码实际上需要消耗多少性能？如果必然要重新编码，是否需要IP摄像机具有极高的质量？

在本节中，我们将比较几种可能的配置，以及带来的影响，以试图阐明其中的一些问题。

本节中测试结果是基于以下配置：

CPU：Intel Core i5-5675C @ 3.10GHz（4核）内存：16 GB DDR3网络：100 Mbps LAN

最后，在软件方面，以下测试具有以下特征：

包括模拟不利网络条件的测试使用慢速网络帮助程序脚本。所有结果的4个RTSP流的持续时间为4分钟。在测试期间，每分钟一次向系统添加一个新的IP摄像机流到WebRTC管道，在测试结束时总共有4个RTSP流和4个WebRTC使用者。这也是为什么所有CPU /内存使用情况图都带有4个“步骤”的楼梯，因为每个步骤都对应于添加新的RTSP源和WebRTC使用者。所有测试均在WebRtcEndpoint上设置了最大比特率，以将接收到的REMB带宽估计限制在受控范围内。

转码 vs 透传

我们已经提到Kurento 负责agnosticbin元素，以提供RTSP源和WebRTC使用者之间的视频编解码器互操作性。但是，转码过程在PlayerEndpoint内部是可选的。这意味着仅通过使用PlayerEndpoint的构建器参数useEncodedMedia，就完全有可能使用KMS 模拟图1 的简单体系结构。使用此参数时，将完全跳过PlayerEndpoint内部的不可知元素：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uM2LFbVI-1574415825354)(/kmJehlvvRcz5HLTORFlcLHEI-XSIg43qEf6v7WO6N8tQCJlfQ9vzzoDGf_urq9g7WM7g4lhH_IeKlTofiE0AcctxqcjzaYKDLGqHuC5b3Mpo-0LgYw8-tQUMKbVhv4SwpoOF10lg)]

图5：将Kurento的播放器端点与“ useEncodedmedia”一起使用

这样的效果是，如图1 所示，媒体直接从源传输到WebRTC传输。当然，这具有不能使用SRTCP反馈消息来适应不同网络条件的问题，但是它允许在IP摄像机和WebRTC使用者之间建立快速而简单的网关。

此配置的资源消耗非常小：

如果网络条件良好，则透传是最佳选择（例如，局域网或具有QoS功能的路由）。此模式相当于禁用了WebRTC的所有QoS相关功能。当然，CPU和内存使用量将会降至最低。但是，正如我们已经明确指出的那样，如果发生任何网络事故，视频流的接收将受到以下几个问题的困扰，例如：丢帧导致的卡顿、花屏，甚至连接断开等。

VP8 vs. H.264

资源使用

在尝试比较WebRTC视频编码的这两种选择时，我们可以通过不同的角度进行观察。首先是CPU和内存使用率。我们将通过几个图表来看到这一点：

码率自动调整（网络畅通）

以下测试基于Chrome浏览器。

但是，资源使用并不是我们选择某一编码器的唯一标准。

让我们从客户端的角度看发生了什么，并分析从Chrome浏览器发送到媒体服务器的REMB消息的内容

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-icLN7mG5-1574415825355)(/C_AbrVQCTnuvQ4sQe-OJlmVCroaIoD3Q_bqEV2ilYLeetVRi3BbsSxSW1ryD8cU2F3kmyvpEQz0TDGLfpRDFSXtNCtqE7HdpszBseYtvPcnzGJP0Xo4PgnB8SgpGk_h5yaWPDWoZ)]

WebRTC VP8 REMB比特率提高到允许的最大值（20 Mbps）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FUyUiUOq-1574415825355)(/T2Olh0SVyQyypGYV-RPu3F5ftPFbB6nY07hWCOAVCuqbervhtbB6JGmL5mzg9SoycEOyXtQab0A2QP1zeyAWxi_hRe0j6z8FP56EGZ9zNi7omq4X-QpVkjPFmMD5fX2ZdQit6nMC)]

WebRTC H.264 REMB比特率提高到允许的最大值（20 Mbps）

VP8更具侵略性，能够达到20 Mbps的最大可用比特率。这种侵略性意味着，当网络出现拥塞时，它有可能超过实际可用带宽，下面的测试将会看到这一现象。无疑，这种机制的好处是VP8能够在非常短的时间内提供更好的质量。

H264的反应时间要慢得多，在4分钟的测试中，它只能达到大约2.5 Mbps，即使最大可用带宽是20 Mbps。这意味着，当使用H.264时，Chrome需要花更多的时间来达到最高的质量水平。另一方面，当网络拥塞发生时，它的缓慢意味着一个更稳定的变化，如下图所示。

码率自动调整（网络拥塞）

以下测试基于Chrome浏览器。

当发生网络拥塞时，消费者可用于接收视频的带宽将变得比平时更小，服务器应尝试限制编码比特率。接下来的这些图显示了模拟VP8 的5 Mbps和H.264的2.5 Mbps最大带宽的效果：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-COKVTUpl-1574415825355)(/gfUL96wUHhWUclChEwV5kIkweS7fPElcmOxPnF9eJZShXp7F9mVUenhIxfVsA3QwmzEpznxnZnqWHR99rS76JTBwCHtFZReE89SNLmZj0Diuht3Y9cV3WLeqyLqBzftA36pifnBN)]

WebRTC VP8比特率提高到拥塞（5 Mbps）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tKpPOKhf-1574415825356)(/0f4HKoVaK_fFAa_bIN-04AxY3hDTiXd_Q9tQCNYy0QK5mUXh_pCi7lTLSktliZjRBuYfoTbOMJHObLg8t9sKttC0jZAaldC9uTb2_mkYwAYQknNAIJRI00LMx9j-_XZzdATGtf0H)]

WebRTC H.264比特率提高到拥塞（2.5 Mbps）

在这里，我们看到了前面提到的过冲的一个清晰示例：VP8疯狂地尝试调整为实际可用带宽，但是在尝试中它变得高于实际可用带宽，因此REMB估算值大幅度下降，以便补偿。然后，快速上升再次开始。所以波动非常大。

反观H.264，运行缓慢且稳定，一旦将每个新用户添加到会话中，我们甚至可以看到可用比特率略有下降。添加第二个用户后，第一次REMB校正会非常大，但是之后，其他用户带来的影响非常小（由于实际可用的带宽是4个消费者之间共享，每个消费者的比特率会越来越低）。

IP摄像机中的视频设置

我应该将相机配置为最高质量的影像吗？

这是一个好问题。鉴于稍后将对视频进行重新编码以适应网络带宽，所以在原始源中设置最高的视频质量可能会更好。

这个其实还是一个需要妥协的问题。从IP摄像机发送到Kurento的高质量视频将意味着进行解码需要更高的CPU和内存要求：

在这些测试中，来自RTSP IP摄像机的原始流首先配置为高质量1080p，然后配置为中等质量720p。

1080p视频的设置如下：

H.264 High Profile1920x1080（1080p）4000 kbps VBR @ 30 fps

同样，720p视频的配置如下：

H.264 Baseline Profile1280x720（720p）2000 kbps VBR @ 30 fps

如您所见，无论我们为最终的视频编解码器选择什么，在对WebRTC的视频进行代码转换时，原始材料的原始格式都会对资源使用产生影响。

理想情况下，我们应该根据用户最低可接受的视频质量来做出决定，因为当REMB比特率提高时，他们在屏幕上看到的内容最接近相机生成的原始视频。

单摄像机，多观众

正如我们前面提到的，agnosticbin组件足够聪明，可以避免对同一视频进行多次编码，而只是构建一个编码“树”，该树可以向多个使用者提供单个编码流。

这种设计选择的效果是，每个编解码器仅对CPU和内存使用量进行“付费”一次，并且随后的使用者向计算机添加的资源使用量可忽略不计：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iblffDzP-1574415825359)(/nRLUujxAQXWqpEyX0AmI3RSr1ZdtGTBg6XN3v1A0R5ntolvUF6jZFrnbAMlP-hBvJTYrrTBU55U9Fr41EL8OxELlYmocGF4Nab5lGM_mkg58i_Qaw2iP6iSEwuhJHvyI6QK5WlDT)]

此图显示了持续12分钟的测试中CPU和内存使用的演变情况，其中每分钟将一个新的WebRTC使用者连接到同一RTSP源摄像机，总共12个使用者。如您所见，机器资源的平均使用完全由最初为接收RTSP视频而进行的单个转码驱动。