C++编程-2：使用Android MediaCodec 硬解码延时问题分析

最新推荐文章于 2025-04-21 17:05:11 发布

原创

最新推荐文章于 2025-04-21 17:05:11 发布 · 9.2k 阅读

CC 4.0 BY-SA版权

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

起初在https://software.intel.com/en-us/forums/android-applications-on-intel-architecture/topic/536355和https://software.intel.com/en-us/android/articles/android-hardware-codec-mediacodec这两个网址中找到问题原因和一种解决方法。

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

- 不要设置MediaFormat.KEY_MAX_WIDTH和MediaFormat.KEY_MAX_HEIGHT。

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

先附上解码部分代码：

int OpenMetaCUDAVideoDecoderContext::OnVideoH264(uint8_t * frame, uint32_t frameSize){

    DP_MSG("onVideoData=%6d, %.2X %.2X %.2X %.2X %.2X %.2X %.2X %.2X\n",
           frameSize,
           frame[0],frame[1],frame[2],frame[3],frame[4],frame[5],frame[6],frame[7]
    );

    int  pos = 0;
    if( (frame[4] & 0X1F ) == 0X09 ){
        // this is an iframe
        frame     += 6;
        frameSize -= 6;
    }

    if( (frame[4] & 0X1F ) == 0X07 ){
        // this is an iframe
        iFrameFound = true;
    }
    else if(!iFrameFound){
        // iframe not found, do nothing
        return -1;
    }

    DP_MSG("video264::::%d",frameSize)

    uint8_t *data = NULL;
    uint8_t *pps = NULL;
    uint8_t *sps = NULL;

    // I know what my H.264 data source's NALUs look like so I know start code index is always 0.
    // if you don't know where it start