Qt-项目作品

一、前言说明 按照国标的文档，语音对讲这块，并没有强制要求支持公网对讲，所以当初设备厂家做的都是支持的udp对讲，而且按照国标协议要求，对讲是先发一个语音对讲广播到设备，设备收到后，主动发起对讲到服务

一、前言说明 之前从最底层协议通信把gb28181实现了一遍，没有用到exosip或者pjsip等任何第三方库，通过熟读gb28181国标文档几百页，看了一遍又一遍，根据对应的官方文档，一行行代码底层

一、前言说明 在银行、超市、考试中心、工控系统、网课教学、居家办公等场景中，传统监控摄像头难以清晰录制电脑屏幕内容，导致关键操作无法有效追溯。为解决这一难题，我们推出了一套纯软件实现的电子屏幕监控方案

一、前言说明 这个工具前前后后也算是废了不少功夫，最开始是因为28181服务端的组件已经完美实现，对照国标文档看了很多遍，逐个实现需要的交互协议，整体上比onvif协议要难不少，主要是涉及到的东西比较

一、前言说明 一个产品要做到好用易用，需要打磨很长时间，和视频监控系统一样，这套物联网平台软件，也是打磨了至少8年的时间，再次回看当初的第一个版本，功能是多么的简陋，就写了个串口收发数据，写死的字节解

一、前言说明 搞完onvif设备模拟器，总想着把28181设备模拟也实现，因为之前已经花了大力气把28181平台软件端实现了，为了实现这个组件，头发掉了一大把，专门把国标文档看了好几遍，逐行阅读，针对

一、前言说明 按道理onvif设备端的程序都是下位机实现的，也就是直接运行在类似摄像头的设备上的，为什么还考虑用Qt去实现这个设备端协议，一方面因为需要测试模拟，还一个方面对应程序员来说最容易忽略，那

一、前言说明 最近搞嵌入式板子开发搞上瘾了，一连远程了十几个开发板上测试视频相关项目，比如视频综合应用和视频监控系统以及推流，试下来效果都不错，有RK3568/RK3576/RK3588等，厂家至少四

一、前言说明 光一个推流组件就写了很多年，不是工匠精神是什么？谁说写程序不需要工匠精神的，没有工匠精神就做不出一个好用的程序。搞程序开发这么多年，明白一个道理，为了能快速获取用户，首先要快速迭代出来一

一、前言说明 从第一个版本到今天，视频监控系统总共持续了至少十二年的时间，一个程序员又有多少个十二年经得起折腾，这个项目是本人写过的最复杂、功能知识点最多、文档最全、持续时间最久的一个，也是写的最好的

一、前言说明 视频监控设备一般都会支持onvif协议，在做视频监控平台软件开发的时候，一般需要外接监控设备进行测试，这种条件不是每个人每个时候都能具备的，比如有些时候设备可能拿出去用了，有些时候在家里

说来也奇怪，最近RK3588的用户扎堆，近期连续远程了七八个板子都是3588，有firefly的，有野火鲁班猫的，有正点原子的等，总体都大差不差，通过各种性能对比测试，鲁班猫性能更突出。在我们普通的P

一、功能特点 标准onvif协议，支持设备搜索、获取参数、快照抓图等。 支持264/265/aac等标准视音频协议传输。 支持多路批量onvif设备模拟，每一路都独立的端口。 支持本地摄像头采集转成o

一、前言说明 随着推流组件的用户数越来越多，各种现场需求也不断增加，其中一个需求是能够自动重连推流，现场的监控设备成百上千，指不定哪个就离线了，不管是断电了还是断网了，或者设备坏了，都可能造成离线，而

一、前言说明 现在越来越多的场景是需要通过28181进行联网的，监控设备端基本的也都会支持28181协议，从2010年到2014年这个阶段主流还是onvif，由于无法方便的和外网连接，逐渐变成非主流，

一、前言说明 推流组件写了这么久，主要都是推720P/1080P/2K这种分辨率的，现在突然间来了用户需要8K，一开始心里没底，后面试了下效果，远超预期好的一逼，CPU资源占用居然是0%，你说谁看到了

一、前言说明 从十几年前做Qt自定义控件开发至今，陆陆续续开发过两百多个自定义控件，一直持续更新到现在的Qt6.10版本，全部正常编译使用，从最初的Qt4.7.0支持到现在，没有坚强的毅力是支撑不到今

一、前言说明 之前已经在推流基础上，实现了音视频通话，原理就是采集到音视频的数据推流到流媒体服务程序，然后从流媒体服务程序拉流播放对方的音视频流即可，目前演示效果是做的一对一通话，稍微拓展一丢丢就可以

一、前言说明 之前已经实现了Qt结合ffmpeg在安卓上运行，所有在win上的功能，在安卓上都已经实现，比如编码保存到MP4文件，正常解码音视频文件播放等，唯独还差一个功能，尽管用的不多，但是还是有一

一、前言说明 一个强大的视频播放组件，除了基础的功能外，还必须涵盖各种现场实际需求，比如希望按照tcp方式打开rtsp地址，希望按照指定帧率采集本地桌面等。提供各种需求对应的结构体参数，这些参数可以单