讲GB28181的文章十篇有九篇在讲SIP信令。可真正决定你能不能看到画面的是信令谈完之后那段被打包成PS的媒体流。它不常被提起却是排障时绕不开的一环。做视频平台的人迟早会遇到几个说不清的问题1设备明明显示在线点播却一直转圈信令没问题画面就是不出来2浏览器里用WebRTC很流畅换成HLS就慢半拍明明是同一路画面3录像回放的时间轴和告警时间对不上几分钟4对接第三方平台时对方问你们给的是PS还是ES答不上来。这几个问题的答案其实都在同一个地方——封装。一段画面从摄像头到浏览器要换几次包装先把整条链路摆出来后面所有内容都围绕它展开摄像头编码输出 ES裸码流→打PES包加时间戳→复用封装成PS流→RTP切片并加序号→UDP/TCP网络传输→平台收流解RTP→解PS还原ES裸码流→按目标协议重新封装成RTMP/FLV/HLS/WebRTC→浏览器无插件播放。这里面出现了三次包装和拆包第一次是设备端。摄像头的编码芯片输出的是ESElementaryStream裸码流——就是一帧一帧的H.264或H.265数据加上一路G.711或AAC音频。裸码流没有时间信息、不区分音视频没法直接用于传输和存储。所以设备要先把它封装成PS。第二次是传输层。PS是一个流但网络传输需要分包、需要序号、需要时间戳来对抗乱序和抖动。这一层由RTP负责把PS流切片、加上序号与时间戳通过UDP或TCP发出去。第三次是平台侧的目标封装。PS这种格式浏览器是不认的。平台必须解封装拿到裸码流再按前端需要的协议重新打包——RTMP、FLV、HLS、WebRTC每种格式的包结构都不一样。理解这三次转换就能理解为什么同一路画面在不同播放方式下表现不同画面内容从头到尾没变变的只是外面那层包装。国标为什么选了PS而不是TS或者直接走裸流这是最常被问到的问题。答案要从PS和TS的设计初衷说起。PSProgram Stream节目流出自MPEG-2系统层标准ISO/IEC 13818-1它的设计前提是传输信道相对可靠——比如光盘、硬盘。PS的包是变长的一个PS包可以很大音视频复用在一起靠包头里的系统时钟参考SCR和PES层的时间戳PTS/DTS做同步。DVD用的就是PS。TSTransport Stream传输流出自同一份标准但设计前提完全相反——信道会出错。TS把数据切成固定188字节的小包每个包自带同步字节和错误指示丢了一包不至于毁掉整段。数字电视广播、IPTV用的都是TS。GB28181选择PS是有道理的安防场景的核心诉求恰恰是存下来、能回放、能定位。录像文件要长期保存、要按时间轴精确检索、要能导出成证据材料——这些都是PS的强项。而TS为抗丢包付出的固定开销在录像存储这个场景里反而是浪费。至于为什么不用裸流ES裸流没有时间戳、不区分音视频存储和回放无从下手。国标里大量的能力——录像检索、历史回放、时间轴定位——都依赖PS里那套时间信息。没有封装就没有这些能力。PS流里到底装了什么拆开一个PS流从外到内大致是三层PS包头PackHeader。每个PS包的开头里面最关键的字段是SCRSystem Clock Reference系统时钟参考——它标记这个包在整个流里的绝对时间位置。可以把它理解成这包数据在整个节目里的秒数。系统头SystemHeader。可选描述流的整体参数比如码率上限、有几路音视频。PES包PacketizedElementaryStream。真正装数据的地方。视频和音频各走各的PES靠不同的流ID区分。每个PES包头里有PTS显示时间戳和DTS解码时间戳——这两个值告诉播放器这帧该什么时候解、什么时候显示。音视频能不能对上嘴型、快进时会不会花屏全靠它们。所以GB28181一条完整的媒体流路径是这样的H.264 ESG.711 ES→加PTS/DTS打成PES视频PES音频PES→加SCR/系统头复用成一个PS流→加RTP序号与时间戳切片成RTP包通常payload type96→走UDP或TCP→网络传输。GB28181同时支持UDP和TCP两种传输方式。UDP效率高但对网络质量敏感跨网段、跨NAT时容易丢包TCP可靠但会有队头阻塞弱网下延迟会累积。选哪个取决于实际网络环境而不是哪个更好。平台为什么要做转封装PS到浏览器之间那一步现在到了最关键的一段PS这种格式没有任何一种主流播放方式能直接吃。浏览器不认PS播放器不认PSHLS也不认PS。平台必须做一次拆了重装。EasyGBS在这一层做的事情可以拆成四步第一步收流与解RTP。按序号重组RTP包处理乱序、丢包、重复包。这一步如果网络质量差就会表现为花屏、卡顿、画面撕裂。第二步解PS拿到ES。解析PS包头与PES头还原出H.264/H.265视频裸流和音频裸流同时提取时间戳。第三步按需转码。如果目标协议不支持原始编码格式就需要转码。视频侧平台支持H.264、H.265并可做码率自适应与多子码流切换音频侧如果国标设备的音频编码如G.711与目标协议要求的格式不一致就需要做音频转码。第四步按目标协议重新封装。这一步是同一路画面不同体验的根源延迟为典型参考区间实际受网络、分片大小、播放器缓冲策略影响。这里有个很实用的判断延迟的绝大部分不是编码造成的是封装与缓冲策略造成的。HLS之所以慢是因为它必须等一个分片完整生成才能播放分片越大越慢。这不是平台性能不好是协议本身的机制决定的。所以选型时应该先问这个场景能不能接受几秒延迟再决定用哪种输出。EasyGBS在这一层的另一个设计值得单独提按需拉流。没有用户在看的通道只保留SIP心跳不进行视频拉流与转码。对上万路点位的项目来说这个机制节省的带宽与算力相当可观——因为绝大多数通道在绝大多数时间是没有人看的。这层封装对排障有什么用理解了封装很多玄学问题就有了明确的排查方向。下面这张表可以直接拿去用。一个值得养成的习惯先看SIP报文再看媒体流。EasyGBS提供SIP报文诊断能力可以判断信令交互是否正常。信令正常但无画面问题基本就在传输层或封装层信令都不正常那就回到注册、心跳、端口这些基础项。封装这层东西平时看不见出问题时却处处是它。花半天时间把它理清楚比事后排查三天要划算得多。