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

原创 Qt/C++原创项目作品精选（祖传原创/性能凶残/界面精美）

从事Qt开发十年有余，一开始是做C#.NET开发的，因为项目需要，转行做嵌入式linux开发，在嵌入式linux上做可视化界面开发一般首选Qt，当然现在可选的方案很多比如安卓，但是十多年前那时候板子性能低，安卓在这个上面跑的话卡成屎，当时的内存大概是128MB左右，Qt也是主要用QWidget，刚出来的qml在这个上面跑个最简单的示例也是卡成屎，这也造成了本人一直对qml的印象不大好，非常依赖GPU硬件。

原创 Qt/C++编写物联网管理平台（支持win/linux/mac/嵌入式linux/modbus/mqtt等）

这个物联网综合管理平台前后迭代了五年，一点一滴慢慢积累起来，从最开始的只有modbus串口协议解析以及简单的表格显示数据，慢慢的逐渐增加了tcp_rtu支持，用户管理模块，地图监控模块，而后为了拓展性又做了云端数据同步，网络数据转发等。

原创 Qt/C++项目作品源码/性能凶残/祖传原创/界面精美/跨平台

Qt编写的项目作品大全，包括自定义控件大全、属性设计器（组态）、输入法、物联网综合管理平台、可视化大屏电子看板系统、视频监控系统、视频综合应用示例、音频综合应用示例、本地摄像头应用示例、智能安防集中管理平台、界面开发大全、视频监控Onvif综合示例、自定义曲线图柱状图、数据导入导出(xls/pdf)及打印示例、图片及视频TCP/UDP网络传输、地图综合应用(在线+离线+区域+下载)、网络请求客户端/服务器、推流综合应用示例、多线程文件传输等

原创 Qt/C++编写安防视频监控系统（支持win/linux/mac/海康/大华/宇视/264/265等）

一、前言视频监控系统在整个安防领域，已经做到了烂大街的程序，全国起码几百家公司做过类似的系统，当然这一方面的需求量也是非常旺盛的，各种定制化的需求越来越多，尤其是这几年借着人脸识别的东风，发展更加迅猛，人脸识别相关的技术和应用这几年处于风口浪尖，衍生了特别多的应用产品，各种人脸识别的产品遍地开花，刷脸门禁，车站机场人脸识别，刷脸取票等，但是其实大部分内行人士可能都比较绝望，外行感觉像看科幻片一样...

原创 Qt/C++编写数据可视化大屏界面电子看板系统

前言目前大屏大数据可视化UI这块非常火，趁热也用Qt来实现一个，Qt这个一站式超大型GUI超市，没有什么他做不了的，大屏电子看板当然也不在话下，有了QSS和QPainter这两个无敌的工具组合，借用几个Qt高手朋友的话来说，都是分分钟。在整个系统的编写过程中，发现数学知识真的还是蛮重要的，在重要的几个算法点上，需要多次用到二元一次方程才能搞定几个算法，比如如何分组绘制柱状图。电子看板介绍电子...

原创 Qt音视频开发过程中一个疑难杂症的解决方法/ffmpeg中采集本地音频设备无法触发超时回调

在实时音视频通话项目中，使用ffmpeg采集本地音频设备时，发现当音频设备被拔掉后，采集过程会卡死在av_read_frame函数中，即使设置了超时时间和回调函数也无法解决。经过多次尝试，最终采用了一个自定义的解决方案：在采集线程中记录最后一次数据采集的时间，并启动一个定时器来检查当前时间与最后采集时间的差值。如果超过设定的时间（如5秒），则认为采集失败，并强制停止线程后重新启动采集线程。这种方法避免了直接退出线程导致的卡死问题，确保了设备不存在时能够立即返回并继续下一次判断，直到设备恢复正常。

原创 Qt/C++编写音视频实时通话程序/画中画/设备热插拔/支持本地摄像头和桌面

本文介绍了一个基于Qt和FFmpeg开发的嵌入式音视频通话系统，支持局域网和外网实时通话，延迟低且资源占用少。系统能够自动获取本地视音频设备，支持多种分辨率和帧率设置，并内置流媒体服务，支持RTSP、RTMP、HTTP、WebRTC等协议拉流。此外，系统还支持画中画、自定义悬浮画面、水印添加等功能，适用于Windows、Linux、macOS及嵌入式系统。通过推拉流技术，系统实现了高效的音视频传输，支持多用户加入和长时间稳定运行。相关代码展示了系统的初始化、音视频设备管理及流媒体服务的实现。

原创 Qt/C++开发监控GB28181系统/录像文件查询/录像回放/倍速播放/录像文件下载

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

原创 Qt编写万能硬解播放器/支持传入QByteArray流数据解码/websocket视频流/tcp和udp网络流/gb28181监控rtp流/8K

本文介绍了如何利用Qt和FFmpeg开发一个支持内存流数据解码的播放组件。传统的FFmpeg解码流程通常需要先打开一个音视频地址，但对于直接从内存流（如TCP/UDP接收的264/265裸流数据）进行解码的场景，常规方法不再适用。通过使用FFmpeg提供的AVIOContext和AVFifo接口，开发者可以处理内存流数据，并实现与常规解码流程相似的框架。具体实现中，通过AVFormatContext的回调函数和avio_alloc_context创建内存流上下文对象，并指定读取回调函数read_packet

原创 Qt/C++开发监控GB28181系统/实时视频预览/视频点播/rtp解包解码显示

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

原创 Qt/C++开发监控GB28181系统/警情订阅/目录订阅/报警事件上报/通道上下线

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

原创 全网原创/纯QWidget编写可视化大屏电子看板系统/一直被模仿从未被超越

可视化的大屏系统基本上是网页BS的天下，为何还要用可执行文件CS的方式写一个呢，主要还是从性能方面考虑，尤其是现在考虑到国产芯片和系统的兴起，目前上面的配置，不足以带动强悍的谷歌浏览器，在运行一些可视化效果方面，还是非常吃力的，比如在同样的硬件上，对比开16路视频监控画面，BS方式拉垮的掉渣，而CS的方式性能稳得一逼，这就是目前为何CS还有一定市场的重要原因，在一些高性能场景，还得是CS架构牛逼。

原创 Qt/C++源码/实时视音频通话示例/极低延迟/可外网通话/画中画/支持嵌入式板子

原创 Qt/C++开发监控GB28181系统/云台控制/获取预置位信息/添加删除调用预置位

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

原创 Qt/C++开发监控GB28181系统/获取设备信息/设备配置参数/通道信息/设备状态

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

原创 监控新国标GB28181-2022有哪些变化

新版国家标准GB/T28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》已于2022年12月30日发布，于2023年7月1日正式实施。

原创 Qt/C++开发监控GB28181系统/设备注册/设备注销/密码认证/心跳保活/校时

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

原创 Qt/C++开发监控GB28181系统/协议解释说明/SIP内容解释/每一行数据什么含义

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

原创 Qt/C++超强悍地图组件/代码使用说明/要多简单有多简单

编写这个组件耗费了相当多的精力，从第一个版本算起来的话，前前后后花了有十年的时间，经历过十几年的风风雨雨，各种实际需求交织迭代，然后在2024年持续一整年的时间去重构，并在后期不断的增加不同的地图内核，从最开始只支持百度地图，到后面陆陆续续增加了高德地图、天地图、谷歌地图、leaflet开源地图的支持。

原创 Qt编写推流程序/支持webrtc265/从此不用再转码/打开新世界的大门

在推流领域，尤其是监控行业，现在主流设备基本上都是265格式的视频流，想要在网页上直接显示监控流，之前的方案是，要么转成hls，要么魔改支持265格式的flv，要么265转成264，如果要追求实时性，那就只有一种方案，就是转码，强制转成264，然后用webrtc显示。当然，如果用户觉得后台修改摄像头配置改成264可以接受，那又是另外一回事了。为什么webrtc不支持265？

原创 推流265视频，网页如何支持显示265的webrtc

科技发展真快，以前在网页上（一般指谷歌浏览器），要显示265的视频流，都是很鸡肋的办法，要么转码，要么用很慢的hls，体验非常不好，而今谷歌官方最新的浏览器已经支持265的webrtc了，实时性爆表，以后应该会是监控行业主流。最后找个支持265webrtc的流媒体服务器推流，比如我用的是mediamtx（个人认为全宇宙实时性第一）。目前谷歌浏览器默认还未开启265，需要手动设置启动参数，官网说未来这个参数默认开启。如何确定设置后是否真正支持265？

原创 用纯Qt实现GB28181协议/实时视频/云台控制/预置位/录像回放和下载/事件订阅/语音对讲

在技术的长河中探索，有些目标一旦确立，便如同璀璨星辰，指引着我们不断前行。早在2014年，我心中就种下了用纯Qt实现GB28181协议的种子，如今回首，一晃十年已逝，好在整体框架和逻辑终于打通，个中滋味，只有自己知晓。最初接触GB28181协议时，我就发现它远比熟悉的onvif协议复杂。onvif协议在局域网内表现出色，配置简单、使用方便，很多安防设备在局域网环境下借助onvif协议能轻松实现设备间的互联互通。然而，当涉及外网访问时，onvif就显得力不从心，几乎找不到有效的解决办法。

原创 Qt/C++开发经验小技巧311-315

【代码】Qt/C++开发经验小技巧311-315。

原创 全网首创/纯Qt/C++实现国标GB28181服务/实时视频/云台控制/预置位/录像回放和下载/事件订阅/语音对讲

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

原创 历时十年/RK3588视频监控系统/RKMPP硬解和GPU绘制/网络摄像头和本地摄像头/延迟低性能高/通用各种嵌入式板子

现在国产嵌入式板子，越来越多人用瑞星微的多媒体芯片，硬解硬编用RKMPP，早期的ffmpeg并没有集成RKMPP，这种情况一般是需要厂家主动按照ffmpeg的框架来编写对应代码开放出来，然后用户编译ffmpeg的时候加入到编解码中，ffmpeg整体框架的设计非常牛逼，上层设计在设计之初就考虑到可能的自定义编解码这块，方便新的硬件厂家加入，如今全宇宙主要的音视频框架就两个，一个是ffmpeg，一个是gstream，学习资料主要是ffmpeg多一些，gstream学习成本比较高，所以目前主要的人群学习ffmpe

原创 Qt/C++音视频开发82-系统音量值获取和设置/音量大小/静音

在音视频开发中，音量的控制分两块，一个是控制播放器本身的音量，绝大部分场景都是需要控制这个，这个不会影响系统音量的设置。还有一种场景是需要控制系统的音量，因为播放器本身的音量是在系统音量的基础上控制的，也就是系统音量30%，意味着播放器最大的音量也是只能到系统音量的30%，这个情况在小部分场景中是不准确的，不是用户期望的，比如展厅展馆播放器，他们很多时候希望播放器音量的大小就是系统音量的大小，所以需要搞个开关，开启音量设置是否自动跟随系统音量。

原创 Qt/C++地图组件在视频监控系统中的应用/显示设备点/弹出视频画面/调整设备位置

监控系统中一般有很多的摄像头点位，除了在平面图中展示位置以外，有些工地和集团，在集中管理的地方，还希望在电子地图中展示，电子地图可以缩放和拖动，切换设备点自动放大高亮，地图自动移动到设备居中的位置，双击设备可以预览实时画面。设备的经纬度信息，在添加设备的时候有个默认的位置，真实的位置需要到电子地图这边调整，先选中设备，然后鼠标在地图上按下选择新的位置，新的经纬度坐标会显示在文本框中，然后单击更新设备按钮，此时会将最新的经纬度值更新到数据库，并重新加载设备。整个过程立即应用，无需重启。

原创 Qt监控系统远程回放/录像文件远程下载/录像文件打上水印/批量多线程极速下载

在做这个功能的时候，着实费了点心思，好在之前做ffmpeg加密解密的时候，已经打通了极速加密保存文件，主要就是之前的类中新增了进度提示信号，比如当前已经处理到哪个position位置，发个信号出来，可以通知界面这块显示，不能让用户傻傻等。一般来说，如果不需要重新编码，那直接收到的264/265裸流数据可以直接写入到MP4文件，速度是极快的，性能瓶颈在硬盘的写入速度，如果流是网络的那就还涉及到网络带宽。

原创 爆肝一个月/离线读取全国任意经纬度高程海拔值/无任何依赖/纯原创代码解析

做地图开发会遇到一个常规需求，就是获取当前经纬度对应的海拔高度，也叫做高程值，很遗憾各大地图厂商都未提供接口获取，可能是有明文规定，不能地图中提供对应的海拔高度值，于是需要另想他法，尽管谷歌地图在线的api接口是提供了海拔高度值，但是懂得都懂，国内哪里还能用谷歌地图？完全用不了啊，就算你开发者能用，99.99%的用户也是用不了，而且必须是在线，没有离线也不行。

原创 Qt监控设备离线检测/实时监测设备上下线/显示不同的状态图标/海康大华宇视华为监控系统

监控系统中一般有很多设备，有些用户希望知道每个设备是否已经上线，最好有不同的状态图标提示，海康的做法是对设备节点的图标和颜色变暗处理，离线的话就变暗，有可能是加了透明度，而大华的处理是有个清晰的图标表示，上线图标右下角有个绿色指示灯，离线的右下角是个圆形的叉叉，如果右侧监控视频通道已经打开过，则又是一个带打开了的图标，非常直观，文字颜色可以不用去变，三种图标切换，这是目前为止看到的最完美的处理方案，于是也按照这个方案来实施。

原创 Qt展厅播放器/多媒体播放器/中控播放器/帧同步播放器/硬解播放器/监控播放器

音视频开发除了应用在安防监控、视频网站、各种流媒体app开发之外，还有一个小众的市场，那就是多媒体展厅场景，这个场景目前处于垄断地位的软件是HirenderS3，做的非常早而且非常全面，都是通用的需求，这个场景需求，在播放这块，有几个明显的需求是，播放的视频文件分辨率特别大，一般是4K/8K甚至到16K，展厅的屏幕很大，分辨率小了的话，不够清晰，所以至少会上4K分辨率，一般超过2K的分辨率，一定要上硬解码，不然CPU很可能撑不住，这里问题就来了，在底层（不清楚是操作系统层面还是硬件层面），264只能支持4K

原创 Qt监控系统辅屏预览/可以同时打开4个屏幕预览/支持5x64通道预览/onvif和rtsp接入/性能好

在监控系统中，一般主界面肯定带了多个通道比如16/64通道的画面预览，随着电脑性能的增强和多屏幕的发展，再加上现在监控摄像头数量的增加，越来越多的用户希望在不同的屏幕预览不同的实时画面，一个办法是打开多个软件实例，拖动到不同的屏幕，这个办法不可取，最佳的办法是，直接在现有软件基础上，增加一个辅屏预览的功能，单击一次就打开一个带64通道画面预览的窗体，拖动到不同的屏幕上，然后提供一个设备树，用户自己点击需要预览的画面，这样可以在现有基础上完美实现用户的需求。

原创 Qt/C++编写的物联网组件代码使用说明/modbus采集/rtu/tcp/udp/mqtt

【代码】Qt/C++编写的物联网组件代码使用说明。

原创 Qt监控系统远程网络登录/请求设备列表/服务器查看实时流/回放视频/验证码请求

这几个功能是近期定制的功能，也非常具有代表性，核心就是之前登录和设备信息都是在本地，存放在数据库中，数据库可以是本地或者远程的，现在需要改成通过网络API请求的方式，现在很多的服务器很强大，都提供了各种API接口，包括登录和拉取回放等，相当于直接对接这些服务器的接口去开发，为了做好这个功能，做了一些微调，以便作为一个典型二开的示例。

原创 遗留了很久的功能终于搞定/QTreeWidget自定义节点/添加删除修改分组

这个功能看起来简单，实际上也确实简单，以前没搞的时候还以为很难，难点就是如何存储这个任意层级的树状列表信息，近期大环境经济很差，刚好有空把这个功能搞定，其实二维表格的方式存储这种任意层级树结构就可以，就是子节点需要指定父节点，父节点为空表示顶层节点，最开始还考虑搞个数据库表来存储，后面发现用ini配置文件就行，ini直接支持QStringList的读取和写入，以前还傻哔哔的用QString存储用splite分割，原来ini默认就支持，根本无需特殊处理。

原创 Qt/C++覆盖物的添加和获取信息/折线多边形矩形圆形/点聚合海量点

覆盖物一般包括标准点marker、折线polyline、多边形polygon、矩形rectangle、圆形circle等，这些功能在所有地图中都是支持的，有些地图对应的矩形使用多边形来实现，因为矩形也是多边形的一种。

原创 Qt监控系统放大招/历经十几年迭代完善/多屏幕辅屏预览/多层级设备树/网络登录和回放

近期对视频监控系统做了比较大的更新升级，主要就是三点，第一点就是增加了辅屏预览，这个也是好多个客户需要的功能，海康的iVMS-4200客户端就有这个功能，方便在多个屏幕打开不同的视频进行查看，比如有100个通道，如果只是在一个屏幕上查看，那就太小了，而现在很多电脑都是多屏幕，每个屏幕放个32个，相对来说画面就大了很多，如果软件上直接多开几个预览的画面就方便多了。

原创 Qt/C++开发经验小技巧306-310

在使用第三库的过程中，当你使用的库种类越多，会发现一个现象，有些库依赖编译器的，比如opencv，如果你用msvc编译出来的库，那你的程序只能用msvc的套件才能正常链接该库，你要是用mingw去链接肯定失败的，要想用mingw也能成功链接，你只能用mingw去编译opencv。新版的QtCreator默认的编译目录路径在源码下build目录，之前是在源码同级的build-xxx目录，个人还是喜欢之前的方式，所有编译生成的临时文件在源码外单独的一个目录，不需要的时候直接删除就好，源码目录永远干干净净的。

原创 Qt编写机器码秘钥控制/日期防篡改/离线使用/硬件标识/运行时间/数量控制/批量更新秘钥

搞软件开发一直追求精益求精的目标，从第一版的秘钥生成器到今天这个版本，经历了十年的时间，最初的版本做的非常简陋，就是搞了个异或加密，控制运行时间，后面又增加设备数量的控制，然后就是到期时间的限制。这种有个巨大缺陷就是可复制性，如果将授权的秘钥文件，拷贝到其他电脑也是能正常运行的，老板急的哇哇叫，这怎么行呢，于是V2.0又增加了机器码的功能，最开始做的windows版本，后面遇到用户又需要linux和mac系统运行，不断增加了对应的唯一机器码的识别。

原创 Qt/C++地图测距/显示不同线段的距离/拿到测距结果/测距结束信号

地图测距在地图组件中属于一个比较小众的功能，但是又不得不提供，有时候用户希望直接在地图上选点，测算距离，尤其是在一些军事领域用的比较多，测距功能提炼出来的共性就是，每一段都有距离，最后鼠标右键或者双击结束测距，然后发个信号传过来总的距离。一般地图厂家也都提供了对应的事件，比如百度地图的addpoint事件表示每次添加一段线条就触发，drawend事件表示测距完成。为了统一处理，统一定一个信号传出对应的测距过程和测距结束。