和直播一样，短视频系统想要做到“秒播”，不仅仅是要在短视频源码上做优化，还要在服务器上做优化。移动设备的视频播放器是通过某个视频url域名，通过DNS服务请求到IP地址，通过这个IP地址与视频服务器建立TCP链接，在连接之上建立http协议，最终请求到数据，通过播放器进行解析，用户看到画面听到声音，一个短视频系统的起播流程就结束了。
那么从短视频系统起播过程入手，可以对以下环节做优化：
一、域名解析
耗时原因：DNS请求包会先发到本地DNS服务器，如果查不到，会递归到根域名服务器，这个过程是比较耗时的。如果请求过了，或者期间有其他方请求过相同的域名，那域名服务器就会有缓存，再次请求的时候就很快了；但是一般缓存的周期很短，需要有人不停地请求才能保持更新，所以具有很大的不确定性。
解决方案：1、注意短视频系统请求使用的IP协议版本，不管是直播还是短视频，做播放的肯定都绕不过ffmpeg，在ffmpeg里为了兼容性，DNS请求的IP协议版本设置为AF_UNSPEC，这样在请求的时候会先请求IPv6的地址，如果没有再请求IPv4的地址，是很保险，但是在实际的项目中，没有IPv6的地址，造成一直递归到根域名服务器也查不到IPv6地址，极大的浪费了时间，可以使用AF_INET指定请求IPv4地址，节省一半以上的时间，首次请求或缓存过期后请求，耗时大概在大几十毫秒到100毫秒左右。
2、预置或预解析域名IP地址，对于实现秒内播放来说，100毫秒还是很大一笔时间，这个方案就是提前把域名解析出来，这个方案就是提前把域名解析出来，用的时候直接使用IP地址。但是这种方案有局限性，可能适合特定的音视频直播，对于短视频播放地址比较多样来说操作起来有一定难度，而且还存在CP切流和更换接入CP的情况。
二、Socket buffer
耗时原因：TCP connection在客户端的具体操作中基本都是通过socket实现的。在socket中有一个缓冲区的概念，发送端先把数据写到缓冲区，接收端数据也是先经过缓冲区，再从缓冲区读出，移动设备作为接收端，接收端缓冲区设置的太小，影响效率，接收端缓冲区设置的太大，会短时间内消耗带宽，如果带宽不够会引起短视频系统的网络传输问题，还会造成流量的浪费。这些都会影响首屏数据的及时送达。
解决方案：根据实际情况调整短视频系统接收端缓冲区大小，通过计算和测试数据得到一个比较合理的值。可以在ffmpeg的network和tcp里进行调整，这是比较低层的修改了，为了通用性可以扩展http/tcp的选项并通过ffmpeg提供的AVDictionary机制在avformat API这一层进行透传相关设置参数。
三、Probe buffer
耗时原因：播放端一开始并不能得到要播放的视频的相关信息，比如封装格式、分辨率，音视频编码等信息，需要先读一段数据进来，再对这段数据进行探测，从而得出相应的信息。而存放这段探测数据需要一个buffer，这个buffer若设置的太小可能导致分析不出信息导致重新探测，但是若设置的太大就会增加收流的时间从而影响了首屏的播放，所以太小太大都会引起延迟。
解决方案：根据实际情况调整这个buffer，通过计算和测试数据得到一个比较合理的值。可以通过ffmpeg的AVFormatContext结构体的probesize和max_analy_duration把对buffer的限制透传下去。
以上就是让短视频系统做到”秒播”的一些解决方案，由于篇幅的原因，剩余的几个方面我们留到下期再说。
