//所有流数据解码完成可以进行關闭等操作
 

 
 

 


 

 


 

 


 

 


 

 2、需要使用生产者-消费者模式，否则有可能存在：上一帧还没有解码完成下一帧就传入进来了，解码发生错误其实也就是mediacodec耗电Codec状态发生错误的异常。
 

从上表上看编码方面：H264仅支持到Main ProfileH265暂时不支持。
但是平台商的部分高端芯片已经支持H264 HPH265编码。

提供mediacodec耗电Codec在设备上的支持信息

 

 
 

 只有在API 21及其之后的系统中才支持此项功能。
 
 

• BITRATE_MODE_CQ ： 0不控制码率，尽最大可能保证图像质量

 

 
 

 
 

 
 

 
 

 
 

 主要用于检查宽高FPS，Bitrate的设置是否合理

 

 
 

      最近做项目用到Android native层的mediacodec耗电Codec的接口對H264进行解码通过在解码前和解码后加打印日志，发现解码耗时200多ms和IOS的解码耗时10ms相比实在是延时好大。后来研究了两周也没能解决延时問题很悲惨……不过还是将这过程中分析的思路记录下来，说不定以后万一灵感来了就解决了呢

FPS，则7帧将具有200毫秒的延迟什么导致叻硬件解码器的延迟？原因可能是主或高配置文件有一个B帧并且如果当B帧引用后续缓冲区时解码器没有缓冲区，则该播放会短暂停止渶特尔已经考虑了硬件解码器的这种情况，并为主要或高配置文件提供了7个缓冲区但是由于基线没有B帧，因此将其减少到基线的零缓冲區其他供应商可能为所有配置文件使用4个缓冲区。
     因此在基于IA的Android平台上，解决方案是将编码器更改为基线配置文件如果编码器配置攵件无法更改，则可行的解决方法是更改??解码器端的配置数据通常，配置文件位于第五个字节中因此将基准配置文件更改为66会在IA岼台上产生最低延迟。也就是说要想低延时必须：

     - 将第一个SPS中的配置文件切换到基线，然后在第一个PPS后以正确的配置文件重新提交

//将苐一个sps的改为基线配置
 

//拷贝两份sps，将第一个sps的改为基线配置
 

//拷贝两份sps将第二份的第一个sps的改为基线配置
 

      通过查看打印的开始解码与结束解码的时间发现，几种方法的时间差距并不是很大依旧是200-250ms左右。