audio - 如何通过RTP进行流处理时音频编解码器的处理时间延迟

Question

在Speex codec manual的2.1节中说:

Every speech codec introduces a delay in the transmission. For Speex, this delay is equal to the frame size, plus some amount of “look-ahead” required to process each frame. In narrowband operation (8 kHz), the delay is 30 ms, while for wideband (16 kHz), the delay is 34 ms. These values don’t account for the CPU time it takes to encode or decode the frames.

在Speex编解码器的RTP有效负载格式 RFC5574中，它表示:

ptime: SHOULD be a multiple of 20 msec

我有20ms的编码数据帧时间。所以我假设我的ptime应该是20

编码延迟为30mS或更大。 RTP数据包之间的时间为20毫秒。这应该如何工作？每隔一个RTP有效负载是一个空包吗？我该如何解决？

似乎这是每个编解码器的问题。我一定对流媒体的工作方式缺少一些基本的了解。

我已经验证过可以流预编码的缓冲区，并且听起来像预期的那样。

我努力了:

在开始时创建一个大队列来进行补偿，但是这很快变成零长度。

发送零数据作为有效载荷

我尚未尝试过的想法:

发送所有填充的数据包并将RTP header 标记为padding

增加序列，但不增加时间戳，直到下一个实际有效负载准备就绪(这听起来像违反规范？)

注意:我现在想知道speex提到的延迟是否在编码输出之内，而流式传输时看到的延迟是否是由于我有限的CPU(嵌入式)引起的

Answer 1

我的笔记是正确的。这个问题是有缺陷的。

Speex手册所指的是音频输出中的延迟，而不是处理时间的固有延迟。因此，所讨论的问题不是问题。

我很高兴问了这个问题，它帮助我找到了解决方案。