AMediaCodec_dequeueOutputBuffer速度较慢，在一个设备上返回-10000

Question

我目前正在为H264视频流编写解码器。目标平台是Android，所以我使用的是MediaCodec API（Android OS>=6.0)。

我在4个设备上测试了我的代码（4个设备上都是相同的）：

• 它在小米红米5 Plus上运行得很好（实际上速度相当快）。
• 在Nexus 7和三星Galaxy Tab A上运行速度非常慢
• 它在Samsung Galaxy Tab S2上失败，在amediaCodeC_DequeueOutputBuffer(configure和start返回正确的值(amedia_ok))中出现神秘错误代码-10000。

所以我的问题是：

1. 我能以某种方式优化它吗？我测试了每个MediaCodec API调用的时间性能，看起来AmediaCodeC_DequeueOutputBuffer在这里是一个巨大的瓶颈（每个帧有80%-90%的时间）。
2. 对于银河标签2上的-10000错误，我能做些什么吗？我读过MediaCodecs的文档，但没有描述。我只在VLC的源代码(modules/codec/omxil/mediacodec_ndk.c)中发现了常量AMEDIA_ERROR_UNKNOWN=-10000（问题2.b:他们是从哪里找到这个常量的？）。

设备规格（来自/etc/media_codecs.xml的解码器）：

>

小米红米5 Plus:Android 7.1.2“视频/AVC”解码器:omx.qcom.video.decoder.avc、omx.qcom.video.decoder.avc.secure

Nexus 7（平板电脑）Android 6.0.1“视频/AVC”编解码器：omx.qcom.video.decoder.avc,omx.qcom.video.decoder.avc.secure

Samsung Tab A
Android 7.1.1“视频/AVC”解码器：omx.qcom.video.decoder.avc,omx.qcom.video.decoder.avc.secure,omx.sec.avc.sw.dec

Samsung Tab S2:
Android 7.0“视频/AVC”解码器:omx.exynos.avc.dec、omx.exynos.avc.dec.secure、omx.sec.avc.sw.dec

我可以看到所有执行得当的设备（即使很慢）都有高通解码器的共同点。

我的代码：

//initialization (I omitted checks for errors, all initialization is executed without any errors.:
//f contains pointers to functions from libmediandk.so

const char mime[] = "video/avc";
mDecoder = f.createDecoderByType(mime);
AMediaFormat* mFormat = f.createMediaFormat();

const int colorFormat = 19; //COLOR_FormatYUV420Planar
f.setString(mFormat, c.keyMime, mime);
f.setInt32(mFormat,  c.keyWidth, width);
f.setInt32(mFormat,  c.keyHeight, height);
f.setInt32(mFormat,  c.keyColorFormat, colorFormat);
f.setInt32(mFormat, "encoder", 0);
f.setInt32(mFormat, "max-input-size", 0);

//both sps and pps are extracted from the stream
f.setBuffer(mFormat, "csd-0", sps, sizeof(sps));
f.setBuffer(mFormat, "csd-1", pps, sizeof(pps));

media_status_t status = f.configure (mDecoder, mFormat, NULL, NULL, 0);
status = f.start(mDecoder);

f.deleteMediaFormat(mFormat);

lastOutputBufferIdx = -1;

//this is executed every loop
//data -> char* with this frame's H264 encoded data
//I omitted error check for clarity

const int TIMEOUT_US = -1; //-1 -> blocking mode
AMediaCodecBufferInfo info;
char* buf = NULL;

if (lastOutputBufferIdx != -1){
    f.releaseOutputBuffer(mDecoder, lastOutputBufferIdx, false);
    lastOutputBufferIdx = -1;     
}
ssize_t iBufIdx = f.dequeueInputBuffer(mDecoder, TIMEOUT_US);
if (iBufIdx >= 0){
     buf = f.getInputBuffer(mDecoder, iBufIdx, &bufsize);
     int usedBufSize = 0;
     if (buf){
         usedBufSize = dataSize;
         memcpy(buf, data, usedBufSize);
     }
     media_status_t res = f.queueInputBuffer(mDecoder, iBufIdx, 0, usedBufSize, getTimestamp(), 0);
}

//here's my nemesis (this line is both bottleneck and -10000 generator):
ssize_t oBufIdx = f.dequeueOutputBuffer(mDecoder, &info, TIMEOUT_US);

//I am not interested in processing any error codes from {-1,-2,-3}
//INFO_TRY_AGAIN_LATER, INFO_OUTPUT_FORMAT_CHANGED, INFO_OUTPUT_BUFFERS_CHANGED)
while (oBufIdx == -1 || oBufIdx == -2 || oBufIdx == -3){
    oBufIdx = f.dequeueOutputBuffer(mDecoder, &info, TIMEOUT_US);
}

while (oBufIdx >= 0)
{
    buf = f.getOutputBuffer(mDecoder, oBufIdx, &bufsize);
    AMediaFormat format = f.getOutputFormat(mDecoder);
    f.getInt32(format, "width", &width);
    f.getInt32(format, "height", &height);
    f.deleteMediaFormat(format);

    //yuv_ is struct returned by my function
    yuv_.data = buf + info.offset;

    yuv_.size = bufsize;
    yuv_.width = width;
    yuv_.height = height;

    yuv_.yPlane = yuv_.data + info.offset;
    yuv_.uPlane = yuv_.yPlane + height * width;
    yuv_.vPlane = yuv_.uPlane + (height * width) / 4;

    yuv_.yStride = width;
    yuv_.uStride = width / 2;
    yuv_.vStride = width / 2;
}

lastOutputBufferIdx = oBufIdx;

Answer 1

最大的问题是，您只向解码器提供一个数据包，然后阻塞，等待返回单个解码帧。

硬件解码器通常有一点延迟；通过解码器的一个单一帧所需的时间比在单个帧之间所需的时间更长，如果您只是不断地馈送它们。

所以不要停下来等待输出，而是在可能的情况下提供更多的输入包（如果您有可用的）。从第一个数据包输入到第一个解码输出的时间可能是相同的，但在此之后，您应该更快地得到下一帧。有些解码器甚至不会返回任何东西，无论您等待多长时间，直到您给它提供了至少几个输入数据包。