是否可以在 WebRTC (Chrome/Chromium) 中禁用抖动缓冲区

Question

我正在尝试尽可能减少远程机器控制应用程序的 Chromium WebRTC 视频延迟。由于发送和接收 PC 通过以太网（交叉电缆）直接连接，我猜可能不需要接收缓冲，因为不应该有延迟、乱序或丢失的数据包。

我在调整 jitter_buffer_common.h 中的 kMaxVideoDelayMs 值后重建了 Chromium。这产生了好坏参半的结果，包括在接收视频时产生不稳定的行为（断断续续）以及使 googPlisSent 随着时间的推移稳步上升。此外，当 kMaxVideoDelayMs 设置为低于某个阈值（大约 60 毫秒）时，googJitterBufferMs 和 googTargetDelayMs 会不规律地跳跃。将 kMaxVideoDelayMs 设置为 100 毫秒时，一切似乎都运行良好，但我想尽量减少整体延迟。

我想知道是否可以完全禁用或绕过接收抖动缓冲区，因为这似乎可以减少在发送 PC 上捕获视频和在接收 PC 上显示视频之间的整体延迟。

Answer 1

您仍然需要一个抖动缓冲区来存储数据包，直到您拥有一个完整的帧（并执行其他相关处理，这些处理已挂在抖动缓冲区之外）。音频抖动缓冲区通常有效地运行事物，并控制何时显示音频/视频。这一切都在 NetEq 中很深，并且可能无法被禁用。

如果您将音频和视频作为单独的流（未同步或没有音频）运行，那么视频应该已经以尽可能快的速度运行，但如果有延迟，这是由于操作系统调度造成的，并且可能还会出现在 DeliverFrame 代码（或者更确切地说是最终调用 DeliverFrame 的代码）中存在一定量的起搏延迟。