发布和播放
视频流中有两个主要的服务器端WebRTC功能：发布和播放。 在发布的情况下，视频流是从网络摄像头捕获的，并从浏览器移动到服务器。 在播放的情况下，流以相反的方向移动-从服务器到浏览器，在设备屏幕上的HTML5 <video>浏览器元素中被解码并播放。
UDP和TCP
视频可以在两种传输协议上移动：TCP或UDP。 在UDP的情况下，RTCP NACK反馈正在积极工作，该反馈携带有关丢失数据包的信息，因此，确定UDP通道的恶化是一项相当简单的任务，减少了对NACK（负ACK）的计数以确定质量。 NACK和PLI（图片丢失指示器）反馈越多，实际丢失越多，信道质量越差
不带NACK的TCP
在本文中，我们将对TCP协议更加感兴趣。 在TCP上使用WebRTC时，不会发送NACK RTCP反馈，如果发送了，则它们不会反映损耗的真实情况，并且无法从反馈中确定通道的质量。 如您所知，TCP是保证交付的传输协议。 因此，在信道降级的情况下，网络上的数据包将以传输协议级别发送。 迟早会将其交付，但不会为这些损失生成NACK，因为 实际上没有损失。 包裹最终会迟到。 迟到的数据包根本不会被收集在视频帧中，并且会被拆包器丢弃，结果，用户将看到类似以下内容的东西：
根据反馈，一切都会好起来的，但是图片中会出现伪像。 以下是Wireshark流量的屏幕截图，这些屏幕截图说明了在压缩的TCP和UDP通道上已发布流的行为，以及Google Chrome统计信息的屏幕截图。 屏幕截图显示，在TCP的情况下，与UDP相比，NACK度量标准没有增长，尽管事实是该通道的一切情况都很糟糕。
TCP协议
UDP协议
还有为什么如果有UDP则需要通过TCP流传输
合理的问题。 答：通过通道推动大分辨率。 例如，在流式传输VR（虚拟现实）时，权限可能始于4k。 不可能将这种分辨率和约10 Mbps比特率的流推入常规通道而不会丢失，服务器会吐出UDP数据包，然后它们开始在网络中的数据包中丢失，然后发送出去，依此类推。 视频数据包的大量转储破坏了视频，最终质量变差。 因此，对于通用网络和高分辨率全高清（4k），基于TCP的WebRTC用于视频传输，以消除网络数据包丢失为代价，但会增加一些通信延迟。
RTT确定频道质量
因此，没有度量可以保证说该通道的所有情况都不好。 一些开发人员尝试依赖RTT指标，但是它不适用于所有浏览器，并且无法给出准确的结果。
下面根据callstat项目的版本说明了信道质量对RTT的依赖性
REMB解决方案
我们决定从稍微不同的角度来解决这个问题。 REMB在服务器端工作，该服务器端计算所有传入流的传入比特率，计算其与平均值的偏差，并且在大范围扩散的情况下，可通过RTCP协议发送特殊的REMB命令来使浏览器降低比特率。 浏览器会收到这样的消息，并将视频编码器的比特率降低为推荐值-这就是防止通道过载和输入流降级的方法。 因此，在服务器侧，已经实现了用于计算比特率的机制。 平均和散射确定通过卡尔曼滤波器实现。 这使您可以随时以高精度消除当前比特率，并滤除严重偏差。
读者可能会有一个问题-“服务器在传入流上看到的比特率知识将给它带来什么？” 这样可以准确了解具有比特率的视频正在服务器上输入的内容，并确定其值。 要评估通道的质量，还需要一个组件。
外发比特率及其重要性
发布WebRTC流的统计信息显示视频流以什么比特率退出浏览器。 就像一个大胡子的玩笑：管理员，检查机器：“子弹从我这边飞出来。 问题就在你身边..“ 检查通道质量的想法是比较两个比特率：1）浏览器发送的比特率2）服务器实际接收的比特率。
管理员发射子弹并计算其离开家的速度。 服务器计算在家中接收它们的速度。 此事件中还有另一个参与者，TCP是一个超级英雄，位于管理员和服务器之间的中间位置，可以随机放慢子弹的速度。 例如，它可以在100秒内制动100颗随机子弹，持续2秒，然后让它们再次飞行。 这是一个矩阵。
在浏览器端，我们从WebRTC统计信息中获取当前的比特率，然后在JavaScript实现中使用Kalman过滤器对图形进行平滑处理，并在输出中获得客户端浏览器比特率的平滑版本。 现在我们几乎拥有了所需的一切：客户端比特率告诉我们流量如何离开浏览器，服务器比特率告诉服务器如何看到此流量以及接收到的比特率。 显然，如果客户端比特率仍然很高，并且服务器比特率相对于客户端开始下降，则意味着并非所有“子弹都已飞过”，并且服务器实际上看不到发送给它的流量的一部分。 基于此，我们得出结论，该通道出了点问题，是时候将指示灯切换为红色了。
还有更多
这些图是相关的，但是时间相对于彼此略有偏移。 对于完全相关，有必要组合时间表以比较历史数据在同一时间点的客户端和服务器比特率。 取消同步看起来像这样：
它看起来像一个时间同步的图表。
测试中
这种情况很小，有待测试。 我们发布视频流，打开并观看发布的比特率的时间表：在浏览器端和服务器端。 根据图表，我们看到了几乎完美的匹配。 该指标称为“完美”。
接下来，我们开始破坏渠道。 为此，您可以在Windows上使用免费的“ winShaper ”工具，在MacOS上使用“ Network Link Conditioner ”。 它们使您可以将通道捏到设定值。 例如，如果我们知道640x480的流可以加速到1Mbps，则将其压缩到300 kbs。 同时，我们还记得我们正在使用TCP。 我们检查测试结果-图形显示反相关，并且指标陷入不良状态。 实际上，浏览器会继续发送数据，甚至提高比特率，试图将新的流量推入网络。 该数据以重传的形式驻留在网络上，并且没有到达服务器，结果，服务器显示了相反的图像并说它看到的比特率下降了。 真的不好
我们进行了许多测试，这些测试表明指示器的正确操作。 结果是一项功能，使您可以定性和有效地通知用户有关通道的问题，以发布流和回放（其工作原理相同）。 是的，为了这个绿色红色的PERFECT-BAD灯泡，我们将整个花园围起来。 但是实践表明，该指标非常重要，对当前状态的缺失和误解会极大地破坏通过WebRTC进行视频流服务的普通用户的生活。
参考文献
WCS 5.2-用于开发Web和移动视频应用程序的媒体服务器
WebRTC通道质量控制文档，用于发布和播放
REMB-服务器端比特率管理
NACK-控制来自服务器端的丢失数据包