门户
书籍
教程
论坛
问答
下载
签到
个人空间
帐号
自动登录
找回密码
密码
登录
立即注册
登录
注册
搜索
搜索
搜索
热搜
qml
quick
串口
输入中文
数据库
arm
百度地图
qt聊天
QT安装
安装
多窗口
中文乱码
聊天
局域网
鼠标
QT
图片
乱码
rs485通讯
多线程
android
多文档编辑器
本版
用户
本版
用户
【HUX】问题互助平台
博客
动态
好友
帖子
收藏
道具
勋章
任务
淘帖
动态
日志
相册
分享
记录
留言板
群组
门户
导读
排行榜
设置
我的收藏
退出
Qt开源社区
›
精品文章(Qter团队原创教程)
›
基础教程
›
Qt/C++开发监控GB28181系统/个人理解/要点总结/经验分享 ...
发布主题
返回列表
Qt/C++开发监控GB28181系统/个人理解/要点总结/经验分享
0
回复
458
查看
[复制链接]
liudianwu
当前离线
积分
2978
liudianwu
累计签到:7 天
连续签到:1 天
来源:
2026-1-11 09:32:07
显示全部楼层
|
阅读模式
## 一、前言说明
### 1.1 新增协议
**gb28181-2022主要新增了如下几个协议:**
1. 注册重定向,有些大的平台,下级域可能几万个设备同时连接,会导致并发不够,所以需要有个注册重定向机制,主动告知下级域重新注册到指定的上级域服务器,也就是相当于有个专门的重定向注册服务程序,专门分配注册连接。如果离线后,又需要先注册到重定向服务器,重新分配。
2. 图像抓拍,支持最多抓拍10张图片,可以设置抓拍间隔,最小1s。有些场景尤其是4G摄像头,为了省流量,平时就只需要抓拍报警图像到平台即可,平时不点播视频,视频太费流量。还有就是本来一些场景需要抓拍报警图片专门存储,之前2016版本只能去点播视频抓图,整个过程很繁琐很慢,使用非常鸡肋,而且费宽带。
3. 云台绝对控制,也叫精准控制,之前云台只能连续控制,也是最常用的方式,有些场景需要精准定位控制云台。并且云台位置变化会主动推送到服务器。
4. 增加了看守位的查询HomePositionQuery、巡航轨迹列表查询CruiseTrackListQuery、巡航轨迹查询CruiseTrackQuery、目标跟踪控制命令TargetTrack。
5. 增加了存储卡状态查询及应答命令,设备升级命令。这两个用的少一些。
### 1.2 个人理解
1. gb2818协议是基于sip协议的一套协议框架,而sip是和http协议类似的一套基于udp/tcp载体的协议,最终底层通过udp/tcp收发数据。sip是一套多媒体通信框架,而gb28181就是在这套框架上,定义了具体的通信内容,也就是收发数据填充的内容。
2. sip协议收发通常用的第三方开源库有osip/exosip,exosip依赖osip,是对osip的二次封装,带了具体传输层,osip相当于用来构建要收发的数据,本身没有收发功能。还有个更强大开源库pjsip,带了rtp解析。具体可参考
https://blog.csdn.net/weixin_43147845/article/details/144219082
3. sip协议说复杂也复杂,说简单也简单,复杂就是涉及到的具体协议规约特别庞大,和http协议是并列的一种机制。简单就是如果只是少量的通信,可以直接用udp/tcp通信收发解析,要发送的数据每一行都回车换行,最后一起发出去即可。就是发送和解析不大方便,需要去寻找和取出关键字再处理,而开源库会给你处理好对应的数据结构,比如解析后有枚举字段直接判断。
4. onvif是国际标准协议,gb28181是国家标准协议,各有优缺点,onvif通常是通过搜索到设备再去和设备通信,而gb28181刚好相反,是让设备主动连服务器,带上校验等参数,连上后,服务器再去和设备通信。这样相当于可以跨网了,而onvif通常只能局域网。gb28181还有个优势就是组网,可以层层级联,非常适合国内各种大监控系统的建设。
5. onvif客户端是先udp组播获取到设备,然后再发送http请求到不同的地址来交互,请求中可以获取到视频流rtsp地址,然后自己用ffmpeg等框架打开这个地址播放就行。而gb28181服务端是先udp/tcp监听端口,对连上的设备进行sip协议格式的数据内容的交互,发送请求播放指令后,开启发送rtp数据包,再用ffmpeg等框架解析这个数据包就行。
6. gb28181注册的时候Expires为有效期时间,一般是3600秒,如果是0则表示注销。同理订阅也是这个机制,订阅下发的时候有个有效期,如果有效期0就表示取消订阅。
### 1.3 要点总结
1. gb28181协议一般会选择udp通信,默认也是udp,早期国标设备都是只支持udp。
2. 服务端开启端口监听,设备端填写好对应参数后,会尝试往对应端口发数据进行连接。
3. 设备端间隔(心跳间隔默认是60s)发送REGISTER信令,服务端收到后,分析数据中是否带了鉴权信息(也就是用户认证相关信息),没有带的话则应答Unauthorized,带了的话,可以取出认证的信息,和要求的参数对比,比如国标服务端编号、认证密码、域编码信息,不一致则应答信息错误,叫客户端重新发。都没问题则表示认证通过。
4. 认证后服务端发送MESSAGE信令,带上xml数据,获取设备信息,收到设备信息后,再去查阅目录也就是获取通道列表。
5. 设备端在注册成功后,每隔一段时间发送一次心跳信息。方便服务端判断是否离线。
6. 设备端一旦注册成功,在有效期(一般是3600s)内,不会再去注册,默认就是认为已经注册成功。所以有时候服务端这边开启服务后,未必先收到REGISTER注册指令,而是可能先收到的心跳指令,所以服务端这边要做个特殊处理,收到心跳后,先判断该设备在系统中是否已经存在,不存在则先获取设备信息,再去获取通信列表。
7. 服务端支持多个设备注册,通过设备编号区分,严格要求同一个系统中设备编号不能重复,否则容易错乱。
8. 每个设备都可以有多个视频通道,一般摄像头IPC只有1个通道,录像机NVR有多个通道。如果是国标级联,相当于把服务端当做一台NVR设备,每个设备的通道都转换成唯一标识的通道。
9. 点播视频和云台控制等,都有个前提是要先获取到对应的通道列表,因为下发的数据中就要指定是哪个通道。
10. 点播视频是服务端向设备端通过发送INVITE信令,带上sdp数据(具体sdp格式规范在gb28181-2016文档的第100页),sdp数据中包含了通道编号、音视频格式、音视频数据如何交互等信息。
11. 服务端点播视频前,先要打开一个空闲的端口,这个端口号在sdp数据中带上,设备端收到点播指令后,会将音视频数据发给这个指定的端口,收到这些数据后再去用ffmpeg解码播放即可。sip这边只负责信令交互,并不负责音视频数据的通信。
12. 关闭视频很关键,因为可能开了多个点播窗口,所以需要在点播视频后应答的ACK指令数据中,记住当时信令中的from/to/callid数据,在关闭视频的时候用播放时对应的这几个数据发给设备端,才能真正停止。
13. 一个设备可能有多个通道,一个通道可能存在多个点播流,每个流都对应唯一的端口,所以需要有个队列记住这些点播流对应的ssrc/from/to/callid数据,可以指定关闭某一路流。
14. 点播流需要对应端口接收流,一般这个端口需要动态分配,也可以不同流公用一个端口,公用端口不用担心数据会冲突,里面都是rtp的数据包,通过ssrc区分是哪一个流的数据包,这个ssrc是由点播发起者下发的,在sip指令中附加在subject属性上,sdp中有个y属性专门放这个ssrc字符串。在端口数量允许的情况下,一般建议每一路流都不同的端口,方便区分管理。
15. 点播流的过程,一般第一步是先打开监听端口成功后,然后才将这个端口通过sip指令发给设备,因为端口有可能被占用,所以只有当打开监听端口成功的时候,再去点播流,这样才是通的,不然也是白搭。
16. 语音对讲和点播视频流程不一样,是反着来的,先服务端发送语音广播指令Broadcast到设备,设备返回是否支持语音对讲,如果支持,会主动发送INVITE信令,带上sdp数据,服务端搜到这个sdp数据后解析,然后服务端主动往设备对应的端口发送带了语音数据的RTP数据包,设备端的声音会通过之前的音视频流传输过来。
17. 云台控制和预置位相关处理就简单一些,因为都是单向操作。通过MESSAGE信令带上xml数据,数据中包含了要执行的通道编号和动作,这个动作的数据,是一个标准的固定长度8字节,16进制字符串数据格式,比如A5 0F 01 00 00 00 00 00,将要执行的动作替换对应的数据位即可,停止云台也是一个单独的动作。
18. **ffmpeg中并不能直接解码RTP数据包,需要解包后才是PS流才可以正确的解码,一般会用第三方开源库jrtp去实现解包,当然他也支持封包,发送语音数据的时候也要用到,jrtp直接就是带了网络通信,比如监听UDP端口收数据。**
19. 在信令交互过程中,可以多一些无关的数据,但是不能少一些必要的字段数据,比如invite信令必须带有Subject,缺少的话无法正常解析导致失败。
20. 拉流分三种模式,udp、tcp被动、tcp主动。udp是指服务端这边监听udp端口,等待设备端主动发数据;tcp被动是指服务端这边监听tcp端口,等待设备端主动连接和发数据;tcp主动是指服务端主动连接设备端,连接成功后设备端主动发数据。一般内网建议用tcp被动模式,比如GA内网一般会采用这个模式;外网如果要求实时性高于清晰度,则用udp模式,如果要求稳定性不丢包则用tcp被动模式;理论上外网也就是公网上,tcp主动模式几乎用不,因为服务端无法正常连接到设备端,除非做了端口映射。
21. 拉流中的udp和tcp被动模式,需要考虑一个细节,那就是端口占用问题,必须先监听端口成功后(不成功则端口递增直到成功),再把对应端口通过sip协议发给设备端,而不是先发端口再去监听端口。这是很多国标系统忽略的一个细节,一旦端口占用直接歇菜。
22. 有些设备对应TCP主动方式拉流会校验端口号,所以建议在连接的时候,对应socket要绑定地址和端口,如果没有绑定,则设备端收到这个连接后,会主动断开导致无法正常收流。
23. 有些运营商可能会显示TCP流量,在4G设备的场景下,UDP正常而TCP不正常的情况下,如果运行一段时间断流,需要考虑这个问题,可以换个取流方式或者换个流量卡供应商。
## 二、效果图
## 三、相关地址
1. 国内站点:[
https://gitee.com/feiyangqingyun
](
https://gitee.com/feiyangqingyun
)
2. 国际站点:[
https://github.com/feiyangqingyun
](
https://github.com/feiyangqingyun
)
3. 个人作品:[
https://blog.csdn.net/feiyangqingyun/article/details/97565652
](
https://blog.csdn.net/feiyangqingyun/article/details/97565652
)
4. 文件地址:[
https://pan.baidu.com/s/1d7TH_GEYl5nOecuNlWJJ7g
](
https://pan.baidu.com/s/1d7TH_GEYl5nOecuNlWJJ7g
) 提取码:01jf 文件名:bin_video_28181
## 四、功能特点
1. 支持设备注册、注销、心跳、校时、注册认证、注销认证等。
2. 设备上线后可以手动获取设备状态、设备信息、配置信息、预置位信息等。
3. 设备上线后自动获取设备通道信息,包括中文通道名称。识别到通道上线离线变化,会重新获取该设备的所有通道信息。
4. 支持视频点播,可以分别点播主码流和子码流,内置rtp解包线程,解包后发给视频播放组件解码播放。
5. 每个设备每个通道支持点播多个视频,通过ssrc区分,支持共用端口和不同端口收流。
6. 支持对某个设备下面所有通道、某个通道、某个通道对应的某个流分别关闭。
7. 支持录像文件查询和回放,回放控制支持暂停播放、继续播放、倍速播放、切换播放进度。
8. 支持录像文件下载,支持倍速比如8倍速下载,可同时多线程批量下载。
9. 回放和下载同时支持IPC和NVR,比如摄像头自带的SD存储卡录像文件回放,NVR上的硬盘录像文件回放。
10. 支持云台控制,向上、向下、向左、向右、左上、右上、左下、右下方位移动,镜头放大缩小,光圈放大缩小,镜头聚焦放焦。
11. 支持预置位信息的查询、调用、添加、修改、删除等操作。
12. 自动目录订阅功能,通道上线下线都有对应的信号通知。
13. 内置定时读取通道信息机制,以保证通道信息是最新的,比如有些NVR是不断更新的通道信息。
14. 内置订阅警情和位置移动功能,订阅后各种警情事件比如运动目标检测报警、入侵检测报警、徘徊检测报警等自动上报。
15. 支持语音对讲功能,可以直接在视频窗体的悬浮条上单击语音对讲按钮,再次单击关闭对讲,对讲期间悬浮条常驻显示。
16. 支持设备布防撤防,布防后警情信息会主动上报。
17. 国标服务同时支持udp和tcp方式,可选只监听一种或者两种都监听,tcp方式自动处理粘包问题。
18. 国标拉流同时支持udp、tcp被动、tcp主动三种方式,每个通道都可以自由选择何种拉流方式。
19. 内置拉流端口池,每次拉流从中取出一个,关闭流自动回收端口号,重复利用。
20. 收流端口自动纠错,自动跳过被占用的端口,不会出现端口占用导致收流失败的情况。
21. 支持三种取流方式自动检测离线重连,检测到离线后,自动重启点播拉流整个流程。
22. 录像文件回放,上一个完成后自动切换到下一个继续回放,直到所有回放完成。支持高达8倍速回放。
23. 视频播放自适应硬解码,极低资源占用,实时性极好,带悬浮条显示视频流信息,可以直接在悬浮条单击按钮保存录像文件到本地。
24. 支持几千路国标消息交互并发,实时视频流支持64路同时显示,可以拓展更多路数。
25. 支持阿里云等云服务器,可以分别设置内NETJ听地址和外网访问地址,一般云服务器上是监听地址用内网,对外访问用外网地址。
26. 支持视频分发,也就是推流,视频通道打开后可以自动推流到流媒体服务器,其他需要的地方拉流即可,支持rtsp、rtmp、hls、webrtc等方式拉流。
27. 视频分发也叫推流分发,表格方式展示正在推流的信息,其中包括显示统计哪些流正在被多少个地址拉取,比如有两个地方通过rtsp打开了取流,则对应推流地址行所在rtsp列显示数量2,非常直观的展示有多少个拉流。
28. 视频分发支持无人观看超时自动关闭推流和点播,提高带宽的利用率,没人观看太久的时候,没必要点播拉流和推流。在后台服务模式下,通道推流自动复用,当该通道已经存在点播推流,则复用该路流数据,不会再去点播,节约资源。
29. 提供后台服务功能,定义了一套私有协议,根据私有协议进行交互,支持tcp、http、mqtt等方式交互,方便第三方程序接入集成。通信协议非常完整,支持获取设备列表、获取指定通道视频地址、云台控制、预置位操作、录像查询、录像回放、录像下载、回放倍速等控制、警情消息通知、视频点播和关闭等。
30. 支持注册重定向,方便做负载均衡和区域化部署,这样可以支持几十万个设备连接都没问题。
31. 支持图像抓拍,可以设置抓拍最多10张图片,可设置抓拍间隔,抓拍到的图片会通过信号通知。
32. 实时预览和录像回放都支持推流,推流支持叠加文字和图片水印以及各种ffmpeg支持的滤镜效果,支持多个水印同时叠加。
33. 同时支持gb28181-2011、gb28181-2016、gb28181-2022以及后续可能的所有协议版本。
34. SIP解析和交互采用纯Qt底层代码实现,udp/tcp通信交互,祖传原创代码解析,不依赖任何第三方。
35. 代码量少,gb28181交互部分共几千行代码,注释详细,接口友好,使用极其简单,提供非常详细的使用示例。
36. 支持海康、大华、宇视、华为、天地伟业等所有国标设备,包括一些没有ssrc的设备。
37. 支持所有Qt版本和编译器以及操作系统,包括但不限于win、linux、mac、android、嵌入式linux、树莓派香橙派、国产os等。
## 五、相关代码
```cpp
```
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有帐号?
立即注册
x
回复
使用道具
举报
返回列表
发表新帖
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
公告
可以关注我们的微信公众号yafeilinux_friends获取最新动态,或者加入QQ会员群进行交流:190741849、186601429(已满)
我知道了