赞
踩
请尊重分享成果,转载请注明出处,本文来自逆流的鱼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帧等待时间:
播放端优化:
修改播放器逻辑,基于FFmpeg二次开发,FFmpeg起播视频,都是拿到视频完整信息,才起播。能不不能只拿到部分信息,就起播。就要修改代码了。通常FFmpeg起播时,finder_decoder, avformat_find_stream_info较耗时,前者去找解码器,相对后者,又不那么耗时,凡事都有相对。在avformat.h声明。在libavformat\utils.c中实现如下:
finder_decoder:
avformat_find_stream_info
的函数耗时,达到起播快。如果是基于ijkplayer二次开发的,不用修改c层,直接在ijkVideoView.java中,也可以作相应修改。
注意:修改任何参数,都是有代价的,要视具体情况。这个值修改,大小,可能播不起来,这种情况就坑了,如果是先有画面,在有声音,音画不同步。
还有一些方法如,播放端识别首个关键帧即启动播放,或者通过减小GOP间隔来提高加载速度;也是可以达到的。
优化是一个渐进的过程,从表面显而易见的开始,逐步拆解流程,找到可能的优化点,对这些点逐个分析,找到性能瓶颈,然后想办法解决。当然优化有时也需要权衡代价和效果,重点先解决性价比比较高的优化点。
第一时间获得博客更新提醒,以及更多android干货,源码分析,欢迎关注我的微信公众号,扫一扫下方二维码或者长按识别二维码,即可关注。
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。