Android媒体编解码器非常依赖设备供应商。三星是令人难以置信的问题,运行相同的代码的其他设备将运行良好。这是我过去6个月的生活。
虽然它可能会感觉不对,但最好的方法是尝试+ catch +重试。有4个不同的地方,MediaCodec会抛出异常:
- 配置 - NativeDecoder.Configure(...);
- 开始 - NativeDecoder.Start();
- 渲染输出 - NativeDecoder.ReleaseOutputBuffer(...);
- Input - codec.QueueInputBuffer(...);
注:我的代码是在Xamarin中,但调用映射非常接近原始的Java。
配置格式描述的方式也很重要。该mediacodec会崩溃Nexus设备上,如果你不指定:
formatDescription.SetInteger(MediaFormat.KeyMaxInputSize, currentPalette.Width * currentPalette.Height);
当你发现任何异常,你将需要确保mediacodec复位。不幸的是重新获得心不是以旧的API的水平,但你可以模拟具有同样的效果:一旦你捕获的错误时,你通过新的输入,您可以检查
#region Close + Release Native Decoder
void StopAndReleaseNativeDecoder() {
FlushNativeDecoder();
StopNativeDecoder();
ReleaseNativeDecoder();
}
void FlushNativeDecoder() {
if (NativeDecoder != null) {
try {
NativeDecoder.Flush();
} catch {
// ignore
}
}
}
void StopNativeDecoder() {
if (NativeDecoder != null) {
try {
NativeDecoder.Stop();
} catch {
// ignore
}
}
}
void ReleaseNativeDecoder() {
while (NativeDecoder != null) {
try {
NativeDecoder.Release();
} catch {
// ignore
} finally {
NativeDecoder = null;
}
}
}
#endregion
:
if (!DroidDecoder.IsRunning && streamView != null && streamView.VideoLayer.IsAvailable) {
DroidDecoder.StartDecoder(streamView.VideoLayer.SurfaceTexture);
}
DroidDecoder.DecodeH264FrameBuffer(payload, payloadSize, frameDuration, presentationTime, isKeyFrame);
渲染到纹理 - 目前看来似乎是最稳定的选择。但设备碎片真的伤害了这个领域的android。我们发现便宜的设备如Tesco Hudl对视频来说是最稳定的。即使在屏幕上也有多达21个并发视频。根据分辨率/ fps,Samsung S4可以达到4-6左右,但像HTC这样的产品可以和Hudl一样工作。它是一个唤醒电话,让我意识到三星设备是从字面上抄袭苹果设计,并与android-sdk混合在一起,实际上打破了许多功能。
这不能解决问题。 –
是否有任何可以从错误代码-34推断出来的东西? –
不幸的是,我不能找到。您可能需要查看MediaCodec的源代码,以查找该代码中抛出的-34。 – Devsil