关键帧
MediaCodec 有两种方式触发输出关键帧,一是由配置时设置的 KEY_FRAME_RATE和KEY_I_FRAME_INTERVAL参数自动触发,二是运行过程当中经过 setParameters 手动触发输出关键帧。android
自动触发输出关键帧
在MediaCodec硬编码中设置I(关键帧)时间间隔,在 api 中是这么设置的web
mediaFormat.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1); //关键帧间隔时间 单位s
自动触发实际是按照帧数触发的,例如设置帧率为 20 fps,关键帧间隔为 1s ,那就会每 20桢输出一个关键帧,一旦实际帧率低于配置帧率,那就会致使关键帧间隔时间变长。因为 MediaCodec 启动后就不能修改配置帧率/关键帧间隔了,因此若是但愿改变关键帧间隔帧数,就必须重启编码器。api
手动触发输出关键帧:缓存
if (System.currentTimeMillis() - timeStamp >= 1000) {//1000毫秒后,设置参数
timeStamp = System.currentTimeMillis();
if (Build.VERSION.SDK_INT >= 23) {
Bundle params = new Bundle();
params.putInt(MediaCodec.PARAMETER_KEY_REQUEST_SYNC_FRAME, 0);
mMediaCodec.setParameters(params);
}
}
关键帧踩坑
有时候你会发现自动触发关键帧方式失效了ide
经排查发现真正的缘由是在于视频的输入源,若是是经过Camera的PreviewCallback的方式来获取视频数据再喂给MediaCodec的方式是没法控制输出关键帧的数量的。
发现当选择支持颜色格式为yuv420p的编码器时,KEY_I_FRAME_INTERVAL 设置无效;
选择支持yuv420sp的编码器时,KEY_I_FRAME_INTERVAL 设置有效;svg
想要控制输出输出关键帧数量就必须经过调用MediaCodec.createInputSurface()方法获取输入Surface,再经过Opengl渲染后喂给MediaCodec才能真正控制关键帧的数量。ui
//判断输出数据是否为关键帧的方法:
boolean keyFrame = (bufferInfo.flags & MediaCodec.BUFFER_FLAG_KEY_FRAME) != 0;
部分机型MediaCodec.configure直接crash
未设置编码强制要求的一些配置 会抛出 IllegalStateException
看这个例子stackoverflow编码
若是初始化MediaFormat视频流的预设宽高高于当前手机支持的解码最大分辨率那么在调用MediaCodec.configure的时候就会crash。把MediaFormat.createVideoFormat时候的宽高设置小一点就ok了,那么就会有另一个问题,就是若是我设置1080*720的后,视频流来了一个1920*1080的会不会有影响?若是当前设备的最大分辨率高于这个值,就算预设值不同,也仍是能够正常解码并显示1920*1080的画面。那么若是低于这个值呢?两种状况 绿屏/MediaCodec.dequeueInputBuffer的值一直抛IllegalStateExceptionspa
如何获取当前手机支持的解码最大分辨率
每一个手机下都有这样一个文件,/system/etc/media_codecs.xml (your path)。这是一个xml文件,能够直接看到MediaCodecs–>Decoders节点下的各个视频格式的支持状况,以华为荣耀7x Android 8.0为例
获取解码视频的宽和高
//得到音视频的配置器MediaFormat
private static MediaFormat getFormat(String path,boolean isVideo) {
try {
MediaExtractor mediaExtractor = new MediaExtractor();
mediaExtractor.setDataSource(path);
int trackCount = mediaExtractor.getTrackCount();
for (int i = 0; i < trackCount; i++) {
MediaFormat trackFormat = mediaExtractor.getTrackFormat(i);
if (trackFormat.getString(MediaFormat.KEY_MIME).startsWith(isVideo ? "video/" :"audio/")) {
return mediaExtractor.getTrackFormat(i);
}
}
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
//单独获取宽高
MediaFormat newFormat = getFormat(path,true);
int videoWidth = newFormat.getInteger(MediaFormat.KEY_WIDTH);
int videoHeight = newFormat.getInteger(MediaFormat.KEY_HEIGHT);
//结合编码时获取宽高
MediaFormat newFormat = mMediaCodec.getOutputFormat();
int videoWidth = newFormat.getInteger(MediaFormat.KEY_WIDTH);
int videoHeight = newFormat.getInteger(MediaFormat.KEY_HEIGHT);
部分机型MediaCodec.dequeueOutputBuffer一直报IllegalStateException
部分机型会一直卡在MediaCodec.INFO_TRY_AGAIN_LATER中,有的缘由也是由于这个
该机型硬解码最大配置分辨率低于当前视频流的分辨率
部分机型输出的数据过短,或者为0
取出 output buffer 后,要手动设置 position 和 limit(api19如下必须设置),有些设备的编码器不会设置这两个值,致使没法正确取出数据;取出 input buffer 后,要手动调用 clear。参见 bigflake FAQ #11
mMediaCodec.createInputSurface()建立失败或者取出的数据不理想
虽然 mMediaCodec.createInputSurface() 从 API 18 就已经引入,但用在某些 API 18 的机型上会致使编码器输出数据量特别小,画面是黑屏,因此 Surface 输入模式从 API 19 启用。
mMediaCodec.createInputSurface() 必须在mediaformat.configure(..)以后,在mediacodec.start() 以前调用。
关于BufferInfo中的presentationTimeUs设置
若是不正确设置presentationTimeUs,有的设备的编码器会丢掉输入桢,或者输出图像质量不好,参见bigflake FAQ #8;
MediaCodec 使用的是微秒,大多数java 使用毫秒和纳秒,单位要处理好
若是采用surface输入,想要丢帧要如何操做
??(什么时候开始编码条件) 知足该条件后开始编码。这就作到可控了。
if (mBufferInfo.size != 0 && ??(什么时候开始编码条件)) {
outputBuffer.position(mBufferInfo.offset);
outputBuffer.limit(mBufferInfo.offset + mBufferInfo.size);
// mMuxer.writeSampleData(mTrackIndex, encodedData, bufferInfo);
} else {
outputBuffer.clear();
}
// 处理结束,释放输出缓存区资源
mMediaCodec.releaseOutputBuffer(outputBufferIndex,false);
输出数据和写入数据为MP4要在同一线程中,不然会出现偶发性的花屏,马赛克等
如下作法会出现花屏,马赛克
if (mBufferInfo.size != 0) {
outputBuffer.position(mBufferInfo.offset);
outputBuffer.limit(mBufferInfo.offset + mBufferInfo.size);
//这边线程就懒得写成阻塞等待数据做用了,懒。知道这个状况就OK了
new Thread(new Runnable() {
@Override
public void run() {
// mMuxer.writeSampleData(mTrackIndex, encodedData, bufferInfo);
}
}).start();
}
关于 bitrate_mode 配置问题
MediaCodec中的bitrate mode有个坑,好比我在设置以前想确认下CBR是否支持,那么会调用isBitrateModeSupported()判断,这样会有问题。
// MediaCodecInfo.java
public boolean isBitrateModeSupported(int mode) {
for (Feature feat: bitrates) {
if (mode == feat.mValue) {
return (mBitControl & (1 << mode)) != 0;
}
}
return false;
}
mode是否支持从bitrates判断
private static final Feature[] bitrates = new Feature[] {
new Feature("VBR", BITRATE_MODE_VBR, true),
new Feature("CBR", BITRATE_MODE_CBR, false),
new Feature("CQ", BITRATE_MODE_CQ, false)
};
framework竟然把它写死了!而不是从hardware或者xml中获取,而xml是写着支持的。
vendor/rockchip/common/vpu/etc/media_codecs.xml
若是你写代码比较严谨,先用isBitrateModeSupported()判断CBR是否支持,那么就悲剧了。
另外,在默认状况下,若是上层没有主动设置bitrate_mode的话,返回的是VBR。 也就是默认采用VBR 关于VBR CQ CBR区别,可查看Android原生编解码接口 MediaCodec 之——彻底解析中的流控。
关于 level、profile设置
因为视频编码后显示的数据质量偏低,因此须要调整质量。这个时候须要在这个设置level、profile
Profile是对视频压缩特性的描述(CABAC呀、颜色采样数等等)。
Level是对视频自己特性的描述(码率、分辨率、fps)。
简单来讲,Profile越高,就说明采用了越高级的压缩特性。
Level越高,视频的码率、分辨率、fps越高
// 不支持设置Profile和Level,而应该采用默认设置
mediaFormat.setInteger(MediaFormat.KEY_PROFILE, MediaCodecInfo.CodecProfileLevel.AVCProfileHigh);
mediaFormat.setInteger("level", MediaCodecInfo.CodecProfileLevel.AVCLevel41); // Level 4.1
关于设置这两个参数,我发现某些设备上,设置了无效,仍是默认值,经排查
是由于在android7.0如下,android 内部写死了参数,编码出来的只能是Baseline,除非系统改过这个BUG,否者设置无效,甚至会致使configure参数失败。