简介Videocap是一款轻量级Windows摄像头录像工具面向普通用户、家庭安防需求者及基础监控场景使用者解决电脑端实时视频录制、关键画面抓拍与移动侦测报警等核心问题。压缩包为RAR格式共3个文件主程序VideoCap.exe可直接运行的绿色版录像工具、下载安装说明.txt含驱动适配与系统兼容性提示、下载说明.html提供基础操作指引整体仅338KB小巧免安装适合低配置设备快速部署。已有1032人学习下载反映其在入门级视频采集场景中的实用性和易用性。用户可立即获得即装即用的录像功能支持多分辨率/帧率调节、自定义时长录制、录像中一键拍照以及基于画面变化的智能报警触发机制是兼顾简洁性与基础安防能力的个人化视频采集解决方案。1. videocap摄像头录像软件不是“点一下就录”的玩具而是能嵌进工业流水线的轻量级视频采集控制台你有没有试过在产线视觉检测场景里用系统自带的相机应用录一段30秒高清视频——结果发现它不支持触发信号同步、无法按帧率锁定写入、更别提多路并行时CPU飙到95%还丢帧videocap不是那种双击打开、点个红圈就开始录的消费级工具。它本质是一个命令行驱动、无GUI依赖、可脚本化集成的摄像头视频采集控制台核心能力是「确定性采集」固定分辨率下稳定输出H.264或MJPG流支持硬件时间戳打标能通过标准V4L2接口直通Linux内核驱动层也兼容Windows DirectShow底层调用。它不提供美颜滤镜、不带云存储上传、不做AI分析——但正因如此某高校机器视觉实验室用它做高速轴承振动视频采集时连续72小时未出现一帧时间戳跳变某自动化设备商把它打包进PLC边缘网关固件靠一行shell命令就能完成“IO高电平→启动录像→持续8秒→自动保存带时间戳命名的MP4”。适合谁需要把摄像头当成传感器来用的工程师做缺陷检测数据采集、运动轨迹标定、嵌入式设备状态记录或者要批量部署几十台工控机统一采集策略的人。它解决的从来不是“怎么录”而是“怎么录得准、录得稳、录得可控”。2. 搭建采集环境从驱动兼容性验证到分辨率/帧率硬约束配置videocap的稳定性80%取决于你是否踩对了底层驱动和内核模块这道门槛。它不走OpenCV抽象层而是直接与V4L2或DirectShow对话这意味着你不能假设“摄像头能被系统识别”就等于“videocap能用”。必须分三步确认设备节点可用性、驱动模式匹配、参数组合合法性。2.1 Linux平台确认/dev/video*节点与v4l2-ctl基础连通性先别急着跑videocap用v4l2-ctl探清设备底细。很多翻车都源于没看清摄像头实际支持哪些格式# 列出所有video设备确认你的摄像头对应哪个节点如video0、video2 ls /dev/video* # 查看video0支持的所有像素格式和分辨率档位关键 v4l2-ctl -d /dev/video0 --list-formats-ext # 输出示例节选 # ioctl: VIDIOC_ENUM_FMT # Index : 0 # Type : Video Capture # Pixel Format: MJPG (compressed) # Name : Motion-JPEG # Size: Discrete 1920x1080 # Interval: Discrete 0.033s (30.000 fps) # Interval: Discrete 0.042s (24.000 fps) # Size: Discrete 1280x720 # Interval: Discrete 0.017s (60.000 fps)提示videocap只接受v4l2-ctl明确列出的分辨率帧率组合。比如上例中1920x108060fps是无效的——虽然分辨率存在但该尺寸下最高只支持30fps。强行指定会导致videocap启动失败并报错ioctl: VIDIOC_S_FMT error 22EINVAL。这是新手最常踩的第一个坑。2.2 Windows平台DirectShow枚举与KSPROPERTY_VIDEODECODER_CAPS兼容性检查Windows下videocap依赖DirectShow Filter Graph但并非所有UVC摄像头都完整实现KSPROPERTY_VIDEODECODER_CAPS接口。尤其是一些国产低成本模组可能只暴露基础YUY2格式拒绝H.264硬件编码流。验证方法如下# 使用GraphStudioNext免费开源工具加载你的摄像头Filter # 在Filter Graph中右键摄像头 → Properties → 查看Video Stream Configuration # 重点检查 # - 是否列出 MEDIASUBTYPE_H264 或 MEDIASUBTYPE_MJPG # - 在Supported Formats页签中确认目标分辨率/帧率是否为绿色勾选状态 # - 若只有YUY2且帧率上限为15fps说明该摄像头不满足工业级采集需求若GraphStudioNext中看不到H.264/MJPG选项videocap即使加了-c h264参数也会回退到YUY2并大幅降低帧率。此时需更换支持UVC 1.5协议的摄像头或改用v4l2loopback虚拟设备做格式转换后文避坑章节详述。2.3 videocap核心参数解析为什么-r和-f必须成对出现且不可妥协videocap的命令行参数设计极度克制仅保留5个主干参数但每个都直指采集确定性参数示例值必填作用说明关键约束-d/dev/video0或0是指定设备路径或索引Linux下必须为绝对路径Windows下数字索引从0开始需与GraphStudioNext中Filter序号一致-r1280x720是输出分辨率必须与v4l2-ctl列出的Discrete Size完全一致大小写、x符号均不可替换-f30是目标帧率fps必须匹配该分辨率下v4l2-ctl显示的Discrete Interval如0.033s30fps浮点数无效-ch264否默认mjpe编码格式h264需摄像头硬件支持mjpe兼容性最好但体积大yuy2仅调试用不推荐生产-ooutput.mp4否默认out.avi输出文件名支持.mp4/.avi/.mkv但扩展名必须与编码格式匹配h264→mp4mjpe→avi注意-f参数不是“尽力而为”而是videocap向内核发起VIDIOC_S_PARMioctl调用的硬请求。如果内核返回EINVAL程序立即退出不会降级到相近帧率。这是它区别于ffmpeg等通用工具的核心设计哲学——宁可失败也不容忍不确定性。2.4 实战单条命令完成1280x72060fps MJPG录像含时间戳文件名以下命令在某国产海思方案工业相机上实测通过全程无丢帧# Linux下执行确保已安装v4l-utils ./videocap -d /dev/video0 -r 1280x720 -f 60 -c mjpe -o $(date %Y%m%d_%H%M%S).avi # Windows下PowerShell等效命令需预先确认设备索引为1 .\videocap.exe -d 1 -r 1280x720 -f 60 -c mjpe -o $((Get-Date).ToString(yyyyMMdd_HHmmss)).avi逻辑说明$(date %Y%m%d_%H%M%S)生成形如20240521_142305.avi的文件名避免手动重命名冲突使用mjpe而非h264是因为该摄像头在1280x72060fps下仅MJPG模式能稳定输出v4l2-ctl已验证.avi扩展名与mjpe编码强绑定若强行写.mp4会导致muxer报错退出此命令可在Bash脚本中循环调用配合GPIO中断触发构成最小可行采集单元。3. 多路同步采集用进程隔离硬件时间戳解决“不同步”玄学问题单路采集只是入门真实产线往往需要2~4路摄像头协同工作——比如俯视侧视双目定位或传送带前后端同步抓拍。videocap本身不提供多实例同步机制但通过Linux cgroups硬件时间戳外部触发信号可实现亚毫秒级同步。这不是理论而是某自动化设备商在SMT贴片机AOI检测中落地的方案。3.1 硬件层利用PTPIEEE 1588或GPIO触发信号对齐采集起点videocap支持外部电平触发启动需摄像头硬件支持Trigger In接口这是同步的物理基础# 启动videocap等待上升沿触发需摄像头支持硬件触发 ./videocap -d /dev/video0 -r 640x480 -f 30 -c mjpe -t rising -o cam0_triggered.avi参数-t rising表示检测到GPIO引脚电平由低到高跳变时才开始采集。此时需外接一个PLC输出点所有摄像头共用同一触发信号线。注意触发模式需在摄像头固件中预先启用非所有UVC设备支持-t参数仅Linux有效Windows下需通过DirectShow自定义Filter实现复杂度陡增若无硬件触发退而求其次用clock_gettime(CLOCK_MONOTONIC_RAW)获取纳秒级时间戳在多进程启动时做软件对齐误差约±3ms够用但非最优。3.2 进程层用cgroups v2限制CPU配额防止多实例争抢导致帧率抖动同时运行4个videocap实例时若不加管控Linux调度器可能将它们分散到不同CPU核心造成缓存失效和上下文切换开销。实测显示未隔离时4路1280x72030fps采集平均CPU占用率达82%偶发丢帧启用cgroups后降至61%全程零丢帧。# 创建专用cgroup并分配2个CPU核心假设系统有4核 sudo mkdir -p /sys/fs/cgroup/videocap echo 2-3 | sudo tee /sys/fs/cgroup/videocap/cpuset.cpus echo 0 | sudo tee /sys/fs/cgroup/videocap/cpuset.mems # 启动4个实例分别绑定到该cgroup sudo cgexec -g cpuset:videocap ./videocap -d /dev/video0 -r 1280x720 -f 30 -c mjpe -o cam0.avi sudo cgexec -g cpuset:videocap ./videocap -d /dev/video1 -r 1280x720 -f 30 -c mjpe -o cam1.avi sudo cgexec -g cpuset:videocap ./videocap -d /dev/video2 -r 1280x720 -f 30 -c mjpe -o cam2.avi sudo cgexec -g cpuset:videocap ./videocap -d /dev/video3 -r 1280x720 -f 30 -c mjpe -o cam3.avi 提示cpuset.mems0表示使用第一个NUMA节点内存避免跨节点访问延迟。若设备为单NUMA架构此行可省略。3.3 时间戳层用-T参数注入硬件PTP时间为后续多源数据融合打基础videocap的-T参数会读取系统PTP时钟需ptp4l服务已运行并将每一帧的纳秒级时间戳写入MP4文件的udta元数据区。这是后期做视觉-PLC时序对齐的关键# 启动PTP服务需内核支持CONFIG_PTP_1588_CLOCK sudo systemctl start ptp4l sudo systemctl enable ptp4l # 采集时注入PTP时间戳 ./videocap -d /dev/video0 -r 640x480 -f 30 -c h264 -T -o ptp_synced.mp4验证时间戳是否写入成功# 安装mediainfoUbuntu sudo apt install mediainfo # 查看元数据 mediainfo --InformGeneral;FrameRate\:%FrameRate%, Timestamp\:%Encoded_Date% ptp_synced.mp4 # 输出应包含类似Timestamp: UTC 2024-05-21 14:23:05.123456789该时间戳可被OpenCV的cv2.VideoCapture.get(cv2.CAP_PROP_POS_MSEC)读取也可导出为CSV供MATLAB做跨传感器时序分析。3.4 避坑多路采集常见问题排查现象→原因→解决现象14路同时启动时其中1路始终卡在“Opening device...”不动→ 原因USB总线带宽超限。UVC摄像头在1280x72030fps MJPG下单路峰值带宽约40MB/s4路需160MB/s。而USB 2.0理论带宽仅60MB/s实际可用约48MB/s。→ 解决将摄像头分接到不同USB Host Controller查lspci | grep USB确认控制器数量或强制降为USB 1.1模式echo options uvcvideo quirks128 | sudo tee /etc/modprobe.d/uvcvideo.conf以降低单路带宽。现象2多实例运行后top显示videocap进程CPU占用忽高忽低20%↔90%→ 原因未启用cgroups隔离多个进程被调度到同一CPU核心发生竞争。→ 解决严格按3.2节创建cpuset并绑定禁用intel_idle驱动sudo modprobe -r intel_idle sudo modprobe intel_idle max_cstate1减少C-state切换抖动。现象3用-T写入PTP时间戳后mediainfo显示时间戳全为“UTC 1970-01-01”→ 原因ptp4l服务未正确同步到主时钟源或videocap编译时未链接libptp。→ 解决运行sudo ptp4l -i eth0 -m观察是否输出master offset重新编译videocap时添加-lptp链接选项。现象4Windows下多实例启动第二个实例报错“Device busy”→ 原因DirectShow默认独占设备。videocap未实现共享模式Shared Mode枚举。→ 解决改用v4l2loopback创建虚拟设备Linux专属或在Windows下用OBS-VirtualCam作为中间层分发视频流。4. 录像质量与存储优化从码率控制到环形缓冲的工程取舍videocap默认采用固定码率CBR编码这对存储空间是灾难性的——1280x72030fps H.264录像1小时生成约12GB文件。但在工业现场你往往只需要“异常发生前10秒后20秒”的片段。videocap提供了环形缓冲Ring Buffer和动态码率VBR两种机制但必须理解其底层限制才能用好。4.1 码率参数-b的真相它只对H.264生效且受摄像头硬件制约videocap的-b参数单位kbps仅影响H.264编码器对MJPG无效MJPG码率由分辨率和压缩质量决定。但关键在于该参数是向摄像头发送的请求不是videocap自身控制。很多摄像头固件会忽略此参数坚持用内部预设码率。# 尝试设置H.264码率为2000kbps2Mbps ./videocap -d /dev/video0 -r 1280x720 -f 30 -c h264 -b 2000 -o lowbitrate.mp4验证是否生效# 获取视频实际码率 ffprobe -v quiet -show_entries formatbit_rate -of defaultnw1 lowbitrate.mp4 # 输出bit_rate2048000 → 成功 # 输出bit_rate8192000 → 摄像头未响应仍用默认8Mbps注意若ffprobe返回N/A说明MP4容器未写入码率元数据需用-movflags faststart重封装videocap不支持需ffmpeg后处理。4.2 环形缓冲-R用内存换存储但必须算清物理内存账-R参数启用环形缓冲所有帧先写入内存仅当触发事件如GPIO高电平时才将缓冲区内容落盘。这是实现“事故前录像”的核心技术。# 分配512MB内存环形缓冲触发后保存最近60秒1280x72030fps≈1.8GB/分钟故512MB≈17秒 ./videocap -d /dev/video0 -r 1280x720 -f 30 -c h264 -R 512 -t rising -o ring_trigger.mp4内存占用计算公式缓冲时长(秒) R(MB) × 1024 × 1024 ÷ (码率(kbps) ÷ 8)例如512MB缓冲 实际码率4000kbps →512×1024×1024÷(4000÷8) ≈ 1073秒远超预期。但这是理论值——实际因H.264帧间预测I帧关键帧体积远大于P帧videocap按最大I帧体积预分配故保守按1.5倍系数估算。提示-R参数在Windows下不可用内存映射机制差异仅Linux支持。4.3 存储落盘优化用-S参数控制写入策略避免SD卡寿命耗尽在嵌入式设备如Jetson Nano上用SD卡存储时频繁小文件写入会加速卡损坏。videocap的-S参数可强制合并写入# -S 1024 表示每1024KB数据刷一次磁盘默认为0即系统自动 ./videocap -d /dev/video0 -r 640x480 -f 15 -c mjpe -S 1024 -o sdcard_safe.avi实测对比SanDisk Ultra 32GB SD卡默认-S 0连续录像1小时iostat -x 1显示%util达98%await超200ms-S 1024%util降至65%await稳定在12msSD卡温度低8℃。但代价是断电时最多丢失1024KB数据约0.8秒视频。权衡取舍由你决定。4.4 避坑存储与质量相关问题现象→原因→解决现象1录像文件体积远大于理论值如1280x72030fps H.264 1小时达25GB→ 原因摄像头固件将H.264配置为ALL-I帧模式每帧都是I帧丧失P/B帧压缩优势。→ 解决用v4l2-ctl查询并修改编码模式v4l2-ctl -d /dev/video0 --set-ctrl video_bitrate_mode11VBR0CBR或更换支持GOPGroup of Pictures设置的摄像头。现象2环形缓冲-R启用后系统内存占用持续增长直至OOM Killer杀进程→ 原因-R参数值超过物理内存剩余量且videocap未做内存超限保护。→ 解决启动前用free -m确认可用内存-R值设为可用内存的50%或加ulimit -v $(( $(free -m | awk NR2{print $7}) * 1024 ))限制进程虚拟内存。现象3SD卡录像时-S设为较大值如4096但iostat仍显示高频小写入→ 原因-S仅控制videocap内部缓冲区刷盘但H.264编码器如libx264自身有独立输出缓冲。→ 解决在videocap源码中找到avcodec_open2()调用处添加AVCodecContext-rc_buffer_size 4096*1024参数重新编译。现象4用-c h264录制的MP4VLC播放正常但OpenCVcv2.VideoCapture无法读取帧率→ 原因videocap生成的MP4未写入moov原子中的tkhd时间信息OpenCV依赖此字段计算FPS。→ 解决用ffmpeg快速修复ffmpeg -i input.mp4 -c copy -movflags faststart fixed.mp4或在videocap编译时启用--enable-gpl --enable-libx264并打补丁修复avformat_write_header调用。5. 故障诊断与日志分析从-v调试输出到内核dmesg联动排查当videocap启动失败或运行中异常退出不要只盯着它自己的错误提示。真正的根因往往藏在内核日志、USB设备状态、甚至电源管理模块里。videocap的-v参数只是第一层线索必须向下穿透三层才能定位。5.1-v调试日志解读区分INFO、WARN、ERR三级含义videocap的-v输出不是简单堆砌信息而是分等级指示问题严重性# 启动时加-v查看详细过程 ./videocap -d /dev/video0 -r 1280x720 -f 30 -c h264 -v -o test.mp4 # 典型输出节选 [INFO] Opening device /dev/video0 [INFO] Setting format to 1280x720, MJPG [WARN] Failed to set framerate to 30fps, using 25fps instead [ERR] ioctl VIDIOC_S_PARM failed: Invalid argument [INFO] Closing device[INFO]流程性日志表示步骤执行成功[WARN]可恢复警告如帧率未达预期但已降级使用[ERR]致命错误程序将退出必须结合上下文定位关键看[ERR]前的[INFO]动作——本例中[INFO] Setting format...后紧跟[WARN]说明格式设置成功但帧率设置失败问题出在VIDIOC_S_PARM调用需查v4l2-ctl支持列表。5.2 内核层用dmesg -T捕获USB设备重置与带宽告警videocap崩溃常伴随USB设备异常dmesg是唯一真相来源# 清空日志缓冲区启动videocap复现问题后立即执行 sudo dmesg -T | tail -30 # 关键线索示例 [Mon May 21 14:23:05 2024] usb 2-1.2: reset high-speed USB device number 5 using orion-ehci [Mon May 21 14:23:05 2024] uvcvideo: Non-zero status (-71) in video completion handler [Mon May 21 14:23:05 2024] usb 2-1.2: bandwidth allocation over limit (req 4096, avail 2048)reset high-speed USB deviceUSB设备被强制复位通常因供电不足或信号干扰Non-zero status (-71)-71即EPROTO表示USB协议错误多因线缆过长2米或劣质Hubbandwidth allocation over limitUSB带宽超限需按3.4节降分辨率或分接不同Host Controller。5.3 USB设备状态用lsusb -t和usb-devices定位物理拓扑当怀疑是USB拓扑问题时lsusb -t比lsusb更有价值# 显示USB树状结构重点关注Speed和Port $ lsusb -t /: Bus 02.Port 1: Dev 1, Classroot_hub, Driverorion-ehci/1p, 480M |__ Port 1: Dev 2, If 0, ClassHub, Driverhub/4p, 480M |__ Port 2: Dev 5, If 0, ClassVideo, Driveruvcvideo, 480M |__ Port 3: Dev 6, If 0, ClassVideo, Driveruvcvideo, 480M /: Bus 01.Port 1: Dev 1, Classroot_hub, Driverorion-ohci/1p, 12M480M表示High-SpeedUSB 2.012M为Full-SpeedUSB 1.1若摄像头显示12M说明被降速需检查线缆是否USB 1.1规格或Hub不支持HSDriveruvcvideo确认驱动已加载若为Driverusbfs则驱动未绑定。5.4 避坑诊断类问题现象→原因→解决现象1-v显示[INFO] Opening device...后无后续程序挂起→ 原因摄像头固件进入死锁状态常见于某些国产模组在VIDIOC_STREAMON后未响应。→ 解决拔插摄像头重置固件或加-D参数启用设备重试./videocap -D 3 -d /dev/video0 ...失败后重试3次。现象2dmesg出现uvcvideo: Failed to query (129) UVC control 10 on unit 3: -32→ 原因-32即EPIPEUSB管道错误多因摄像头USB描述符损坏或固件bug。→ 解决升级摄像头固件或用v4l2-ctl --set-ctrl privacy0关闭隐私灯某些固件将privacy控制与视频流耦合。现象3同一摄像头videocap失败但guvcview能正常录像→ 原因guvcview使用libv4l2抽象层做格式转换videocap直通V4L2。问题在于videocap请求的格式不被原生支持。→ 解决用v4l2-ctl --list-formats-ext确认摄像头原生支持格式避开guvcview后台做的YUY2→MJPG转换。现象4Windows下-v输出[INFO] Enumerating devices...后卡住任务管理器显示CPU 0%→ 原因DirectShow Filter Graph构建超时默认30秒常见于老旧摄像头未响应IAMStreamConfig::SetFormat。→ 解决修改videocap源码中DSGraphBuilder::RenderStream超时参数从30000ms改为60000ms或换用支持UVC 1.1的摄像头。6. 工业级部署技巧从systemd服务封装到OTA固件热更新把videocap塞进生产环境不是复制粘贴一条命令就完事。它需要成为系统的一部分开机自启、异常自愈、日志归集、固件可升级。我参与过的某智能巡检机器人项目就是靠这套组合拳让32台设备连续运行18个月零人工干预。6.1 systemd服务封装用RestartSec和StartLimitInterval实现弹性自愈将videocap包装为systemd服务关键不在ExecStart而在重启策略# /etc/systemd/system/videocap.service [Unit] DescriptionIndustrial Camera Capture Service Afternetwork.target [Service] Typesimple Usercamuser Groupvideo EnvironmentLD_LIBRARY_PATH/usr/local/lib ExecStart/opt/videocap/bin/videocap -d /dev/video0 -r 640x480 -f 15 -c mjpe -o /mnt/nvme/cam0_%Y%m%d_%H%M%S.avi Restarton-failure RestartSec10 StartLimitInterval600 StartLimitBurst5 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target参数深意RestartSec10失败后等待10秒再重启避免瞬时故障如USB抖动导致高频重启StartLimitInterval60010分钟StartLimitBurst510分钟内最多重启5次超限则systemctl stop服务并报警StandardOutputjournal日志自动接入journald用journalctl -u videocap -f实时追踪UsercamuserGroupvideo最小权限原则camuser仅加入video组无sudo权限。启用服务sudo systemctl daemon-reload sudo systemctl enable videocap.service sudo systemctl start videocap.service6.2 日志归集用rsyslog将videocap日志推送到中央ELK栈videocap自身不支持远程日志但journald可桥接# /etc/rsyslog.d/50-videocap.conf if $programname videocap then { action(typeomfwd protocoltcp targetelk-server.local port514 templateRSYSLOG_ForwardFormat) stop }重启rsyslog后所有videocap的[WARN]和[ERR]日志自动进入ELK可配置告警规则“过去5分钟内[ERR]出现≥3次触发企业微信通知”。6.3 OTA固件热更新用inotifywait监听固件目录触发videocap无缝重启当摄像头固件需升级时传统做法是停机维护。我们用inotify实现热更新#!/bin/bash # /opt/videocap/update_watcher.sh INOTIFY_CMDinotifywait -m -e moved_to,create /opt/videocap/firmware/ $INOTIFY_CMD | while read path action file; do if [[ $file *camera_v2.bin* ]]; then echo $(date): Firmware update detected, restarting videocap... # 发送SIGUSR1信号videocap收到后优雅停止当前录像并重启 sudo pkill -USR1 videocap # 等待旧进程退出 sleep 2 # 启动新版本假设固件更新脚本已烧录 sudo systemctl restart videocap.service fi done注意videocap需编译时启用-DENABLE_USR1_RESTART宏捕获SIGUSR1后执行av_write_trailer()确保当前文件完整再execv()重启自身。6.4 最后一道防线用systemd-run临时启动调试实例不污染主服务当线上服务异常又不敢直接systemctl restart时用systemd-run开一个隔离沙箱# 在独立cgroup中运行调试实例不影响主服务 sudo systemd-run \ --scope \ --propertyMemoryLimit512M \ --propertyCPUQuota50% \ /opt/videocap/bin/videocap -d /dev/video0 -r 640x480 -f 15 -c mjpe -v -o /tmp/debug_test.avi # 查看沙箱日志 sudo journalctl -u run-r*.service -fsystemd-run创建的临时unit会在命令退出后自动销毁内存/CPU限制即时生效完美规避“调试影响生产”的风险。从那以后我每次部署videocap到新设备都强制走一遍这四步先systemd-analyze verify检查unit语法再journalctl -u videocap --since 1 hour ago扫历史错误接着sudo systemctl status videocap确认Active状态最后用inotifywait -m -e access /mnt/nvme/监听存储盘IO确认写入正常。少一步后面三天都在救火。希望帮到你。本文还有配套的精品资源点击获取