简介本资源面向音视频开发、流媒体协议学习及嵌入式方向的中级开发者解决从网络RTP数据流中提取H264视频与AAC音频并合成为可播放MP4文件的工程问题。包内共31个文件约197KB以17个C/C头文件为核心涵盖RTP解析、流媒体会话、MP4封装与轨道管理等模块另有2个C源文件、Makefile与工程配置文件负责编译构建并附带SDP会话描述、测试MP4及示例输入便于快速验证。已有486人学习下载。读者可借此理解RTP载荷解析、H264与AAC时间戳对齐、MP4容器封装及工程组织方式获得一套可直接编译调试的参考实现适合作为流媒体合成入门的实践素材。1. 为什么 RTP 流落成 MP4 会翻车时间戳才是那个隐藏的坑很多人第一次做 RTP 转 MP4都会觉得这事不难把 H264 和 AAC 的裸数据从 RTP 包里剥出来塞进 MP4 的 box 里不就完了结果一跑就翻车——播放器要么花屏要么音画不同步要么干脆只认第一帧。问题几乎从来不在“拆包”上而在时间戳。RTP 的 RTP Timestamp 是一个随机的 32 位基准值采样率不同、时钟频率不同H264 是 90000HzAAC 常见是 44100Hz 或 48000Hz而 MP4 要的是以 timescale 为单位的、从 0 开始的、单调递增的 DTS/PTS。这中间的换算、回绕处理、B 帧重排序才是真正决定成败的底层机制。搞懂它你才能明白为什么“能播”和“播得对”之间隔着一整套时间基转换逻辑。2. RTP 拆包与 NAL 重组从乱序包到完整帧的还原机制2.1 RTP 头部字段到底哪些必须留RTP 包不是把数据一裹就完事它的头部里藏着后续所有时间计算的原料。固定头 12 字节里跟合成 MP4 强相关的有四个字段Sequence Number16 位用于排序和丢包检测、Timestamp32 位同一帧的所有分片共享同一个值、Marker Bit标记一帧的最后一个包、Payload Type区分 H264 和 AAC。很多实现只取 payload 丢掉头部后面做时间基转换时才发现无从下手只能靠猜帧率这就是典型的血泪经验。常见的实现思路是先按 SSRC 分组因为一个 RTP 会话里可能混着多路流再按 Payload Type 分流到 H264 队列和 AAC 队列。Sequence Number 用来做重排序缓冲因为 UDP 传输下包到达顺序不保证。Timestamp 则作为“帧归属”的唯一依据——同一个 Timestamp 的多个 RTP 包属于同一帧Marker Bit 为 1 的那个包标志该帧结束。2.2 H264 的 FU-A 与 STAP-A 分片重组H264 over RTP 有两种最常见的打包模式。小 NAL 单元用 STAP-ASingle-Time Aggregation Packet一个 RTP 包里塞多个完整 NAL大 NAL 单元用 FU-AFragmentation Unit一个 NAL 被切成多个 RTP 包。重组逻辑的核心是看 NAL 头后的第一个字节# 判断 FU-A 分片并重组完整 NAL 单元 def reassemble_fu_a(packets): nal_buffer b for pkt in packets: payload pkt.payload fu_indicator payload[0] fu_header payload[1] start_bit (fu_header 7) 0x01 # 分片起始 end_bit (fu_header 6) 0x01 # 分片结束 nal_type fu_header 0x1F if start_bit: # 用 FU indicator 的 F 和 NRI 加上原始 NAL type 重建 NAL 头 nal_header bytes([(fu_indicator 0xE0) | nal_type]) nal_buffer nal_header payload[2:] else: nal_buffer payload[2:] if end_bit: yield nal_buffer nal_buffer b这段逻辑里fu_indicator 0xE0保留的是 forbidden_zero_bit 和 nal_ref_idcnal_type来自 FU header 的低 5 位。重建出来的 NAL 头必须和原始编码器输出完全一致否则解码器会直接报错。STAP-A 则简单得多payload 第一个字节后跟着若干「2 字节长度 NAL 数据」的单元循环切出来即可。2.3 AAC 的 AU Header 与多帧聚合AAC over RTP 的打包方式由 SDP 里的sizelength、indexlength、indexdeltalength三个参数决定。最常见的是每个 RTP 包带一个 AU Header Section里面用sizelength位描述后面每个 AAC 帧的长度。如果sizelength13那每 13 位就是一个 AU 的大小。解析时先读 AU-headers-length16 位单位是 bit再按这个长度切出 AU Header最后按每个 AU 的长度从 payload 里切出裸 AAC 帧。这里最容易踩的坑是 bit 对齐——AU Header 不是字节对齐的必须用位操作读取直接按字节切会错位。3. 时间基转换RTP Timestamp 到 MP4 时间轴的映射原理3.1 为什么不能直接用 RTP Timestamp 当 PTSRTP Timestamp 的初始值是随机的这是协议规定的目的是防止明文攻击和流同步猜测。它还是个 32 位无符号数会回绕。而 MP4 的 stts box 要求每个 sample 的时长是正整数且 DTS 从 0 开始单调递增。直接把 RTP Timestamp 填进去播放器会看到巨大的初始偏移和周期性的时间跳变表现就是音画不同步或者播放卡顿。正确的做法是以第一个包的 RTP Timestamp 为基准后续每个帧的时间戳减去基准值得到相对时间差再按MP4_timescale / RTP_clock_rate的比例换算成 MP4 时间单位。H264 的 clock rate 固定 90000AAC 的 clock rate 等于采样率。MP4 的 timescale 可以自选视频常用 90000 或 1000音频直接用采样率最省事。3.2 回绕处理与单调性保证32 位 Timestamp 在 90000Hz 下大约 13 小时回绕一次长时间录制必然遇到。处理方式是维护一个 64 位的扩展时间戳每次新时间戳比上一个小于某个阈值比如 2^31就认为发生了回绕高位加一。class TimestampUnwrapper: def __init__(self): self.last_raw None self.epoch 0 def unwrap(self, raw_ts): if self.last_raw is None: self.last_raw raw_ts return raw_ts # 回绕判定新值远小于旧值认为跨过了 2^32 if raw_ts self.last_raw and (self.last_raw - raw_ts) (1 31): self.epoch 1 self.last_raw raw_ts return raw_ts (self.epoch 32)展开后的 64 位时间戳再减去起始基准就能得到单调递增的相对时间。注意音频和视频要各自维护独立的 unwrapper因为两路的起始基准和时钟频率都不同。3.3 音视频对齐谁的时间轴说了算音视频同步的本质是让两路 PTS 在同一个时间基下对齐。常见做法是选一个主时间基比如都用 90000音频的 PTS 按audio_ts * 90000 / sample_rate换算。但这里有个精度陷阱44100 和 90000 不是整数倍关系换算会产生累积误差。更稳的方案是视频用 90000音频用采样率作为 timescaleMP4 的 mvhd 里记录各自的 timescale播放器会自动做归一化。这样避免了手动换算的舍入误差也是大多数封装库的实际选择。4. MP4 封装stts、stss、ctts 三个 box 如何决定可播性4.1 stts 与帧时长的离散化sttsTime-to-Samplebox 存的是一组「sample_count sample_delta」的游程编码。如果所有帧时长一致就只有一个条目如果帧率浮动就要按实际间隔分组。这里的关键是sample_delta 必须是整数而 RTP 时间戳换算后可能得到小数。处理方式是把 timescale 设得足够大比如 90000让舍入误差小到可忽略。如果 timescale 太小比如用 1000那 30fps 下每帧 33.33 只能取 33 或 34累积几秒就会明显偏。4.2 stss 与关键帧索引stssSync Samplebox 记录哪些 sample 是关键帧IDR。没有这个 box播放器会认为所有帧都是关键帧拖进度条时可能从非 IDR 帧开始解码直接花屏。构建时遍历 NAL 单元遇到 nal_type 为 5IDR或 7SPS、8PPS的帧就记录其 sample 序号。注意 SPS/PPS 通常要单独提取出来放进 avcC box而不是留在样本数据里。4.3 ctts 与 B 帧的显示顺序如果编码器开了 B 帧DTS 和 PTS 就不相等。cttsComposition Time-to-Samplebox 存的是 PTS 减 DTS 的偏移量。RTP 的 Timestamp 对应的是 PTS而解码顺序需要从 NAL 的 slice header 里解析 pic_order_cnt 来推导。很多简易实现直接忽略 ctts把 PTS 当 DTS 用结果就是 B 帧画面顺序错乱表现为快速运动场景下的画面撕裂或回跳。如果不想处理 B 帧编码时关掉 B 帧是最省事的规避方式但会牺牲一点压缩率。# 构建 avcC box 的核心字段 def build_avcC(sps_list, pps_list): # configurationVersion 固定为 1 # AVCProfileIndication 来自 SPS[1] # profile_compatibility 来自 SPS[2] # AVCLevelIndication 来自 SPS[3] # lengthSizeMinusOne 通常为 3表示 4 字节长度前缀 avcC bytes([1, sps_list[0][1], sps_list[0][2], sps_list[0][3], 0xFF]) avcC bytes([0xE1]) len(sps_list).to_bytes(2, big) for sps in sps_list: avcC len(sps).to_bytes(2, big) sps avcC bytes([len(pps_list)]) for pps in pps_list: avcC len(pps).to_bytes(2, big) pps return avcClengthSizeMinusOne设为 3 意味着每个 NAL 单元前有 4 字节的长度前缀这是 MP4 样本数据的标准格式和 RTP 里的起始码格式不同封装时必须做转换。5. 避坑与排查RTP 转 MP4 最常见的五类翻车5.1 现象播放器只播第一帧就停原因通常是 stts 里所有 sample_delta 都是 0或者 moov box 里 mvhd 的 duration 为 0。检查时间基换算时是否把 RTP Timestamp 直接减基准后忘了乘比例因子导致所有帧时长算出来都是 0。解决方式是打印前 10 帧的原始时间戳和换算后时长确认差值非零且递增。5.2 现象音频正常但视频花屏多半是 NAL 重组时 FU-A 的起始分片丢了或者 SPS/PPS 没有正确写入 avcC。排查时把重组后的 NAL 单元 dump 出来用工具检查第一个 NAL 是不是 SPSnal_type7第二个是不是 PPSnal_type8。如果 SPS/PPS 出现在样本数据里而不是 avcC 里部分播放器会拒绝解码。5.3 现象音画逐渐不同步越播越偏这是时间基换算的累积误差。检查音频和视频是否用了同一个 timescale 做手动换算。如果音频 44100 换算到 90000 时每帧都舍入几分钟后就会偏出几百毫秒。解决方式是让音频保持采样率作为 timescale不要强行统一。5.4 现象拖进度条后画面卡死stss box 缺失或关键帧索引错误。用工具查看 stss 的条目数如果为 0 或者远少于实际 IDR 帧数量说明关键帧检测逻辑有问题。注意 IDR 帧的 nal_type 是 5但有些编码器会把 SPS/PPS 和 IDR 打包在同一个 RTP 时间戳里需要把整个访问单元标记为关键帧。5.5 现象长时间录制后时间戳跳变32 位 RTP Timestamp 回绕没有处理。检查 unwrapper 的回绕阈值是否设成了 2^31。如果阈值太小正常的大间隔帧会被误判为回绕如果太大回绕时又检测不到。90000Hz 下2^31 约等于 6.6 小时正常帧间隔远小于这个值所以用 2^31 作为阈值是安全的。6. 设计取舍为什么没有一种封装方案能通吃所有场景做 RTP 转 MP4 的封装本质上是在三个约束之间找平衡实时性、兼容性、存储效率。实时性要求尽快落盘就不能等太久做重排序兼容性要求覆盖各种播放器就得把 moov box 放在文件头部但这需要预先知道所有帧的元信息存储效率要求时间基尽量小以减少整数位宽但小时间基又会放大舍入误差。常见的实现思路有两种。一种是「先缓存后写」把整段流的所有帧先收完构建完整的 sample table再一次性写 moov 和 mdat。这种方式兼容性最好但内存占用高不适合长时间录制。另一种是「边收边写」先写 mdat最后再回填 moov或者用 fragmented MP4 格式把 moov 拆成多个 moof。fragmented MP4 适合流式场景但部分老播放器支持不好。我一般会这么理解如果目标是本地存档、对兼容性要求高就选先缓存后写并且把 timescale 设成 90000视频和采样率音频B 帧要么关掉要么老老实实算 ctts。如果目标是实时预览或直播录制就用 fragmented MP4牺牲一点兼容性换低延迟。没有银弹只有对场景的取舍。从那以后我每次做封装都会先把前 100 帧的 DTS、PTS、sample_delta 打印出来确认时间轴单调且间隔合理再去看播放器表现。这个习惯帮我省掉了大量靠猜来定位问题的时间。希望帮到你。本文还有配套的精品资源点击获取