WebRTC 减少播放时延

背景

产品未做优化的时候整段时延在网络状况良好的时候也有将近三四百毫秒。这对于时延要求比较高的场景是无法接受的,需要想办法去看下有没有优化的方案。

问题的排查

排查定位问题底层的思路,拆分法、控制变量法、搜索引擎,前人经验。

RTP拓展 播放时延(playout-delay)

这个方法是在WebRTC社区看到,忘记原贴地址了,WebRTC社区有了很多前人踩过的坑了,很多问题的思路可以在上面进行搜索

WebRTC 谷歌社区

这个方法是我想减少播放jitterBuffer的大小去减少播放时延发现的,这里的方法是官方文档的地址

webrtc.googlesource.com/src/+/refs/...

这个RTP拓展是RTP发送方想要改变接收方的播放延迟量限制在一定范围内,约定最小延迟和最大延迟。接收方会尽力交付,但是不一定会满足,和前端getUserMedia里面约束很像。

这里面有一定官方的指导值,我这里贴一下官方原话:

  • 0 ms: Certain gaming scenarios (likely without audio) where we will want to play the frame as soon as possible. Also, for remote desktop without audio where rendering a frame asap makes sense
  • 100/150/200 ms: These could be the max target latency for interactive streaming use cases depending on the actual application (gaming, remoting with audio, interactive scenarios)
  • 400 ms: Application that want to ensure a network glitch has very little chance of causing a freeze can start with a minimum delay target that is high enough to deal with network issues. Video streaming is one example.

具体的操作方法是: 我们在SDP的报文里面对RTP拓展做了声明

ini 复制代码
a=extmap:10 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

这里事先约定了ID为10的RTP拓展头的报文为播放时延拓展头,后续为WebRTC的识别做出指导

然后通过WireShark的报文可以过滤看到RTP报文存在拓展头ID是10的标识,代表接入成功

yaml 复制代码
    Header extensions
        RFC 5285 Header Extension (One-Byte Header)
            Identifier: 8
            Length: 2
            Extension Data: a256
        RFC 5285 Header Extension (One-Byte Header)
            Identifier: 10
            Length: 3
            Extension Data: 000000

移除SR报文

这里面对接进来RTP拓展,并把时延设置为0ms, 我当时是没发现有什么作用的,后来看了文档里面有一段关键的话:

Also, for remote desktop without audio where rendering a frame asap makes sense

这对于没有音频的场景是有意义的,那么反过来说就是如果存在音频通道的场景,这个值就是无意义的

那么为什么存在音频就无法设置0ms的尽快交付播放呢?后来我查了资料,存在音视频同步的概念,也叫音画同步,为了控制音画同步,WebRTC采用控制音频和视频的Jitter buffer 的延迟,间接控制了播放延迟,从而达到音视频同步的效果,那么也就影响了我们上面的设置的播放延迟。

音视频同步相关的了解:zhuanlan.zhihu.com/p/346004563

这里面涉及他们怎么实现音视频同步的,我这里不额外展开,需要关注的是,WebRTC是通过SR报文里面音视频采集的时间戳来实现同步的,那么当时我这边考虑是否去除了SR报文就可以了,确实是这样的,去除之后,E2E的时延就降低下来了,办公室的网络环境在220ms左右,减去T1的时延,在140ms左右,算是一个玩王者荣耀都算可玩的状态,算是一个阶段性的优化了

编码方式调整

这里还没做,未验证可行性和兼容性,后面再填坑

相关推荐
~央千澈~18 小时前
优雅草蜻蜓T语音会议系统私有化部署方案与RTC技术深度解析-优雅草卓伊凡|clam
webrtc·实时音视频·rtc
old-six-programmer2 天前
NAT 类型及 P2P 穿透
服务器·网络协议·webrtc·p2p·nat
大胡子大叔3 天前
webrtc-streamer视频流播放(rstp协议h264笔记)
笔记·webrtc·rtsp·webrtc-streamer
_可乐无糖3 天前
AWS WebRTC: 判断viewer端拉流是否稳定的算法
linux·服务器·webrtc·aws
却道天凉_好个秋3 天前
WebRTC(十三):信令服务器
webrtc
却道天凉_好个秋12 天前
WebRTC(七):媒体能力协商
webrtc
音视频牛哥13 天前
十年打磨,属于我们的技术进化与系统化演进之路
音视频开发·视频编码·直播
十年编程老舅13 天前
音视频流媒体高级开发-学习路线
ffmpeg·音视频·音视频开发·音视频编解码·c++音视频·流媒体服务器·音视频学习路线
MarkGosling15 天前
【开源项目】解放小爱音箱!用XiaoMusic打造你的私人无限曲库
人工智能·python·音视频开发