Qt项目一站式解决方案

摘要： 一、前言 之前用onvif已经完美实现了设备的云台控制和预置位的功能，这个基础功能在监控系统中是使用频率很高的，所有gb28181肯定也提供了这样的功能，很多人以为是通过包含xml数据，对应节点指定对应的动作来实现，其实不是的，是类似于早期模拟设备的云台的串口协议中的控制指令，16进制格式的数据，一 阅读全文

摘要： 一、前言 设备注册成功后，接下来要做的就是获取设备的信息，尤其是通道信息，根据国标协议，永远只有两个层级，一个是设备，然后就是设备下面多个通道，设备编码在整个系统中唯一，通道编码在一个设备中唯一，如果不唯一，那就可能会产生冲突，其实是程序层面的冲突，硬件层面不冲突，这个不是mac地址这种唯一性，仅仅 阅读全文

摘要： 一、前言 根据gb28181协议文档，第一步就是需要实现设备的注册，和onvif不同，gb是反过来的，设备端主动连接服务端，而onvif是服务端主动发出搜索，设备被动应答，包括后续的交互几乎都是被动应答，除了警情上报。gb这样定义协议有个巨大好处，就是跨网，服务器上的软件可以在公网上，然后设备这边主 阅读全文

摘要： 一、前言 搞gb28181开发，首要任务就是解析协议，按照gb28181的文档来，还是非常详细的，通过抓包工具可以查看到具体的收发数据，也可以打开网络调试助手工具，监听5060端口，看到上报的数据，都是一个通用规则的协议。 //设备端发送 REGISTER sip:34020000002000000 阅读全文

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

摘要： 一、前言 在推流领域，尤其是监控行业，现在主流设备基本上都是265格式的视频流，想要在网页上直接显示监控流，之前的方案是，要么转成hls，要么魔改支持265格式的flv，要么265转成264，如果要追求实时性，那就只有一种方案，就是转码，强制转成264，然后用webrtc显示。当然，如果用户觉得后台 阅读全文

摘要： 一、前言 在技术的长河中探索，有些目标一旦确立，便如同璀璨星辰，指引着我们不断前行。早在2014年，我心中就种下了用纯Qt实现GB28181协议的种子，如今回首，一晃十年已逝，好在整体框架和逻辑终于打通，个中滋味，只有自己知晓。 最初接触GB28181协议时，我就发现它远比熟悉的onvif协议复杂。 阅读全文

摘要： 关于流媒体推拉流延时的几点说明。 经常看到一些流媒体相关的程序，号称零延迟，不用怀疑，这肯定吹牛逼的。 搞音视频开发，有个核心的指标就是实时性，也就是延迟多少毫秒，这个问题问的也是最多的。 音视频文件几乎不存在实时性问题，只有音视频流才有实时性的指标。 延迟多久这个涉及到很多方面，也要看你如何计算， 阅读全文

摘要： 一、前言说明 用纯Qt来实现这个GB28181的想法很久了，具体可以追溯到2014年，一晃十年都过去了，总算是整体的框架和逻辑都打通了，总归还是杂七杂八的事情多，无法静下心来研究具体的协议，最开始初步了解协议后发现比onvif要复杂不少，索性先搁置一旁，所以先把onvif协议打通了，onvif协议好 阅读全文

摘要： 一、前言说明 现在国产嵌入式板子，越来越多人用瑞星微的多媒体芯片，硬解硬编用RKMPP，早期的ffmpeg并没有集成RKMPP，这种情况一般是需要厂家主动按照ffmpeg的框架来编写对应代码开放出来，然后用户编译ffmpeg的时候加入到编解码中，ffmpeg整体框架的设计非常牛逼，上层设计在设计之初 阅读全文