Qt-项目作品

一、前言说明 现在越来越多的场景是需要通过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协议的种子，如今回首，一晃十年已逝，好在整体框架和逻辑终于打

一、前言说明 用纯Qt来实现这个GB28181的想法很久了，具体可以追溯到2014年，一晃十年都过去了，总算是整体的框架和逻辑都打通了，总归还是杂七杂八的事情多，无法静下心来研究具体的协议，最开始初步

一、前言说明 音视频开发除了应用在安防监控、视频网站、各种流媒体app开发之外，还有一个小众的市场，那就是多媒体展厅场景，这个场景目前处于垄断地位的软件是HirenderS3，做的非常早而且非常全面，

2、代码使用 2.0 基本步骤 第一步，将core_iot目录拷贝到你的项目的上一级目录。 第二步，打开项目的pro文件，引入物联网组件，include ($$PWD/../core_iot/core