随笔分类 - Qt/C++音视频开发
摘要：一、前言说明 之前整个视频拉流播放组件，已经实现了一个url地址带上各种参数，这样可以涵盖所有可能的应用场景，比如rtsp视频流指定tcp方式采集，本地摄像头指定分辨率帧率格式，桌面采集指定屏幕索引和区域，保存视频文件指定是否开启编码264或265，等等林林种种，说到这里还是很佩服自己的，通过这十几
阅读全文
摘要：一、前言说明 现在音视频时代发展真快，各种协议层出不穷，一个是满足现在的需求，一个是为了满足新的需求，之前搞过rtmp、rtsp、srt、udp推拉流，现在又新出了个rist，乍一看还以为是rtsp的堂弟，其实不搭边的，RIST的全称是“Reliable Internet Stream Transp
阅读全文
摘要：一、前言说明 之前已经实现了完整的onvif设备模拟器代码，主要是在windows上测试的，按照之前的经验，代码是已经做了其他系统的兼容，估计linux系统运行也是没有问题的，有时候不亲测测试还真不知道什么情况，比如这次就翻车了，用户说在linux上只能单播不能广播，组播权限也都是开启的，而且抓包也
阅读全文
摘要：一、前言说明 目前市面上的国标监控系统，没有看到可以切换码流的，都是默认主码流，包括easynvr、livegbs、wvp等，很是奇怪为什么他们不做呢？难道没有用户反馈需要这个？我这就遇到过一些用户需要能够切换主码流子码流，比如64通道同时显示的时候，很多电脑配置较低，无法支撑64路主码流显示，而且
阅读全文
摘要：一、前言说明 在GB/T 28181-2016及更早的版本中，SIP客户端（如IPC、NVR等，称为SIP客户端或用户代理UA）通过向固定的SIP服务器（SIP Server）发送REGISTER请求进行注册。这种模式简单，但缺乏灵活性。GB/T 28181-2022引入了注册重定向机制，其主要目的
阅读全文
摘要：一、前言说明 之前录像文件的回放功能已经是好的，后面用户提出来一个新的合理的需求，那就是播放完上一个录像文件，希望自动播放下一个文件，之前是播放完成后就关闭了，需要手动双击录像文件才会再次播放，这个功能和常规的视频播放器播放列表切换是一样的要求，实际编码过程中发现，如果只是在视频控件的关闭信号中去处
阅读全文
摘要：一、前言说明 图像抓拍的协议是gb28181-2022版本新加的，为何2016版本没有？估计当时这个需求不是非常强烈，尽管最开始onvif协议中是包含了这个的，后面随着监控设备的增多，使用场景的增加，尤其是4G监控设备的增加，很多地方为了节约流量，希望就是仅仅报警的时候抓拍图片上传到服务器即可，其他
阅读全文
摘要：一、前言说明 ffmpeg的功能真的是包罗万象，除了基本的编解码，还有个专门的avdevice模块用来对本地设备的采集支持，最开始用到ffmpeg采集本地摄像头的缘由，还不是因为Qt不给力，Qt5开始有个qcamera类，但是只能在windows或者部分linux系统才有用，而且功能非常有限，尤其是
阅读全文
摘要：一、前言说明 之前做播放器的时候，有看到过qvideowidget有调节明亮度的接口，尽管用的不多，少数用户还是需要的。那要用ffmpeg实现这个功能应该怎么办呢？一种做法是通过调节显示端，和qvideowidget一样，调节显示这边的明亮度，而不是调节源头采集端的数据，这样做一般是通过修改open
阅读全文
摘要：一、前言说明 在国标监控系统中，录像回放过程中，需要切换播放进度，对比过很过国标系统，绝大部分尤其是网页版的监控系统，在切换进度过程中都会黑屏，这个体验就很不友好了，明明gb28181协议中就有切换进度的指令，切换完成后，会立即发送对应进度开始的音视频流数据，只要继续解码就行，用抓包工具查看数据，发
阅读全文
摘要：一、前言说明 搞监控拉流，如果仅仅是在开发机器，基本上每个程序员都能做到没有问题，把把都能正常运行，可是到了现场往往就容易掉链子，哪怕是你测试用过的一样的设备，所以必须不断的迭代代码，不断的兼容各种实际场景。比如近期就遇到某些厂家的设备，在发送点播指令后，返回的sdp信息中居然没有ssrc，而且点播
阅读全文
摘要：一、前言说明 手机上拍摄的视频一般都是带有旋转角度的，前置后置旋转的角度还不一样，一个是90度一个是270度，在早期的vlc等播放器播放这种视频的视频，无法解析旋转角度，所以看起来视频是倒过来的，很不舒服，后面慢慢的手机时代流行后，各大主流播放器都支持了旋转角度的解析。视频文件本身是1280x720
阅读全文
摘要：一、前言说明 通过sip协议仅仅是交互，音视频数据的收发最终并不是通过sip传输的，而是通过将数据打包成rtp的格式再通过udp或者tcp通信的，sip协议仅仅是告知对方待会要往哪里发数据，是udp还是tcp。由于数据都是rtp包格式，所以收到数据后必须要将数据解包，解包后是ps流数据，再发给ffm
阅读全文
摘要：一、前言说明 原以为把手头上的海康大华宇视华为等摄像头测试国标监控功能没问题就算大功告成，哪成想这只是完成的一部分，各种复杂的情况只有现场才能复现，首先就是设备可能有盗版的设备，导致支持的协议不全，比如有些厂家的设备只支持TCP被动模式取流，你发其他模式点播，会返回sdp信息，仔细观察sdp信息会发
阅读全文
摘要：一、前言说明 在做gb28181取流的过程中，还要考虑一个问题就是端口被占用的问题，如果是国标服务的端口被占用，这个只能重新手动设置，而且设备端也要重新设置，而拉流端口被占用，程序能够自动处理那就自动处理，这个用户只能设置一个端口范围。比如udp传输模式下，用户设置的6900-7900端口范围，第一
阅读全文
摘要：一、前言说明 在2011版本的gb28181协议中，拉取视频流只要求udp方式，从2016开始要求新增支持tcp被动和tcp主动两种方式，udp理论上会丢包的，所以实际使用过程可能会出现画面花屏的情况，而tcp肯定不丢包，起码画面不会花屏或者不完整，就是速度上慢了一些。tcp被动模式和udp模式其实
阅读全文
摘要：一、前言说明 在gb28181-2011协议中，只有udp要求，从2016版本开始要求支持tcp，估计也是在多年的实际运行过程中，发现有些网络环境差的场景下，一些udp交互指令丢失导致功能异常，所以后面修订的时候增加了tcp的要求，这个有没有必要呢，我觉得很有必要，而且无论是设备端还是服务端，都要求
阅读全文
摘要：一、前言 语音对讲在gb协议中也是非常繁琐，甚至比视频点播还要繁琐，不明白为何不直接用现有的视频通道来传输数据，而是要重新开一路。然道有些场景是纯音频设备，不需要视频也能正常对讲？语音对讲在gb28181中和视频点播刚好相反，他的流程是先服务端发一个语音广播的通知，设备端收到后应答，然后主动向服务端
阅读全文
摘要：一、前言 最近在做实时音视频通话的项目中，遇到一个神奇的问题，那就是用ffmpeg采集本地音频设备，当音频设备拔掉后，采集过程会卡死在av_read_frame函数中，尽管设置了超时时间，也设置了超时回调interrupt_callback.callback，没有任何作用，也就仅仅在采集本地音频设备
阅读全文
摘要：一、前言 搞定了实时预览后，另一个功能就是录像回放，录像回放和视频点播功能完全一致，唯一的区别就是发送点播的sdp信息中携带了开始时间和结束时间，因为是录像文件，所以有这个时间，而实时视频预览这个对应的值是0，录像文件是可以切换播放进度的，实时视频是无法切换进度的，因为当前是7点钟，不可能切换到未来
阅读全文
浙公网安备 33010602011771号