RTP传输MP3帧无法被VLC播放的问题排查与时间戳咨询

一、先解决VLC的帧错误问题（核心） #

从报错信息来看，VLC解析MP3帧时出现了帧大小超限、找不到合法起始码的问题，这大概率是RTP打包环节出了问题：

• 严格遵循单RTP包对应单MP3帧：MP3帧是自包含的独立单元，RTP传输MP3（Payload Type 14）要求每个UDP包只能封装一个完整的MP3帧，不能拆分帧，也不能将多个帧塞进同一个包。一旦违反这个规则，VLC就会解析失败。
• 检查MP3帧的完整性：虽然编码后保存文件正常，但要确认发送时有没有把LAME输出的完整帧数据发出去——尤其要注意帧开头的同步字（0xFFE或0xFFF）有没有被截断，或是误传了额外字节（比如编码缓存的残留数据）。
• 核对帧长度：VLC报“frame too big”说明接收到的帧长度超过了当前MP3格式的最大值。请确认LAME编码后返回的帧长度是否准确，发送时有没有严格按照这个长度传输，有没有在RTP头之外多传了其他数据。

二、RTP时间戳的正确计算 #

RTP传输MPEG音频的时间戳时钟频率确实是90000Hz，正确的计算方式是基于音频样本数，而非直接用毫秒数乘90：

• 先确认MP3帧的样本数：MPEG-1 Layer3每帧固定1152个样本，MPEG-2 Layer3每帧是576个样本。
• 时间戳增量公式：增量 = 帧样本数 × 90000 ÷ 音频采样率
  比如你的音频是44.1kHz采样率（MPEG-1），每帧1152样本：1152 × 90000 ÷ 44100 ≈ 2371，每发送一帧就给时间戳累加2371即可。
• 初始时间戳可以设一个随机32位值，整个流过程中保持递增，不要随意重置。

三、RTP头部的其他注意事项 #

• Payload Type 14对应MPEG-1 Audio，如果你的MP3是MPEG-2格式（比如采样率22.05kHz），建议换成Payload Type 10，部分播放器对Type14的兼容仅限于MPEG-1。
• 确认Sequence Number（16位）和Timestamp（32位）都通过HTONS/HTONL函数转换成网络大端序，Delphi原生支持这些转换函数。
• SSRC（同步源ID）要设置一个固定的随机32位值，同一个流全程保持不变，不要每次发送都生成新值。

四、调试技巧 #

• 用Wireshark抓UDP包，检查每个RTP包的结构：12字节头部之后是否紧跟完整的MP3帧，帧开头是否是0xFF开头的同步字，包总长度是否等于12+帧长度。
• 把抓包中的MP3帧数据提取出来保存成MP3文件，看能否正常播放——如果可以，说明问题出在RTP头部或时序上；如果不行，说明发送的帧本身存在问题。

内容的提问来源于stack exchange，提问作者Ross