如何在RTP流传输时处理音频编解码器的处理时延

Question

在Speex codec manual的第2.1节中，它说：

  

每个语音编解码器都会在传输中引入延迟。对于Speex，此延迟等于帧大小加上一些量   处理每一帧所需的“预见”。 在窄带操作（8 kHz）中，延迟为30 ms，而对于宽带（16   （kHz），延迟为34 ms 。这些值不考虑对帧进行编码或解码所需的CPU时间。

在Speex Codec的RTP有效载荷格式中，RFC5574表示：

  

ptime：应该是20毫秒的倍数

我有20mS的编码数据帧时间。所以我认为我的ptime应该是20。

编码延迟为30mS或更长。 RTP数据包之间的时间是20毫秒。这应该怎么样？每个其他RTP有效负载都是空数据包？我该如何解决这个问题？

看起来这是每个编解码器的问题。我必须错过对流媒体如何运作的一些基本理解。

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

我试过了：

• 在开头创建一个大型队列进行补偿，但这很快就会变为零长度。
• 发送零数据作为有效负载

我尚未尝试的想法：

• 发送所有填充的数据包并将RTP标头标记为填充
• 增加序列而不是时间戳，直到下一个实际有效负载准备就绪（这听起来像是违反规范？）

注意：我现在想知道speex提到的延迟是否在编码输出中，而我在播放时看到的延迟是由于我的CPU（嵌入式）有限

Answer 1

我的说明是正确的。这个问题有缺陷。

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

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