业界(直播/视频会议等场景)常用的首屏秒开技术初探

由于2021年3月份入职了一家新公司，工作一直比较忙，2021年都没写几篇学习总结的文章，今天有点时间来写一篇，扯淡的话不扯了，下面步入主题。

做过视频传输的同学应该都知道，以直播为例，推流端的GOP一般是间隔几秒，如果GOP过小，I帧就会比较多，势必会占用比较大的带宽，这种情况下，如果拉流端的链路不好，势必会影响观众的体验。比较好的做法是在服务端缓存1到2个GOP，这样服务端可以先把缓存的GOP数据发送给后进来的拉流端，然后再发送后续的音视频数据，但是这里还需要注意以下几点：

一、GOP缓存首屏优化

直播领域有两大指标：首屏和流畅性。假设用户推流侧GOP为4秒，那么在某些情况下，新进入的拉流侧需要4s后才能看到直播画面(即需要等待将近4秒钟收到第一个I帧，首屏才能渲染播放)，这样的体验，对直播来说是不可接受的。

常用的解决方案，一般是在服务端缓存1到2个GOP，当client和server连接成功后，先发送GOP缓存里的数据，再发送当前的媒体数据。client收到数据后，根据一定的策略进行音视频同步，然后再加速追帧。

当然在具体的实践过程中，还要注意一些事项：GOP缓存大小、client的jitter buffer大小的配合、GOP缓存里音视频的对齐(即音视频同步问题)、不同推流端GOP大小不同的适配等。

pacer 平滑发送

假设推流端的GOP设置的比较大，当拉流侧媒体建立连接成功后，服务端可能会一股脑的将缓存的所有数据发送给拉流端，这样会引起一个严重的后果，导致拉流客户端的缓冲区溢出或者其他问题。这时候就需要server端的pacer平滑发送发挥作用了。

但是在实际实践过程中，要特别注意pacer追帧速率和客户端追帧速率的配合，不然可能起不到作用，还会适得其反。

二、拉流侧选择服务质量好的服务器就近接入

这个不同大厂都有相应专门的调度团队来做相应的事情，下面只来谈下一种基于RTP统计网络延迟的一种做法。

发送RTP每个服务器都在RTP包上加上扩展头，扩展头里面的内容为NTP时间戳，这样就可以知道每跳花费的时间。可能有同学会质疑：每台服务器的基准时间不一样，这种统计方法就不准确了。这就需要做下服务器间的时间同步问题，在传输大网设置一个全局的NTP校时服务，虽然NTP时间没有绝对对齐，但是把误差搞定在1ms内就可以了。