海康国标GB/T 28181 PS流解析实战：从RTP抓包到H.264/H.265裸流提取

简介：面向音视频开发与流媒体技术人员的实用资源，聚焦海康威视设备及国标PS流（Program Stream）解析，提供基于ffmpeg的解封装实现与不依赖第三方库的直接解析两种方案。前者适合快速集成与多格式兼容，后者可深入理解PS流结构、PTS/DTS时间戳提取及音视频数据包分离逻辑。资源共27个文件，以C++源码为主，含6个cpp源文件和5个头文件，另有Visual Studio工程文件（sln、vcxproj）便于直接打开编译调试，压缩包仅2.24MB，体量轻巧。已有1095人学习，适合希望从代码层面掌握PS流解复用的开发者。压缩包内两个独立版本目录结构清晰，可直接对比实现差异，也可作为二次开发或项目移植的参考基础。 做国标GB/T 28181接入这几年，我收到过好几份名为“海康、国标ps流解析”的压缩包，打开之后基本是同一类东西：一两段信令抓包、几段PS流二进制样本、外加各路网友写的解析代码。说白了，凡是需要把海康摄像头接入自建视频平台的人，最后几乎都会撞上同一个坎——信令通了、设备上线了、INVITE也发出去了，但视频流就是黑屏。这问题九成出在PS流（Program Stream）解析上。

这篇文章我就以这份资料里沉淀的实践笔记为线索，把海康设备通过国标GB/T 28181上报的PS流，从RTP抓包到H.264/H.265裸流提取，再到送进解码器播放的完整链路讲清楚。适合三类人看：一是自研视频平台、正在对接国标设备的服务端开发者；二是做视频网关、需要把国标流转换成RTSP/FLV/WebRTC等格式的中间件开发者；三是负责安防平台运维，经常要对着抓包文件排查“设备在线但不出流”的工程师。

1. 会碰到PS流解析的场景，比预想的多得多

1.1 自研平台直接接入海康设备

最典型的就是自研平台作为SIP服务器，把海康的IPC、NVR、模数混合设备直接注册进来。很多人拿到海康设备后，第一步都是开ONVIF或者RTSP，因为这两个协议的资料多、工具全，用VLC就能验证。但客户现场往往要求走国标GB/T 28181，尤其是新建安防平台或政府类项目，信令层面必须按国标规范来。

设备注册上线之后，平台向设备发送INVITE请求，设备在200 OK里回SDP，然后就开始通过RTP向平台推送媒体流。这个媒体流默认封装就是PS流。也就是说，平台侧不仅要做SIP信令处理，还要在媒体面接收RTP、重组PS、提取出H.264/H.265裸流，最后送进解码器或转封装模块。任何一环出了问题，用户看到的就是黑屏或者花屏。

这里有一个容易忽略的点：SDP协商结果并不只影响推流参数，它还直接决定了解析器的启动方式。比如视频编码是H.264还是H.265，音频是G.711还是AAC，RTP打包是基于TCP还是UDP，负载类型是96还是98，这些都要先解析出来，再决定后续怎么处理PS包。

1.2 平台向上级平台级联推送

第二种场景是把自己平台的视频流向上级国标平台级联。这时候自己的平台既是SIP客户端，也是媒体源。平台内网里的摄像头可能走的是RTSP、ONVIF或者厂商私有SDK，但要推给上级平台时，必须把编码数据重新封装成PS流，再通过RTP推出去。

很多人在这个场景下会踩一个坑：直接把H.264的Annex-B裸流塞进RTP负载里发出去，上级平台要么黑屏，要么花屏。原因就是国标GB/T 28181规定媒体流采用PS封装，而且PS包头、系统头、PSM、PES这些结构基本都要有。视频编码数据在HDMI线里传送是一回事，在国标信令协商出的媒体通道里传输又是另一回事，容器格式必须对得上。

级联场景的难点还不只是封装，而是码率适配和并发控制。一个平台下面挂着几百路摄像头，上级平台拉流时按需发送INVITE，平台要动态地从内部存储或实时流中取数据，重新封装成PS并推出去。每路流的封装逻辑要做到“互不干扰”，资源回收也要及时，否则长时间运行内存会持续上涨。

1.3 运维排查时如何用抓包定位问题

第三类场景是运维排查。设备不上线、上线了不出流、推了几分钟黑屏、图像花掉又恢复，这些现场问题最后都会落到抓包分析上。我自己的排查顺序是：先看SIP信令是否正常交互，再看媒体端口是否通、是否有RTP包到达，最后才看RTP负载里能不能找到PS起始码00 00 01 BA。

很多运维同事对信令非常熟，一到媒体分析就卡住。原因在于信令是文本协议，肉眼能读懂，而PS流是二进制容器，需要工具或脚本去展开。如果对PS结构不熟，抓包文件里明明是一堆有效数据，也看不出问题在哪。反过来，如果理解了PS流的结构，用Wireshark的“Follow UDP Stream”再导出原始字节，很快就能判断是设备没发流、RTP被防火墙丢弃，还是PS负载本身异常。

2. 开始解PS前，先把容器、编码、传输这三层关系理顺

2.1 一次国标INVITE协商之后，能拿到哪些关键信息

在写解析代码之前，必须能看懂SDP里每一行是什么意思。国标GB/T 28181的INVITE请求和响应中，SDP会明确给出媒体格式和传输参数。比如常见的SDP片段里会有这样几行：

m=video 6000 RTP/AVP 96 98 c=IN IP4 192.168.1.100 a=rtpmap:96 PS/90000 a=rtpmap:98 H264/90000 a=sendonly

其中rtpmap里写着“PS/90000”，意思是96号负载类型承载的是PS封装，时钟频率90000赫兹。这就告诉接收端：收到的RTP负载要先按PS容器去解，解出来的编码数据再根据SDP里协商的编码格式去解码。

SDP里还能看到RTP传输协议。国标GB/T 28181-2016支持TCP和UDP两种RTP传输方式。UDP模式下要处理丢包和乱序，解析器要有状态恢复能力；TCP模式下RTP包前面会加4字节的长度前缀，解析前要先剥离这段长度信息。很多人第一次对接国标平台时只用VLC去拉流测试，等到自己写代码才发现UDP和TCP的组包逻辑完全不同。

2.2 PS流的关键结构：不是一堆随机的二进制

PS流是MPEG-2系统层定义的一种容器格式，最显著的特征就是到处都有起始码。和TS流固定188字节一个包不同，PS流是可变长包，一般用于相对可靠的点对点传输，像光盘存储、RTP承载这类场景。国标GB/T 28181选择PS作为媒体封装，因为它适合在RTP这种面向连接的传输通道上承载整帧数据。

一个典型的PS流由四类结构组成：包头部、系统头、PSM（Program Stream Map）和PES包。它们分别用起始码区分：

拿到一个PS包之后，第一件事就是识别起始码，然后根据起始码类型分流。很多人解PS时不喜欢处理PSM，直接按固定的stream_id去抓视频PES，这在单路视频、无音频的情况下确实能跑通，但一旦设备同时推送视频和音频，或者视频编码信息变了，不解析PSM就会出错。

2.3 海康设备RTP负载的真实形态，不是每次都从PS头开始

海康设备走国标上报时，绝大多数情况下RTP负载的第一个字节就是PS起始码00 00 01 BA。但我也遇到过例外，设备在RTP负载前面加了一段私有扩展头，导致按PS标准去解析时根本找不到包头，视频自然出不来。

判断方法很简单：收到RTP包后，先取负载前四个字节，如果不等于00 00 01 BA，不要急着判定“不是PS流”，先把这段数据显示成十六进制看看。如果是海康的私有扩展，通常会有固定长度的头字段，把扩展头的长度算出来再往后找，往往就能看到PS头了。

还有一个普遍现象：海康NVR多路通道同时出流时，每一路的RTP包是独立的，SSRC不同，RTP时间戳也不同。但同一个通道的PS流里，视频和音频会被复用到一个PS包序列里。如果只按video的RTP SSRC去过滤数据，把音频PES丢掉，那音频就丢了；如果不去区分stream_id，把音频数据误当成视频送进解码器，图像就会花掉。

3. 手写一个PS解复用器的完整思路

3.1 先别碰PS头，把RTP包整理干净

不管负载里装的是PS还是裸H.264，第一步都是先把RTP这一层处理好。RTP包头里最需要关注的是seq、timestamp和payload type。seq用于判断丢包和乱序，timestamp用于音视频同步，payload type用于确认是不是自己要的PS流。

UDP场景下，RTP包可能乱序到达，如果直接按到达顺序把负载拼起来，PS包内部的数据就是乱的。正确做法是按seq从小到大重排，或者至少做一个重排序窗口，窗口内的乱序包先缓存，等seq连续后再送往解析器。窗口大小不用太大，国标设备的RTP包间隔通常很稳定，缓存32个包左右就够用。

TCP场景下，RTP包前面有4字节的长度字段，这个长度是整个RTP包的长度，不是负载长度。解析时要先读这4个字节，确定包边界，再把RTP头剥掉，剩下的才是RTP负载。很多人用TCP方式拉流黑屏，就是忘了这4字节的前缀，把长度信息当成负载的一部分去解析。

3.2 从PS头一路解析到PES

拿到一段以00 00 01 BA开头的字节流后，先判断PS头版本。第二个字节的高四位是版本标识，一般看第4个字节（从0开始算的话是buf[4]）的高四位，如果是“10”就是MPEG-1版本，“01”是MPEG-2版本。海康和绝大多数国标设备推送的都是MPEG-2版本。

MPEG-2版本的PS头长度不固定，包含SCR、program_mux_rate等字段，还有可变的stuffing字节。实际开发时一般不会去完整解析每个字段，只需要正确计算出PS头的长度，然后跳过它，继续往下找系统头、PSM或者PES起始码。

PES包的解析是关键。PES起始码是00 00 01加上stream_id，E0到EF是视频，C0到DF是音频。PES头里有16位的PES_packet_length，这个字段表示后面还有多少字节属于当前PES包。但要注意，在海康推流中，一个视频帧数据量可能超过65535字节，一个PES包并不一定刚好承载一帧。解析逻辑不能认为一个PES就是一帧，还要在PES载荷里通过00 00 01起始码去切分H.264/H.265的NALU。

PES头里还有PTS和DTS信息，这两个值是90kHz时钟，单位是90分之一毫秒。换算成毫秒时直接除以90就行。如果PES头标志位里PTS_DTS_flags为“10”，表示只有PTS；为“11”表示PTS和DTS都有。解码和显示时，PTS用来做音视频同步，DTS用来控制解码顺序，B帧多的码流两者区别明显。

3.3 从PES载荷提取H.264/H.265裸流

视频PES的载荷里装的就是编码后的ES流，以NALU为单位。H.264的NALU起始码是00 00 01或者00 00 00 01，H.265也是同样的起始码规则。解析时直接扫描00 00 01，找到起始码后，从下一个起始码开始才算新的NALU。

实际解析时有一个很核心的问题：PES包的边界和NALU边界不是对齐的。一个NALU可能横跨两个PES包，一个PES包也可能包含多个NALU。所以解析器不能在PES包结束时就把数据直接交给解码器，而是要把PES载荷先追加到一个缓冲区里，按照起始码切出一个个完整的NALU，再把NALU交给解码器或转封装模块。

H.264的SPS和PPS非常重要，前者是序列参数集，包含分辨率、帧率等信息，后者是图像参数集，包含熵编码模式等。解码器初始化时需要SPS/PPS，否则拿到IDR帧也没法解。海康设备一般会在视频流开始时的第一个IDR帧前带上SPS/PPS，但后续的关键帧不一定重复携带。所以解析器应该缓存最近一次收到的SPS/PPS，在解码器初始化时主动注入。

H.265除了SPS/PPS，还有VPS，视频参数集。H.265的PES里如果显示数据是十六进制的40 01 0C开头的片段，那就是VPS。解析H.265时，VPS、SPS、PPS三件套要一起缓存，缺一个都可能出现解码器初始化失败。

3.4 一个可以照着写的简化状态机

下面这段是核心解析流程的简化伪代码，省略了长度校验和错误处理逻辑，但状态机的骨架是完整的。

// state: 0 找PS头, 1 跳过PS头, 2 解析PSM/PES, 3 提取ES while (read_rtp_payload(buf, len) > 0) { if (type == PS_PACK_HEADER && buf[0]==0 && buf[1]==0 && buf[2]==1 && buf[3]==0xBA) { ps_header_len = parse_ps_header(buf, len); offset = ps_header_len; while (offset < len) { if (buf[offset]==0 && buf[offset+1]==0 && buf[offset+2]==1) { if (buf[offset+3]==0xBC) { parse_psm(buf+offset, len-offset); } else if (buf[offset+3]>=0xE0 && buf[offset+3]<=0xEF) { pes_len = parse_pes_header(buf+offset, len-offset); es_data = get_es_payload(buf+offset, pes_len); split_nalus(es_data); } } offset++; } } }

实际生产环境要比这个复杂得多，比如RTP分包导致的“一个PS包横跨多个RTP包”、UDP丢包后找不到完整PS头等情况，都需要加状态保存和错误恢复。我的经验是：解析器每次收到RTP包时，先尝试在新负载里找00 00 01 BA，如果找不到，就把负载追加到上一段残留缓冲区里继续解析。这样无论PS包怎么被RTP分包，都能正确重组。

4. 海康国标PS流调试中印象最深的几个坑

4.1 RTP负载的第一个字节不是00 00 01 BA

这个坑我前前后后踩过三次。第一次是在一个老项目上，平台收到的RTP负载前面有好几个字节，怎么都找不到PS头，最终发现是海康某型号IPC固件会在RTP负载前面加私有扩展。后来换了新固件，扩展头又消失了，兼容性真是让人头疼。

建议处理方案：不要在解析器里硬编码“RTP负载第一个字节必须是PS头”，而是做一次适应性检测。如果负载前4字节不是00 00 01 BA，就从头字节开始扫描，最多扫描到第64个字节，找到00 00 01 BA后就从该位置开始解析，同时记录下这个偏移量，后续包复用同一个偏移值。这样可以兼容多种设备的私有前缀。

不过需要提醒的是，如果扫描了256字节还找不到PS头，不要再继续扫了，基本可以断定这是非PS负载，或者RTP payload type配错了。继续盲目搜索只会浪费CPU，还会把正常数据切坏。

4.2 SPS/PPS不是每个IDR都带，缓存策略要果断

海康设备在国标推流时，通常只在视频流的起始位置送SPS/PPS。如果平台在推流中途才加入解码，或者解析器缓存被误清掉，那么后面收到的IDR帧也会因为缺少参数集而解不出来。

正确的做法是在解析器内部维护一个编码参数缓存。当收到类型为7的NALU（H.264 SPS）和类型为8的NALU（H.264 PPS）时，直接覆盖更新缓存。当解码器初始化或切换通道时，先把缓存的SPS/PPS以“00 00 00 01 + NALU”的格式拼好，连同IDR帧一起送下去。

H.265同理，类型为32的NALU是VPS，33是SPS，34是PPS。这三类参数集的优先级最高，解析时要保证“先于关键帧送达解码器”。如果参数集缓存为空，即使收到了IDR，也应该先缓存不送去解码，等到参数集到位后再拼帧。

4.3 FFmpeg直接解析海康PS流报错，别急着怀疑自己

很多人习惯拿到PS流后先扔给FFmpeg，用avformat_open_input直接打开，结果FFmpeg返回Invalid data found when processing input，就开始怀疑自己抓包抓错了。实际上，FFmpeg对PS容器的解析严格遵循MPEG-2标准，而一些海康设备推送的PS流在字段细节上并不完全标准，比如PSM的版本号不递增、PES长度与实际数据不匹配等。FFmpeg通常会容忍部分问题，但超过了容错范围就报错。

不用在一棵树上吊死。遇到这种情况，正确姿势是自己先按PS起始码做一次粗略的切分，提取出H.264/H.265裸流，然后用ffprobe工具验证裸流是否正常。把提取出来的裸流存成文件，用ffprobe看一下能否识别出编码格式、分辨率和帧率，基本就能判断是解析问题还是设备推流问题。

4.4 时间戳跳变与音视频不同步

海康设备国标推流时，RTP时间戳和PES头里的PTS都是90kHz时钟，两边理论上应该一致。但实际抓包会发现，有些设备在码流切换分辨率、网络波动重推关键帧时，RTP时间戳会出现跳变，跳变幅度甚至能达到几千甚至几万。

如果解码端完全按照RTP时间戳去驱动显示，就会出现画面卡顿或快进。更合理的方式是以PES头里的PTS作为主时间基准，RTP时间戳只用于组包和排序。解析时把PTS换算成毫秒，显示时间直接用这个毫秒值驱动。

音视频同步也要按PTS对齐。如果PS包里同时有视频PES和音频PES，音频PTS和视频PTS必须换算到同一时间base后进行比较。音频超前或滞后超过一定阈值时，再做丢帧或插帧处理。否则观众看到的就是口型对不上，画面和声音各走各的。

4.5 视音频之外的私有流，别当垃圾扔

海康NVR或部分IPC的PS流里，除了视频PES和音频PES，还会出现BD起始码的私有流。这个流在部分设备上承载的是设备侧叠加的OSD信息、智能分析结果或IO状态。

遇到私有流时，有两个选择：一是通过PSM里的stream_type判断其真实用途，如果是音视频就直接送解码器做同步；二是确认是厂商私有协议，再根据自己的业务决定是否解析。最忌讳的是把BD流的数据当成音频或视频塞给解码器。我在一个项目里见过解码器持续报错，排查了两天才发现是有设备把私有流数据混在视频PES后面，解析器没做stream_id过滤。

5. 解析出裸流之后，怎么送进解码器

5.1 自己喂解码器还是交给FFmpeg

拿到H.264/H.265裸流之后，有两条路可选。一条是把裸流重新封装成MP4或者FLV再交给播放器，另一条是直接用解码器解码后在自研播放器里渲染。前者转发简单，做好封装头就行；后者延迟更低，适合实时预览场景。

我的经验是：如果项目只要求“能在播放器里看”、不要求极低延迟，就重新封装。用FFmpeg的libavformat把H.264裸流封装成FLV或者fMP4，再通过HTTP-FLV或HLS分发，代码量小、稳定。如果项目要求毫秒级实时预览、还要做AI分析，那最好直接对接解码器，自己管理缓冲和渲染。

5.2 解码前的数据规范化：start code和extradata缺一不可

裸流送解码器之前，编码数据必须保证Annex-B格式，也就是每个NALU前面都有起始码。如果是从PS流里提取出来的NALU，本身不带起始码长度字段的话，要自己补上。H.264的SPS/PPS需要额外设置到解码器的extradata里，这个设置时机比送第一帧数据还要早。

用FFmpeg解码时，如果直接用avcodec，可以把SPS/PPS和Extradata关联好，也可以直接把Annex-B格式的数据填进AVPacket，让解码器内部去解析。只要保证每个AVPacket里包含完整的视频帧数据，不要把一个视频帧拆成两个包送进去，解码就不会出大问题。

5.3 低延迟场景下的缓冲改进

低延迟场景下，最影响延迟的就是解析器和解码器之间的缓冲。常见的做法是在解析器里设置一个最大缓冲时长，比如200毫秒，如果缓冲超过这个值，就果断丢弃旧的缓存帧，只保留最新的关键帧。这样在弱网环境下图像会“跳帧”但不至于越拉越慢、延迟越积越大。

还要注意关键帧和非关键帧的处理差异。如果当前丢帧了，后续收到的普通P帧和B帧都依赖前面的参考帧，解码出来也是花屏，不如直接丢弃这些帧，等下一个IDR到了再恢复显示。海康设备支持信令请求关键帧，平台可以主动发媒体控制消息请求I帧，比傻等下一个自然关键帧快得多。

6. 抓包和样本文件，比十段代码更有用

最后分享一点日常习惯。我在排查国标对接问题时，永远优先抓包，而不是直接在代码里加日志。抓包文件可以保存下来，反复用Wireshark分析，也能发给设备厂商定位。

Wireshark里过滤国标推流最常用的两个过滤器组合是“rtp && ip.src==设备IP”和“rtp.ssrc==目标SSRC”。抓到RTP包后，选中任意一个RTP包，右键“Follow”再选择“UDP Stream”，就能在导出原始数据时看到PS起始码00 00 01 BA。把这段数据导出成.bin文件，就可以用ffprobe或自定义脚本做离线解析。

我会在项目里留一个“样本库”目录，按设备品牌和型号存放抓包文件，比如“海康-DS-2CD7A47-RTV-PS.bin”“海康-NVR-国标-音频视频混合.bin”。下次对接新设备时遇到问题，先拿样本库里的已知正常文件跑解析器，能快速区分是解析器bug还是新设备的差异。这个方法帮我省掉了大量和厂商来回沟通的时间。

至于“海康、国标ps流解析”这类资料包里常见的代码片段，我的建议是参考结构、不要盲抄。每家设备的PS流细节差异不小，抄来的代码大概率没法直接跑通生产环境。先把PS容器的层次关系理解透，再结合抓包数据逐层验证，遇到问题时才不会被表象带偏。

本文还有配套的精品资源，点击获取