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

Question

我在运行在Nexus 5上的格拉菲卡 MediaCodec示例代码中执行了一些简单的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 millis。对于HW加速解码来说，这似乎是相当长的时间。

有办法减少这种延迟吗？

Answer 1

我想你看到了一些第一帧特有的效果。我重复了您的实验，进一步增加了强制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 was的延迟，但随后的输出帧几乎立即可用。我使用的视频是" camera -test.mp4“(720 p摄像机输出)。

要了解发生这种情况的原因，请查看日志中的其他内容，以及它出现的位置。从第一个queueInputBuffer日志行开始，计算在这一行和第一个dequeueOutputBuffer行之间出现的日志数。我数着我的OMX-VDEC-1080 p的大约60行输出。现在，计算在输出缓冲区开始出现后，OMX行出现的数量。在录像结束之前我什么也没看到。

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

这表明，我们可以通过快速输入前几帧来减少启动延迟。为了测试这一点，我将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 to减少到30 to。

(注意所有时间戳是如何以“2”结尾的？用于日志时间的计时器似乎是舍入到最近的10 may，因此实际时间增量可能略有不同。)

我们缓慢地输入初始帧的原因是，在每个输入缓冲区提交之后，我们试图从解码器中提取输出，等待10毫秒的输出，而这些输出永远不会出现。我最初的想法是，我们希望在dequeueInputBuffer()或dequeueOutputBuffer()上等待超时，但不是两者兼而有之--可能首先对输入使用超时值，然后在输入不足时切换到输出超时。(就这一点而言，输入的初始超时可能是-1，因为我们知道在第一个输入缓冲区排队之前不会发生任何事情。)

我不知道是否有办法进一步减少延迟。