h.264 - RTP 分片与 UDP 分片

Question

如果 UDP(或 IP)层进行分段，我不明白为什么我们要在 RTP 级别进行分段。

据我了解，假设我们在以太网链路上，MTU 为 1500 字节。

例如，如果我必须发送 3880 字节，在 IP 层分段，将产生 3 个数据包，分别为 1500、1500 和 940 字节(IP header 为 20 字节，因此总开销为 60 字节)。

如果我在 UDP 层执行此操作，则开销将为 84 字节(3x 28 字节)。

在 RTP 层，它有 120 字节的开销。

在 H264/NAL 打包层，FU-A 模式多出 3 个字节(因此最终为 123 个字节)。

对于这么小的数据包，初始数据包大小最终增加了 3.1%，而在 IP 层，总体上只会浪费 1.5%。

知道它总是比低层碎片更糟糕，是否有任何正当理由在 RTP 层制定如此复杂的打包规则？

Answer 1

RTP 的设计考虑到了 UDP。

Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality.

然而，添加到原始 UDP 的 RTP 服务(例如检测数据包重新排序、丢失和计时的能力)要求 UDP 数据由 RTP 有效载荷和服务信息组成。

The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.

然后 RTP 被设计为可扩展的、通用的头和数据特定的有效载荷:

RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed.

所有报价均来自 RFC 1889 "RTP: A Transport Protocol for Real-Time Applications" .

也就是说，H.264 流的 RTP 开销不仅仅是带宽的浪费。 RTP header 和 H.264 有效载荷格式允许以中等成本以更可靠的方式处理视频数据流，同时利用定义明确且适用于不同类型数据的规范。