GB28181
1. 国标GB28181摄像头模拟
实现了将h264封装ps流并打包rtp推流到服务器
先抛开标题, 整体的GBServer需要交互Sip和流媒体(ZLMediaKit实现)两部分
目前先了解Sip信令部分
ZLMediaKit获取实时流API
127.0.0.1/index/api/getMediaList
1.1 Sip信令简介
Sip(session initiation protocol): 由互联网工程任务组制定的, 用于多方多媒体通信的框架协议
是一个基于文本的应用层控制协议, 独立于底层传输协议, 用于建立、修改和终止IP网络上的双方或多方多媒体会话信令: 控制电路的信号,是终端和终端、终端和网络之间传递的一种消息,专门用来控制电路,建立、管理、删除连接, 以使用户能够正常通过这些连接进行通信事务: 客户和服务器之间的操作从第 1 个请求至最终响应为止的所有消息构成一个SIP事务
一个正常的呼叫一般包含三个事务
其中,呼叫启动包含两个操作请求:邀请(Invite)和证实(ACK),前者需要回送响应, 后者只是证实已收到最终响应, 不需要回送响应
呼叫终结包含一个操作请求:ByeSIP URL (Uniform Resource Locators): 一般结构为
SIP: 用户名: 口令 @ 主机: 端口;传送参数: 用户参数; 方法参数; 生存期参数; 服务器地址参数? 头部名=头部值

Sip信令交互过程

摄像头(客户端)像服务段发送注册请求
服务器回复
401(未授权, 未携带密码)摄像头收到
401第二次发起注册, 此次注册携带密码(密钥)服务器返回注册成功(
200OK)服务器像摄像头发起
invite请求,告诉摄像机我要接受流媒体,并包含SDP(解释自己能处理的流)摄像机收到
invite后回复100(Trying)摄像机传输message(必要信息,ip port…)
摄像机回复状态码
101(Establishment)摄像机回复状态码
200, 并且包含了 SDP(摄像机告诉服务器, 我的摄像头有哪些流)服务器收到
200服务器收到SDP后, 向摄像机发送
ACK确认摄像机开始推流
摄像机发送
BYE服务器回复
200
1.2 PS流
PS流封装标准如下,其详细信息暂不去了解

GB28181要求的RTP流格式
I帧的PS流格式,这里需要注意的是SPS、PPS之前要加上PES头部
如下图所示, 其中绿色部分就是我们拿到的H.264裸流数据, 须将它拆分成三段并在前面加上PES头部
这一点在GB28181标准中没有细说,需要通过分析海康IPC流才能看出
一般情况下IDR帧很大, 超过了RTP的负载长度限制(1400字节), 所以上面这一个I帧要拆分成若干包RTP分多次发送
第一包的结构如上图所示, 第二包以后RTP的结构就简单多了, 如下
上面提到的是I帧的情况,P/B帧的帧格式较为简单了, 因为它既没有SYS、PSM, 也没有SPS、PPS
P/B帧大小一般不超过1400字节, 如果超过1400字节, 也需分成多包RTP数据进行传输, 超出1400部分的第二包RTP结构
头部信息:
1 | //RTPHeader |
1 | //PSH(PS Header) |
1 | //SYS,它包含了流类型信息,比如音频还是视频、视频编码格式 |
1 | //PSM,这里面记录了媒体信息,比如音视频的编码格式: |
1 | //PES头部,它记录了帧的时间戳,DTS可以不填,如果填写要和PTS保持一致,且同一帧数据的PTS要也要一样(即SPS、PPS、IDR的PES要一致) |
时间戳的比特位结构,下图表示的比较清晰
难度太高,暂时搁置


