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
第二次发起注册, 此次注册携带密码(密钥)服务器返回注册成功(
200
OK)服务器像摄像头发起
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要一致) |
时间戳的比特位结构,下图表示的比较清晰
难度太高,暂时搁置