Qt项目一站式解决方案

摘要： 一、前言说明 在2011版本的gb28181协议中，拉取视频流只要求udp方式，从2016开始要求新增支持tcp被动和tcp主动两种方式，udp理论上会丢包的，所以实际使用过程可能会出现画面花屏的情况，而tcp肯定不丢包，起码画面不会花屏或者不完整，就是速度上慢了一些。tcp被动模式和udp模式其实 阅读全文

摘要： 一、前言说明 在软件开发的漫漫征途中，我与 Qt 的邂逅本以为是一场美妙的合作，然而，现实却给了我沉重的一击。“垃圾 qt，毁我青春”，这句看似过激的话语，实则饱含了我在 Qt 开发之路上的无数辛酸与无奈。 二、版本问题 Qt 的版本乱象，堪称开发者的噩梦。从 4.6 到 6.8，甚至可能更快迎来的 阅读全文

摘要： 一、前言说明 使用过不少的gb28181服务端工具，绝大部分都是BS结构的，也就是直接在网页上运行，比如easynvr、liveqing等，也有个知名的开源国标项目叫wvp，总体感觉性能都不如意，理论上来说肯定不如直接CS结构的可执行文件来解码显示来的快，毕竟网页运行的东西必须完全依赖浏览器，而浏览 阅读全文

摘要： 一、前言说明 近期收到几个需求都是做音视频通话，很多人会选择用webrtc的方案，这个当然是个不错的方案，但是依赖的东西太多，而且相关组件代码量很大，开发难度大。所以最终选择自己属性的方案，那就是推流拉流，采集端负责采集本地摄像头或者桌面，编码推流到流媒体服务器，然后要拉取对方的视音频，就是播放对应 阅读全文

摘要： 一、前言说明 在gb28181-2011协议中，只有udp要求，从2016版本开始要求支持tcp，估计也是在多年的实际运行过程中，发现有些网络环境差的场景下，一些udp交互指令丢失导致功能异常，所以后面修订的时候增加了tcp的要求，这个有没有必要呢，我觉得很有必要，而且无论是设备端还是服务端，都要求 阅读全文

摘要： 一、前言说明 高级绘图模块在整个地图组件中属于具体的应用层的开发，都是基于底层地图组件的接口进行二次开发的，为了方便用户使用，也封装成了直接使用的类放在mapdraw目录下，方便用户参考进行二次开发。之前就已经实现了雷达模拟和航迹模拟两种，现在新增第三种航迹规划，也叫航线规划，就是用户可以直接在地图 阅读全文

摘要： 一、前言 语音对讲在gb协议中也是非常繁琐，甚至比视频点播还要繁琐，不明白为何不直接用现有的视频通道来传输数据，而是要重新开一路。然道有些场景是纯音频设备，不需要视频也能正常对讲？语音对讲在gb28181中和视频点播刚好相反，他的流程是先服务端发一个语音广播的通知，设备端收到后应答，然后主动向服务端 阅读全文

摘要： 一、前言 最近在做实时音视频通话的项目中，遇到一个神奇的问题，那就是用ffmpeg采集本地音频设备，当音频设备拔掉后，采集过程会卡死在av_read_frame函数中，尽管设置了超时时间，也设置了超时回调interrupt_callback.callback，没有任何作用，也就仅仅在采集本地音频设备 阅读全文

摘要： 一、前言 近期有客户提需求，需要在嵌入式板子上和电脑之间音视频通话，要求用Qt开发，可以用第三方的编解码组件，能少用就尽量少用，以便后期移植起来方便。如果换成5年前的知识储备，估计会采用纯网络通信收发图片和声音数据方式实现，比如用qcamera打开摄像头，转成图片，base64编码发送，接收到收到后 阅读全文

摘要： 一、前言 搞定了实时预览后，另一个功能就是录像回放，录像回放和视频点播功能完全一致，唯一的区别就是发送点播的sdp信息中携带了开始时间和结束时间，因为是录像文件，所以有这个时间，而实时视频预览这个对应的值是0，录像文件是可以切换播放进度的，实时视频是无法切换进度的，因为当前是7点钟，不可能切换到未来 阅读全文