GB28181

CLion平台集成Qt框架实现GB/T 28181-2016推流例子，包含Sip信令交互+OpenCV采集相机预览数据+FFmpeg编码+PS封装+RTP发送PS流到国标平台（ZLMediaKit）

1. 初始化 SIP 参数并注册到国标平台

• 初始化 SIP 相关参数（如设备 ID、服务器地址、端口等），并通过 eXosip2 库向国标平台（GB/T 28181-2016）发起注册请求；

2. 视频采集

• 使用 OpenCV 采集视频画面，获取 cv::Mat (BGR) 格式的原始数据；

3. 音频采集

• ⚠️ 方案待确定。

4. 拉流信令与编码

• 客户端默认仅进行本地预览，不进行编码与推流，当国标平台下发拉流信令（Invite 请求）后，客户端才开始编码：
  • 通过 FFmpeg 软编码生成完整的 H.264 帧数据（包含起始码）并记录编码帧数；
  • ⚠️ 方案待确定。

5. 视频帧封装为 MPEG-2 PS 流（这一步坑超多！！！）

• 将编码帧数转为90kHz（const auto pts_90k = pkt->pts * 90000 / VIDEO_FPS）时间基准的时间戳。

  ⚠️ 关键提示：GB/T 28181-2016要求必须是90kHz下的时间基准，否则推流将无画面！

• 将整帧 H.264 数据按照起始码拆分为 NALU（网络应用层单元，是H.264数据的基本单元），同时提取 SPS/PPS 帧数据并缓存，并把IDR帧筛选出来。
• 将 SPS/PPS 以及筛选选出来IDR帧的按照顺序【[起始码]+[SPS]+[PPS]+[IDR 帧]】组帧，并封装为 PES 包。
• 将非IDR帧的按照顺序【[起始码]+[P 帧]】组帧，并封装为 PES 包。

  ⚠️ 关键提示：上面提到的IDR帧和P帧本质上是一系列 NALU ，IDR帧必须要比任何帧先发送到平台，否则平台不解析画面帧数据，因为SPS/PPS携带这视频帧的基本信息。

• 将上述步骤得到的数据——即 PES 包作为载荷，按照 IDR 帧（添加系统头和 PSM ）和非 IDR 帧封装为 MPEG-2 PS 流。

  ⚠️ 关键提示：添加系统头和PSM的时候，坑超多！每个字节，每个Bit位都得清楚是什么含义，否则无法正确封装！

6. 音频帧编码与封装为 MPEG-2 PS 流

• ⚠️ 方案待确定。

  ⚠️ 关键提示：GB/T 28181-2016要求必须是90kHz下的时间基准，否则推流音画不同步！

• 将 PCM 编码为 G.711μ（G.711a）；
• 将整帧的 G.711μ（G.711a）并封装为 PES 包。音频封装较简单，直接塞进到 PES 包中即可。
• 将上述步骤得到的数据——即 PES 包作为载荷，封装为 MPEG-2 PS 流。

  ⚠️ 关键提示：音频帧全是非IDR帧，即，不用添加系统头和PSM和起始码。这里一定要注意！！！

7. PS 包分片处理

• 由于 RTP MTU 限制约为 1400 字节，需对较大的 PS 包进行分片；
• 判断每个 PS 包大小：
  • 若 ≤ 1400 字节：直接作为单个 RTP 包发送；
  • 若 > 1400 字节：按 RFC 3984 或 GB/T 28181 规范进行 RTP 分片封装。
• 这一步没什么坑，就是把PS 包进行分片，并封装为 RTP 包，不过要注意Sip的sdp消息里面是要求设备以什么方式发送到平台，一定要按照sdp里面的方式发送，否则平台收不到包。

8. 网络传输

• 将封装好的 RTP 包（单包或分片）通过 TCP 或 UDP 发送至国标平台：
  • TCP 模式：连接可靠、抗丢包，适合网络不稳定环境；
  • UDP 模式：延迟更低，适合实时性要求高的场景；
• 传输协议类型由平台信令协商确定，客户端动态适配。