直播技术总结（五）如何快速起播直播流

请尊重分享成果，转载请注明出处，本文来自逆流的鱼yuiop，原文链接：
http://blog.csdn.net/hejjunlin/article/details/72860470

经常会看到，很多公司都在带宽和卡顿中抉择，想把H.265编码格式做为视频编码格式普及开来，用于客户端播放，无论在TV上，还是手机上，由于很多设备不支持这种编码格式，所以往往要做适配。有人问，为什么大家都在说切H.265？

H.265是ITU-T VCEG 继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括：提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P（分辨率1280*720）普通高清音视频传送。

回到商业目的本质上来，就是省带宽。在有限带宽下传输更高质量的网络视频。这就是相比于H.264最突出的。当然还有有些在算法优化上，更高效。最终都是省带宽。打个比方理解，原来10M带宽，可以传输1T的网络视频，现在用H.265编码格式，可以传输2T的同等清晰度的网络视频。要用H.265来做编码格式，其代价就是设备计算能力：H.265编码的视频需要更多的计算能力来解码。所以，经常看到手机发烫，电视盒子发烧，手机更加耗电。因为会把CPU一下飙起来。前面都是闲话，今天总结下如何快速起播直播流。直播行业流传一句话，现在的直播应用，没有混到秒开，都不意思，说自己搞直播的。这句话不是没有道理的。

对于直播来讲，它是一个流，它不像点播，大家都从0秒开始，任何一个视频文件，0秒第一个帧肯定都是关键帧。那么对于直播来讲，是一个随机的时间点接到这个视频流进行播放，那么我接入的这个时间点的帧有可能拿到的第一个帧的数据是I帧，也有可能是B帧，也有可能是P帧。这是一个随机的。在这种情况下，我们大概率会出现一个黑屏的状态。因为我拿到的是个P帧，对于P帧来讲，解码器面那个Buffer是空的，它不知道这个P帧如何进行解码，所以它只能丢弃这个帧。

先来看一个花屏，解释参考帧丢失，I帧是关键帧，一个完整画面，可以独立解码，P帧，是前向预测编码帧，可以理解为运动补偿帧，根据关键帧+运动补偿预测下一个关键帧。B帧，是双向预测编码帧，也是用来预测修补下一个I帧，所以B帧，P帧统称为参考帧。如 I P P B I 如下

视频流是1080*1920分辨率的。用1080*720的，没有任何问题。猜测如下原因：

• 同一种视频封装格式，分辨率越小，花屏现象越少。
• 分辨率越小，服务端发送给客户端的数据越小，其花屏现象越少，说明花屏现象与服务端发送的数据量有关。
• 可能的原因是服务端发送的数据量较大时，客户端缓冲区不足，导致数据丢失的问题，从而引起花屏现象。

对于直播来讲，我一秒钟的帧数是固定的，只能等到我下一个关键帧到来的时候，我才能开始去播放。当然正好赶巧了的话，接入那瞬间得到的数据正好是个I帧。就可以达到秒开的效果。

服务端优化，CDN 预缓存 GOP，以高倍速推送，缩短I帧等待时间：

• 在直播服务器中，支持设置一个cache，用于存放GOP(就是I/P/B组起来的)，客户端播放。
  直播服务器缓存了当前的GOP序列，当播放端请求数据的时候，CDN会从I帧返回给客户端，从而保证客户端可以快速获取I 帧进行显示；当然，由于缓存的是之前的视频信息，当音频数据到达播放端后，为了音视频同步，播放器会进行视频的快进处理（也就是赶上，据说百度视频云，在~“赶上”~这块，还专门写了专利），但这种影响很小；相比于能够达到“秒开”的效果，这个代价是值得的；

播放端优化：

• DNS解析加快，通常，DNS解析，意味着要把一个域名为xxx.com解析成ip过程，平时请求网页，网络差，就会打开网页半天。

• 修改播放器逻辑，基于FFmpeg二次开发，FFmpeg起播视频，都是拿到视频完整信息，才起播。能不不能只拿到部分信息，就起播。就要修改代码了。通常FFmpeg起播时，finder_decoder, avformat_find_stream_info较耗时，前者去找解码器，相对后者，又不那么耗时，凡事都有相对。在avformat.h声明。在libavformat\utils.c中实现如下：

  finder_decoder：
  

  
  
  
  avformat_find_stream_info：
  
  
  
  这里优化后者，主要修改两个参数，一个是 probesize，一个是 analyzeduration，分别用来控制其读取的数据量大小和时长。减少 probesize 和 analyzeduration 可以降低avformat_find_stream_info 的函数耗时，达到起播快。

如果是基于ijkplayer二次开发的，不用修改c层，直接在ijkVideoView.java中，也可以作相应修改。

注意：修改任何参数，都是有代价的，要视具体情况。这个值修改，大小，可能播不起来，这种情况就坑了，如果是先有画面，在有声音，音画不同步。

还有一些方法如，播放端识别首个关键帧即启动播放，或者通过减小GOP间隔来提高加载速度；也是可以达到的。

优化是一个渐进的过程，从表面显而易见的开始，逐步拆解流程，找到可能的优化点，对这些点逐个分析，找到性能瓶颈，然后想办法解决。当然优化有时也需要权衡代价和效果，重点先解决性价比比较高的优化点。

第一时间获得博客更新提醒，以及更多android干货，源码分析，欢迎关注我的微信公众号，扫一扫下方二维码或者长按识别二维码，即可关注。

如果你觉得好，随手点赞，也是对笔者的肯定，也可以分享此公众号给你更多的人，原创不易