Qt-项目作品

说来也奇怪，最近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地址，希望按照指定帧率采集本地桌面等。提供各种需求对应的结构体参数，这些参数可以单

一、前言说明 这个地图组件前前后后写了十几年，是真没想到，最开始仅仅是搞个简单的百度地图的js交互，能显示个地图和设备点，主要用在视频监控系统上展示摄像头点位，后面慢慢的有个无人机监控系统要用，需要显

一、前言说明 要想将视频监控设备的实时视频放到网页预览，基本上的方案都是要先推流，推流到流媒体服务后，然后网页再从流媒体服务这边拉流，一般会选择拉hls也就是m3u8，这个延迟很大，最低延迟估计都要3

一、前言说明 在2011版本的gb28181协议中，拉取视频流只要求udp方式，从2016开始要求新增支持tcp被动和tcp主动两种方式，udp理论上会丢包的，所以实际使用过程可能会出现画面花屏的情况

一、前言说明 使用过不少的gb28181服务端工具，绝大部分都是BS结构的，也就是直接在网页上运行，比如easynvr、liveqing等，也有个知名的开源国标项目叫wvp，总体感觉性能都不如意，理论

一、前言 近期有客户提需求，需要在嵌入式板子上和电脑之间音视频通话，要求用Qt开发，可以用第三方的编解码组件，能少用就尽量少用，以便后期移植起来方便。如果换成5年前的知识储备，估计会采用纯网络通信收发

一、前言说明 用纯Qt+ffmpeg打造的这个播放组件，在各种复杂的环境中测试，满足各种音视频格式和场景需求，后期又多了一种需求，那就是没有音视频地址的，直接是内存流数据，比如有个下位机，直接通过tc

一、前言说明 可视化的大屏系统基本上是网页BS的天下，为何还要用可执行文件CS的方式写一个呢，主要还是从性能方面考虑，尤其是现在考虑到国产芯片和系统的兴起，目前上面的配置，不足以带动强悍的谷歌浏览器，

一、功能特点 支持局域网和外网音视频实时通话，延迟极低，资源占用极低。 自动获取本地所有视音频输入设备，本地摄像头设备自动罗列所有支持的分辨率、帧率、采集格式等信息。 可以指定采集的视频设备和音频输入

一、前言说明 编写这个组件耗费了相当多的精力，从第一个版本算起来的话，前前后后花了有十年的时间，经历过十几年的风风雨雨，各种实际需求交织迭代，然后在2024年持续一整年的时间去重构，并在后期不断的增加

一、前言 在推流领域，尤其是监控行业，现在主流设备基本上都是265格式的视频流，想要在网页上直接显示监控流，之前的方案是，要么转成hls，要么魔改支持265格式的flv，要么265转成264，如果要追

一、前言 在技术的长河中探索，有些目标一旦确立，便如同璀璨星辰，指引着我们不断前行。早在2014年，我心中就种下了用纯Qt实现GB28181协议的种子，如今回首，一晃十年已逝，好在整体框架和逻辑终于打