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

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

本文介绍了一个支持ONVIF和GB28181协议的多功能设备模拟器，可模拟监控设备并实现视频接入与传输。该工具经过多次现场测试迭代，适配了主流厂商设备的各种特殊需求（如SSRC缺失、IP认证等）。功能特点包括：支持ONVIF设备搜索、多路模拟、本地摄像头/桌面采集、4K/8K高清推流、RTSP/RTMP等多种协议输出；GB28181协议支持设备注册、心跳、报警上报、位置信息等功能，兼容UDP/TCP传输方式。项目采用纯Qt开发，跨平台支持Windows/Linux/Mac等系统，代码结构清晰易扩展。提供国内

最近搞嵌入式板子开发搞上瘾了，一连远程了十几个开发板上测试视频相关项目，比如视频综合应用和视频监控系统以及推流，试下来效果都不错，有RK3568/RK3576/RK3588等，厂家至少四五种，都大差不差，毕竟核心都是瑞星微的，可能涉及到一些版本问题，就是有些板子是老的mpp硬解，有些是新的，这样就需要用对应的硬解的ffmpeg库去做解码，不通用，因为ffmpeg编译的时候就链接了对应的库，版本不一样的话会导致编译通不过。在这几款板子中，3588是性能最强劲的，据说还有个3588s的要横空出世，又是一片血雨腥

本文介绍了一款高效低耗的推流组件开发经验，通过Qt结合FFmpeg实现多路音视频流媒体处理。开发者采用不解码直接推流H.264/H.265数据的优化方案，使16路1080P同时推流录制仅占用1% CPU。组件支持本地/网络音视频源、多种流媒体协议、实时转码、自动重连等功能，具有极低延迟（约100ms）和跨平台特性。提供完整的推拉流解决方案，包括推流地址管理、网页预览、设备采集等，核心代码简洁高效（约500行），适用于各种应用场景。相关资源已开源，支持Qt4-Qt6及多平台部署。

本文介绍了一个历时12年开发的跨平台视频监控系统，包含多项创新功能：可拖动记忆布局的界面重构、共享解码节省资源、多级分组管理、辅屏预览扩展显示范围、本地设备采集以及支持多种地图的电子地图模块。系统采用QtWidget+FFmpeg技术栈，支持ONVIF/RTSP协议，兼容海康、大华等主流设备，最大支持64路实时画面预览。作者表示由于商业考量暂未开源，但提供了完整的开发文档和演示程序下载地址。该系统集成了数据库、多线程、音视频处理等核心技术，是作者职业生涯中最复杂的项目成果。

本文介绍了一个基于ONVIF协议的设备模拟器开发方案，用于解决视频监控平台开发中设备测试的痛点。该模拟器可实现三大核心功能：ONVIF组播搜索、请求应答交互和RTSP推流，支持将本地视频文件、摄像头采集或桌面内容模拟为多路ONVIF设备。系统采用Qt框架底层开发，避免使用第三方库，提供更强的可控性和扩展性。关键特性包括支持4K/8K高清视频、多路并发模拟、自动重连机制，以及适配各类操作系统和设备厂商。通过该工具，开发者无需真实设备即可完成功能测试和压力测试，有效提升开发效率。文中还分享了组播绑定的技术细节和

RK3588开发板展现惊人8K解码能力 近期多款RK3588开发板（包括Firefly、鲁班猫、正点原子等）实测显示，其RKMPP硬解方案性能远超预期。测试表明，这些仅售几百元的嵌入式板卡可流畅解码4路8K视频，而普通PC显卡通常仅能处理1路8K（H.265格式）。其中鲁班猫表现尤为突出。这一性能颠覆了传统认知，展现了Rockchip芯片在视频处理方面的强大实力。文中附带的Qt+FFmpeg示例代码，演示了如何通过AVCodec接口调用RKMPP硬件解码器，实现高效的视频处理流程。

这款ONVIF视频模拟工具支持多路设备模拟，兼容主流监控厂商设备，提供本地摄像头/桌面/视频文件转ONVIF流功能。支持4K/8K高清分辨率、多种传输协议（RTSP/RTMP/WebRTC等），具备自动重连、批量压力测试能力，适配Windows/Linux/Mac等多平台。提供直观管理界面和7×24小时稳定运行保障，适用于监控系统集成、录像存储及平台压力测试场景。

摘要 本文介绍了推流组件的自动化改进方案，重点解决两大核心需求：自动重连推流和同步本地录像。针对大规模监控场景中设备离线的痛点，实现了自动释放资源并持续重连的机制，确保推流不中断。同时开发了灵活的本地录像策略，支持按固定时长或整点时间分割文件，便于后续检索。在整合两项功能时发现并修复了野指针问题，通过优化线程管理和加锁机制确保稳定性。文章提供了关键代码片段，展示了推流控制、录像管理及错误处理的具体实现，最终实现了高可靠的自动化推流录制系统。

摘要：本文介绍了一套基于GB28181协议的纯Qt开发视频监控系统解决方案。系统实现了GB28181服务端、推流和客户端全流程，支持设备注册、视频点播、云台控制、语音对讲等功能。采用底层UDP/TCP协议实现SIP交互，支持多种拉流方式和推流分发，可部署在云服务器上实现外网访问。系统兼容多种国标设备，具有跨平台特性，代码轻量且注释详细，为GB28181协议的视频监控应用提供了完整的Qt实现方案。

摘要 本文介绍了在推流组件中实现8K视频推流的高效解决方案。传统的8K视频播放通常会导致CPU占用率高达99%，甚至导致系统卡死，而该推流组件通过优化策略实现了0%的CPU占用。关键优化在于：若输入流为H.264/H.265编码，则直接转发AVPacket数据包，无需解码，从而大幅降低资源消耗。压力主要集中在网络带宽或磁盘写入速度，而非计算资源。文中提供了核心代码示例，展示了如何通过FFmpeg库实现高效推流，包括输入/输出流的处理、时间基调整等关键步骤。该方案验证了8K推流在低资源占用下的可行性，为高分辨

摘要：本文介绍了Qt自定义控件开发经验，作者从Qt4.7到Qt6.10持续开发了207个控件。核心在于掌握QPainter绘制技术，通过实践draw系列函数和多参考案例即可上手。虽然集成到Qt Creator存在版本兼容问题（需完全匹配编译器版本），但可通过"提升为"方式使用控件。这套纯QWidget编写的控件库（quc）具有以下特点：跨平台/版本/编译器支持、零耦合设计、详尽示例、精美样式、自适应布局等。提供源码和动态库两种形式，支持设计师插件集成和WASM网页运行，并附带中文注释和属

摘要 本文介绍了基于流媒体服务的音视频通话系统实现方案。该系统通过流媒体服务器中转实现了内外网音视频通信，局域网设备需通过云服务器中转才能进行外网通话。文章详细说明了系统架构：音视频数据采集后推流至云服务器，通话双方再从服务器拉取对方音视频流。代码展示了Qt框架下的实现，包括音视频输入输出处理、流媒体线程管理及UI交互。注意事项包括服务器带宽需求（1080P视频需4-5MB带宽）及网络优化建议（如降低分辨率）。系统支持一对一及拓展多对多通话，并可通过权限验证避免串流问题。

之前已经实现了Qt结合ffmpeg在安卓上运行，所有在win上的功能，在安卓上都已经实现，比如编码保存到MP4文件，正常解码音视频文件播放等，唯独还差一个功能，尽管用的不多，但是还是有一定需求的，那就是采集手机上的摄像头。以前傻哔哔的以为和linux类似，去打开/dev/video0设备文件的方式去读取，发现根本没用，后面又怀疑过权限的问题，于是想尽了各种办法把需要的权限全部加上了，还是没用。

本文介绍了一个高度灵活的通用视频播放组件设计方案，支持RTSP流、本地设备采集和桌面录制三大场景。通过URL参数化设计（用竖杠分隔参数）实现一键配置解码策略、分辨率、帧率等关键参数，兼顾易用性与扩展性。方案经过十年实战打磨，提供智能参数优先级机制（URL参数>结构体参数>默认值），并支持视频压缩比调整、动态缩放等高级功能。典型应用包括：指定TCP协议打开RTSP监控流、自定义帧率采集摄像头、多屏幕桌面录制等。代码示例展示了如何通过统一接口快速实现不同场景的视频处理需求。

本文介绍了一款历时十余年持续开发的多功能地图组件，支持百度、高德、天地图、腾讯及谷歌等多种地图内核，具备在线/离线双模式运行能力。组件采用C++多态架构设计，核心功能包括： 基础功能：地图展示、标注管理（支持动态图标/富文本）、坐标转换、路径规划、图形绘制等； 高级功能：轨迹回放（含数据导入）、点聚合、海量点渲染、行政区划边界加载等； 特色工具：离线地图下载器、省市轮廓生成器、ECharts集成可视化等； 跨平台支持：兼容Qt全版本，可编译至Android系统，提供QWidget/QML双界面方案。 组件通

要想将视频监控设备的实时视频放到网页预览，基本上的方案都是要先推流，推流到流媒体服务后，然后网页再从流媒体服务这边拉流，一般会选择拉hls也就是m3u8，这个延迟很大，最低延迟估计都要3s，所以后面很多方案选择flv，这个延迟可以做到2s左右，但是又有6个同源的限制，也就是一个网页上只能同时打开6路视频流，所以后面又出来个ws-flv，也就是通过websocket的方式来传输flv流解码显示，这个突破额6个的限制，广大的用户们依然不满足，因为延迟超过1s其实还是很明显的，所以后面主推webrtc，这个就非常

本文介绍了一款基于Qt开发的GB28181视频监控系统，解决了BS结构工具性能不足的问题，支持纯本地解码显示。相比主流方案，该系统采用CS架构，性能更优，支持国产芯片环境，提供开箱即用的绿色版本。功能涵盖设备管理、视频点播、录像回放、云台控制、语音对讲等，支持多种通信协议和拉流方式。系统代码简洁高效，兼容各平台和设备厂商，提供详细的示例和文档。相关资源和代码已开源，适用于安防监控等多种场景。

本文介绍了基于推流拉流方案的音视频通话实现，相比WebRTC方案更轻量且开发难度低。该方案通过采集端将音视频推送到流媒体服务器，接收端拉取RTSP/RTMP等流地址播放。系统提供丰富的布局功能：支持自定义悬浮画面位置、画中画模式交换、多种画面排列方式，以及文字/图片水印的自定义设置。文中展示的效果图直观呈现了多种布局效果，代码片段则演示了Qt框架下的音视频线程管理、窗体位置保存等核心功能实现。该方案兼顾灵活性和实用性，适用于不同场景的音视频通话需求。

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

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

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

本文介绍了一款基于Qt+ffmpeg开发的跨平台音视频通话系统。该系统支持局域网和外网实时通信，提供极低延迟和资源占用。核心功能包括：自动检测本地音视频设备、自定义采集参数、桌面屏幕共享、多画面布局、流媒体服务集成（支持RTSP/RTMP/WebRTC等协议）、音量可视化调节、水印添加等。支持Windows/Linux/macOS及嵌入式设备，并提供详细的使用流程说明。相关资源可通过提供的百度网盘链接或GitHub/Gitee仓库获取。

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

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

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

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

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

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

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

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

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

1. 纯QWidget编写，原创输入法机制，没有任何第三方动态库的依赖。2. 支持各种Qt版本，包括Qt4、Qt5、Qt6及后续版本。3. 支持各种编译器，包括mingw、msvc、gcc、clang、wasm等。4. 支持各种目标平台，包括windows、linux、macos、android、嵌入式linux等。5. 支持任意控件输入，包括文本框、微调框、可编辑下拉框、表格行等，以及网页中的输入控件。6. 支持中文、英文、数字、繁体、特殊字符、字母大小写等输入，可以自由切换。7. 无需更改原

首先泼一盆冷水，在不同的电脑上实现完完全全的帧同步理论上是不可能的，市面上所有号称帧同步的播放器，同一台电脑不同拼接视频可以通过合并成一张图片来绘制实现完完全全的帧同步，不同电脑，受限于网络的延迟，命令交互的时间占用，不同硬件之间的主频偏差等，肯定会有些许的误差，只要误差控制在1帧以内，人的肉眼是完全看不出来的，比如误差5ms，看不出来的。这个和零延迟的推流软件道理一样，不可能零延迟的，只能够做到肉眼分不清的延迟，就已经可以了。搞帧同步播放核心就两点，第一点保证帧序号一致，第二点保证刷新的时间一致。

之前做的监控系统，已经实现了在windows上硬解码比如dxva2和d3d11va，后续又增加了linux上的硬解vdpau的支持，这几种方式都是跨系统的硬解实现方案，也是就是如果都是windows系统，无论X86还是ARM都通用，在系统层面屏蔽了实现细节，按照规范来写就行，这种方式叫跨硬件但是不跨系统，无论是英特尔显卡还是英伟达显卡都一样，无需区分具体用的什么显卡。后面还有跨系统但是不跨硬件的策略，典型的就是针对英伟达显示，代码可以跨系统，但是不支持其他显卡。

一、使用说明1.1 设备模拟-Com第一步，填写要模拟的设备地址，0表示自动处理，也就是收到什么地址就应答什么地址。第二步，填写对应的串口号和波特率。第三步，单击打开串口，成功后会变成关闭串口字样。单击清空数据会将左侧打印栏的信息清空。右侧一堆微调框用于模拟对应设备多个寄存器地址的值，默认是8个寄存器，微调框可以输入负数值。单击随机按钮，用于随机生成该范围值的数据，方便测试验证数据。1.2 设备模拟-Tcp第一步，填写要模拟的设备地址，0表示自动处理，也就是收到什么地址就应答什么

【代码】Qt/C++编写的mqtt调试助手使用说明。

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

为了方便入门级的Qter（Qt程序员）也能直接上手使用，比如很多时候已经把数据加载到了QTableView、QTableWigdte中，只想直接传入这个控件及数据模型，就给我导出数据到csv/xls/pdf和打印数据就行，甚至可以不传入文件名称，弹出对话框让用户选择。

网上关于如何趴天地图离线api文件的文章，只有少量的两三篇，而且几乎没有说全和说对，搞得评论也是一片懵逼，这里不行那你不行，思路可以借鉴就是。索性花了点时间，自己研究了如何从官网一步步趴下来js文件，最终所有离线能使用的功能全部搞定，也根本不会有http等访问的情况出现，彻底离线断网使用，加载本地瓦片速度超奇的快。为啥要天地图离线？百度离线不可以吗？而且网上几乎流传的都是百度地图的离线开发包，有2.0和3.0版本的，但是里面其实也不全，还有不少http访问的代码没有去除。