前面我们讲到，如果要让短视频源码做到”秒播“的话，可以从域名解析、socket buffer、Probe buffer入手，对短视频源码进行优化，那么我们今天来把剩余的几个方面介绍完。
一、Probe list
耗时原因：
和Probe buffer一样，同样是探测的流程，一开始，短视频源码的播放端并不知道要播放的视频是什么格式，需要根据自己支持的格式通过探测得出一个分数，然后依据这个分数给出相应的格式，类似于android的sniff，所以如果ffmpeg设置的支持的格式越多，这个探测list就越长，探测时间也就越长。对于短视频源码来说，CP的内容格式基本是确定的：MP4+H264+AAC。所以对于很多格式的探测是不必要的。
解决方案：
对于没有用的格式可以在ffmpeg build config里移除，只保留需要的格式，比如mp4，最大限度的减小probe list。具体的话就是修改程序中的相关函数。
二、Player buffer
耗时原因：
对于非直播类的播放器，一般都会在player内设计一个缓冲buffer，这是为了播放流畅性和音视频同步的需要，尤其是在网络不稳定或较差的情况下，这个缓冲buffer显得尤为重要。但是这个缓冲buffer有按照帧数设置的，也有设置为1-2秒的，也有设置为3-5秒的。若整个播放过程是几十分钟，甚至是几个小时的体验，在开始播放时缓冲个几秒是可以接受的，但是对于短视频来说，这样的体验并不好。
解决方案：
策略性优化，保证视频第一时间输出，把缓冲机制移到首屏播放之后，当然也要照顾到音频，同时保证音视频的同步，有些取舍要做。例如Android的nuplayer框架设计上受限于这些因素，起播速度远远达不到这些，后来nuplayer升级为exoplayer之后，效果依然不行，需要找厂家做二次开发才可以。
三、分辨率+图像质量+I帧位置
耗时原因+解决方案：
分辨率这个不难理解，如果视频文件的分辨率很高，那1帧的数据会很大，相应的传输时间就会变长。所以选择合适的分辨率录制或转码，也是为播放端的负载考虑，移动端720P左右足够，对于个人秀、内容聚合类的短视频分辨率可以更低。
图像质量并非越高越好，短视频源码开发者需要找到一个平衡点，对于不是不同场景快速切换的720视频，3M和5M码率的区别不大。对于短视频来说，要在画面质量和传输上找到一个平衡。
I帧位置，指的是视频I帧在文件开头的位置，播放器为了防止花屏之类的问题出现，一般在开始播放或seek时都会找到第一个I帧进行解码，一般视频文件一秒有25-30帧，很明显I帧放在第一帧和放在最后一帧对秒播是有影响的。所以根据实际情况，在产品服务链中选择合适的分辨率和图像质量。把I帧放在文件开头第1帧的位置。
以上就是让短视频源码做到秒播的几种常见手段，如果有其他方案，或许会在接下来的文章里继续做补充。
本文为转载文章，来源网络
