简介：基于H.264与AAC的RTP媒体流合成MP4的实现方案，面向流媒体开发者和音视频学习者，解决从RTP数据包中提取H.264视频与AAC音频并封装为MP4文件的常见需求。资源共31个文件，以C语言源码和头文件为主体，涵盖RTP接收、解码、封装等模块设计，同时提供Makefile构建脚本、SDP会话描述文件、示例MP4输出及辅助工具，整个压缩包约197KB，体量轻巧、结构清晰，便于直接阅读和二次开发。目前已有487人学习下载。阅读该方案可系统掌握RTP负载解析、H.264分片重组与AAC帧处理、MP4封装格式等关键环节，配合SDP和示例输出能够快速验证链路完整性。对从事实时音视频传输、播放器开发或流媒体协议研究的技术人员而言，是一份可直接对照调试的实用参考，适合具备一定网络编程基础并希望深入理解MP4与RTP结合机制的开发者。
1. RTP 流合成 MP4：明明都是 H264 和 AAC，为什么不能直接改后缀名
拿到一段抓包工具导出的 RTP 原始流，扩展名改成 .mp4，播放器直接拒绝播放，提示“文件损坏”。这个反直觉的现象每天都在发生：RTP 负载里明明装的就是 H264 NAL 单元和 AAC 音频帧，跟 MP4 文件里的数据本质上是同一种东西，为什么换了个壳就播不了？原因是 RTP 是流式传输协议，它把媒体数据切成小块、打上时间戳、按实时性要求往外丢；而 MP4 是文件容器，要求数据按固定 Box 结构排列，并且必须有 moov 这样的索引区来告诉播放器“哪一帧在哪个字节偏移、时长多少”。两者之间的转换，不是简单的重命名，而是“拆包 → 重组 NAL → 对齐时间戳 → 写索引”的全套工程。搞懂这条链路，你才能写出稳定不翻车的 RTP 转 MP4 工具，也才能真正理解视频封装容器和流媒体协议之间的底层关系。
2. RTP 解包：先从传输层的“果酱铺”里把 H264 和 AAC 的完整帧抠出来
2.1 H264 在 RTP 里的三种包装：单包、FU-A、STAP-A
H264 在 RTP 里并不总是“一个 NAL 单元一个包”。因为 RTP 底层的 UDP 包通常限制在 1460 字节左右（以太网 MTU 1500 减去 IP 头 20 和 UDP 头 8），而一个视频关键帧的 NAL 经常是几十 KB 甚至上百 KB，必须分片。H264 的 RTP 封装规范定义了三种载荷类型：单 NAL 单元（Single NAL）、分片单元（FU-A，Fragmentation Unit）、聚合包（STAP-A，Single-Time Aggregation Packet）。其中 FU-A 是最常见的长帧处理方式，STAP-A 用来把 SPS/PPS 这类小参数集拼在一个包里。
一个新视频帧的第一个分片包长这样：RTP 头之后是 FU indicator 字节和 FU header 字节。FU indicator 的低 5 位是 NAL type，FU header 的 S、E、R 三个标志位分别表示分片起始、结束和保留位。把这两个字节拿掉，再把 FU header 里的 NAL type 写回 FU indicator 的低 5 位，就能得到完整的 NAL head。这种位级别的还原操作如果写错一个 bit，解码器立刻花屏。
2.2 重组 FU-A 分片：判空、判断开始、判断结束，缺一不可
用 Python 写一个重组逻辑，关键步骤就三行流程：
def rtp_to_annexb(rtp_payload, nal_header_size=2): # 第一个字节是 FU indicator，第二个是 FU header fu_indicator = rtp_payload[0] fu_header = rtp_payload[1] nalu_type = fu_header & 0x1F if fu_header & 0x80: # S bit = 1，分片起始 # 把 nalu_type 写回 fu_indicator 的低 5 位 reconstructed = bytes([(fu_indicator & 0xE0) | nalu_type]) # 真正的 NAL 数据从第三个字节开始拼接 return b'\x00\x00\x00\x01' + reconstructed + rtp_payload[2:] elif fu_header & 0x40: # E bit = 1，分片结束 # 此时不需要再拼接 NAL 头，直接接续数据 return rtp_payload[2:] else: # 中间分片，整包都是负载数据 return rtp_payload[2:]这个函数每次只处理一个 RTP 包，返回的是可以扔给 H264 解码器的 AnnexB 格式切片。注意返回结果的长度差异：起始分片返回的内容最长，包含 4 字节起始码和重新拼好的 NAL 头；中间分片最短；结束分片返回的数据和中间分片一样只是纯负载。真正的重组循环在外部维护一个字节缓冲，把同一个时间戳下的所有分片按顺序 append 起来，直到遇到 E bit 才组成完整一帧。
2.3 AAC 在 RTP 里的载荷格式：AU Header 决定原始数据的读取方式
AAC 的 RTP 封装和 H264 完全不是一个套路。AAC 用的是 “AU Header + AU Data” 的结构，一个 RTP 包可以携带多个 Audio Access Unit。AU Header 的前 4 字节是 16 位的 AU-size 和 16 位的 AU-Index，AU-size 表示单个 AAC 原始帧的字节长度。每一帧 AAC 裸数据前面没有 ADTS 头，必须靠 AU Header 里记录的 size 来切分。
def parse_aac_rtp(payload): # 前 4 字节是 AU Headers 的长度（以字节为单位） headers_length = int.from_bytes(payload[0:2], 'big') # 每个 AU Header 占 4 字节（新版）或 2 字节（旧版） offset = 2 frames = [] pos = 2 + headers_length while offset < 2 + headers_length: au_size = int.from_bytes(payload[offset:offset+2], 'big') # AU Header 里 size 的计数单位是“字”，一个字等于 8 字节 au_size = au_size >> 3 frames.append(payload[pos:pos+au_size]) pos += au_size offset += 4 return framesAU Header 里 AU-size 的计数单位极容易搞错。规范规定这个 16 位字段表示的是 “AU size in words”，一个字等于 8 字节。如果你不右移三位直接用，切出来的 AAC 帧长度全部是实际长度的 8 倍，合并出来的音频直接是噪音。这是所有 RTP 转 MP4 工具最容易翻车的地方之一，比 H264 重组隐蔽得多，因为标签不起作用，只有切片完解码才知道对不对。
3. 时间戳与 Stride：RTP 的时间线如何无损映射到 MP4 的 sample 时间轴
3.1 90kHz 的视频时间戳和 44.1kHz 的音频时间戳：两个不同刻度的钟
RTP 时间戳的单位跟编码格式相关。H264 的 RTP 时间戳以 90kHz 为基准，每 tick 是 1/90000 秒；AAC 的 RTP 时间戳以采样率为基准，44.1kHz 音频每 tick 是 1/44100 秒，48kHz 音频则是 1/48000 秒。合成 MP4 时，必须把两套时间线统一换算成 MP4 容器的 timescale（通常视频用 90000，音频用采样率，或统一用 90000）。
假设一个视频帧的时间戳是 rtp_ts_video = 3600 的 RTP 包，对应播放时刻是 3600/90000 = 0.04 秒；一个音频帧时间戳 rtp_ts_audio = 8820，对应 8820/44100 = 0.2 秒。要转成 MP4 的 90000 timescale，音频帧的 MP4 时间戳 = 8820 * 90000 / 44100 = 18000。换算公式的核心是比例关系，不是简单的加减。
3.2 时间戳差值映射：为什么第一个 video sample 的时间戳不强制归零
很多开发者会犯的第一个错误是“把首帧时间戳设为 0”。RTP 流的第一个视频包时间戳往往不是从 0 开始的，有的设备从 1432 这种随机偏移开始。MP4 的 sample 时间轴要求从 0 开始，但不代表你要把 timestamp 减去第一个包的 RTP 时间戳。
正确做法是：记录首帧 RTP 时间戳 rst_offset，然后所有帧的 MP4 时间戳 = (rtp_ts - rst_offset) * mp4_timescale / rtp_rate。这样第一个 sample 的 pts 确实是 0，但整个时间线的相对间隔保持不变。如果直接拿 rtp_ts 去算，文件时间轴会带着一个巨大的偏移，播放器显示的总时长和音画错位全都乱。
def rtp_clock_to_mp4_ts(rtp_ts, rtp_rate, start_offset, mp4_timescale): # 核心比例换算：先算相对包的 tick 偏移，再换算到目标 timescale relative_ticks = rtp_ts - start_offset return int(relative_ticks * mp4_timescale / rtp_rate)3.3 B 帧陷阱：MP4 的 PTS 和 DTS 是两套字段，compose offset 不能省
H264 视频流如果用了 B 帧，解码顺序和显示顺序不一致。MP4 的 stts（time-to-sample）表存的是 DTS 间隔，另有一个 stss 表标记同步帧，还有一个 ctts（composition time offset）表记录每个 sample 的 PTS 与 DTS 差值。RTP 抓包层面你看不到 PTS，因为在 RTP 传输中通常只携带一个时间戳，它代表的是解码顺序（DTS 对应的表现）。
如果你把 RTP 时间戳直接当作 MP4 的 PTS 写入 stts，B 帧场景下画面会乱跳。很多开源工具简单粗暴地把 RTP 时间戳当作 DTS，然后 PTS 等于 DTS，这在全部是 IDR 和 P 帧的流里没问题，一旦出现 B 帧就翻车。MP4 规范允许 ctts 表为空，这意味着 PTS = DTS，但如果实际有 B 帧，播放器会按错误的顺序显示。作为合成工具，你要么放弃对 B 帧流的支持并明确报错，要么在解包时借用一些启发式规则估算 B 帧的 display order——通常的做法是用 SPS 里的 max_num_reorder_frames 和帧间 POC 差值推算每帧的 offset。
4. MP4 容器内部：mdat 写数据、moov 写索引，两个 Box 的协作
4.1 Box 结构全景：ftyp、moov、mdat、moof 到底谁管什么
MP4 是 ISO BMFF 的 Apple 扩展版，基本构建单元是 Box（也叫 atom）。每个 Box 开头是 4 字节长度和 4 字节类型。一个最小可播放的 MP4 至少要有 ftyp（文件类型）、moov（元数据）、mdat（媒体数据）三种 Box。ftyp 声明兼容性，moov 里嵌套 trak（轨道）、stbl（sample table），mdat 里是按 Track 顺序交错排列的 sample 原始数据。
RTP 流合成 MP4 时，通常做法是先写 ftyp，mdat 边接收边写数据，但 moov 必须到最后才写，因为 sample 的字节偏移（stco 表）依赖 mdat 里数据的最终布局。如果你的工具支持 moov 前置（faststart），那就要先写一个空的 moov 占位，算好所有 sample 的偏移后回来覆盖。这里牵扯到一个经典问题：网络流是分批到的，提前预留的 moov 空间不够就会 Box 错位，播放器直接报 “moov atom not found”。
4.2 Sample Table 的五个核心表：stts、stsz、stsc、stco、ctts
MP4 的样本数据是“按 chunk 组织”的。chunk 是一组连续存储的 sample，stsc 表告诉播放器“每个 chunk 里有多少个 sample、从第几个 sample 开始变化”，stco 表告诉播放器“每个 chunk 的字节偏移在哪”。stts 存每个 sample 的 DTS 递增间隔，stsz 存每个 sample 的大小，ctts 存 PTS 与 DTS 的偏移。
构建 sample table 常见实现思路是：先收集所有 sample 的字节大小，计算出每个 chunk 的偏移，最后一次性生成这几个表。视频 track 建议每个 chunk 放 1 个 sample（即每帧一个 chunk），音频 track 每个 chunk 放 1024 个 sample（即每 1024 个音频帧一块）。原因很朴素：chunk 越大，stco 表项越少，文件越小；但太大会导致随机访问时需要加载大量无关数据。视频用 1，因为关键帧之后的帧解码依赖前一帧，随机访问还是要落在关键帧；音频用 1024，因为 AAC 解码天然按块为单位。
typedef struct { uint32_t sample_count; uint32_t sample_delta; } stts_entry; typedef struct { uint32_t sample_count; uint32_t sample_size; } stsz_entry;4.3 SPS/PPS 注入：MP4 的 avcC Box 与 RTP 里的 STAP-A 聚合包
H264 在 RTP 流中以 STAP-A 聚合包出现的 SPS 和 PPS，不能直接丢弃。MP4 容器需要把这两个参数集写进 avcC Box，并且每个关键帧 sample 前要加 4 字节 NAL 长度前缀（Length-Prefixed NAL）而不是 AnnexB 风格的 00 00 00 01 起始码。转换时，要把从 RTP 里恢复出来的 SPS/PPS 二进制写入 avcC Box 的 sequenceParameterSet 字段，再把视频 sample 里的 AnnexB 起始码替换为 4 字节大端长度。
这一步常有三种错误：SPS/PPS 漏写导致解码器无法初始化；起始码没替换导致 MP4 里的 NAL 长度信息错乱；SPS/PPS 在 RTP 流中只出现一次，如果起始的包丢了你需要从关键帧的 FU-A 里找。成熟的工具会维护一个全局的 SPS/PPS 缓存，在收到任何 STAP-A 包时更新，写 moov 时统一取出。
// Length-Prefixed NAL 的写入方式：每个 NAL 前 4 字节为 length uint32_t nalu_len = sample_nal_size; uint8_t prefix[4] = { (uint8_t)(nalu_len >> 24), (uint8_t)(nalu_len >> 16), (uint8_t)(nalu_len >> 8), (uint8_t)(nalu_len) };如果工具不管 SPS/PPS 缓存，直接拿第一个关键帧的 avcC 写进去，遇到“首包不是关键帧”或者“SPS 单独丢包重传”的场景，生成的 MP4 就是废文件。写文件前检查缓存是否为空的这一步，是所有血泪经验堆出来的关键路径。
5. RTP 转 MP4 避坑手册：五条高频翻车现场的血泪排查
5.1 现象：生成的 MP4 时长对不上，播放器拖进度条直接崩溃
原因分析：RTP 包在传输途中会因为网络抖动丢包重排，音频和视频的 RTP 时间戳是各自独立增长的，两轨的 sample 数量和时长不匹配。播放器按 MP4 的 mvhd Box 里声明的总时长读文件，如果实际 mdat 数据不足，拖到末尾就崩。
解决办法：合成前先统计两轨的 RTP 时间戳最大值和最小值，算出各自的实际时长，以较短者为基准截断；mvhd 总时长写成两者中的较大值，同时把 stts 表填满直到覆盖区间。强制让两轨时长一致，比留空洞安全得多。某次直播流转存档，音频末端丢了 200ms，直接按原样合成后每拖到 58 分钟必闪退，截断后问题消失。
5.2 现象：音画不同步越来越严重，开头 10 秒正常，3 分钟差 2 秒
原因分析：典型的时间戳换算率错误。音频 RTP 时钟是采样率（44100），视频是 90000，如果换算时用错了 rtp_rate，比如把音频按 48000 换算进 44100 的流，每秒钟音频会多 3900 ticks，误差持续累积。
解决办法：换算前先读取 SDP 或抓包信息里的媒体描述确认采样率，不能按 44100 硬编码。换算环节加一个自检：用音频总 tick 数和视频总 tick 数分别除以各自 rtp_rate，得到的秒数差异超过 50ms 就报警。这招救了 A 同学一个凌晨上线的项目，他推演了三个小时的“玄学”偏移，最后发现是采样率写死。
5.3 现象：视频播放正常，音频全是爆音或完全无声
原因分析：AAC 的 RTP 载荷切分错误，最典型的就是 5.2 里说的 AU-size 的字长陷阱。另一个原因是从 RTP 提取的 AAC 裸流没有配对 ADTS 头信息。MP4 的音频 sample 不需要 ADTS 头（用 esds Box 里的 AudioSpecificConfig 描述编码配置），但如果你用抓包工具导出的数据是带 ADTS 的，直接塞进 mdat 会多出 7 字节的偏移，解码器按 ASC 配置读数据时全部错位。
解决办法：在解析 AAC 载荷时明确区分 ADTS 和 RAW。如果源流是 ADTS，先 strip 掉每帧前 7 字节再进 mdat；同时用 AudioSpecificConfig 里的 samplingFrequencyIndex 和 channelConfiguration 生成 esds 描述，而不是抄 ADTS 头。把“是否剥 ADTS 头”做成一个输出开关，比判断系统写死更实用。
5.4 现象：视频花屏，播放器报 “cannot decode” 但文件大小看起来正常
原因分析：FU-A 重组时丢包导致 NAL 不完整，最常见的是拿一个不完整的关键帧 NAL 去组装后续帧。关键帧的 NAL 碎片一旦有缺失，整个 GOP 的解码都受影响；而 P 帧不完整只影响当前帧，不会传到后面。
解决办法：重组时维护当前 NAL 的帧类型。收到 S bit 时记录这一帧的 NAL type，如果 type 是 IDR（nal_unit_type = 5）且后续分片有任何缺失，整个 GOP 直接标记为损坏并丢弃，直到下一个关键帧重来。这个“保关键帧”策略在很多商业转码工具里都能看到，属于宁可丢画面不能花屏的工程取舍。某开源播放器对花屏的容忍度低，故意拿有瑕疵的关键帧合成 MP4，播放器直接罢工，丢弃整个 GOP 后文件能正常跳转播放。
5.5 现象：文件拍平后一切正常，一旦 seek（跳转）到中间位置就黑屏
原因分析：MP4 没有约定好关键帧间隔。RTP 流里关键帧出现频率不固定，或者合成时 stss 表（sync sample table）漏标 IDR 帧。播放器 seek 时希望把播放位置跳到最近的关键帧，如果 stss 表是空的或只有开头一个 IDR，就会从头解码到目标位置，体验是黑屏转圈。
解决办法：合成 stss 表时，把每个 IDR sample 的序号写进去。同时建议在 RTP 侧按视频编码的 GOP 结构判断关键帧的出现规律，如果超过 10 秒都没有 IDR 帧，要么标记文件不支持 seek，要么做进程内间隔注入（有风险，因为编码器可能不接受非关键帧刷新），至少要在合成日志里提示用户“该流关键帧间隔过长”。不写 stss 表生成的 MP4 在很多软播放器里能播，但在硬件播放器和剪辑软件里翻车是必然的。这就是 “stss 不能省” 的原因，哪怕全文件只有一个关键帧也要写。
6. 为什么是 MP4 而不是 TS：设计取舍里藏着的工程答案
写合成工具时，至少要被问一次：RTP 流直接转成 TS（MPEG-2 Transport Stream）不是更简单吗？TS 的包结构固定 188 字节，时间戳用 PTS/DTS 双字段，RTP 的负载可以直接塞进 TS 的 payload 区，几乎没有时间轴换算的压力，而且 TS 天生抗丢包，网络推流都用它。抛开兼容性来看，TS 才是更自然的“RTP 数据收纳盒”。但 MP4 之所以是大众播放器、编辑软件、短视频平台统一接受的格式，核心原因是随机访问能力。TS 的索引信息分散在每个包的小字段里，播放器要从头扫到目标位置才能定位；MP4 的 moov 索引是集中式的，seek 到任意时间点的复杂度是 O(1)。这个取舍在短文件上感觉不到，但一个 4K 长视频，TS 的 seek 时间会膨胀到不可接受。
这就引出一个更深层的问题：合成工具应该提供 “流模式” 和 “文件模式” 两套输出。流模式走 TS，保证实时性和抗丢失；文件模式走 MP4，保证可编辑、可跳转、可上传。很多项目一开始直接封装 MP4，后来发现推流场景下 RTP 丢包导致 MP4 接收端卡死，才补了 TS 输出。这是典型的设计取舍教训：容器选择是业务需求驱动的，不是技术品味驱动的。
我自己现在接这类任务，第一步不是写解析逻辑，而是先问一句“合出来的文件要拿来干什么”。能忍受从头播到末尾就选 TS，要求剪辑软件能直接拖时间线就强制 MP4 并必须写好 stss 和 ctts。从那以后我每次收到 RTP 合成需求，都强制先在解析流程前面加一段“输出用途确认”，把两轨时长对齐检查和 SPS 缓存检查放在主流程的入口——这些小习惯让我少捡了无数次坑。希望帮到你。
本文还有配套的精品资源，点击获取
