WebRTC - 删除/减少共享视频流的设备之间的延迟？

Question

我很抱歉没有发布任何代码,但我正在尝试更多地了解延迟和webRTC,最好的方法是remove latency between two or more devices that are sharing a video stream什么？

或者,无论如何,尽可能减少延迟？

考虑到这一点,我想把设备的时钟放到同一时间,以便延迟服务器的请求,这是真正的伎俩吗？

Answer 1

延迟是源(麦克风,摄像机)和输出(扬声器,屏幕)之间路径上的步数的函数.

更改时钟对延迟的影响为零.

您的延迟包括:

设备内部延迟 - 等待屏幕vsync等...; 这里没什么可做的
设备接口延迟 - 较短的电缆可以节省您一些时间,但没有任何可测量的
软件延迟 - 您的操作系统和浏览器; 你或许可以在这里做点什么,但你可能不想,相信你的浏览器制造商正在尽其所能
编码延迟 - 一个更快的处理器在这里有所帮助,但最大的问题是像音频这样的东西,编码器必须等待一定量的音频累积才能开始编码; 默认情况下,这是20ms,所以不多; 最终,你将能够为Opus请求更短的ptimes(控件的名称),但它还处于早期阶段
解码延迟 - 再次,更快的处理器有点帮助,但没有太多工作要做
抖动缓冲延迟 - 音频特别需要在接收器处有一点额外的延迟,这样任何网络抖动(数据包传输速率的波动)都不会导致音频间隙; 这通常是你无法控制的,但这并不意味着它完全不可能
重新同步延迟 - 当您播放同步音频和视频时,如果因任何原因而延迟播放,则可能会延迟另一个播放,以便两者可以一起播放; 这个应该相当小,很可能超出你的控制范围
网络延迟 - 这是您可以提供帮助的地方,可能很多,具体取决于您的网络配置

当谈到两个对等体之间的距离时,你无法改变这种情况的物理特性,但是有很多网络特征可以改变实际的延迟:

直接路径 - 如果由于任何原因,您正在使用中继服务器,那么您的延迟可能会受到很大影响,因为每个数据包都不会直接传输,它需要绕过中继服务器
管道的大小 - 尝试将高分辨率视频压缩到一个小管道上可以工作,但是在一个小管道上获得大的帧内帧可能会增加一些额外的延迟
TCP - 如果禁用UDP,则回退到TCP可能会对延迟产生非常严重的影响,这主要是由于特殊的数据包丢失,这需要重新传输并导致后续数据包延迟直到重传完成(这称为线路阻塞); 这也可能发生在某些不正常的NAT场景中,即使理论上启用了UDP,但很可能会导致使用中继服务器
更大的网络问题 - 也许您的同行在不同的ISP上,而且这些ISP的对等安排很差,因此数据包在对等体之间采用次优路由; traceroute可以帮助您确定事情的进展
拥塞 - 也许你网络上有一些拥塞; 拥塞往往会导致额外的延迟,特别是当它由TCP引起时,因为TCP往往会填满路由器中的尾部丢弃队列,迫使你的数据包等待额外的时间; 如果使用数据通道,也可能导致自我拥塞,拥塞控制算法与TCP默认使用的算法相同,这对于实时延迟是不利的

我确信这不是一个完整的分类法,但这应该给你一个开始.