前面我们讲到,如果要让短视频做到”秒播“的话,可以从域名解析、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帧的位置。
以上就是让短视频做到秒播的几种常见手段,如果有其他方案,或许会在接下来的文章里继续做补充。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。