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左右,算是一个玩王者荣耀都算可玩的状态,算是一个阶段性的优化了

编码方式调整

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

相关推荐
音视频牛哥19 小时前
干货分享之如何设计实现跨平台超低延迟RTSP播放器
音视频开发·视频编码·直播
音视频牛哥20 小时前
从RTSP播放遇到RTP无 Marker探讨RTP规范化打包与稳健切帧
音视频开发·视频编码·直播
她超甜i1 天前
前端通过后端给的webrtc的链接,在前端展示,并更新实时状态
前端·javascript·webrtc
计算机小手2 天前
高效 P2P 文件传输工具:FileSync 利用 WebRTC 技术实现极速安全传输
经验分享·docker·webrtc·开源软件
AI码上来3 天前
当小智 AI 遇上数字人,我用 WebRTC 打造实时音视频应用
人工智能·webrtc·实时音视频
Antonio9153 天前
【音视频】WebRTC 音视频延时、同步分析以及超低延时优化
音视频·webrtc
音视频牛哥3 天前
《“人工智能+”行动意见》深度解析:从智能红利到产业落地,直播模块的技术价值与应用路径
人工智能·计算机视觉·音视频开发
RTC老炮4 天前
webrtc弱网-LossBasedBandwidthEstimation类源码分析与算法原理
网络·算法·webrtc
小噔小咚什么东东4 天前
看到了很多次WebRTC,但是你真的需要它吗?
前端·webrtc
Antonio9154 天前
【音视频】WebRTC P2P、SFU 和 MCU 架构
音视频·webrtc·p2p