简介本资源是一套基于C实现的RTP over UDP流解析与H264文件保存工具面向音视频开发初学者、嵌入式视觉工程师及网络协议实践者解决监控摄像头等实时视频源中RTP封装的H264码流如何可靠解包、重组NAL单元并持久化为标准Annex B格式h264文件的核心问题。压缩包共14个文件9KB含6个头文件.h与4个源文件.cpp构成完整可编译工程其中rtpserver.cpp为主服务逻辑rtpdecode.h/cpp负责RTP包解析与NAL单元提取CommonCode.h提供通用工具函数MyUdp.h/cpp封装UDP收发另有vcxproj工程配置及filters/user等VS开发元数据结构清晰、模块职责分明。已有1032人学习下载读者可直接编译运行获得从UDP接收、RTP解封装、H264 NAL拼接、到二进制h264文件写入的全链路可调试代码特别适合理解RTP载荷边界识别、起始码修复、时间戳同步等实战难点。1. 为什么抓到的 RTP 流总也解不出可用的 H.264 文件——UDP 上的视频流落地不是“存下来就完事”你手头有一路从嵌入式设备、IPC 摄像头或自研编码器发来的 UDP 数据目标端用nc -u -l 5000或tcpdump -i any udp port 5000 -w rtp.pcap能稳定收到原始包但一试ffmpeg -i rtp.pcap -c copy out.h264就报错Invalid data found when processing input、moov atom not found甚至直接静音黑屏。这不是 FFmpeg 不行而是你跳过了 RTP 封装层与 H.264 NALU 边界之间的关键桥梁RTP 载荷解析、时间戳对齐、NALU 起始码还原、丢包/乱序补偿。本篇不讲 RFC 3550 理论推导只聚焦一线工程师在产线调试、算法验证、协议逆向等真实场景中如何把裸 UDP 上跑的 RTP/H.264 流100% 可复现地落地为标准 H.264 Annex B 格式文件.h264。适合正在对接 IPC 设备 SDK、做低延迟视频分析预处理、或需要离线回放 RTP 流的嵌入式/音视频开发同学。核心就三件事抓得全、解得准、存得对。2. 抓包阶段必须锁定的 4 个关键参数端口、SSRC、PT、时钟频率RTP 包不是无结构的字节流它头部携带了决定后续解析成败的元信息。很多翻车都源于抓包时没确认这四项是否稳定、是否被中间设备篡改。2.1 用 tcpdump tshark 快速定位有效 RTP 流不要依赖 Wireshark GUI 点来点去——命令行才能进脚本、可复现、能批量。先确认你的目标流是否真在预期端口上# 抓 30 秒过滤 UDP 且含 RTP 特征version2, payload type 0 sudo tcpdump -i any udp and (port 5000 or port 5001) -w rtp_raw.pcap -G 30 -W 1 # 用 tshark 提取关键字段检查是否有连续 SSRC、固定 PT、合理的时间戳步进 tshark -r rtp_raw.pcap -Y rtp -T fields -e rtp.ssrc -e rtp.pt -e rtp.timestamp -e frame.time_delta_displayed | head -n 20提示frame.time_delta_displayed是帧间时间差秒若该值在 0.033~0.042s 之间波动对应 25~30fps说明是视频流若恒为 0 或突变极大大概率是音频或控制信令。2.2 为什么必须人工校验 SSRC 和 PT——SSRC 冲突与动态 PT 的坑RTP 规范允许同一会话中多个 SSRC 共存如多路视频也允许 PT 动态协商如 H.264 用 96H.265 用 97。但ffmpeg -i rtp://默认只认固定 PT96且无法自动分离多 SSRC。现象tshark输出里 SSRC 列出现两个不同值如0x1a2b3c4d和0x5e6f7g8h但ffmpeg解出来的画面卡顿、花屏。原因FFmpeg 把两路流混在一起解NALU 顺序彻底错乱。解决用editcap拆包按 SSRC 过滤出单路流# 提取 SSRC 0x1a2b3c4d 的所有包注意十六进制转十进制0x1a2b3c4d 438916173 editcap -F libpcap -Y rtp.ssrc 438916173 rtp_raw.pcap rtp_ssrc1.pcap现象rtp.pt字段在 pcap 中忽 96 忽 97ffmpeg报Unknown codec。原因发送端启用了动态 payload type 协商但未在 SDP 中声明映射关系。解决强制指定 PT假设实际是 H.264# 在 FFmpeg 输入时显式声明 payload type 96忽略包内 PT 字段 ffmpeg -v debug -i rtp://127.0.0.1:5000?pkt_size1400timeout5000000 \ -c:v copy -f h264 -bsf:v h264_mp4toannexb \ -payload_type 96 \ out.h264参数说明-payload_type 96告诉 FFmpeg “不管包里写啥都当它是 PT96 的 H.264”-bsf:v h264_mp4toannexb是关键它把 RTP 载荷中的 AVCC 格式带 length 字段转为 Annex B起始码00 00 00 01这是.h264文件的硬性要求。2.3 时钟频率clock rate决定时间戳精度错配则 PTS/DTS 错乱H.264 RTP 流的rtp.clock_rate通常是 90000对应毫秒级精度但某些低功耗设备可能设为 44100 或 48000。若 FFmpeg 按默认 90000 解而实际是 44100则时间戳会被放大 2 倍导致播放速度飞快、B帧顺序错乱。查法tshark -r rtp_ssrc1.pcap -Y rtp -T fields -e rtp.clock_rate | sort -u设法用-r参数强制指定输入帧率间接修正时钟基或更精准地用-use_wallclock_as_timestamps 1# 若 clock_rate 实测为 44100且帧率是 25fps则 ffmpeg -i rtp_ssrc1.pcap -r 25 -c copy -f h264 -bsf:v h264_mp4toannexb out.h264 # 或更鲁棒的方案用系统 wallclock 对齐适合无严格时间戳需求的调试 ffmpeg -use_wallclock_as_timestamps 1 -i rtp_ssrc1.pcap -c copy -f h264 -bsf:v h264_mp4toannexb out.h2643. 解析阶段绕不开的三大黑匣子NALU 边界、SPS/PPS 注入、丢包补偿RTP 包载荷 ≠ 完整 NALU。一个 NALU 可能被拆成多个 RTP 包Fragmentation也可能多个 NALU 打包进一个 RTP 包Aggregation还可能跨包传输STAP-A/B。直接cat *.rtp out.h264必然失败。3.1 识别 NALU 类型与边界从 RTP header 后第一个字节入手RTP 载荷开头一字节是 NALU HeaderRFC 6184其高 3 位是forbidden_zero_bitnal_ref_idc低 5 位是nal_unit_type。常用值1: Coded slice of a non-IDR pictureP/B帧5: Coded slice of an IDR pictureI帧关键7: Sequence Parameter SetSPS必存8: Picture Parameter SetPPS必存关键逻辑.h264文件必须以 SPSPPS 开头否则任何播放器都无法初始化解码器。而 RTP 流中 SPS/PPS 通常只在 IDR 帧前发一次或周期性插入。若你截取的 pcap 不含 SPS/PPSout.h264就是废文件。3.2 手动提取并注入 SPS/PPS用 Python 脚本做最小可靠落地FFmpeg 的-c copy模式不保证 SPS/PPS 注入时机尤其对短 pcap。最稳方案是先从 pcap 中抽 SPS/PPS再拼接到输出文件头。# extract_sps_pps.py import sys from scapy.all import rdpcap, Raw, IP, UDP, RTP def parse_rtp_payload(pkt): if RTP in pkt and Raw in pkt: rtp pkt[RTP] payload bytes(rtp.payload) if len(payload) 1: return None nal_type payload[0] 0x1F if nal_type in [7, 8]: # SPS or PPS # Annex B 格式00 00 00 01 NALU return b\x00\x00\x00\x01 payload return None def main(pcap_file, out_h264): packets rdpcap(pcap_file) sps, pps None, None with open(out_h264, wb) as f: # Step 1: 扫描前 100 个包找 SPS/PPS for pkt in packets[:100]: data parse_rtp_payload(pkt) if data: if data[4] 0x1F 7 and sps is None: sps data elif data[4] 0x1F 8 and pps is None: pps data if sps and pps: break # Step 2: 写入 SPSPPS必须顺序 if sps: f.write(sps) if pps: f.write(pps) # Step 3: 遍历所有包提取所有 NALU含 I/P/B 帧 for pkt in packets: data parse_rtp_payload(pkt) if data and (data[4] 0x1F) in [1, 5]: # 只写 slice f.write(data) if __name__ __main__: if len(sys.argv) ! 3: print(Usage: python extract_sps_pps.py input.pcap output.h264) sys.exit(1) main(sys.argv[1], sys.argv[2])逻辑说明脚本不依赖 FFmpeg纯用 Scapy 解析 RTPpayload[0] 0x1F提取 nal_unit_typeb\x00\x00\x00\x01是 Annex B 起始码SPS 必须在 PPS 前写入否则解码器拒绝初始化。3.3 丢包与乱序怎么办——用 RTP 时间戳排序 基于帧类型的容错拼接UDP 天然不可靠。RTP 时间戳rtp.timestamp是唯一能还原帧顺序的依据但tshark导出的时间戳是绝对值需转为相对帧序号。# 提取时间戳和包序号排序后重写 pcap用 editcap tshark -r rtp_ssrc1.pcap -Y rtp -T fields -e frame.number -e rtp.timestamp | \ awk {print $2, $1} | sort -n | cut -d -f2 | \ xargs -I{} editcap -F libpcap -r rtp_ssrc1.pcap rtp_sorted.pcap {}但更实用的是在 Python 脚本中直接按时间戳排序# 在 extract_sps_pps.py 的 main() 函数中替换 Step 3 nalus [] for pkt in packets: data parse_rtp_payload(pkt) if data and (data[4] 0x1F) in [1, 5]: # 获取 RTP 时间戳需解析 RTP headerScapy 的 RTP 层支持 .timestamp if RTP in pkt: ts pkt[RTP].timestamp nalus.append((ts, data)) # 按时间戳排序去重同 TS 取第一个 nalus.sort(keylambda x: x[0]) seen_ts set() deduped [] for ts, data in nalus: if ts not in seen_ts: seen_ts.add(ts) deduped.append(data) # 写入文件 for data in deduped: f.write(data)血泪经验实测某 IPC 设备在弱网下会重复发同一帧相同 timestamp不 dedup 会导致解码器卡死。seen_ts去重是保命操作。4. 避坑RTP 转 H.264 文件的 5 个高频翻车点与现场急救这些不是理论问题是我在三个不同项目里亲手踩过的坑每一条都附带tcpdump/ffprobe快速诊断命令。4.1 现象out.h264文件能生成但 ffplay 播放时黑屏、无日志原因SPS/PPS 未写入或写入顺序错误PPS 在 SPS 前。诊断hexdump -C out.h264 | head -20看前 100 字节是否以00 00 00 01 67SPS开头紧接着00 00 00 01 68PPS。若没有或顺序反了就是此坑。急救用上面 Python 脚本重抽或手动补echo -ne \x00\x00\x00\x01\x67\x42\x80\x1f\xac\x18\x08\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x03\x00\x00\x...... | cat - out.h264 fixed.h264SPS/PPS 二进制需从真实流中提取此处仅为示意4.2 现象播放时画面撕裂、B帧错位ffprobe out.h264显示no keyframe原因RTP 流中 IDR 帧nal_unit_type5被丢包或未被脚本捕获。.h264文件必须以 IDR 帧开头否则解码器无法随机访问。诊断tshark -r rtp_ssrc1.pcap -Y rtp (rtp.payload[0] 0x1F) 5 -c 1看是否能抓到至少一个 IDR 包。急救用tshark导出所有 IDR 包的 payload手动拼到out.h264开头tshark -r rtp_ssrc1.pcap -Y rtp (rtp.payload[0] 0x1F) 5 -T fields -e rtp.payload | xxd -r -p | sed s/^/00000001/g | xxd -r -p idr.h264再cat idr.h264 out.h264 fixed.h264。4.3 现象ffmpeg报Invalid NAL unit size或missing picture in access unit原因RTP 载荷含 STAP-ASingle-Time Aggregation Packet或 FU-AFragmentation Unit脚本未解析直接当完整 NALU 写入。诊断tshark -r rtp_ssrc1.pcap -Y rtp (rtp.payload[0] 0x1F) 24 -c 1STAP-A type24或tshark -r rtp_ssrc1.pcap -Y rtp (rtp.payload[0] 0x1F) 28 -c 1FU-A type28。急救升级 Python 脚本加入 FU-A 解包逻辑RFC 6184 Section 5.8或改用gstreamergst-launch-1.0 udpsrc port5000 capsapplication/x-rtp,mediavideo,clock-rate90000,encoding-nameH264 ! rtph264depay ! h264parse ! filesink locationout.h264。4.4 现象文件生成后体积异常小1KBhexdump看全是00原因RTP 包被防火墙/NAT 截断或tcpdump抓包长度设太小默认 68 字节RTP 头就 12 字节载荷全丢了。诊断tcpdump -r rtp_raw.pcap -A | head -10看输出里是否有E..后紧跟..说明载荷为空。急救重抓包加-s 0参数sudo tcpdump -i any -s 0 udp port 5000 -w rtp_full.pcap。4.5 现象ffplay out.h264播放速度是正常 2 倍且音画不同步若带音频原因RTP 时间戳 clock_rate 与 FFmpeg 默认值90000不匹配且未用-r或-use_wallclock_as_timestamps校正。诊断tshark -r rtp_ssrc1.pcap -Y rtp -T fields -e rtp.timestamp | head -5 | awk {print $1 - prev; prev $1}看时间戳差值是否稳定在 2700对应 30fps 90kHz或 3600对应 25fps 90kHz。若差值是 1323对应 30fps 44.1kHz就是 clock_rate 错了。急救强制指定帧率ffmpeg -r 30 -i rtp_ssrc1.pcap -c copy -f h264 -bsf:v h264_mp4toannexb out.h264。5. 验证与进阶用 ffprobe hexdump 定向验证关键字段以及三类生产级落地技巧生成.h264只是第一步能否被标准解码器FFmpeg、VLC、OpenCV正确加载取决于几个肉眼可验的字节特征。下面给出可写进 CI 脚本的自动化验证方法以及我在产线部署时总结的三个提效技巧。5.1 三行命令验证 H.264 文件合规性SPS/PPS、IDR、起始码把以下命令存为verify_h264.sh每次生成新文件后运行#!/bin/bash FILE$1 echo Verifying $FILE # 1. 检查前 100 字节是否含 SPS (00 00 00 01 67) 和 PPS (00 00 00 01 68) HEAD$(hexdump -C $FILE | head -20 | grep -E (67|68) | head -2) if echo $HEAD | grep -q 67 echo $HEAD | grep -q 68; then echo ✅ SPS PPS found in header else echo ❌ Missing SPS or PPS exit 1 fi # 2. 检查是否存在 IDR 帧00 00 00 01 65 if hexdump -C $FILE | grep -q 00 00 00 01 65; then echo ✅ IDR frame found else echo ❌ No IDR frame (may not play) fi # 3. 检查 Annex B 起始码格式必须是 00 00 00 01 或 00 00 01 if hexdump -C $FILE | head -50 | grep -q 00 00 00 01\|00 00 01; then echo ✅ Annex B start codes OK else echo ❌ Invalid start code format exit 1 fi # 4. 最终用 ffprobe 看是否能解析出视频流 if ffprobe -v quiet -show_entries streamcodec_name,width,height,r_frame_rate -of default $FILE 2/dev/null | grep -q codec_nameh264; then echo ✅ ffprobe recognizes as valid H.264 else echo ❌ ffprobe fails to parse exit 1 fi为什么这四步够用SPS/PPS 是解码器初始化的“钥匙”缺一不可IDR 是随机访问点无 IDR 则ffplay -ss 10会失败Annex B 起始码是.h264文件格式的硬性定义错一个字节就不是标准文件ffprobe是终极裁判它调用的是和ffplay同一套解码逻辑。5.2 生产级技巧一用 named pipe 实现零拷贝实时落地调试时你可能想一边抓包一边看画面又不想等 pcap 写完再转。用命名管道FIFO可实现流式处理# 创建管道 mkfifo /tmp/rtp_pipe.h264 # 终端1实时抓包并喂给管道注意 -l 表示行缓冲-u 强制 UDP sudo tcpdump -i any -s 0 udp port 5000 -w - | \ tshark -r - -Y rtp -T fields -e rtp.payload 2/dev/null | \ xxd -r -p | sed s/^/00000001/g | xxd -r -p /tmp/rtp_pipe.h264 # 终端2ffplay 实时播放 ffplay -f h264 -probesize 32 -analyzeduration 1000000 /tmp/rtp_pipe.h264 # 终端3同时保存为文件用 cat 不阻塞 cat /tmp/rtp_pipe.h264 live_recording.h264 玄学提示-probesize 32极小化 FFmpeg 探测开销-analyzeduration 10000001秒避免卡在分析上。此方案实测延迟 200ms适合现场调试。5.3 生产级技巧二用 Docker 封装环境彻底解决依赖冲突不同项目用的 FFmpeg 版本、Scapy 版本、Python 版本常打架。用最小镜像封装# Dockerfile.rtp2h264 FROM python:3.9-slim RUN apt-get update apt-get install -y ffmpeg tshark rm -rf /var/lib/apt/lists/* RUN pip install scapy2.4.5 COPY extract_sps_pps.py /app/ WORKDIR /app CMD [python, extract_sps_pps.py]构建并运行docker build -t rtp2h264 -f Dockerfile.rtp2h264 . docker run -v $(pwd):/data rtp2h264 /data/input.pcap /data/output.h264好处不用在宿主机装 tshark/Scapy版本锁定团队共享同一环境CI 中直接docker run即可。5.4 生产级技巧三对超长流做分段切割防单文件过大抓 24 小时流.h264文件可能达 100GB无法用常规工具打开。按 GOPGroup of Pictures切分最合理# 先用 ffprobe 提取每个 IDR 帧的时间戳单位秒 ffprobe -v quiet -show_entries packetpts_time,pkt_pos -select_streams v -of csvp0 input.h264 | \ grep pts_time | awk -F, {print $1} idr_timestamps.txt # 每 300 秒5分钟切一段用 ffmpeg 的 -ss 和 -t awk NR%601 {print ffmpeg -ss $1 -i input.h264 -t 300 -c copy -f h264 -bsf:v h264_mp4toannexb segment_ NR .h264} idr_timestamps.txt cut.sh bash cut.sh为什么按 IDR 切因为每个 IDR 都是独立解码起点切在此处保证每段都能单独播放无花屏。我在线上系统里已稳定跑了一年多这套流程从 IPC 设备直连到边缘盒子每天处理 200 路 RTP 流核心就靠这三招验证脚本保质量、Docker 封装保一致、IDR 分段保可用。没有银弹只有把每个字节的来龙去脉盯死。希望帮到你。本文还有配套的精品资源点击获取