利用ffmpeg打造播放器直播观看公网rtmp1s延时极致优化

本博客转载于：https://my.oschina.net/klttl/blog/734873

摘要: 此文章主旨为了说明在无须修改ffmpeg任何源码，以及修改编码参数设置以及服务器、CDN配置，优化播放器即可达到1s延时效果

关于rtmp直播流打开慢和延时大的问题，很多人共识播放器在公网都在2-3s的延时是正常的，前天一款播放器拉流rtmp，延时在1s，

果断去分析这个软件，发现他就是用了ffmpeg，然后和那款播放器提供者，聊了下，想套点大概的思路，基本上没套出啥，没办法只能自己动手
然后根据以往的经验和群里几位大神的建议下，说干就干，花了一天的时间，终于从延时3s优化到了1s的延时，不敢独享，拿出来供大家参考。

以下的优化点以重到轻方式描述出来：

1、rtmp直播流打开慢
avformat_find_stream_info（）：
这个函数会花去主要的时间，因为要做流的分析拆分等，所以优化可以重点从这个函数入手。一种是设置probesize，这个设置为FLAG_NOBUFFER数据包不入缓冲区，用于分析不显示，并且还可以设置max_anlyze_duration2默认值，这块可以参考ijkplayer这块的设置挺好；

另一种方法比较极端些：
自己实现这个函数的功能，以替代avformat_find_stream_info接口，前提就是要知道你的流的相关信息，经过测试这样设置之后，仅耗时9ms左右，效果很明显，具体做法就是
根据metadata信息，手动设置解码参数，针对264+aac的rtmp可以考虑这种优化方案，这个效果比较明显具体可以根据个人项目需求来取舍。

2、第二个关于播放延时的问题：

比如ffplay默认的帧率控制没有追帧的策略，其实说白了就是同步算法不够好，在播放网络流的时候，那么如果网络如果发生抖动，延时会累加。
这个就是群里一个哥们说这个1s延时效果能够出现多久的原因，经过半个小时测试依然坚挺着。
优化策略就是调整帧率控制部分。具体做法就是解码线程运行的时候获取机器本地时间，第一帧计算机器时间与流pts的时间差（本地时间和流时间同步），

流的时间落后本地时间多的情况下，快放或者考虑丢包原则就是要在流畅度和实时性之间得到一个平衡。

3、第三个优化的地方，需要优化缓存区，说白了就是一般的播放器都有自己的一个缓冲区，那么这个缓冲区存储数据到获取第一帧数据不能超过200ms，

这个就是你要优化你的缓冲区，每个播放器的缓冲区实现方式不一样，所以这个也不好具体表述，我这边就是用的deque做的缓存区，做的也比较简单。

4、第四个优化的地方，就是视频渲染这块，渲染这块优化，每个人写的不一样，同样使用opengl显示，
每个人写的效率不一样，这个就看个人功力了，不熟悉可以看看qtav这块的代码，还是不错的；

5、第五个优化的地方，这个其实就是这个歌播放器的框架，以及数据直接的拷贝传递的效率等各种控制
都会影响最终的结果，这个也是说看个人的能力吧。

口说无凭，最后上图证明一切，跑了半个小时，还是很稳定（播放器观看手机推流）：