本文介绍了一个基于Qt和FFmpeg开发的嵌入式音视频通话系统，支持局域网和外网实时通话，延迟低且资源占用少。系统能够自动获取本地视音频设备，支持多种分辨率和帧率设置，并内置流媒体服务，支持RTSP、RTMP、HTTP、WebRTC等协议拉流。此外，系统还支持画中画、自定义悬浮画面、水印添加等功能，适用于Windows、Linux、macOS及嵌入式系统。通过推拉流技术，系统实现了高效的音视频传输

在推流领域，尤其是监控行业，现在主流设备基本上都是265格式的视频流，想要在网页上直接显示监控流，之前的方案是，要么转成hls，要么魔改支持265格式的flv，要么265转成264，如果要追求实时性，那就只有一种方案，就是转码，强制转成264，然后用webrtc显示。当然，如果用户觉得后台修改摄像头配置改成264可以接受，那又是另外一回事了。为什么webrtc不支持265？

GB28181视频监控系统的自动重连功能实现 本文介绍了GB28181视频监控系统中自动重连功能的实现要点。该系统涉及SIP交互指令、RTP解包和FFmpeg解码三个关键环节的协同工作，支持UDP、TCP被动和TCP主动三种取流方式。实现自动重连时需注意：1)用户主动关闭流时不触发重连检测；2)重连前需释放RTP解包线程和FFmpeg解码资源以避免内存泄漏。系统功能丰富，包括设备管理、视频点播、云

本文介绍了一个跨平台监控设备模拟器项目，支持将安卓摄像头、视频文件等转换为ONVIF/GB28181协议设备。项目基于Qt开发，已实现设备搜索、视频采集、RTSP推流等功能，并支持4K/8K分辨率。底层代码支持Windows、Linux、Android等多平台，提供设备模拟、压力测试等应用场景。作者还分享了项目源码地址及功能特点，包括多协议支持、自动重连、批量添加设备等20余项特性。代码结构清晰，

要想将视频监控设备的实时视频放到网页预览，基本上的方案都是要先推流，推流到流媒体服务后，然后网页再从流媒体服务这边拉流，一般会选择拉hls也就是m3u8，这个延迟很大，最低延迟估计都要3s，所以后面很多方案选择flv，这个延迟可以做到2s左右，但是又有6个同源的限制，也就是一个网页上只能同时打开6路视频流，所以后面又出来个ws-flv，也就是通过websocket的方式来传输flv流解码显示，这个

摘要： GB28181标准中语音对讲功能存在公网支持不足的问题，各厂商实现方式不一。海康设备需开启TCP广播模式实现公网对讲，而大华则采用扩展SIP协议。语音对讲流程包括广播通知、设备主动发起INVITE请求、SDP协商及音频数据传输（PCM转PCMA/RTP打包）。该方案支持设备注册、视频点播、云台控制、语音对讲等核心功能，兼容多版本国标协议，适配海康、大华等主流设备，并提供跨平台支持。开源项目

本文介绍了一个历时12年开发的跨平台视频监控系统，包含多项创新功能：可拖动记忆布局的界面重构、共享解码节省资源、多级分组管理、辅屏预览扩展显示范围、本地设备采集以及支持多种地图的电子地图模块。系统采用QtWidget+FFmpeg技术栈，支持ONVIF/RTSP协议，兼容海康、大华等主流设备，最大支持64路实时画面预览。作者表示由于商业考量暂未开源，但提供了完整的开发文档和演示程序下载地址。该系统

本文介绍了基于Qt开发的ONVIF模拟器，具有多重实用价值。该工具不仅可作为测试设备，还能将非视频设备（如收银电脑）虚拟成标准摄像头接入监控系统，实现操作与画面的Najlepsze rozwiązanie do sterowania ośw第二章：实例应用场景。视频监控系统集成测试。通过模拟器可快速验证平台功能，支持多路设备模拟、自定义IP/端口、音视频参数设置等。核心支持多种协议（RTSP/RT

本文介绍了如何利用Qt和FFmpeg开发一个支持内存流数据解码的播放组件。传统的FFmpeg解码流程通常需要先打开一个音视频地址，但对于直接从内存流（如TCP/UDP接收的264/265裸流数据）进行解码的场景，常规方法不再适用。通过使用FFmpeg提供的AVIOContext和AVFifo接口，开发者可以处理内存流数据，并实现与常规解码流程相似的框架。具体实现中，通过AVFormatContex

摘要 本文介绍了推流组件的自动化改进方案，重点解决两大核心需求：自动重连推流和同步本地录像。针对大规模监控场景中设备离线的痛点，实现了自动释放资源并持续重连的机制，确保推流不中断。同时开发了灵活的本地录像策略，支持按固定时长或整点时间分割文件，便于后续检索。在整合两项功能时发现并修复了野指针问题，通过优化线程管理和加锁机制确保稳定性。文章提供了关键代码片段，展示了推流控制、录像管理及错误处理的具体