发布和播放
在流视频领域，服务器端WebRTC操作有两个主要功能：发布和播放。 在发布的情况下，视频流是从网络摄像机捕获的，并从浏览器移动到服务器。 在播放的情况下，流从服务器到浏览器以相反的方向移动，并在设备屏幕上的浏览器的HTML5 <video>元素中进行解码和播放。
UDP和TCP
视频可以通过两种传输协议移动：TCP或UDP。 对于UDP，NACK RTCP反馈会主动工作，携带有关丢失数据包的信息，由于这是检测UDP信道恶化的一项非常简单的任务，因此归结为对NACK（负ACK）进行计数以确定质量。 NACK和PLI（图片丢失指示器）反馈越多，实际损耗就越多，并且信道质量越低。
不带NACK的TCP
在本文中，我们将重点放在TCP协议上。 在TCP上使用WebRTC时，不会发送NACK RTCP反馈，即使发送了NACK RTCP反馈，也不能反映出损耗的真实情况，并且似乎无法通过反馈来确定信道质量。 众所周知，TCP是具有保证传递的传输协议。 因此，在信道质量恶化的情况下，将在传输协议级别上发送网络中存在的其余数据包。 迟早会将其交付，但不会为这些损失生成NACK，因为实际上没有损失。 结果，分组将延迟到达其目的地。 延迟的数据包根本不会聚集到视频帧中，并且会被拆包器丢弃，结果用户将看到这样的图片，其中充满了伪像：
反馈将显示一切正常，但图片将包含伪影。 您可以在下面看到Wireshark流量的屏幕截图，这些屏幕截图说明了在压缩的TCP和UDP通道上发布的流的行为，以及Google Chrome统计信息的屏幕截图。 在屏幕截图中，您可以看到在TCP情况下，即使通道状态非常糟糕，NACK指标也不会像UDP一样增长。
TCP协议
UDP协议
如果存在UDP，为什么还要通过TCP进行流传输
这是一个合理的问题。 答案是，要通过渠道推动大决议。 例如，在VR（虚拟现实）流传输的情况下，分辨率可能从4k开始。 似乎不可能将具有这种分辨率和约10 Mbps比特率的流无损地推送到常规信道中，服务器吐出UDP数据包，然后开始在网络中成束丢失它们，然后剩下的他们开始被发送，依此类推。 大量丢弃的视频数据包会破坏视频，最终结果是质量会很差。 这就是为什么使用TCP上的WebRTC来在通用网络中以较高的分辨率（例如Full HD和4k）传送视频以消除网络数据包丢失（以略微增加通信延迟为代价）的原因。
RTT用于确定信道质量
因此，没有任何指标可以确保频道处于非常糟糕的状态。 一些开发人员试图依靠RTT指标，但是它远不能在所有浏览器中都能使用，并且无法给出准确的结果。
您可以在下面找到根据callstat项目的信道质量对RTT依赖性的图示
基于REMB的解决方案
我们已决定对这个问题采取稍微不同的方法。 REMB在服务器端工作，它计算所有传入流的传入比特率，计算其与均值的偏差，并建议浏览器在明显分散的情况下降低比特率，并通过RTCP发送专门的REMB命令协议。 浏览器会收到这样的消息，并将视频编码器的比特率降低为推荐值：这是防止信道过载和传入流降级的方法。 这样，比特率计算机制已经在服务器端实现。 色散的平均值和确定是通过卡尔曼滤波器实现的。 这允许在任何时间以高精度获得当前比特率，并过滤任何明显的偏差。
读者肯定会有这个问题，“如何帮助我知道服务器可以看到流中的比特率？”这只会让您了解到视频以比特率的值进入服务器。其中有可能确定。 要评估通道质量，将需要一个以上的组件。
即将到来的比特率及其重要性
发布WebRTC流的统计信息显示了视频流从浏览器输出的比特率。 就像一个老笑话一样，一位站点管理员在检查他的突击步枪时说：“在我这一边，子弹已经飞了出来。 问题就在您这边。。。“检查信道质量的想法涉及比较两个比特率：1）浏览器发送的比特率，2）服务器实际接收的比特率。
站点管理员发射子弹并计算它们在他身边飞出的速度。 服务器计算在其一侧接收它们的速度。 TCP还有另一个参与者，TCP，这是一个超级英雄，位于管理员和服务器之间的中间，可以随意停止项目符号。 例如，它可以停止10枚100枚随机子弹，持续2秒钟，然后让它们再次飞行。 这就是我们在这里看到的矩阵。
在浏览器端，我们从WebRTC统计信息中获取当前比特率，然后在JavaScript实现中使用Kalman过滤器对图形进行平滑处理，并在流程结束时获得客户端浏览器比特率的平滑版本。 现在我们几乎满足了所有需要：客户端比特率告诉我们流量如何从浏览器中流出，服务器比特率告诉我们服务器如何看到流量，以及接收到的比特率是多少。 显而易见，如果客户端比特率仍然很高，并且服务器比特率相对于客户端比特率开始下降，则意味着并非所有项目符号都“到达目标”，并且服务器实际上看不到一部分流量发送给它。 在此基础上，我们可以得出结论，通道出了点问题，是时候将指示器颜色更改为红色了。
还有更多
这些图相互关联，但是它们之间的时间偏移很小。 为了实现完全相关，有必要对图形进行时间匹配，以便将同一时间点的客户端和服务器比特率与历史数据进行比较。 去同步看起来像这样：
这就是时间同步图的样子。
让我们测试一下
我们还有一点要做，我们只需测试一下。 让我们发布视频流，打开它，然后查看发布的比特率的图形：在浏览器端和服务器端。 这些图显示出几乎完美的匹配。 这就是指标的名称，即PERFECT。
然后，让我们开始破坏频道。 为此，我们可以使用以下免费工具：Windows的winShaper或MacOS的网络链接调节器。 它们允许将通道压缩到预设值。 例如，如果我们知道640x480的流可以达到1 Mbps的速度，那么让我们将其压缩为300 kbs。 这样做时，我们一定不要忘记我们正在使用TCP。 让我们检查一下测试结果：图形中存在反相关关系，指标滑向BAD。 确实，浏览器继续发送数据，甚至在增加比特率以试图将新的流量推入网络。 此数据以重传的形式累积在网络中，并且无法到达服务器，结果服务器显示了相反的图像，并说它可以看到的比特率下降了。 确实，这很糟糕。
我们已经进行了大量测试，这些测试表明指示器的正确操作。 因此，我们具有一项功能，可以可靠且迅速地将流发布和播放的通道问题通知用户（按照相同的原理）。 是的，所有这些大惊小怪都是为了这个绿色和红色的灯，完美无瑕。 但是实践表明，该指标非常重要，如果缺少该指标以及无法了解当前状态，可能会给WebRTC视频流服务的普通用户带来大麻烦。
友情链接
WCS 5.2是用于Web和移动应用程序开发的流媒体服务器
发布者和播放者渠道质量控制
REMB-用于带宽控制的接收器估计最大比特率
NACK-用于数据包丢失控制和重新发送的否定确认