我正在尝试尽可能减少远程机器控制应用程序的 Chromium WebRTC 视频延迟。由于发送和接收 PC 通过以太网(交叉电缆)直接连接，我猜可能不需要接收缓冲，因为不应该有延迟、乱序或丢失的数据包。
我在调整 jitter_buffer_common.h 中的 kMaxVideoDelayMs 值后重建了 Chromium。这产生了好坏参半的结果，包括在接收视频时产生不稳定的行为(断断续续)以及使 googPlisSent 随着时间的推移而稳步上升。此外，当 kMaxVideoDelayMs 设置为低于某个阈值(大约 60 毫秒)时，googJitterBufferMs 和 googTargetDelayMs 会不规律地跳跃。将 kMaxVideoDelayMs 设置为 100 毫秒时，一切似乎都运行良好，但我想尽量减少整体延迟。
我想知道是否可以完全禁用或绕过接收 jitter buffer ，因为这似乎可以减少在传输 PC 上捕获视频和在接收 PC 上显示视频之间的整体延迟。
最佳答案
您仍然需要一个 jitter buffer 来存储数据包，直到您拥有一个完整的帧(并执行其他相关的处理，这些处理都卡在 jitter buffer 之外)。音频 jitter buffer 通常有效地运行事物，并控制何时显示音频/视频。这一切都在 NetEq 中很深，并且可能无法被禁用。
如果您将音频和视频作为单独的流(未同步，或没有音频)运行，那么视频应该已经尽可能快地运行，但如果有延迟，那是由于操作系统调度，也可能有一些DeliverFrame 代码(或者更确切地说是最终调用 DeliverFrame 的代码)中的起搏延迟。
关于google-chrome - 是否可以在 WebRTC (Chrome/Chromium) 中禁用 jitter buffer ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33443085/