Qt/C++视频监控/推流/物联网/大屏系统/自定义控件/UI定制/输入法

gb28181协议一般会选择udp通信，默认也是udp，早期国标设备都是只支持udp。服务端开启端口监听，设备端填写好对应参数后，会尝试往对应端口发数据进行连接。设备端间隔（心跳间隔默认是60s）发送REGISTER信令，服务端收到后，分析数据中是否带了鉴权信息（也就是用户认证相关信息），没有带的话则应答Unauthorized，带了的话，可以取出认证的信息，和要求的参数对比，比如国标服务端编号、认证密码、域编码信息，不一致则应答信息错误，叫客户端重新发。都没问题则表示认证通过。

在2011版本的gb28181协议中，拉取视频流只要求udp方式，从2016开始要求新增支持tcp被动和tcp主动两种方式，udp理论上会丢包的，所以实际使用过程可能会出现画面花屏的情况，而tcp肯定不丢包，起码画面不会花屏或者不完整，就是速度上慢了一些。tcp被动模式和udp模式其实是一样的，只不过udp模式是监听的udp端口，而tcp被动模式是监听的tcp端口，然后数据的接收处理完全一样。

GB28181协议服务端实现解析：支持UDP/TCP双通道，自动处理粘包问题 摘要： 本文介绍了基于GB28181协议的服务端实现方案。从2016版协议开始要求支持TCP传输，以解决UDP在网络环境差时的指令丢失问题。通过C++继承机制设计GB28181ServerBase基类，派生出UDP和TCP处理子类，实现双通道支持。特别针对TCP粘包问题（尤其是录像查询场景），提出了完整数据包接收方案。功能涵盖设备管理、视频点播、录像回放、云台控制等30余项特性，支持海康、大华等主流设备。代码采用纯Qt实现，跨平台

GB28181协议中的语音对讲功能相较于视频点播更为复杂，涉及服务端与设备端的多次交互。对讲流程包括服务端发送语音广播通知、设备端应答并发起点播请求、服务端应答并监听端口等步骤。音频数据通过RTP格式传输，设备端的声音通常通过视频通道一并传输。在界面交互上，利用现有的视频控件悬浮条，添加语音对讲按钮，并通过专门的GB28181WidgetManage类管理对讲状态，确保同一时间只有一个通道处于对讲状态。该功能支持设备注册、注销、心跳、校时等操作，并具备视频点播、录像回放、云台控制、语音对讲等多种功能，适用于

录像回放功能与视频点播类似，但需在SDP信息中指定开始和结束时间。实时预览无法切换进度，而录像回放支持进度切换。实现录像回放需先查询录像文件，设备端返回的文件信息可能包含多个文件，需逐个解析。切换播放进度时，部分厂家采用重新点播的方式，导致短暂黑屏，而国标协议提供了直接切换进度的SIP指令，设备端会立即从指定位置开始发流。代码示例展示了查询文件、点播请求、暂停和继续播放的SIP消息格式。

GB28181协议下的实时视频预览功能是系统的核心，尽管其实现过程复杂，涉及SIP命令交互、RTP包解析、PS流转码等多个步骤。开发者通过封装GB28181Widget类，简化了操作流程，用户只需调用openVideo和closeVideo即可实现视频的开启和关闭。此外，系统支持设备注册、视频点播、录像回放、云台控制等多种功能，具备高并发处理能力和良好的扩展性，适用于多种场景和设备。代码结构清晰，注释详尽，便于二次开发和集成。

警情订阅在gb28181协议中也是一个重要的功能，一般是服务端主动问设备端订阅，不知道设备端是否能问服务端订阅？貌似行不通。订阅后设备端一旦有警情消息，会主动发给服务端，比如运动目标检测报警、视频丢失报警、入侵检测报警等，在gb文档中详细列举了对应哪种类型的报警对应哪个type类型，这个还是比较全的，同时还支持拓展信息字段，携带更多的详细信息，比如还有警情的中文描述。

之前用onvif已经完美实现了设备的云台控制和预置位的功能，这个基础功能在监控系统中是使用频率很高的，所有gb28181肯定也提供了这样的功能，很多人以为是通过包含xml数据，对应节点指定对应的动作来实现，其实不是的，是类似于早期模拟设备的云台的串口协议中的控制指令，16进制格式的数据，一个个字节表示对应的含义，这个在国标文档中写的非常的详细，按照那个规则来肯定错不了，上下左右移动有个字节位是固定的数据，所以程序这边只需要根据要操作的动作填充对应位的数据即可。

设备注册成功后，接下来要做的就是获取设备的信息，尤其是通道信息，根据国标协议，永远只有两个层级，一个是设备，然后就是设备下面多个通道，设备编码在整个系统中唯一，通道编码在一个设备中唯一，如果不唯一，那就可能会产生冲突，其实是程序层面的冲突，硬件层面不冲突，这个不是mac地址这种唯一性，仅仅是软件层面的学号的约定。理论上来说可以重复，但是软件编写者一般不会这么要求，包括国标文档也要求不能重复，一旦重复的话，很多逻辑和操作不好处理。

根据gb28181协议文档，第一步就是需要实现设备的注册，和onvif不同，gb是反过来的，设备端主动连接服务端，而onvif是服务端主动发出搜索，设备被动应答，包括后续的交互几乎都是被动应答，除了警情上报。gb这样定义协议有个巨大好处，就是跨网，服务器上的软件可以在公网上，然后设备这边主动去连接，后续的交互都是建立在这个连接上面的，通过心跳消息保持连接。在udp模式下，如果没有心跳保活，在外网环境中，设备端的端口可能会变，意味着服务端无法主动发消息给设备端。

搞gb28181开发，首要任务就是解析协议，按照gb28181的文档来，还是非常详细的，通过抓包工具可以查看到具体的收发数据，也可以打开网络调试助手工具，监听5060端口，看到上报的数据，都是一个通用规则的协议。//设备端发送rport;//服务端应答rport;

用纯Qt来实现这个GB28181的想法很久了，具体可以追溯到2014年，一晃十年都过去了，总算是整体的框架和逻辑都打通了，总归还是杂七杂八的事情多，无法静下心来研究具体的协议，最开始初步了解协议后发现比onvif要复杂不少，索性先搁置一旁，所以先把onvif协议打通了，onvif协议好是好，但是一般在局域网内使用，外网访问几乎没有办法，而GB28181就是为了解决很多痛点定义的一套视频监控规范，毕竟现在满大街都是监控，各个部门机构都要外网远程取流，这就必须上国标，这其实是网络通信的弊端，服务端在没有收到过客