背景
产品未做优化的时候整段时延在网络状况良好的时候也有将近三四百毫秒。这对于时延要求比较高的场景是无法接受的，需要想办法去看下有没有优化的方案。
问题的排查
排查定位问题底层的思路，拆分法、控制变量法、搜索引擎，前人经验。
RTP拓展 播放时延（playout-delay）
这个方法是在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左右，算是一个玩王者荣耀都算可玩的状态，算是一个阶段性的优化了
编码方式调整
这里还没做，未验证可行性和兼容性，后面再填坑