ZLMediaKit中RTP分包MPEG4-Generic格式的Bug分析

在多媒体流媒体服务器ZLMediaKit的子模块media-server中，发现了一个关于RTP协议分包MPEG4-Generic格式音频数据的bug。这个问题主要出现在librtp库的rtp_mpeg4_generic_pack_input函数中，导致音频数据分包异常。

问题背景

RTP协议在传输MPEG4-Generic格式的音频数据时，需要对音频数据进行分包处理。每个RTP包都需要携带AU headers（Access Unit headers），这些头部信息包含了音频数据单元的大小和索引等重要信息。当音频数据过大需要分片传输时，每个RTP包应该只携带当前分片的大小信息，而不是整个音频数据单元的大小。

Bug具体表现

在原始代码中，rtp_mpeg4_generic_pack_input函数在分包处理时存在一个逻辑错误：它将整个音频数据单元的大小写入了每个分包的AU headers中，而不是写入当前分包的实际大小。这导致在接收端解包时，rtp_decode_mpeg4_generic函数会触发断言assert(0)，因为接收到的数据大小与AU headers中声明的大小不匹配。

技术分析

MPEG4-Generic格式的RTP封装规范要求：

1. 每个音频数据单元(AU)可以分成多个RTP包传输
2. 每个RTP包的AU headers必须准确描述当前包中携带的数据量
3. 当AU被分片时，每个分片的AU header应该只包含该分片的大小

原始代码的错误在于没有正确处理分片情况下的AU header填写逻辑，导致接收端无法正确重组音频数据。正确的做法应该是：

1. 对于第一个分片，AU header写入剩余可放入RTP包的数据量
2. 对于后续分片，AU header写入当前分片实际携带的数据量
3. 确保所有分片的AU header大小总和等于原始AU的总大小

解决方案

修改rtp_mpeg4_generic_pack_input函数的实现，确保在分包时：

1. 正确计算每个RTP包可携带的数据量
2. 只将当前分片的大小信息写入AU headers
3. 保持索引信息的连续性

这个修复确保了RTP包的接收端能够正确解析和重组音频数据，避免了断言失败的情况。对于使用ZLMediaKit进行MPEG4-Generic格式音频传输的开发者来说，这个修复保证了音频数据的可靠传输和正确解码。

影响范围

该bug主要影响使用RTP协议传输MPEG4-Generic格式音频数据的场景，特别是当音频帧较大需要分片传输时。对于小音频帧不需要分片的情况，或者使用其他封装格式的情况，不会受到影响。

总结

RTP协议的分包处理是流媒体传输中的关键环节，必须严格按照协议规范实现。ZLMediaKit中的这个bug修复，体现了对协议细节的精确把握，确保了多媒体数据在各种网络条件下的可靠传输。开发者在使用类似功能时，应当特别注意分包逻辑的正确性，避免因协议实现不当导致的数据解析失败。