是否可以在WebRTC (铬/铬)中禁用抖动缓冲区
我正在尝试减少铬WebRTC视频延迟尽可能多的远程机器控制应用程序。由于发送和接收PC是通过以太网(交叉电缆)直接连接的，我猜接收缓冲可能不是必需的，因为应该没有延迟、无序或丢失的数据包。
在调整了jitter_buffer_common.h中的kMaxVideoDelayms值后，我重建了Chromium。这给出了好坏参半的结果，包括创建接收视频的不稳定行为(断断续续)，以及使googPlisSent随着时间的推移稳步上升。此外，当kMaxVideoDelayMs设置为低于某个阈值(约60ms)时，googJitterBufferMs和googTargetDelayMs会不稳定地跳转。当kMaxVideoDelayMs设置为100ms时，一切似乎都运行得很好，但我想尽量减少总的延迟。
我想知道是否可以完全禁用或绕过接收抖动缓冲区，因为这似乎可以减少在发送PC上捕获视频和在接收PC上显示视频之间的总延迟。
回答 1
Stack Overflow用户
发布于 2015-11-06 14:11:45
您仍然需要一个抖动缓冲区来存储数据包，直到您拥有了整个帧(并执行挂起的其他相关处理)。音频抖动缓冲区通常可以有效地执行任务，并控制何时显示音频/视频。这一切都在NetEq中，很可能无法禁用。
如果您将音频和视频作为单独的流(未同步或无音频)运行，那么视频应该已经尽可能快地运行了，但如果存在延迟，这是由于操作系统调度造成的，而且在DeliverFrame代码(或者更确切地说，最终调用DeliverFrame的代码)中也可能存在一定的调整延迟。
https://stackoverflow.com/questions/33443085
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号