媒体服务器项目RTP分包处理中的MPEG4-Generic封装问题分析

在ireader媒体服务器项目的RTP模块中，发现了一个关于MPEG4-Generic封装格式的分包处理问题。这个问题会导致在特定情况下音频数据无法正确解包，最终触发断言错误。

问题背景

RTP协议在传输MPEG4音频数据时，常使用"mpeg4-generic"作为负载类型。这种封装方式需要在RTP包头中包含AU头部(AU headers)，用于描述每个音频单元的尺寸信息。当音频数据较大需要分包传输时，每个RTP包中的AU头部应该只描述当前分片的数据大小，而不是整个音频单元的大小。

问题现象

在项目中，当RTP包大小设置为512字节(这是经过修改的最小值)并传输包含ADTS头的AAC音频数据时，会出现以下情况：

1. 编码器将一帧AAC数据(包含7字节ADTS头)通过rtp_payload_encode_input()送入编码
2. 编码回调立即将数据送去解码
3. 解码器在rtp_decode_mpeg4_generic()函数中触发断言错误

技术分析

问题的根本原因在于rtp_mpeg4_generic_pack_input()函数在分包处理时，错误地将整个音频单元的大小写入了每个分包的AU头部，而不是写入当前分包的实际数据大小。这导致了解包时的混乱：

1. 编码端错误行为：无论是否分包，AU头部总是写入完整帧大小
2. 解码端后果：解包时读取的尺寸信息与实际分片大小不匹配，最终触发断言

正确的实现应该是：

• 对于不分包的情况：AU头部写入完整帧大小
• 对于分包情况：每个包的AU头部只写入当前分片的数据大小

解决方案

项目维护者已经确认了这个问题，并计划修复解码端的断言检查逻辑。正确的修复应该同时考虑编码和解码两端：

1. 编码端修改：在分包时正确计算并写入当前分片大小
2. 解码端增强：改进断言检查，使其能处理异常情况而不崩溃

技术影响

这个问题对于实时音视频传输系统尤为重要，因为：

1. 音频数据经常需要分包传输，特别是高质量音频
2. 错误的尺寸信息会导致接收端无法正确重组音频帧
3. 断言崩溃会直接中断服务，影响系统稳定性

总结

RTP协议中的MPEG4-Generic封装格式需要特别注意分包处理时的尺寸信息写入。开发者在实现这类协议时，必须严格遵循规范，确保编码端和解码端对数据格式的理解一致。对于关键的音视频传输系统，完善的错误处理机制比简单的断言更为重要。