如何减少 MediaCodec 视频/avc 解码中的延迟

我执行了一些简单的计时电影播放器​​.java https://github.com/google/grafika/blob/master/src/com/android/grafika/MoviePlayer.java in the Grafika https://github.com/google/grafika在 Nexus 5 上运行的 MediaCodec 示例代码。我在这些位置放置了一条日志语句：

就在之前的第 203 行

decoder.queueInputBuffer

在第 244 行之后

decoder.dequeueOutputBuffer

我使用关联日志语句presentationTimeUs.

以下是 logcat 的摘录：

01-29 10:56:43.295: I/Grafika(21286): queueInputBuffer index/pts, 2,0
01-29 10:56:43.305: I/Grafika(21286): queueInputBuffer index/pts, 0,33100
01-29 10:56:43.315: I/Grafika(21286): queueInputBuffer index/pts, 3,66466
01-29 10:56:43.325: I/Grafika(21286): queueInputBuffer index/pts, 1,99833
01-29 10:56:43.325: I/Grafika(21286): queueInputBuffer index/pts, 2,133200
01-29 10:56:43.335: I/Grafika(21286): queueInputBuffer index/pts, 0,166566
01-29 10:56:43.345: I/ATSParser(21286): discontinuity on stream pid 0x1011
01-29 10:56:43.345: I/ATSParser(21286): discontinuity on stream pid 0x1100
01-29 10:56:43.345: I/Grafika(21286): queueInputBuffer index/pts, 3,199933
01-29 10:56:43.345: I/Grafika(21286): dequeueOutputBuffer index/pts, 7,0
01-29 10:56:43.345: I/Grafika(21286): queueInputBuffer index/pts, 1,300033
01-29 10:56:43.355: I/Grafika(21286): dequeueOutputBuffer index/pts, 6,33100
01-29 10:56:43.385: I/Grafika(21286): queueInputBuffer index/pts, 2,333400
01-29 10:56:43.385: I/Grafika(21286): dequeueOutputBuffer index/pts, 5,66466
01-29 10:56:43.415: I/Grafika(21286): queueInputBuffer index/pts, 0,366766
01-29 10:56:43.415: I/Grafika(21286): dequeueOutputBuffer index/pts, 4,99833
01-29 10:56:43.445: I/Grafika(21286): queueInputBuffer index/pts, 3,400133
01-29 10:56:43.445: I/Grafika(21286): dequeueOutputBuffer index/pts, 3,133200

我发现从第一个输入缓冲区排队到相应的输出缓冲区出列的时间差为 50 毫秒。这对于硬件加速解码来说似乎需要很多时间。

有没有办法减少这个延迟？

我认为您看到了第一帧特有的一些效果。我重复了你的实验，进一步添加了强迫doRender = false大约第 244 行以避免用于管理输出帧速率的睡眠调用。我懂了：

01-29 14:05:36.552  9115  9224 I Grafika : queueInputBuffer index/pts, 2,0
01-29 14:05:36.562  9115  9224 I Grafika : queueInputBuffer index/pts, 0,66655
01-29 14:05:36.572  9115  9224 I Grafika : queueInputBuffer index/pts, 3,133288
01-29 14:05:36.582  9115  9224 I Grafika : queueInputBuffer index/pts, 1,199955

01-29 14:05:36.602  9115  9224 I Grafika : dequeueOutputBuffer index/pts, 4,0
01-29 14:05:36.602  9115  9224 I Grafika : dequeueOutputBuffer index/pts, 3,66655
01-29 14:05:36.602  9115  9224 I Grafika : dequeueOutputBuffer index/pts, 2,133288
01-29 14:05:36.612  9115  9224 I Grafika : dequeueOutputBuffer index/pts, 4,199955

（为了清楚起见，删除了无关的行。）这证实了您的结果。请注意，虽然 pts=0 的输入和输出之间存在 50 毫秒的延迟，但后续输出帧几乎立即可用。我使用的视频是“camera-test.mp4”（720p 相机输出）。

要深入了解发生这种情况的原因，请查看日志中的其他内容及其出现位置。从第一个开始queueInputBuffer日志行，计算该行与第一个日志之间出现的日志数dequeueOutputBuffer线。我算了一下我的 OMX-VDEC-1080P 大约有 60 行输出。现在计算输出缓冲区开始出现后出现的 OMX-VDEC 行数。直到视频结束我才看到任何东西。

视频解码器显然推迟了一些昂贵的初始化，直到数据可用。那么下一个问题是......它需要多少数据？我在提交第二帧后添加了 500 毫秒的睡眠 (pts==66633)。结果：提交了两个帧，暂停了 500 毫秒，提交了两个帧，一大堆 OMX-VDEC 日志。所以看起来解码器在开始之前需要几帧。

这表明我们可以通过快速输入前几帧来减少启动延迟。为了测试这一点，我改变了TIMEOUT_USEC为零，所以响应速度快，但会烧CPU。新的日志输出（你的日志，没有睡眠，没有渲染）：

01-29 14:29:04.542 10560 10599 I Grafika : queueInputBuffer index/pts, 0,0
01-29 14:29:04.542 10560 10599 I Grafika : queueInputBuffer index/pts, 2,66633
01-29 14:29:04.542 10560 10599 I Grafika : queueInputBuffer index/pts, 3,133288
...
01-29 14:29:04.572 10560 10599 I Grafika : dequeueOutputBuffer index/pts, 4,0
01-29 14:29:04.572 10560 10599 I Grafika : dequeueOutputBuffer index/pts, 3,66633
01-29 14:29:04.572 10560 10599 I Grafika : dequeueOutputBuffer index/pts, 2,133288

通过快速输入初始帧，我们将初始延迟从 50 毫秒减少到 30 毫秒。

（请注意所有时间戳如何以“2”结尾？用于日志时间的计时器似乎四舍五入到最接近的 10 毫秒，因此实际时间增量可能略有不同。）

我们缓慢地输入初始帧的原因是，我们试图在提交每个输入缓冲区后排出解码器的输出，等待 10 毫秒以获取从未出现的输出。我最初的想法是我们想要等待超时either dequeueInputBuffer() or dequeueOutputBuffer()，但不能两者都使用——也许首先使用输入超时和输出快速轮询，然后当我们用完输入时切换到输出超时。 （就此而言，initial输入超时可能为 -1，因为我们知道在第一个输入缓冲区排队之前不会发生任何事情。）

不知道有没有办法进一步减少延迟。