短视频秒开优化

从流程分析优化

视频播放流程.png

如图所示，移动设备的播放器通过某个视频url的域名，通过DNS服务请求到IP地址，通过IP地址与视频服务器建立TCP连接，然后再连接之上建立Http协议，最终请求到数据，给到播放器进行解析音视频解码显示。
为了更好的发现可优化的地方，流程拆解如下：

视频播放流程拆解.png

图中灰色部分是不能优化的，在流程上没有优化控件，而且，这部分容易受到网络情况的影响，所以后续优化，是基于大多数正常网络情况的。图中绿色部分是可以优化并且在显示项目实现中可以实施的。

Domain name：域名解析
- 耗时原因：
  DNS请求包会先发到本地DNS服务器，如果查不到，会递归到根域名服务器，这个过程是比较耗时的。当然，如果请求过了，或者其间其他人请求过相同的域名，那域名服务器就会有缓存，再次请求的时候就会很快了；但是一般缓存周期很短，需要有人不停的请求才能保持更新，所以具有很大的不确定性。
- 解决方案：
  1. 注意请求使用的IP协议版本，做播放的肯定绕不过ffmpeg，在ffmpeg中为了兼容性，DNS请求的IP协议版本设置为AF_UNSPEC，这样在请求的时候会先请求IPV6的地址，如果没有再请求IPV4的地址，是很保险，但是在实际的项目中，没有IPv6的地址，造成一直递归到根域名服务器也查不到IPV6地址，极大的浪费了时间，可以使用AF_INET指定请求IPV4地址，节省一半以上的时间。
```
hints.ai_family = AF_INET;
getaddrinfo(hostname, portstr, &hints, &ai)
```
  1. 预置或与解析域名IP地址，100毫秒对于秒内播放来说还是很大的一笔时间。但是，该方式有局限性，可能适合特定音视频直播，对于短视频地址播放地址比较多样来说操作起来有一定难度，而且存在CP切流()和更换CP()的情况。
    CP切流与更换CP的区别
    补充：
  1. 客户端缓存
  2. ISP服务器DNS缓存
  3. 根域名服务器
  4. 顶级域名服务器
```
修改ffmpeg中tcp.c文件中代码
if (my_getaddreinfo) {
   ret = my_getaddreinfo(hostname, portstr, &hints, &ai)
} else {
   ret = getaddrinfo(hostname, portstr, &hints, &ai)
}

在my_getaddreinfo方法中，可以调用DNS SDK的解析方法，获取到ip，然后填充到ai里面。
```
Socket cache：socket buffer
- 耗时原因
  TCP connection在客户端的具体操作中基本都是通过socket实现的，在socket中有一个缓冲区的概念，发送端与接收到对数据收发都需经过缓存区。作为移动端来说，接收缓冲区设置太小影响效率，接收缓冲区设置太大会短时间内吃掉带宽，从而引起网络传输问题和流量的浪费，这些都会影响首屏数据的及时送达。
- 解决方案
  根据实际情况调整接收端缓冲区大小。可以在ffmpeg的network和tcp里进行调整，为了通用性可以罗占http/tcp的options并通过ffmpeg提供的AVDictionary机制在avformat api这一层进行透传先关设置参数。
```
  av_dict_set(&avdictionary, "param", "value of param")
  setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &len， sizeof(len))
```
Probe buffer：探测buffer
- 耗时原因
  在播放端，一开始并不知道要播放的视频相关信息，比如封装格式、分辨率、音视频编码等信息。需要先读一段数据进来，再对这段数据进行探测，得出相应信息，而存放这段探测数据需要一个buffer。这个buffer设置的大小可能会导致分析不出信息导致重新探测，设置的太大就会增加收流的时间从而影响了首屏的播放，太小太大都会引入延迟。
- 解决方案
  根据实际情况调整这个buffer，通过ffmpeg的AVFormatContext结构体的probesize和max_analy_duration把对buffer的限制透传下去。可以通过观察avformat_find_stream_info这个函数来评价探测耗时。
```
   AVFormatContext -> probesize = n
   AVFormatContext ->max_analyze_duration = m * AV_TIME_BASE
```
在ffmpeg中的utils.c文件中的函数实现中有一行代码是int fps_analyze_framecount = 20，这行代码是默认获取20帧视频数据开播，时间耗时将近1s，可以优化
```
av_dict_set_int(&ffp -> format_opts, "fpsprobesize", 0, 0)
```
Probe list
- 耗时原因
  同样是探测的流程，一开始播放端并不知道这段数据是什么格式，需要根据自己支持的格式通过谈的得出一个分数，然后依据这个分数给出相应的格式。所以如果ffmpeg设置的支持格式越多这个探测list就越长，相应的探测时间也越长。而对于短视频来说，CP的内容格式基本是确定的，基本都是Mp4 + H264/H265 + AAC，所以很多格式的探测是不必要的。
- 解决方案
  对于没有用的格式在ffmpeg build config里移除，只需保留需要的格式，比如Mp4，最大限度的减少probe list。可以通过观察avformat_find_stram_info这个函数来评价探测耗时。
```
disable avi
disable asf
disable mkv
...
```
Player buffer
- 耗时原因
  对于非直播类的播放器，一般都会在player内设置一个缓冲buffer，这是为了播放流畅性和音视频同步的需要，尤其是在网络不稳定或较差的情况下，这个缓冲buffer显得尤为重要。一般这个缓冲buffer有按照帧数设置的，因为一般的播放比如在线电影、电视剧考虑的是整个长时间播放过程的体验，在开始缓冲几秒是可以接受的，但是在短视频的场景下这是不可接受的。
- 解决方案
  策略性优化，保证视频第一时间输出，把缓冲机制一道首屏播放之后，当然这里要照顾到音频，保证音频的同步，有些取舍。Normandie
MP4 Size：分辨率/图像质量/I帧位置
- 耗时原因
  分辨率/图像质量过大，会导致相应的传输时间越长。播放器一般开播或seek时都会找到第一个I帧进行解码，很明显I帧放在第一帧是最好的。
- 解决方案
  分辨率/图像质量折中，把I帧放在文件开头第一帧的位置。
MP4 MOOV box position & Http re-connection
- 耗时原因
  如果在起播过程发生了http re-connection耗时肯定会增加，而且http connection的耗时基本是不可优化的，所以要避免http re-connection的发生。但是mp4作为主流的短视频封装格式，它的MOOV box在文件中的位置直接影响了是否会发生http re-connection，直接点说就是MOOV box放在文件的后面也就是MDAT box后，会产生http re-connection，引入延时。
- 解决方案
  1. 在上传mp4文件的时候吧MOOV box放到了前面
  2. 在mp4文件上传到服务器之后，重新封装，吧MOOV box放到了前面。
Server/CDN
- 耗时原因
  CDN节点部署，路由策略，缓存还是拉流，都会对延时产生影响
- 解决方案
  server进行相关优化
Http connection
- 耗时原因
  协议耗时，比如TCP的握手机制，在网络较差时耗时会较长
- 解决方案
  CDN骨干网络的部署可以改善这种情况
TCP connection
- 耗时原因
  TCP连接在这里是只调用Socket的connect方法，并连接成功的耗时，它是一个阻塞方法，会一直等待TCP的三次握手完成。他直接反应了客户端到CDN服务器节点，点对点的延时情况
- 解决方案
  给用户下发更合适的CDN服务器域名，通过HTTPDNS SDK来优化DNS解析的结果。

从业务分析优化

进入视频播放页面后，加载其他网络数据会占用网络带宽，影响到视频加载。
移动端手机网络带宽限制，带宽大小对视频观看体验影响会很大
播放器拉流的速度，以及缓冲策略的动态控制，能尽快渲染出视频，减少等待时间。
CDN影响

IjkMediaPlayer.OPT_CATEGORY_CODEC, "start-on-prepared", 0)
// 设置缓冲区大小
IjkMediaPlayer.OPT_CATEGORY_FORMAT, "max-buffer-size", 10 * 1024 * 1024)
// 设置探测缓冲区大小
IjkMediaPlayer.OPT_CATEGORY_FORMAT, "probesize", 1024 * 8)
// 每处理一个packet之后刷新io上下文
IjkMediaPlayer.OPT_CATEGORY_FORMAT, "flush_packets", 1)
// 设置探测处理时长
IjkMediaPlayer.OPT_CATEGORY_FORMAT, "analyzeduration", 1000)
// 重连
IjkMediaPlayer.OPT_CATEGORY_FORMAT, "reconnect", 1)
// 设置是否开启环路过滤
//      0 开启，画面质量高，解码开销大
//      48 关闭， 画面质量差，解码开销小
IjkMediaPlayer.OPT_CATEGORY_CODEC, "skip_loop_filter", 0)
IjkMediaPlayer.OPT_CATEGORY_CODEC, "skip_frame", 0)

// 跳帧 保证音视频同步
IjkMediaPlayer.OPT_CATEGORY_PLAYER, "framedrop", 5)
IjkMediaPlayer.OPT_CATEGORY_PLAYER, "min-frames", 2)

IjkMediaPlayer.OPT_CATEGORY_PLAYER, "max_cached_duration", 0)
// 设置无限读
IjkMediaPlayer.OPT_CATEGORY_PLAYER, "infbuf", 0)
// 是否开启播放器缓冲 默认开启
IjkMediaPlayer.OPT_CATEGORY_PLAYER, "packet-buffering", 1)
IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec_all_videos", 1)

短视频秒开优化

从流程分析优化

Domain name：域名解析

Socket cache：socket buffer

Probe buffer：探测buffer

Probe list

Player buffer

MP4 Size：分辨率/图像质量/I帧位置

MP4 MOOV box position & Http re-connection

Server/CDN

Http connection

TCP connection

从业务分析优化