使用Android MediaCodec 硬解码延时问题分析

最新推荐文章于 2024-05-15 09:22:17 发布
最新推荐文章于 2024-05-15 09:22:17 发布
阅读量3.1k 收藏 4
点赞数 1
分类专栏： 音视频
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ssllkkyyaa/article/details/110119538
版权

使用Android MediaCodec 硬解码延时问题分析

使用Android MediaCodec 硬解码延时问题分析
2018年03月29日 09:30:38 珠雨妮儿 阅读数：2492
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zhuyunier/article/details/79730872
最近做项目用到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后以正确的配置文件重新提交。

  先附上解码部分代码：
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

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 starts, you can use a for loop similar to how i find the 2nd and 3rd start codes
int currentIndex = 0;
long blockLength = 0;

int nalu_type = (frame[currentIndex + 4] & 0x1F);
// if we havent already set up our format description with our SPS PPS parameters, we
// can't process any frames except type 7 that has our parameters
if (nalu_type != 7 && formatDesc == NULL)
{
    return -1;
}

if (nalu_type == 7)
{
    currentIndex = H264_findStartCode(frame,frameSize,currentIndex+4);
    size_t spsSize = currentIndex;

    // find what the second NALU type is
    nalu_type = (frame[currentIndex + 4] & 0x1F);

    DP_MSG("onVideoDataSPs=%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]
    );

    // type 8 is the PPS parameter NALU
    if(nalu_type == 8){
        int nextIndex = H264_findStartCode(frame,frameSize,currentIndex+4);
        size_t ppsSize = nextIndex - currentIndex;

        DP_MSG("onVideoDataPPs=%6d, %.2X %.2X %.2X %.2X %.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],
               frame[spsSize+1],frame[spsSize+2],frame[spsSize+3],frame[spsSize+4]
        );

        if(decompressionSession == NULL) {
            formatDesc = AMediaFormat_new();
            AMediaFormat_setString(formatDesc, "mime", "video/avc");
            AMediaFormat_setInt32(formatDesc, AMEDIAFORMAT_KEY_WIDTH, 1920); // 视频宽度
            AMediaFormat_setInt32(formatDesc, AMEDIAFORMAT_KEY_HEIGHT, 1088); // 视频高度

            sps = (uint8_t *)malloc(spsSize);
            pps = (uint8_t *)malloc(ppsSize);
            memcpy (sps, &frame[0], spsSize);
            memcpy (pps, &frame[spsSize], ppsSize);

            AMediaFormat_setBuffer(formatDesc, "csd-0", sps, spsSize); // sps
            AMediaFormat_setBuffer(formatDesc, "csd-1", pps, ppsSize); // pps

            DP_MSG("createDecompSession ========= ")
            this->createDecompSession();

            if(sps != NULL)
            {
                free(sps);
                sps = NULL;
            }
            if(pps != NULL)
            {
                free(pps);
                pps = NULL;
            }

        }

        // now lets handle the IDR frame that (should) come after the parameter sets
        // I say "should" because that's how I expect my H264 stream to work, YMMV
        currentIndex = nextIndex;
        nalu_type = (frame[currentIndex + 4] & 0x1F);

        while(currentIndex != -1 && nalu_type != 5 && nalu_type != 1){
            currentIndex = H264_findStartCode(frame,frameSize,currentIndex+4);
            nalu_type = (frame[currentIndex + 4] & 0x1F);
        }
    }
}

int32_t afout = 0;
   nalu_type = 5; // temp
// type 5 is an IDR frame NALU.  The SPS and PPS NALUs should always be followed by an IDR (or IFrame) NALU, as far as I know
if(nalu_type == 5)
{

    DP_MSG("jniPlayTs size=%d and %d \n",AMediaFormat_getInt32(formatDesc,AMEDIAFORMAT_KEY_COLOR_FORMAT,&afout),afout);
    //DP_MSG("theNativeWindow format %p and %d \n",theNativeWindow,ANativeWindow_getFormat(theNativeWindow));
    // find the offset, or where the SPS and PPS NALUs end and the IDR frame NALU begins
    int offset = currentIndex;//
    blockLength = frameSize - offset;

    data = &frame[offset];

    DP_MSG("nalu_type ===5 ")
    //DP_MSG("nalu_type ===5 %s /n ",AMediaFormat_toString(formatDesc))

    if(decompressionSession == nullptr)
    {
        DP_MSG("decompressionSession is null")
    }

    DP_MSG("OpenMetaCUDAVideoDecoder Start decoding: frameIdentifier=%lld",frameIdentifier);
    avx_info("OpenMetaCUDAVideoDecoder Start decoding: ","frameIdentifier=%lld",frameIdentifier);

    static int64_t  llPts = 0;

    ssize_t index = -1;
    index = AMediaCodec_dequeueInputBuffer(decompressionSession, 10000);
    if(index>=0)
    {
        size_t bufsize;
        auto buf = AMediaCodec_getInputBuffer(decompressionSession, index, &bufsize);
        if(buf!= nullptr )
        {
            DP_MSG("buf!= nullptr5======ww")
            memcpy(buf,data,blockLength);

            AMediaCodec_queueInputBuffer(decompressionSession, index, 0, blockLength, (uint64_t)frameIdentifier, 0);

            llPts += 3000;
        }

    }

    AMediaCodecBufferInfo info;
    auto status = AMediaCodec_dequeueOutputBuffer(decompressionSession, &info, 0);
    if (status >= 0) {
        if (info.flags & AMEDIACODEC_BUFFER_FLAG_END_OF_STREAM) {
            DP_MSG("output EOS");
        }

        size_t outsize = 0;
        u_int8_t * outData = AMediaCodec_getOutputBuffer(decompressionSession,status,&outsize);
        auto formatType = AMediaCodec_getOutputFormat(decompressionSession);
        DP_MSG("format formatType to: %s", AMediaFormat_toString(formatType));
        int colorFormat = 0;
        int width = 0;
        int height = 0;
        AMediaFormat_getInt32(formatType,"color-format",&colorFormat);
        AMediaFormat_getInt32(formatType,"width",&width);
        AMediaFormat_getInt32(formatType,"height",&height);
        DP_MSG("format color-format : %d width ：%d height :%d", colorFormat,width,height);

		AMediaFormat_delete(formatType);
        DP_MSG("OpenMetaCUDAVideoDecoder End   decoding: frameIdentifier=%lld,%d,%d,%p",info.presentationTimeUs,info.size,outsize,outData)
		if(this->kController){
            //OpenMetaPixelBuffer _kPixelBuffer(pixelBuffer,sizeof(pixelBuffer));
            OpenMetaPixelBuffer _kPixelBuffer(outData,sizeof(outData));
            _kPixelBuffer.kLine[0]  = outData;
            _kPixelBuffer.kLine[1]  = outData + width * height;
            _kPixelBuffer.kSizeX    = width;
            _kPixelBuffer.kSizeY    = height;
            _kPixelBuffer.kDataType = 1;
            _kPixelBuffer.kTimeStamp = info.presentationTimeUs;

            if(this!=NULL && this->kController!=NULL)
            {
                this->kController->OnVideoImage(&_kPixelBuffer);
            }

        }
        avx_info("OpenMetaCUDAVideoDecoder End   decoding:","%lld,%d,%d,%p",info.presentationTimeUs,info.size,outsize,outData);
        AMediaCodec_releaseOutputBuffer(decompressionSession, status, info.size != 0);

    } else if (status == AMEDIACODEC_INFO_OUTPUT_BUFFERS_CHANGED) {
        DP_MSG("output buffers changed");
    } else if (status == AMEDIACODEC_INFO_OUTPUT_FORMAT_CHANGED) {
        auto format = AMediaCodec_getOutputFormat(decompressionSession);
        DP_MSG("format changed to: %s", AMediaFormat_toString(format));
        AMediaFormat_delete(format);
    } else if (status == AMEDIACODEC_INFO_TRY_AGAIN_LATER) {
        DP_MSG("no output buffer right now");
    } else {
        DP_MSG("unexpected info code: %zd", status);
    }
  
}

return 0;
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206

}

  针对查到的解决办法，对以上代码进行了修改，分别是：
  • 1

//将第一个sps的改为基线配置
sps = (uint8_t *)malloc(spsSize);
sps[0+5] = 66;
memcpy (sps, &frame[0], spsSize);

pps = (uint8_t *)malloc(ppsSize);
memcpy (pps, &frame[spsSize], ppsSize);

AMediaFormat_setBuffer(formatDesc, “csd-0”, sps, spsSize); // sps
AMediaFormat_setBuffer(formatDesc, “csd-1”, pps, ppsSize); // pps

//拷贝两份sps，将第一个sps的改为基线配置
sps = (uint8_t *)malloc(spsSize * 2);
memcpy (sps, &frame[0], spsSize);
sps[0+5] = 66;
memcpy (sps + spsSize, &frame[0], spsSize);

pps = (uint8_t *)malloc(ppsSize);
memcpy (pps, &frame[spsSize], ppsSize);

AMediaFormat_setBuffer(formatDesc, “csd-0”, sps, spsSize * 2); // sps
AMediaFormat_setBuffer(formatDesc, “csd-1”, pps, ppsSize); // pps
//拷贝两份sps，将第二份的第一个sps的改为基线配置
sps = (uint8_t *)malloc(spsSize * 2);
memcpy (sps, &frame[0], spsSize);
memcpy (sps + spsSize, &frame[0], spsSize);
sps[spsSize+5] = 66;

pps = (uint8_t *)malloc(ppsSize);
memcpy (pps, &frame[spsSize], ppsSize);

AMediaFormat_setBuffer(formatDesc, “csd-0”, sps, spsSize * 2); // sps
AMediaFormat_setBuffer(formatDesc, “csd-1”, pps, ppsSize); // pps
通过查看打印的开始解码与结束解码的时间发现，几种方法的时间差距并不是很大，依旧是200-250ms

SoLucky2017
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Android MediaCodec 硬解码H264
11-21
Android MediaCodec 硬解码H264，包括h264文件，以及另一个硬解码例子。
Android 视频播放延时抖动那些事
六月初曲的博客
09-08 2370
Android 视频播放延时抖动那些事
一文搞懂 Android 音视频编解码器 MediaCodec
最新发布
weixin_46056189的博客
05-15 1815
一文搞懂 Android 音视频编解码器 MediaCodec，介绍了MediaCodec的流程和基本用法。
MediaCodec 低延时解码
juruiyuan111的专栏
08-04 1176
我们在使用Android的硬解进行解码时，如果是Android11以上则可以使用其特性低延迟，以下是Android 11支持的低时延特性：ANGLE支持：Android 11引入了ANGLE（Almost Native Graphics Layer Engine）支持，它是一个开源的跨平台图形引擎，可以将OpenGL ES和Vulkan API转换为DirectX API。使用ANGLE可以提高图形渲染的性能和稳定性。
音视频开发之旅（六）MediaCodec硬编解流程与实践
yabin的专栏
10-24 1311
目录 MediaCodec介绍 工作原理和基本流程 数据格式 生命周期 同步和异步模式 流控 实践：AAC解码为PCM同步和异步的两种实现 遇到的问题 参考 收获 一、介绍 Android底层多媒体模块采用的是OpenMax框架，实现方都要遵循OpenMax标准。Google默认提供了一系列的软编软解的实现，而硬编硬解则由芯片厂商完成，所以不同芯片的手机，硬编硬解的实现和性能是会有差异的。比如我手机的编解码
Android 硬解码MediaCodecDemo
12-12
本篇文章将深入探讨“Android硬解码MediaCodecDemo”，介绍如何利用MediaCodec进行硬解码操作，并处理在实际应用中可能遇到的crash、ANR（Application Not Responding）以及黑屏问题。 一、MediaCodec简介 ...
android MediaCodec 实现h264硬编解码全过程
05-27
MediaCodec 实现h264硬编解码全过程，视频数据从摄像头读出 yv12格式，转换为I420，投递给encoder,再从encoder取出编码后的h264数据投递给decoder后显示到surfaceView; 实现了udp将h264数据发送到指定主机，可通过...
Android硬解码H264,AAC文件 Demo
06-27
Android利用MediaCodec硬解码H264,AAC文件并播放Demo。相关博客：http://blog.csdn.net/a512337862/article/details/72629755和http://blog.csdn.net/a512337862/article/details/72629755
Android 用MediaCodec实现视频硬解码
12-28
通过分析和学习这个示例，开发者可以更好地理解和应用MediaCodec进行视频硬解码。 总结来说，MediaCodec是Android系统中用于高效视频处理的关键组件，尤其在硬解码场景下，它能显著提升性能。掌握其使用方法对于...
MediaCodec视频解码流程详解及参考demo
分享音视频技术
11-08 6495
本文主要讲解mediacodec的视频解码流程，及demo参考例子。
Android 音视频编解码(三) -- 视频编码和H264格式原理讲解
夏至的稻穗的博客
12-30 4949
视频编码标准其实有很多，而大名鼎鼎的就是 H264 了，可以说是最常用，最普遍的视频编码格式。其实除了H264,还有H265，H264和H265都是国际标准化组织（ISO）和国际电信联盟（ITU）开发的编码标准，而VP8、VP9 和 AV1是谷歌开发的编码标准，H264 和 H265 是需要专利费的，所以VP8、VP9 和 AV1（都是免费）也是谷歌为了对抗他们高昂专利费而开发出来的。上面讲到了视频编码的原理，这里我们通过H264来了解视频编码中的码流结构，以及H264 是如何解决4中冗余信息的。
十分钟完成安卓MediaCodec视频解码
热门推荐
不会前端的安卓不是好JAVA工程师
07-17 2万+
码字辛苦！转载请注明出处！ 0.前言 MediaCodec是安卓自带的视频编解码工具，由于使用的是硬解码，其效率相对FFMPEG高出来不少。 但由于部分厂商的解码器的设计，在某些手机上，H.264解码帧会缓存几帧再渲染，造成7帧左右的延迟现象。如果对解码实时性要求较高，可以通过减少IDR帧间隔来解决（三星的Exynos解码器除外）。 首先不得不说，MediaCodec的使用相对于其他解码工...
【音视频开发（一）】---MediaCodec NDK解码
sdewenking的专栏
02-20 2127
简单介绍使用NDK进行h264裸流解码的过程
浅谈Android中Surface显示延迟处理
u010029439的博客
06-26 3128
http://ragnraok.github.io/surface_display_lag.html 浅谈Android中Surface显示延迟处理 最近在使用GLES在Surface上渲染结果的时候，遇到了一个显示延迟的问题，当渲染时间过长，同时帧率要求比较高的时候，如果不加控制，就会造成显示的延迟，如果界面没有交互，倒是不会看出什么问题，如果是强交互的场景，这种情况下就会造成可感知的...
【转】使用Android MediaCodec 硬解码延时问题分析
开发资料记录室
01-15 4539
      最近做项目用到Android native层的MediaCodec的接口对H264进行解码，通过在解码前和解码后加打印日志，发现解码耗时200多ms，和IOS的解码耗时10ms相比实在是延时好大。后来研究了两周也没能解决延时问题，很悲惨……不过还是将这过程中分析的思路记录下来，说不定以后万一灵感来了就解决了呢。      起初在https://software.intel.com/e...
Android 音视频编解码(二) -- MediaCodec 解码(同步和异步)
irainsa的博客
04-07 985
在上一个的文章中，已经对 MediaCodec 有个感性的认知，这一章，来学习 MediaCodec 的解码功能。
android mediacodec 解码
12-29
Android Mediacodec 是 Android 平台上用于进行音频和视频解码的类库。它允许开发者可以直接访问底层的多媒体编解码器，并对音频和视频数据进行解码和编码操作，能够更加高效地操作多媒体数据。 使用 Mediacodec 进行解码时，首先需要创建一个 Mediacodec 对象，然后配置解码器的参数，例如指定要解码的音频或视频格式、创建输入和输出的数据流等。接下来，可以将需要解码的数据传入解码器的输入缓冲区中，解码器将会自动进行解码操作，并将解码后的数据输出到输出缓冲区中。最后，开发者可以从输出缓冲区中获取解码后的数据，进行后续的处理或者显示操作。 Mediacodec 的优势在于它可以直接利用硬件加速来进行解码操作，因此在解码大量多媒体数据时能够取得更好的性能表现。同时，它也提供了比较底层的接口，使得开发者可以更加灵活地控制解码的过程，以满足不同的需求。 总的来说，Android Mediacodec 是一个强大的多媒体解码库，可以帮助开发者在 Android 平台上更加高效地进行音频和视频解码操作。通过它，开发者可以获得更好的性能和更加灵活的控制能力，为多媒体应用程序的开发带来了很大的便利。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值