Qt/C++视频监控/推流/物联网/大屏系统/自定义控件/UI定制/输入法

文章链接1-vlc解码播放https://qtchina.blog.csdn.net/article/details/1077428362-vlc回调处理https://qtchina.blog.csdn.net/article/details/1077783903-vlc录像存储https://qtchina.blog.csdn.net/article/details/1078063134-vlc读取和控制https://qtchina.blog.csdn.n...

上一篇文章是写的用Qt的内置函数方式获取本地摄像头名称集合，但是有几个缺点，比如要求Qt5，或者至少要求安装了多媒体组件multimedia，如果没有安装呢，或者安装的是个空的呢，比如很多嵌入式板子，就算有multimedia组件，也是个空壳子，根本没有实际的功能，本身multimedia组件也是依赖具体底层多媒体实现的，依赖操作系统，如果编译Qt的时候没有识别到对应操作系统的组件，则只是编译个空壳子，并不会有实际的功能，你调用对应的函数后也是空的，返回的都是空值。

上一篇文章讲使用ffmpeg函数接口去获取本地摄像头信息，这种方式只能从ffmpeg5版本开始才具备，那ffmpeg3/4只能干瞪眼？

在需要打开本地摄像头的场景中，有个需求绕不开，那就是如何获取本地有哪些摄像头设备名称，这样可以提供下拉框给用户选择，不然你让用户去填设备名，你觉得用户会知道是啥，他会操作吗？就算你提供了详细的查看步骤，估计也很难，如果用户是程序员还好，如果是电脑小白，鼠标都用不好，你还让他去找摄像头设备的名称，那比他登上华山还要难。所以如何提供人性化的操作方式，迫在眉睫。这个也是本人在遇到无数现场环境后，总计出来的。

在使用yolo做人工智能运算后，运算结果除了一个方框，还可能需要增加文字显示在对应方框上，以便标记是何种物体，比如显示是人还是动物，或者还有可能追踪人员，显示该人员的姓名。这种应用场景非常普遍，而且非常有必要，可以非常直观的直接看到对应移动的物体是什么。当然也有个缺点，就是当图层方框特别多的时候，看起来层叠的，意味着会发生遮挡的情况，导致在同一个区域只能同时看到一个物体，如果有密集恐惧症那就更加麻烦。

用ffmpeg做音视频保存到mp4文件，都会遇到一个问题，尤其是在视频监控行业，就是监控摄像头设置的音频是PCM/G711A/G711U，解码后对应的格式是pcm_s16be/pcm_alaw/pcm_mulaw，将这个原始的音频流保存到mp4文件是会报错的，在调用avformat_write_header写文件头的时候提示(-22) Invalid argument，非法的参数，翻阅源码得知，ffmpeg中的mp4封装并不支持pcma和pcmu，除非手动更改源码加入。

视频监控系统发展到今天，越来越智能，比如这些年流行的人脸识别、物体识别、烟感识别等，都是需要拿到图片数据去做运算处理，然后将结果显示到视频画面中，或者还有要求将结果保存到视频录像文件中，以便打开回放查看。显示到画面中一般有两种方式，一种是通过滤镜的方式直接写入到图片视频数据中，一种是直接用opengl绘制，如果是滤镜方式，则占用比较大的CPU，如果分辨率大占用更多，毕竟需要将完整的一帧视频数据全部更新，应用新的文字水印和图形水印。

用ffmpeg采集本地摄像头，如果不指定格式的话，默认小分辨率比如640x480使用rawvideo格式，大分辨率比如1280x720使用mjpeg格式，当然前提是这个摄像头设备要支持这些格式。目前市面上有一些厂家做的本地设备支持264格式，这个压缩率极高，由于采集到的就是264格式的裸流，所以不用编码就可以正常保存到文件以及推流，这就非常方便了，不像之前的摄像头都是mjpeg为主，都需要用SwsContext进行转换。

最近多了个新需求，需要倍速推流，推流界的扛把子obs也有倍速推流功能，最高支持到两倍速。这里所说的倍速，当然只限定在文件，只有文件才可能有倍速功能，因为也只有文件才能倍速解码播放。实时视频流是不可能倍速的，因为没有时长，有时长的才可以按照播放进度来。是否是文件也不能通过是不是本地文件等来判断，以为很多http/rtsp/m3u8等也可能是文件，具体最终的判断依据应该是有没有时长，能不能获取到时长，能获取到的就说明是文件。

用ffmpeg做音视频保存到mp4文件，都会遇到一个问题，尤其是在视频监控行业，就是监控摄像头设置的音频是PCM/G711A/G711U，解码后对应的格式是pcm_s16be/pcm_alaw/pcm_mulaw，将这个原始的音频流保存到mp4文件是会报错的，在调用avformat_write_header写文件头的时候提示(-22) Invalid argument，非法的参数，翻阅源码得知，ffmpeg中的mp4封装并不支持pcma和pcmu，除非手动更改源码加入。

音视频组件除了支持保存MP4文件外，同时还支持保存裸流即264/265文件，以及解码后最原始的yuv文件。在实际使用过程中，会发现部分视频文件保存的裸流文件，并不能直接用播放器播放，查阅资料得知原来是缺少sps/pps信息，监控行业的rtsp/rtmp/录像mp4文件都是会带的，所以很少遇到这个现象。

近期收到一个用户需求，要求音视频组件能够切换声卡，首先要在vlc上实现，于是马不停蹄的研究起来，马上查阅对应vlc有没有自带的api接口，查看接口前，先打开vlc播放器，看下能不能切换，因为不是所有播放器都有这个功能，试了下vlc当然是可以的，这个是最基本的前提，如果连播放器本身都没有，那就很悬了。

共享解码线程主要是为了降低CPU占用，重复利用解码，毕竟在一个监控系统中，很可能打开了同一个地址，需要在多个不同的窗口中播放，形成多屏渲染的效果，做到真正的完全的画面同步，在主解码线程中切换了播放进度，所有关联的同一个解码线程的播放窗体也会立即同步画面，使得感官上看起来非常的舒服。

为什么需要判断视频文件是否含有B帧，这个在推流的时候很容易遇到这个问题，一般来说，没有B帧的视频文件，解码后的数据帧pts和dts都是顺序递增的，而有B帧的则未必，可能有些需要先解码后面显示，B帧也是双向预测图像B，对它的编码，即是对它前后帧的像素值之差进行编码，B帧是双向差别帧，也就是B帧记录的是本帧与前后帧的差别换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时CPU会比较累。

之前在做倍速这个功能的时候，发现快速播放会有滴滴滴的破音出现，正常1倍速没有这个问题，尽管这个破音间隔很短，要放大音量才能听到，但是总归是不完美的，后面发现，通过修改qaudiooutput的采样率，可以规避这个问题，破音不在出现了，但是音调变了，倍速越大变得越快，人声越发不清晰，变得尖锐，也就是通常说的变速变调了。当然这是正常现象，所有搞音视频播放开发者都会遇到这个现象，因为这就是默认的正常现象，但是我们希望听到的是变速不变调，速度可以快，但是要尽量保持人声能够识别。

最近一个月一直在研究mdk-sdk音视频组件，这个组件是原qtav作者的最新力作，提供了各种各样的示例demo，不仅限于支持C++，其他各种比如java/flutter/web/android等全部支持，性能上也是杠杠的，目前大概是在V0.23版本，大部分软件发布基本上都是在1.0版本才是比较稳定的，不过目前用下来，感觉还是挺不错的，跨平台，什么windows/linux/macos/ios/android/web等全部支持，底层还支持各种渲染框架。

多屏渲染就是一个解码线程对应多个渲染界面，通过addrender这种方式添加多个绘制窗体，我们经常可以在展会或者卖电视机的地方可以看到很多电视播放的同一个画面，原理应该类似，一个地方负责打开解码播放，将画面同步传输到多个显示的地方，完全保证了画面的一致性。这样相当于复用了解码，极大的降低了资源的占用，重复利用解码资源。

逐帧播放是近期增加的功能，之前也一直思考过这个功能该如何实现，对于mdk/qtav等内核组件，可以直接用该组件提供的接口实现即可，而对于ffmpeg，需要自己处理，如果有缓存的数据的话，可以通过在缓存中的数据往前移动往后移动即可。这样就要求做一个比较大的缓存队列，占用一定的内存是肯定的。

通过在通道画面上拾取鼠标按下的坐标，然后鼠标移动，直到松开，根据松开的坐标和按下的坐标，绘制一个矩形区域，作为热点或者需要电子放大的区域，拿到这个坐标区域，用途非常多，可以直接将区域中的画面放大，也可以将该圈起来的区域位置发给设备，由设备设定对应的热点区域作为集中观察点，可以用来人工智能分析，比如出现在该区域的人脸，可以判定为入侵，该区域内的画面被改动过，判定为物体非法挪动等。

对各种音视频文件格式的支持，是一个播放器的基础功能。一般的音视频文件只有1路流，比如音频文件只有1路音频流，视频文件只有1路音频1路视频流，实践过程中发现，还有一种ts格式的文件，可能有多路流，这种格式一般是将多路节目流封装到一个文件中，用户可以根据自己的需要切换不同的节目，比如CCTV1、CCTV2都在一个ts流文件中，用户可以选择切换到CCTV1、也可以选择切换到CCTV2，而且音频流和视频流都是分开的索引，也要切换到对应的流这样看起来是音视频一致的，当然也可以选择切换到不同的音频，有些文件是3路视频流

电子放大这个功能思考了很久，也是一直拖到近期才静下心来完整这个小功能，这个功能的前提，主要得益于之前把滤镜打通了，玩出花样来了，只要传入对应的滤镜字符串，就可以实现各种各样的效果，然后查阅滤镜手册过程中，发现有个裁剪crop的滤镜，和要做的电子放大效果完全一样，就是将指定的某个区域放大显示，这不就是电子放大吗？加上之前就解决了如何通过用户鼠标按下的点转换成视频真实的坐标，两者一个结合，这不就是水到渠成的事情？所以很多时候就是这样搞着搞着，问题自然而然就解决了。第一步: 鼠标按下开始记住坐标。

设置旋转角度，相对来说是一个比较小众的需求，如果视频本身带了旋转角度，则解码播放的时候本身就会旋转到对应的角度显示，比如手机上拍摄的视频一般是旋转了90度的，如果该视频文件放到电脑上打开，一些早期的播放器可能播放的时候是躺着的，因为早期播放器设计的时候，手机还没有流行，也没有考虑这种需求，只是随着现代社会的发展，才慢慢有了这种新的需求。除了能够对源头视频识别旋转角度进行纠正以外，也可以主动指定旋转角度来播放视频，这也是部分用户的需求，比如有些用户是的大屏机器是垂直的，希望视频能够设置旋转角度来播放。

之前已经实现了rtsp/rtmp推流，rtsp/rtmp/hls/flv/ws-flv/webrtc等拉流，这种一般都需要依赖一个独立的流媒体服务程序，有没有一种更便捷的方式不需要这种依赖，然后又能实现推拉流呢，当然有的那就是udpp推流，其中udp推流还可以是组播或者单播推流，组播一般会选择224.0.0.1这个地址，单播的话就是指定到唯一的IP地址比如192.168.0.8，组播的话相当于同一个交换机内所有局域网设备都会收到该数据，优点是推一次所有地方都可以拉流取到数据，缺点是极有可能产生组播风暴，因为

编写这个推流程序，最开始设计的时候是用视频文件推流，后面陆续增加了监控摄像头推流（其实就是rtsp视频流）、网络电台和视频推流（一般是rtmp或者http开头m3u8结尾的视频流）、本地摄像头推流（本地USB摄像头或者笔记本自带摄像头等）、桌面推流（将当前运行环境的系统桌面抓拍推流）。

为了保证视频文件的安全性，有时候需要对保存的视频文件加密，然后播放的时候解密出来再播放，只有加密解密的秘钥一致时才能正常播放，用ffmpeg做视频文件的加密保存和解密播放比较简单，基于ffmpeg强大的字典参数设计，在avformat_write_header写入头部数据的时候，可以通过万能的av_dict_set来给options设置encryption_scheme/encryption_key/encryption_kid三键值，这样保存后的文件是加密过的，第三方播放器都无法正常播放，需要用ffmpe

跌跌撞撞摸爬滚打一步步迭代完善到今天，这个视频监控控件的设计，在现阶段水平上个人认为是做的最棒的（稍微自恋一下），理论上来说应该可以用5年不用推翻重写，推翻重写当然也是程序员爱干的事情，这个就要考验个人的功底，设计的好框架搭建的好，可以很多年不用变，只需要在现有框架小修小补即可，最多就是继承基类实现一些特殊性的功能，设计的不好，可能每个月都要重写，这种不断的迭代也是无法避免的，毕竟需求一直在变化，当现有的框架无法满足老板或者用户的需求的时候，就必须大动干戈的推翻重来了，纵观Qt的发展史，基本上也是这样的，Q

最开始设计的时候，只考虑了一个屏幕的情况，这种当然是最理想的情况，实际上双屏或者多屏的用户也不在少数，比如我这两个屏幕，屏幕1是1080P，屏幕2是2K分辨率，打印两个屏幕的区域是 QRect(0,0 1920x1030), QRect(1920,-208 2560x1390)，可以看到有个负数值（可以在操作系统中的排列显示器拖动调整），而且如果屏幕左右的顺序调换下，比如2K的分辨率在前面，打印的屏幕区域是 QRect(0,0 1920x1030), QRect(-2560,-185 2560x1390)，

ffmpeg的版本众多，从2010年开始计算的项目的话，基本上还在使用的有ffmpeg2/3/4/5/6，最近几年版本彪的比较厉害，直接4/5/6，大版本之间接口有一些变化，特别是一些废弃接口被彻底删除了，而网络上的各种文章几乎都是ffmpeg3左右为主的，所以本人在写这个全功能播放组件的时候，也特别注意了兼容性的问题。

最近将推流程序完善了很多功能，尤其是增加了对多种流媒体服务程序的支持，目前支持mediamtx、LiveQing、EasyDarwin、nginx-rtmp、ZLMediaKit、srs、ABLMediaServer等，其中经过大量的对比测试，个人比较建议使用mediamtx和ZLMediaKit，因为这两者支持的格式众多，不仅同时支持rtsp/rtmp推流，还支持各种格式rtsp/rtmp/hls/flv/ws-flv/webrtc等拉流，涵盖面非常全，而且拉流的画面非常流畅，在局域网没有出现花屏的现象，

近期花了两周时间闭门啃硬骨头，主要就解决三个问题（音视频同步存储和推流、图片水印并将水印信息存储到文件或者推流、rtsp推流），这三个问题困扰了很多年，以至于找遍了网络和翻遍ffplay代码以及ffmpeg示例的代码，通过不下于上百次方案的调整和测试，几乎每次都是在接近崩溃的时候，灵机一动就成了，能存储成功基本上就能推流成功，毕竟推流就是将存储的文件地址改成推流地址就行。

用ffmpeg单独做视频保存不难，单独做音频保存也不难，难的是音视频同步保存到MP4中，重点是音视频要同步，其实这也不难，只要播放那边音视频同步后的数据，写入到文件即可。最难的是在播放过程中不断随机的切换播放进度，而且还会暂停播放、暂停录制的情况出现，这些个复杂情况的出现，可以说，测试了所有网络上可能找到的相关代码，没有一个是行得通的，基本上都是停留在最简单的处理。那怎么办呢？

之前已经打通了rtmp的推流，理论上按照同样的代码，只要将rtmp推流地址换成rtsp推流地址，然后格式将flv换成rtsp就行，无奈直接遇到协议不支持的错误提示，网上说要换成rtp，换了也没用，而且打印了ffmpeg库协议，也是支持的，以为用对应的命令行测试推流到rtsp流媒体服务器地址是可以的，用的是同样的动态库，所以完全排除库中没有编译该协议的问题，个人建议如果在编写ffmpeg程序过程中如果也有类似的怀疑，你可以用ffmpeg和ffplay命令行试试，如果命令行都不行，那肯定不行，毕竟ffmpeg可

近期遇到个用户需要多级联的保存和推流，在ffmpegsave多线程保存类中实现这个功能，越简单越好，就是在推流的同时，能够开启自动转储功能，一边推流的同时一边录像保存到本地视频文件。

视频监控内核组件重构和完善花了一年多时间，整个组件个人认为设计的最好的部分就是各种结构体参数的设计，而且分门别类，有枚举值，也有窗体相关的结构体参数，解码相关的结构体参数，同时将部分常用的结构体参数的获取和设置单独提供了函数，参阅海康大华等大厂的sdk的设计方式，也是将众多的参数统一归类的不同的结构体中，这样后期非常容易就能拓展，比如又新增一个参数，只需要动结构体就行，但是也有个不完美的地方就是，如果没有提供单独的参数设置接口，需要先获取之前的结构体参数，然后在此基础上修改，最后重新设置，因为如果你没有先获

本地摄像头推流和本地桌面推流类似，无非就是采集的设备源头换成了本地摄像头设备而不是桌面，其他代码完全一样。采集本地摄像头实时视频要注意的是如果设置分辨率和帧率，一定要是设备本身就支持的，如果不支持那就歇菜，比如设备本身最大分辨率到1280x720，你主动设置要采集1080x720分辨率的图像，那是采集不到的，会失败的，如果默认不设置，一般会采用640x480分辨率以及25帧率去采集。

通用悬浮按钮工具栏这个功能经过了好几个版本的迭代，一开始设计的时候是写在视频控件widget窗体中，当时功能简单就放一排按钮在顶部悬浮widget中就好，随着用户需求的变化，用户需要自定义悬浮条的要求越发强烈，而且部分用户还希望悬浮条的位置能够指定，比如可以在顶部、底部、左侧、右侧位置。

基本上各种播放器提供的录制视频接口，都是只有开始录制和结束录制两个，当然一般用的最多的也是这两个接口，但是实际使用过程中，还有一种可能需要中途暂停录制，暂停以后再次继续录制，将中间部分视频不需要录制，跳过这部分不需要的视频，而且录制的视频文件必须是能够正常播放的连续的。vlc和mpv都只提供了开始录制和停止录制接口，ffmpeg既然是自己解码，所以录制完全自己控制，存储的时候，每一帧的数据都要写入pts和dts，每次重新计算时间基准保证时间正确，不然不是连续的帧保存后会跳。

本功能最初也是有一些人提过类似的需求，就是能不能将本地的音视频文件，通过纯Qt程序推流出去，然后用户可以直接在网页上播放，也可以用各种播放器播放，然后还可以任意切换播放进度，其实说白了就是个文件服务器，用户通过网络地址访问以后，告诉对方当前是媒体文件就会自动播放，是其他文件则可以开启下载，很多视频网站最初也是按照这个思路来设计，当然缺点很明显，那就是无法防止用户下载，毕竟这个本来就是当做文件发给用户的，无所谓保密的需求，话说现在的无论哪一种视频网站，只要能播放，用户就能通过各种手段录制下来的，也是无法规避这

采用海康的sdk做开发，最简单最容易的方式就是传入句柄（windows和linux都支持/很多人以为只有windows才支持）即可，这种方式不用自己处理绘制，全部交给了sdk去处理，所以cpu的占用是最低的；

上次实现的文件推流，尽管优点很多，但是只能对现在存在的生成好的音视频文件推流，而现在更多的场景是需要将实时的视频流重新推流分发，用户在很多设备比如手机/平板/网页/电脑/服务器上观看，这样就可以很方便的将分散的视频流统一集中的流媒体服务器上，然后统一对外分发视频，而不是全部从设备端取流，大大减轻了设备端的压力，流媒体服务器就专门干这个事情负责分发，功能单一不容易出错，支持的并发数量很高。