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