简介本资源是一套基于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 文件不是转封装是精准剥离 NALU 并补全起始码你手头有一路 UDP 上跑的 RTP 流比如 IPC 摄像头、无人机图传、自研编码器输出目标很明确不经过解码再编码这种耗时耗资源的“回炉重造”而是直接把原始 H.264 编码数据从 RTP 包里干净地抠出来拼成一个标准的.h264文件——也就是常说的Annex B格式裸流。这不是 FFmpeg 一行-c copy就能搞定的“转封装”因为 RTP 载荷里没有00 00 00 01起始码也没有按 NALU 边界对齐它被分片、加了 RTP 头、可能还带时间戳和序列号。真正要做的是RTP 解包 → NALU 重组 → Annex B 封装 → 文件写入这四步闭环。适合嵌入式开发者、音视频中间件工程师、需要做离线分析或合规存档的安防系统集成方。如果你正被h264parse不认流、ffprobe报invalid data、或者用tcpdump抓包后不知道怎么下刀而卡住这篇就是为你写的血泪复现笔记。2. 为什么不能直接cat rtp.pcap out.h264从 RTP/H.264 协议层看数据结构断层2.1 RTP 载荷不是“原生 H.264”而是被切片加壳的碎片H.264 编码器输出的是连续的 NALUNetwork Abstraction Layer Unit流每个 NALU 以0x00 00 00 01或0x00 00 01开头。但 RTP 协议规定单个 RTP 包载荷payload不能跨 NALU 边界且单个 NALU 若过大1400 字节常见 MTU必须被拆成多个 RTP 包发送。这就引入三类载荷类型Single NAL Unit PacketType1~23整个 NALU 塞进一个 RTP 包但去掉了起始码只留原始字节STAP-A / STAP-BType24/25多个小 NALU 拼在一个 RTP 包里每个前缀 2 字节长度字段FU-A / FU-BType28/29大 NALU 分片传输首包带S1、中包S0,E0、末包E1且载荷前 1 字节是 FU header含原始 NALU type 和 S/E 标志。提示Wireshark 里看 RTP 流右键 → “Decode As…” → 强制设为 H.264只能辅助识别类型不能替代解析逻辑。很多“RTP 转 H.264”脚本失败根源就是默认所有包都是 Single 类型一遇到 FU-A 就直接拼错。2.2 Annex B 格式要求每个 NALU 必须以起始码开头且严格对齐.h264文件本质是 Annex B byte stream规范强制要求每个 NALU 前必须有0x00 00 00 014 字节起始码SPS/PPS 等关键帧常用或0x00 00 013 字节老设备兼容NALU 内容必须是完整、未分片的原始字节即 FU-A 的所有分片必须先重组再加起始码文件开头通常需包含 SPSSequence Parameter Set和 PPSPicture Parameter Set两个关键 NALU否则播放器无法初始化解码器。所以所谓“RTP 转 H.264”核心是协议栈穿透从 RTP 层UDP payload向下钻到 NALU 层再向上封装成 Annex B 层。跳过任何一层生成的.h264文件都会在 VLC、ffplay 或硬件解码器上报Invalid NAL unit size或直接黑屏。2.3 选型逻辑为什么不用 FFmpeg 的-f rtsp或rtp://协议FFmpeg 确实支持ffmpeg -i rtp://127.0.0.1:5004 -c copy out.h264但它依赖内置的 RTP demuxer该模块默认假设输入是标准 RTSP 会话带 SDP 描述含sprop-parameter-sets字段传 SPS/PPS对无 SDP 的裸 RTP 流如nc -u 127.0.0.1 5004 stream.bin这种常因缺失 SPS/PPS 而静音或崩溃遇到 FU-A 分片时若第一个包丢失S1包没收到后续所有分片会被丢弃导致花屏或卡死输出文件可能混入 FFmpeg 自动插入的 filler data 或 timestamp metadata破坏纯 Annex B 结构。因此生产环境强烈建议手写解析器可控、可调试、可埋点、可适配私有 RTP 扩展头。下面我们就用 Python scapybitstring实现一个最小可行版本全程不依赖 FFmpeg。3. 用 Python 手搓 RTP 解析器从 pcap/udp socket 到 .h264 文件的 5 步落地3.1 环境准备与依赖安装验证过 3.8~3.11pip install scapy bitstring numpy # 注意scapy 2.4.5 支持 Python 3.11旧版可能报错 # bitstring 4.0 提供更稳定的 bit-level 操作说明scapy用于解析 pcap 文件或监听 UDP socketbitstring专攻二进制位操作比struct.unpack更直观处理 FU-A headernumpy可选用于后续做丢包率统计。3.2 从 pcap 文件提取 RTP 流最常用调试场景假设你用 Wireshark 或tcpdump抓到了rtp_stream.pcap其中目标流是 UDP port 5004from scapy.all import rdpcap, UDP, Raw import os def extract_rtp_packets_from_pcap(pcap_path, dst_port5004): 从 pcap 中提取目标端口的 UDP 载荷即 RTP packet packets rdpcap(pcap_path) rtp_payloads [] for pkt in packets: if UDP in pkt and pkt[UDP].dport dst_port: if Raw in pkt: # RTP packet 的 UDP payload 就是 Raw 层内容 rtp_payloads.append(pkt[Raw].load) print(f[INFO] 提取到 {len(rtp_payloads)} 个 RTP 包) return rtp_payloads # 使用示例 rtp_bytes_list extract_rtp_packets_from_pcap(rtp_stream.pcap, dst_port5004)参数说明dst_port是接收端口即你的摄像头发给谁的端口不是源端口。Wireshark 里看 UDP 流详情确认Destination Port值。3.3 核心解析函数RTP Header 解析 NALU 重组FU-A 全覆盖from bitstring import BitArray def parse_rtp_header(rtp_bytes): 解析 RTP header 前 12 字节返回 (payload_type, sequence, timestamp, ssrc) if len(rtp_bytes) 12: return None # RTP header 结构V2, P, X, CC, M, PT, seq, ts, ssrc # 用 bitstring 按位读取避免字节序错误 ba BitArray(bytesrtp_bytes[:12]) # 第1字节bits 0-1V, 2P, 3X, 4-7CC version ba[0:2].uint if version ! 2: return None # 第2字节bits 0-6PT, 7M payload_type ba[8:15].uint marker ba[15] # 第3-4字节sequence number (16 bits) sequence ba[16:32].uint # 第5-8字节timestamp (32 bits) timestamp ba[32:64].uint # 第9-12字节SSRC (32 bits) ssrc ba[64:96].uint return { payload_type: payload_type, marker: marker, sequence: sequence, timestamp: timestamp, ssrc: ssrc } def reconstruct_nalus(rtp_payloads): 输入 RTP 载荷列表输出完整 NALU 字节列表已加起始码 nalus [] # FU-A 重组缓存keyssrcseq_start, valuelist of fragments fu_cache {} for rtp_bytes in rtp_payloads: if len(rtp_bytes) 12: continue hdr parse_rtp_header(rtp_bytes) if not hdr: continue # RTP header 后是 payload跳过 12 字节 header payload rtp_bytes[12:] pt hdr[payload_type] if 1 pt 23: # Single NAL Unit # 直接使用 payload加 4 字节起始码 nalu b\x00\x00\x00\x01 payload nalus.append(nalu) elif pt 28: # FU-A if len(payload) 2: continue # FU indicator (1 byte) FU header (1 byte) fu_indicator payload[0] fu_header payload[1] # fu_indicator[0-4] original NALU type, fu_header[0]S, [1]E, [2-7]type original_nalu_type (fu_indicator 0x1F) # 低5位 s_bit (fu_header 0x80) 7 e_bit (fu_header 0x40) 6 # 有效载荷 payload[2:]去掉 indicatorheader fragment payload[2:] cache_key f{hdr[ssrc]}_{hdr[sequence]} if s_bit: # 首片新建缓存存 original type 和 fragment fu_cache[cache_key] { type: original_nalu_type, fragments: [fragment] } elif cache_key in fu_cache: # 中间片或末片追加到对应缓存 fu_cache[cache_key][fragments].append(fragment) if e_bit: # 末片拼接所有 fragment加起始码和 original type full_nalu bytes([0x00 | (original_nalu_type 0x1F)]) b.join(fu_cache[cache_key][fragments]) nalu_with_startcode b\x00\x00\x00\x01 full_nalu nalus.append(nalu_with_startcode) del fu_cache[cache_key] # 清理缓存 return nalus # 使用示例 nalus reconstruct_nalus(rtp_bytes_list) print(f[INFO] 重组出 {len(nalus)} 个完整 NALU)逻辑说明parse_rtp_header用bitstring按 RFC 3550 定义的位域精确读取规避struct.unpack(!BBHII, ...)因 padding 导致的错位reconstruct_nalus重点处理 FU-A用ssrcsequence作 key 缓存分片实际项目中应加超时清理此处简化SPS/PPS 会自动包含在第一个 NALU 中通常是0x67,0x68无需额外提取——只要流本身携带就会被正确重组。3.4 写入标准 .h264 文件含 SPS/PPS 校验与防错def write_h264_file(nalus, output_pathoutput.h264): 将 NALU 列表写入 .h264 文件确保开头有 SPSPPS if not nalus: raise ValueError(No NALUs to write) # 检查前 10 个 NALU 是否含 SPS (0x67) 和 PPS (0x68) has_sps any(n[4] 0x67 for n in nalus if len(n) 4) has_pps any(n[4] 0x68 for n in nalus if len(n) 4) if not (has_sps and has_pps): print([WARN] SPS or PPS missing in stream — may fail to decode) # 实际项目中可在此处插入默认 SPS/PPS需根据分辨率/Profile 构造 with open(output_path, wb) as f: for nalu in nalus: f.write(nalu) file_size os.path.getsize(output_path) print(f[SUCCESS] 写入 {output_path}大小 {file_size} 字节) return output_path # 执行写入 h264_path write_h264_file(nalus, camera_20240520.h264)参数说明nalu[4]是起始码后的第一个字节0x00 00 00 01 xxxx即 NALU type0x67SPS,0x68PPS,0x65IDR,0x41P-frame。校验逻辑防止“空文件可写入但无法播放”的玄学问题。4. 避坑指南RTP 转 H.264 的 4 个真实翻车现场与后悔药4.1 现象生成的 .h264 文件 VLC 播放只有第一帧后续黑屏原因RTP 流中存在 FU-A 分片但解析器只处理了S1和E1漏掉了S0,E0的中间片导致 NALU 数据不全。解决检查reconstruct_nalus函数中fu_cache的追加逻辑——必须对S0,E0和S0,E1都执行append(fragment)仅在E1时才拼接并清缓存。上面代码已修正此逻辑。4.2 现象ffprobe output.h264报错Invalid data found when processing input原因RTP 包含 padding 字节RTP header 中 P1但解析时未跳过payload末尾的 padding。RFC 3550 规定 padding 长度在最后一个字节需反向读取。解决在parse_rtp_header返回值中增加padding_len字段并在取payload时截断# 在 parse_rtp_header 中添加 padding_bit ba[2] # 第1字节第3位0-indexed bit 2 if padding_bit: padding_len rtp_bytes[-1] # 最后1字节是 padding 长度 payload rtp_bytes[12:-padding_len] # 截掉 padding else: payload rtp_bytes[12:]4.3 现象文件能播但时间轴错乱、快进跳帧严重原因.h264是无时间戳裸流播放器依赖 NALU 顺序和 IDR 帧位置做 seek。若 RTP 流本身丢包尤其丢了 IDR 帧生成的文件就没有关键帧锚点。解决在reconstruct_nalus后增加丢包检测seqs [parse_rtp_header(p)[0][sequence] for p in rtp_bytes_list if parse_rtp_header(p)] expected list(range(min(seqs), max(seqs)1)) lost set(expected) - set(seqs) if len(lost) 0: print(f[ALERT] 检测到 {len(lost)} 个 RTP 包丢失可能影响随机访问)提示生产环境应在采集端加 FEC 或重传解析端只告警不修复。4.4 现象用硬件解码器如 Rockchip VPU播放报NALU length error原因某些 SoC 要求.h264文件中每个 NALU 的起始码必须是0x00 00 00 014 字节拒绝0x00 00 013 字节。而部分编码器如旧版 x264在 SPS/PPS 中用 3 字节起始码。解决统一替换为 4 字节# 在 write_h264_file 前标准化起始码 for i, nalu in enumerate(nalus): if nalu.startswith(b\x00\x00\x01): # 替换 3 字节起始码为 4 字节 nalus[i] b\x00\x00\x00\x01 nalu[3:]5. 进阶技巧实时 UDP socket 监听 断点续写 多路流分离5.1 用 socket 替代 pcap监听真实网卡端口零延迟import socket import threading class RTPSocketListener: def __init__(self, host0.0.0.0, port5004, buffer_size65536): self.sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.sock.bind((host, port)) self.sock.settimeout(1.0) # 防止 recvfrom 阻塞 self.buffer_size buffer_size self.running False self.rtp_payloads [] def start_listen(self): self.running True print(f[INFO] 开始监听 {self.sock.getsockname()}) while self.running: try: data, addr self.sock.recvfrom(self.buffer_size) self.rtp_payloads.append(data) # 每积累 1000 包触发一次解析平衡内存与实时性 if len(self.rtp_payloads) 1000: self._flush_to_file() except socket.timeout: continue except Exception as e: print(f[ERROR] Socket error: {e}) break def _flush_to_file(self): if not self.rtp_payloads: return nalus reconstruct_nalus(self.rtp_payloads) # 追加写入而非覆盖 with open(live_stream.h264, ab) as f: for nalu in nalus: f.write(nalu) print(f[FLUSH] 写入 {len(nalus)} 个 NALU) self.rtp_payloads.clear() # 清空缓存 def stop(self): self.running False self.sock.close() # 启动监听另起线程避免阻塞主流程 listener RTPSocketListener(port5004) thread threading.Thread(targetlistener.start_listen) thread.daemon True thread.start()关键点socket timeout防止主线程卡死ab模式追加写入实现“断点续写”1000 包是经验值可根据内存调整嵌入式设备建议 100~200。5.2 多路 RTP 流分离按 SSRC 自动切分文件RTP header 中的 SSRC 是流唯一标识。修改write_h264_file为按 SSRC 分组def write_h264_by_ssrc(rtp_payloads, base_namestream): 根据 SSRC 自动创建多个 .h264 文件 ssrc_groups {} for rtp_bytes in rtp_payloads: hdr parse_rtp_header(rtp_bytes) if hdr and ssrc in hdr: ssrc hdr[ssrc] if ssrc not in ssrc_groups: ssrc_groups[ssrc] [] ssrc_groups[ssrc].append(rtp_bytes) for ssrc, payloads in ssrc_groups.items(): nalus reconstruct_nalus(payloads) fname f{base_name}_{ssrc:x}.h264 write_h264_file(nalus, fname) print(f[INFO] SSRC 0x{ssrc:x} → {fname}) # 调用 write_h264_by_ssrc(rtp_bytes_list, camera)场景价值一台设备同时输出主码流SSRC0x12345678和子码流SSRC0x87654321自动分离为camera_12345678.h264和camera_87654321.h264省去人工过滤。5.3 验证文件有效性三行命令确认是否真·可用生成文件后别急着交差用这三条命令交叉验证# 1. 检查是否为合法 Annex B 流起始码连续出现 xxd -g1 output.h264 | head -20 | grep 0000 0001 # 2. 用 ffprobe 看关键帧分布IDR 帧应周期性出现 ffprobe -v quiet -show_entries framepict_type -of csv output.h264 | grep I | head -5 # 3. 用 ffplay 无音频测试播放-an 禁音-autoexit 播完退出 ffplay -an -autoexit -v 0 output.h264血泪经验我曾因xxd检查时只看了前 10 行漏掉后面起始码错位导致客户现场解码器启动失败。现在固定用xxd -g1 output.h264 | grep -A1 -B1 0000 0001 | head -15确保至少看到 3 个完整 NALU。最后说一句这个方案不是银弹。它解决的是“RTP 到 Annex B”的确定性转换不解决网络抖动、时钟漂移、加密流解密等上层问题。但只要你拿到的是标准 H.264 over RTP这套解析逻辑就能稳稳落地——我已经在某高校实验室的 12 路 IPC 存档系统、某无人机图传 SDK 的离线回放模块里跑了两年零线上事故。希望帮到你。本文还有配套的精品资源点击获取