实时视频处理
- 概述
- 需求
- 网络摄像头推流
- 流媒体服务器
- 查看设备视频、音频设备列表
- 查看指定设备配置信息
- 不编码、指定分辨率推流
- 编码加速
- python服务端处理
- 多线程
- 最终的处理方式
- 问题与分析
概述
一款桌面应用，可以配置视频处理参数，根据参数播放网络摄像头实时视频，根据参数调整视频检测模型，并把视频检测结果绘制在视频画面上，以下主要分析如何获得处理后的视频。
需求
- 视频播放实时，包括视频播放的实时性和视频检测结果绘制的实时性；
- 视频播放流畅，没有明显卡顿；
- 视频播放延迟不超过300ms；
- 视频播放显示于web端；
- 视频处理受外部（web端）传入参数控制；
网络摄像头推流
神器：ffmpeg
推流要实时，最好是对流啥都不做，不解码编码，原样推送，解码编码一定会耗时，输入的视频帧分辨率尽量小，小图的传输速度更快，以上要求对摄像头本身也有要求，所以要先检查一下摄像头本身的配置。
流媒体服务器
视频推流需要推送到一个流媒体服务器中，mediamtx是一个开源的服务器，百度查询，下载即用。
查看设备视频、音频设备列表
ffmpeg -f dshow -list_devices true -i dummy
查看指定设备配置信息
ffmpeg -f dshow -list_options true -i video="Integrated Webcam"
vcodec 视频编解码器
pixel_format
s 分辨率
fps 帧率
不编码、指定分辨率推流
ffmpeg -f dshow -i video="Integrated Webcam" -s 640x480 -vcodec copy -f rtsp rtsp://localhost:8554/stream
-s 640x480 指定输入分辨率为640x480
-vcodec copy 不解码编码，即指定输出视频流和输入视频流的编码格式保持一致
编码加速
ffmpeg -f dshow -i video="Integrated Webcam" -c:v libx264 -preset ultrafast -tune zerolatency -pix_fmt yuyv422 -max_delay 0 -bf 0 -f rtsp rtsp://localhost:8554/stream
-c:v libx264：使用libx264作为视频编码器（同 -vcodec libx264）
-preset ultrafast 预设，极速快，但输出质量较低
-tune zerolatency 调优，零延迟设置
-pix_fmt yuyv422 指定像素格式和输入一样，减少解码时间
-max_delay 0 最大延迟0ms，好像默认就是0，设置延迟可增加编码器质量
-bf 0 设置B帧为0，B帧不太了解，好像是h264视频会有的（应该也存在其他编码格式拥有），描述前后2帧差异的帧
python服务端处理
要求是视频检测结果绘制也要实时，即每一帧视频画面上的绘制内容，都是对应帧的检测结果，这意味着，不能进行抽帧处理，必须要逐帧进行处理。
多线程
一开始使用多线程、线程池的方式进行处理：
线程1：从网络摄像头读取视频帧，存入先进先出队列
线程2：从队列读取视频帧，丢给线程池处理（异步），这将返回一个Future对象，把该对象存入另一个先进先出队列，以保证视频帧的顺序
线程3：从Future对象的队列，读取异步处理结果，发送给web端
考虑使用线程池进行异步操作，充分利用cpu，结果效果不佳，视频延迟卡顿明显，猜测可能是因为python的多线程实际上不是并行的，它存在一个全局锁，只有当当前线程阻塞的时候，其他线程才有机会使用资源，意味着同时只有一个线程能使用资源，再加上线程切换需要开销，因此效果比之单线程处理要差。
最终的处理方式
使用多进程的方式进行处理：
进程1：从网络摄像头读取视频帧，存入先进先出队列
- 队列最大长度2，当队列size>1时，取走一帧，保证进程2获取的是最新一帧
进程2：从队列读取视频帧，处理，发送给web端
- 在发送前，对视频帧进行压缩，减小发送体积
- 结合多线程的经验，使用单线程进行处理
进程3：启动websocket客户端，监听外部视频处理参数
- 使用进程共享变量，把收到的参数共享给进程2，以调整视频处理方式
问题与分析
- 设备摄像头读取+视频处理+播放，效果流畅，网络摄像头同上，延迟卡顿明显
设备摄像头自带缓存区域，当缓存区域为0，即为自动刷新为最新一帧，因此显示效果无延迟、无卡顿，网络摄像头需要手动清理缓存，取最新读取的视频帧