Android WebRTC实例化OMX.qcom.video.decoder.vp8解码器崩溃如何解决

问题根因 #

从崩溃日志可直接定位问题根源：

• 设备硬件VP8解码器OMX.qcom.video.decoder.vp8资源耗尽，返回InsufficientResources(0x80001000)错误，无法初始化新的解码实例
• WebRTC JNI层未捕获Java层抛出的MediaCodec$CodecException异常，直接触发!env->ExceptionCheck()断言导致崩溃
  这类问题集中出现在国产ROM、三星部分机型上，是因为这类系统对硬件Codec资源的管控更严格，长时间通话过程中如果出现分辨率、码率切换，WebRTC反复重建硬件编解码实例时容易出现资源泄漏，累积到一定程度就无法申请新的资源。

修复方案 #

方案1：优先使用软件编解码（快速验证修复） #

如果对通话画质、性能要求不是极高，可以直接禁用硬件编解码，完全规避硬件Codec资源相关的问题，修改初始化代码如下：

peerConnectionFactory = PeerConnectionFactory.builder()
        .setOptions(options)
        // 第二个参数设为false表示禁用硬件编码器
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(MeetingClient.mRootEglBase.getEglBaseContext(), false, true))
        // 直接使用软件解码器工厂，不调用硬解逻辑
        .setVideoDecoderFactory(new SoftwareVideoDecoderFactory())
        .createPeerConnectionFactory();

替换后先验证崩溃是否消失，如果确认消失则说明问题确实出在硬件编解码适配层面。

方案2：机型灰度适配硬件编解码 #

如果需要保留硬解的性能优势，可以增加机型判断逻辑：

• 建立问题机型/ROM黑名单，比如小米、华为、OPPO、vivo、三星的已知问题机型，匹配到则走软解逻辑
• 其他机型保留默认硬解逻辑，兼顾性能和稳定性

方案3：自定义硬解异常捕获逻辑 #

继承WebRTC的HardwareVideoDecoder、HardwareVideoEncoder类，在初始化编解码的方法外层增加try-catch，捕获MediaCodec相关异常，初始化失败时自动降级到软解，不要让异常抛到JNI层触发断言崩溃。

方案4：优化编解码参数降低资源消耗 #

• 固定通话的分辨率、码率范围，避免网络波动时WebRTC频繁调整分辨率导致编解码实例反复重建
• 强制指定使用H264编码替代VP8，绝大多数安卓机型对H264硬件编解码的适配更成熟，资源泄漏概率更低
• 通话结束后主动销毁PeerConnection实例，释放所有编解码相关资源，避免资源残留

内容的提问来源于stack exchange，提问作者famfamfam