低速串行链路下IP/UDP/RTP数据包头的压缩( 七 )


::
:RTP头扩展:(假如环境中设置了X位)
::
::
-------------------------------
RTP数据
//
//
-------------------------------
:填充:(假如环境中设置了P位)
...............................
假如FULL_HEADER初始化的环境中IPv4头数目多余1,则封装头的IPID字段必须如[3]所
述按照绝对值形式发送 。这些字段标识为"RANDOM"字段 。它们按照与原始包中相同的顺序被
插入COMPRESSED_RTP包,如图所示,其后紧接着是UDP校验和或MSTI字节 。除非IPv4包正好
在UDP头之前,该头的IPID才会被区别发送,例如,假如二次差分为0,或者二次差分不为0
但该字段是作为deltaIPv4ID字段它就不占任何位 。假如没有IPv4头正好位于UDP头之前,
则I位必须为0且不应存在deltaIPv4ID字段 。
3.3.3.COMPRESSED_UDP包格式
假如RTP头中任何一般情况下应为常量的字段(如负载类型字段)发生了变化,则必须发
送一个非压缩RTP头 。假如IP和UDP头不需要更新,则该RTP头可以用COMPRESSED_UDP包携带,
而不必用FULL_HEADER包 。除了M,S和T为为常数0以及没有相应的delta字段以外,
COMPRESSED_UDP包同COMPRESSED_RTP格式相同:
01234567
...............................
:会话环境ID的msb:(假如使用16位CID)
-------------------------------
会话环境ID的lsb
--- --- --- --- --- --- --- ---
000I链路顺序号
--- --- --- --- --- --- --- ---
::
UDP校验和 (假如环境中校验和非0)
::
...............................
::
"RANDOM"字段 (假如被封装)
::
...............................
:deltaIPv4ID:(假如I=1)
-------------------------------
UDP数据
:(非压缩RTP):
请注重,这里IP/UDP头的压缩形式和[3]中定义的COMPRESSED_NON_TCP包类型不同 。其目
的是象IPv4所答应的那样,当禁用UDP校验和时使压缩目标达到2字节 。[3]中定义的协议没
有使用UDP包的差分编码,所以在用于IPv4时,除了前面的两个压缩字节,还有两个字节的
IPID和两个字节的非0UDP校验和都要进行传输 。对于IPv6,可使用COMPRESSED_NON_TCP包
类型来替代 。
3.3.4.差分编码Encodingofdifferences
COMPRESSED_RTP和COMPRESSED_UDP包的delta字段为变长编码,可将压缩数据映射到更多
的通常使用值 。下面规定了一种优化的哈夫曼编码作为缺省编码,推荐在实现表驱动delta
编/解码器来为会话进行面向表协商时使用 。针对一定范围内数据的测试表明,在合理的表
规模下基于对位流进行顺序解释的编码执行速度比非表驱动的实现要快,这种缺省表和哈夫
曼编码就是例子 。缺省delta编码规范见下表 。该编码在IPID和RTP顺序号变化很小的情况
下可高效编码,此时压缩器发出的包丢失,但仍能将大多数音视频deltas保持为2字节 。左
边的列是要编码的10进制数,右边的列是16进制显示的编码后按发送顺序排列(网络字节顺
序)的字节序列 。其中显示了相临范围的首尾值,其余均省略:
十进制16进制
-16384C00000
::
-129C03F7F
-1288000
::
-1807F
000
::
1277F
1288080
::
16383BFFF
16384C04000
::
4194303FFFFFF
对于正数,在一个字节内直接以0到127表示 。假如该字节的最高两位是10或者11,则表示
分别表示要扩展到2或3个字节 。低6位按照降序同后面紧跟的1到2个字节联合表示一个14或
22位值 。
当包出现乱序或者在MPEG视频的RTP时间戳故意被打乱时可能会出现负数的delta值 。这

推荐阅读