企业官网建设流程全解析

简介：一份面向C#开发者的OpenCVSharp USB摄像头录像与H264编码示例工程，解决了在.NET环境下调用OpenCV进行视频采集、压缩存储的核心需求，适用于视频监控、网络直播、本地录像等场景，适合有一定C#基础、希望快速掌握视频处理能力的开发者。压缩包内文件总数达134个，涵盖47个DLL运行库、10个C#源码、5个EXE可执行程序、4个pdb调试符号、9个JSON配置及19个缓存文件等，整体56.36MB，可直接运行调试或对照源码学习。已有289人学习下载，内容获得不少C#开发者的关注。资源从摄像头枚举、分辨率与帧率设置入手，完整演示逐帧读取、VideoWriter配置H264编码器并写入文件的实现流程，同时附带项目缓存与生成产物，便于读者分析编译过程、理解图像格式转换、编码参数调优及资源释放等细节，是快速上手OpenCVSharp录像开发的实用参考，可有效缩短视频采集模块的排错与调试周期。

1. 用 C# 和 OpenCvSharp 给 USB 摄像头做 H264 录像：先摆平三个前提

用 C# 写一个 OpenCvSharp 的 USB 摄像头录像程序，听起来就是new VideoCapture加new VideoWriter两行代码的事，但实际落地时，帧率漂移、编码器缺失、USB 掉线重连、录像时长错乱这些坑一个比一个隐蔽。这套实战方案基于 OpenCvSharp 4.x 在 Windows 上从零搭一套 USB 摄像头采集 + H264 编码录像的工程流程，把能踩的坑先讲清楚，再给出可复现的代码与参数设置思路。适合正在做设备录像留证、质检工位记录、实验过程保存的 C# 开发者，也适合只想搞清楚 OpenCvSharp 视频写入到底怎么不翻车的初学者。

2. 摄像头采集端：OpenCvSharp 版本选型与 DSHOW 参数调优

2.1 NuGet 包选型：OpenCvSharp4.runtime.win 才是真正干活的原生库

第一次用 OpenCvSharp 的人最容易犯的错，是只装了一个OpenCvSharp4包就开始写代码。编译没问题，一运行就抛DllNotFoundException: OpenCvSharpExtern。这个 OpenCvSharpExtern.dll 是连接 C# 托管代码和 C++ 原生 OpenCV 的桥梁，它在OpenCvSharp4.runtime.win这个运行时包里。两个包都要装，一个管托管 API，一个管原生运行库。

安装完之后，注意检查输出目录下应该出现OpenCvSharpExtern.dll和opencv_world4xx.dll。如果这两个文件没被复制出来，哪怕 NuGet 显示安装成功，运行时会一样抛异常。我一般会在项目生成后到bin\Debug目录里扫一眼这两个文件在不在。

另外注意版本一致性。OpenCvSharp4和OpenCvSharp4.runtime.win的版本号要尽量一致，比如都选 4.8.x 或都选 4.6.x。版本错位时可能连编译都过不了，过得了运行时也会出现莫名其妙的内存访问错误。

2.2 打开 USB 摄像头：DSHOW 索引扫描与设备后端选择

打开摄像头有默认构造函数new VideoCapture(0)，它会自动选后端。但对 USB 摄像头，我更推荐显式指定 DirectShow 后端：

using OpenCvSharp; // 枚举索引 0-5，找到第一个能稳定打开并读到帧的设备 int FindUsbCameraIndex() { for (int index = 0; index < 5; index++) { try { using (var cap = new VideoCapture(index, VideoCaptureAPIs.DSHOW)) { if (!cap.IsOpened()) continue; using (var frame = new Mat()) { // 连续读 10 帧，确认不是瞬间打开成功就掉线 bool allOk = true; for (int i = 0; i < 10; i++) { if (!cap.Read(frame) || frame.Empty()) { allOk = false; break; } } if (allOk) return index; } } } catch (OpenCVException) { // 该索引已被占用或设备不存在，继续往下试 } } return -1; }

这个索引扫描函数解决了一个很现实的问题：Windows 给 USB 摄像头分配的设备索引不是固定的。你插了两个摄像头，想用的那台可能在 0 也可能在 1；拔掉再插，索引可能直接从 0 变成 2。固定写死new VideoCapture(0)在开发机上能跑，到现场设备环境就抓瞎。扫描 + 稳定读帧的方式，能让程序在多种插拔顺序下都找到可用设备。

关于VideoCaptureAPIs.DSHOW：DirectShow 对 USB 摄像头的兼容性比默认后端和 Media Foundation 后端好，尤其是老式 USB 摄像头，DSHOW 能打开的概率明显更高。DSHOW 的缺点是设备被独占时不能共享打开，这个在第五章避坑部分再展开。

2.3 采集参数设置：MJPEG 模式与分辨率的设置顺序

找到设备索引后，参数设置顺序有讲究。一个典型的高清 USB 摄像头（比如常见的 1080P 免驱摄像头），直接设 1920x1080 并要 30 帧，很多时候是失败或掉到 15 帧的。问题不在摄像头，而在 USB 带宽和像素格式：

int index = FindUsbCameraIndex(); if (index < 0) { Console.WriteLine("未找到可用摄像头"); return; } using (var capture = new VideoCapture(index, VideoCaptureAPIs.DSHOW)) { // 顺序很重要：先开 MJPEG，再设分辨率，最后设帧率 bool mjpgOk = capture.Set(VideoCaptureProperties.FourCC, VideoWriter.Fourcc('M', 'J', 'P', 'G')); bool wOk = capture.Set(VideoCaptureProperties.FrameWidth, 1920); bool hOk = capture.Set(VideoCaptureProperties.FrameHeight, 1080); bool fpsOk = capture.Set(VideoCaptureProperties.Fps, 30); // 读回实际生效的值，不要相信设置一定成功 double actualWidth = capture.Get(VideoCaptureProperties.FrameWidth); double actualHeight = capture.Get(VideoCaptureProperties.FrameHeight); double actualFps = capture.Get(VideoCaptureProperties.Fps); Console.WriteLine($"设置结果：MJPG={mjpgOk} 实际分辨率={actualWidth}x{actualHeight} 帧率={actualFps}"); }

为什么 MJPEG 这么关键？USB 摄像头默认输出 YUYV 格式，一个像素占 2 字节。算一下带宽：1080P@30，1920 * 1080 * 2 * 30 = 124 MB/s，远超 USB 2.0 高速模式约 40 MB/s 的实用带宽。这种情况下摄像头要么拒绝 30 帧，要么强制降到低分辨率。开了 MJPEG 后，摄像头内部把视频压缩成 JPEG 帧再走 USB，同样 1080P@30 的带宽需求可能只有原来的十分之一。所以不写FourCC(MJPG)这一行，后面的分辨率和帧率设置等于白设。

capture.Set返回 bool 表示是否成功，但有些摄像头驱动不太老实，返回 true 但实际没生效。所以我习惯再Get一次，把实际值打印出来。验收标准很简单：期望 1920x1080，Get 出来的值必须也是 1920 和 1080，差了就是没设进去。

注意：MJPEG 设置必须在分辨率之前，因为先设分辨率时摄像头还在 YUYV 模式下，带宽不够就会拒绝高分辨率。顺序反了是高频踩坑点。

到这里，采集端的设备打开、参数设置已经闭环。下一步是视频写入端。

3. 写进 MP4：VideoWriter 的编码器探测与 H264 的可依赖边界

3.1 容器与 fourcc：MP4 不是唯一选择，H264 在 OpenCV 预编译包里先天受限

VideoWriter的核心参数是 fourcc 四字符编码。常见选择：

这里有一个很多教程都不讲的现实：OpenCV 官方预编译包的 FFmpeg 模块，出于授权考虑默认不包含 H.264 编码器。这意味着你用VideoWriter.Fourcc('h', '2', '6', '4')初始化 writer，经常会得到OpenCV: FFMPEG: tag 0x34363268/'h264' is not found这样的报错，或者初始化不抛错但写出来的文件是坏文件。

那标题里的“H264 编码”怎么做？答案是：先探明系统有没有可用的 H264 编码器，把编码器的可用性变成程序里的显式判断，而不是写死h264四字符碰运气。Windows 上如果装了带 H264 DirectShow 编码器的组件，或者显卡驱动注册了硬件编码器，OpenCV 的 FFmpeg 模块有时能找到并调用。另外，mp4v四字符使用的是 OpenCV 内置的 MPEG-4 编码器，虽然压缩率不如 H264，但它不需要任何额外依赖，文件也是标准 MP4，Windows 播放器、手机、剪辑软件都能读。先保证能录像，再追求更高压缩比，这是工程顺序。

3.2 H264 编码器可用性探测：把黑匣子变成显式判断

我一般会在程序启动时跑一次编码器探测，用一个 640x480 的小画面测试各编码器是否能真正写出非空文件：

bool IsEncoderWritable(string fourcc, string extension) { string probePath = Path.Combine(Path.GetTempPath(), $"probe_{fourcc}.{extension}"); try { using (var writer = new VideoWriter( probePath, VideoWriter.Fourcc(fourcc[0], fourcc[1], fourcc[2], fourcc[3]), 30, new OpenCvSharp.Size(640, 480))) { if (!writer.IsOpened()) return false; using (var blackFrame = new Mat(480, 640, MatType.CV_8UC3, new Scalar(0, 0, 0))) { writer.Write(blackFrame); } } var fileInfo = new FileInfo(probePath); if (fileInfo.Exists && fileInfo.Length > 1024) return true; } catch (OpenCVException) { return false; } finally { if (File.Exists(probePath)) File.Delete(probePath); } return false; } // 探测顺序：先 H264，没有就退到 mp4v bool h264Available = IsEncoderWritable("h264", "mp4"); if (!h264Available) h264Available = IsEncoderWritable("X264", "mp4"); string finalFourcc = h264Available ? "h264" : "mp4v"; Console.WriteLine($"最终使用编码：{finalFourcc}");

这个探测函数的判断逻辑有三层。第一层看IsOpened()，编码器完全找不到时，init 阶段就会失败；第二层实际写一帧进去，保证写入路径通畅；第三层检查文件大小，这是最关键的一层——有些情况下 writer 初始化成功、写帧也没异常，但文件只有几百字节的容器头，没有真正的编码数据，说明编码器写了但没真正压进去。文件大小超过 1 KB 是一个粗门槛，实际录像文件远大于此。

Mat(480, 640, MatType.CV_8UC3, new Scalar(0, 0, 0))创建了一帧纯黑图像，行数 480、列数 640，对应宽 640 高 480，三通道 8 位无符号整数类型，正是 VideoWriter 最常见的输入格式。这个测试画面足够小，探测耗时基本可以忽略。

3.3 录像主循环：写入、释放与文件完整性检查

选好编码器后，进入录像主循环。这里有一个特别容易被忽略的点：VideoWriter 的Size参数必须和摄像头实际输出分辨率严格一致，不能直接引用你设置的期望值，因为摄像头可能没有按你的设置输出。

// 继续使用上面已经设置好参数的 capture using (var capture = new VideoCapture(index, VideoCaptureAPIs.DSHOW)) { capture.Set(VideoCaptureProperties.FourCC, VideoWriter.Fourcc('M', 'J', 'P', 'G')); capture.Set(VideoCaptureProperties.FrameWidth, 1920); capture.Set(VideoCaptureProperties.FrameHeight, 1080); capture.Set(VideoCaptureProperties.Fps, 30); // 用 Get 读实际输出的分辨率，而不是用期望值 int outWidth = (int)capture.Get(VideoCaptureProperties.FrameWidth); int outHeight = (int)capture.Get(VideoCaptureProperties.FrameHeight); double outFps = capture.Get(VideoCaptureProperties.Fps); string fourcc = h264Available ? "h264" : "mp4v"; using (var writer = new VideoWriter( @"D:\rec\test.mp4", VideoWriter.Fourcc(fourcc[0], fourcc[1], fourcc[2], fourcc[3]), outFps, new OpenCvSharp.Size(outWidth, outHeight))) { if (!writer.IsOpened()) { Console.WriteLine($"视频写入器初始化失败，编码器：{fourcc}"); return; } using (var frame = new Mat()) { DateTime startTime = DateTime.Now; while ((DateTime.Now - startTime).TotalSeconds < 30) { if (capture.Read(frame) && !frame.Empty()) { writer.Write(frame); } } } } // using 块结束，自动释放 writer } // 写完后验证文件可读 using (var verify = new VideoCapture(@"D:\rec\test.mp4")) { if (verify.IsOpened()) { Console.WriteLine($"文件验证通过，帧数：{verify.Get(VideoCaptureProperties.FrameCount)}"); } }

VideoWriter.Fourcc(fourcc[0], fourcc[1], fourcc[2], fourcc[3])是把字符串拆成四个字符传进去，比硬编码Fourcc('m','p','4','v')灵活，探测函数得到什么字符串就用什么编码。

关于释放：using块保证了 writer 在退出后 Dispose，这一步不是可有可无。MP4 容器在写入结束后需要正常落盘收尾，把索引信息写到文件末尾。如果程序直接退出没释放，得到的文件经常是损坏的，播放器打开提示文件不可读。长时间录像场景，我会按固定时长分段生成文件，避免单个文件过大导致异常风险堆积。

到这里，一条从摄像头到 MP4 文件的链路已经通了。但这条链路离“工程可用”还差几步：帧率锁存、断线重连、自动分片。

4. 录像工程化：帧率锁存、掉线重连与分片策略

4.1 录像时长错乱：摄像头 FPS 不靠谱，用 Stopwatch 锁真实帧率

把上面的程序跑起来，录 10 分钟，文件用播放器一打开，发现时长不是 10 分钟而是 7 分钟，或者画面明显加速。原因是摄像头给的 FPS 是标称值，实际 USB 传输中帧间隔并不稳定，摄像头内部也可能丢帧。VideoWriter 写文件时按你传入的fps参数给帧打时间戳，实际写入帧数和这个时间戳对不上，播放器按时间戳换算出来时长就错了。

解决思路是采集循环内自己做帧率控制：

const double TargetFps = 30.0; const double FrameIntervalMs = 1000.0 / TargetFps; var sw = Stopwatch.StartNew(); double lastWriteMs = 0; while (recording) { double now = sw.Elapsed.TotalMilliseconds; if (now - lastWriteMs < FrameIntervalMs) { Thread.Sleep(2); continue; } if (capture.Read(frame) && !frame.Empty()) { writer.Write(frame); lastWriteMs = now; framesWritten++; } else { // 读帧失败，短暂等待后重试，避免空转 Thread.Sleep(5); } }

Thread.Sleep(2)的作用是让出 CPU 时间片，保证循环不会忙等，2 毫秒的粒度在 30 FPS 的帧间隔（约 33 毫秒）下完全够用。lastWriteMs记录了上一帧写入的时刻，只有距离上一帧超过 33 毫秒时才写下一帧，这样即使摄像头某段时间抽风多给了几帧，写出去的节奏也基本稳定在 30 FPS。

用这个方法，录像的实际时长和framesWritten / TargetFps基本一致。想更精确，可以把framesWritten记录到日志，录像结束后和播放器显示的时长对比，差距在 1 秒以内算正常。

4.2 USB 掉线自动重连：设备索引漂移与重试机制

USB 摄像头在长时间运行中可能掉线，线上场景最常见的原因是接触不良、USB 线过长供电不足、摄像头驱动崩溃。掉线后capture.Read()会连续返回 false。简单的做法是直接退出程序，但无人值守场景需要自动重连。

重连有个很隐蔽的坑：摄像头拔掉再插上，Windows 可能分配新的设备索引，之前绑定好的 index 已经指向另一个设备或者空设备。所以重连逻辑必须重新扫描索引，而不是对原VideoCapture对象反复Reopen()：

VideoCapture ReconnectCamera() { const int maxAttempts = 10; for (int attempt = 0; attempt < maxAttempts; attempt++) { int index = FindUsbCameraIndex(); if (index < 0) { Console.WriteLine($"第 {attempt + 1} 次扫描未发现摄像头，5 秒后重试"); Thread.Sleep(5000); continue; } var capture = new VideoCapture(index, VideoCaptureAPIs.DSHOW); if (capture.IsOpened()) { // 重新应用 MJPEG 和分辨率参数，因为新实例不会继承旧设置 capture.Set(VideoCaptureProperties.FourCC, VideoWriter.Fourcc('M', 'J', 'P', 'G')); capture.Set(VideoCaptureProperties.FrameWidth, outWidth); capture.Set(VideoCaptureProperties.FrameHeight, outHeight); capture.Set(VideoCaptureProperties.Fps, 30); return capture; } capture.Dispose(); Thread.Sleep(2000); } return null; }

重连成功后，VideoCapture是一个全新的实例，原来的 writer 可以直接继续用吗？答案是可以，只要分辨率不变，VideoWriter 不关心帧从哪里来。但要注意重连瞬间画面可能没有立即稳定，最好丢前 20 帧再开始写。

提示：USB 线超过 3 米或者接了劣质延长线，掉线的概率会指数级上升。工程现场优先用带屏蔽的短 USB 线，掉帧和断连问题会少很多。

4.3 无人值守录像：按固定时长分片，避免单文件损坏风险

长时间录像（比如连续录 8 小时）时，单文件方案风险很高。最大的问题是：如果程序中途异常退出，整个 MP4 文件因为没有正常 Finalize，前面所有录像全部打不开。分片方案把风险切碎，每段录像独立，某一段损坏不影响前一段和后一段。

const int SegmentSeconds = 300; VideoWriter currentWriter = null; DateTime segmentStart = DateTime.Now; string segmentDir = @"D:\rec\segments"; while (!stopRequested) { if (currentWriter == null || (DateTime.Now - segmentStart).TotalSeconds >= SegmentSeconds) { currentWriter?.Dispose(); // 释放上一段，写入完整尾部索引 string fileName = Path.Combine( segmentDir, DateTime.Now.ToString("yyyyMMdd_HHmmss") + ".mp4"); currentWriter = new VideoWriter( fileName, VideoWriter.Fourcc('m', 'p', '4', 'v'), TargetFps, new OpenCvSharp.Size(outWidth, outHeight)); segmentStart = DateTime.Now; Console.WriteLine($"新分片：{fileName}"); } // 帧率控制 + Read + Write 循环（同 4.1） } currentWriter?.Dispose(); // 收尾时释放最后一个分片

分片时长按需求定。质检工位一般 5 分钟一片，安防场景可以 30 分钟一片。时长越短，损坏损失越小，但文件数越多，要有自动清理策略，比如只保留最近 7 天的文件。

分片完成后，每次切换 writer 都是一次完整释放，这样上一段文件的索引信息已经写进文件末尾，即使下一段录像中途程序崩了，上一段的文件仍然是可播放的。

5. USB 录像常见问题避坑：五个高频故障处理记录

5.1 Read 永远 false：设备被其他进程独占，或后端选错

现象：capture.IsOpened()返回 true，但capture.Read()一直返回 false，偶发能读到几帧后继续 false。

原因：最常见的是系统自带的“相机”应用或其他程序正在占用摄像头。Windows 下多数 USB 摄像头不支持多进程共享打开，DSHOW 后端下独占尤其明显。另外 Media Foundation 后端在部分老式摄像头上有兼容问题，表现为能打开但读不了帧。

解决：先关掉所有可能占用摄像头的应用，再运行程序。如果程序本身有预览窗口，预览和录像不要开两个VideoCapture实例。代码层面，把后端从默认换成DSHOW，并在扫描函数里用连续读 10 帧的方式验证，能稳定读到才继续。现场排查时，用任务管理器结束“相机”应用是最快的验证手段。

5.2 VideoWriter 初始化失败，或报 h264 tag not found

现象：用h264做 fourcc，初始化时抛异常，或者控制台输出tag 0x34363268/'h264' is not found，有的场景不抛异常但写出的文件无法播放。

原因：OpenCV 官方预编译包里的 FFmpeg 模块没有内置 H264 编码器，运行时要靠系统已注册的编码器来压 H264。裸 Windows 环境没有这个编码器，所以直接写h264大概率失败。

解决：先用 3.2 节的探测函数确认系统有没有可用 H264 编码器，有就用，没有就自动降级到mp4v。如果项目方必须要求 H264 文件，两个方向：一是给部署机器安装带 H264 DirectShow 编码器的组件，装完再跑探测确认；二是只把 OpenCvSharp 当采集端，每帧Mat交给 Media Foundation 或显卡硬编管线处理，这条路工程量大一些，但压缩率和文件体积表现更好。

5.3 写出的文件 0 字节或只有几百字节

现象：录像流程正常走完，输出目录里的文件存在，但大小只有 0 KB 或几百字节，播放器完全打不开。

原因：两种情况。第一，编码器不可用但IsOpened()没报错，writer 建了个空壳；第二，Size参数和实际写入的帧尺寸不一致，比如摄像头实际输出 1280x720，writer 初始化传的是 1920x1080，OpenCV 里的行为不是自动缩放而是直接拒绝写入或写坏数据。

解决：写帧前确认frame.Size()与 writer 的 Size 完全一致。用capture.Get(VideoCaptureProperties.FrameWidth/Height)读回实际值，用实际值做 writer 参数。另外把编码器探测作为启动必跑步骤，探测不通过就不初始化 writer，直接把错误抛在界面里，不要带着坏配置跑完整场录像才发现文件不可用。

5.4 设置 1920x1080 不生效，读回来还是 640x480

现象：capture.Set(FrameWidth, 1920)返回 true，但Get读回来是 640，分辨率设置白写了。

原因：摄像头在 YUYV 模式下因 USB 带宽限制，拒绝 1080P 高帧率，驱动自动回退到低分辨率。更少见的原因是摄像头本身不支持该分辨率，厂商驱动的能力表里根本没有。

解决：把 MJPEG 设置在分辨率之前，先切换像素格式再谈分辨率。设置后务必Get读回确认，如果确认摄像头物理上不支持 1920x1080，就退到 1280x720 再试。项目验收时，我会把“实际输出的分辨率、帧率”打印在启动日志里，作为第一项自检指标。

5.5 录像文件时长错乱，10 分钟录出 7 分钟

现象：实际录满 10 分钟，播放器显示 7 分钟，画面播放速度偏快。

原因：摄像头实际输出帧率低于设定值。比如设定 30 FPS，实际平均只有 21 FPS，VideoWriter 按 30 FPS 打时间戳，文件和真实时间就对不上。

解决：用 4.1 节的 Stopwatch 锁帧法，写帧节奏由程序控制而不是依赖摄像头帧间隔。另一个补救是：录完一段后主动去读实际写入帧数，和播放器上报的时长做对比，发现偏差就说明摄像头采集不稳定，需要在代码里进一步收紧读帧节奏或降低分辨率换取稳定帧率。

6. 最后一步：编码器自检脚本与自动分片录像的验证技巧

6.1 启动时先做编码器自检，别把问题留到录像结束后

这套方案里最值得固化的一个习惯，是把编码器探测逻辑放在录像任务启动的第一行。每次录像启动时依次做三件事：扫描摄像头索引、探测 H264 编码器可用性、确认实际分辨率。全部通过才进入录像循环，任何一项不通过都要在界面上给出明确提示。

// 启动自检：摄像头 + 编码器 + 分辨率，三者缺一不可 int camIndex = FindUsbCameraIndex(); if (camIndex < 0) throw new InvalidOperationException("未发现可用摄像头"); string h264Name = "h264"; if (!IsEncoderWritable(h264Name, "mp4")) h264Name = "mp4v"; // 先开摄像头拿实际分辨率，再初始化 writer using (var cap = new VideoCapture(camIndex, VideoCaptureAPIs.DSHOW)) { cap.Set(VideoCaptureProperties.FourCC, VideoWriter.Fourcc('M', 'J', 'P', 'G')); cap.Set(VideoCaptureProperties.FrameWidth, 1920); cap.Set(VideoCaptureProperties.FrameHeight, 1080); cap.Set(VideoCaptureProperties.Fps, 30); int w = (int)cap.Get(VideoCaptureProperties.FrameWidth); int h = (int)cap.Get(VideoCaptureProperties.FrameHeight); using (var writer = new VideoWriter( Path.Combine(@"D:\rec", DateTime.Now.ToString("yyyyMMdd_HHmmss") + ".mp4"), VideoWriter.Fourcc(h264Name[0], h264Name[1], h264Name[2], h264Name[3]), 30, new OpenCvSharp.Size(w, h))) { // 分片录像逻辑同 4.3 } }

这个自检脚本的另一个价值，是让录像程序的启动从“可能出错”变成“不可能出错”。编码器探测、索引扫描、分辨率确认提前把不可控变量都消除了，剩下的录像主循环只是机械执行。

6.2 分片录像的可读性验证：每个分片闭环时自动检查

分片方案虽然降低了单文件损坏风险，但风险没有完全归零。我的习惯是每次释放 writer 后，立刻用VideoCapture把刚写的分片打开读一遍，验证文件头和帧数，确认可读才在日志里标记完成：

currentWriter?.Dispose(); string verifyFile = Path.Combine(segmentDir, lastSegmentName); using (var verify = new VideoCapture(verifyFile)) { if (!verify.IsOpened() || verify.Get(VideoCaptureProperties.FrameCount) < 1) { // 文件不可读，记录日志并快速重录本段 Console.WriteLine($"分片验证失败：{verifyFile}"); } }

这段验证代码本质上是给录像链路加了一层“后悔药”。文件能否播放不依赖代码逻辑推断，直接打开读一遍，问题立刻暴露。

从那以后，我每次写 USB 摄像头录像功能，都强制先跑一遍编码器探测和摄像头扫描，分片切换完顺手验证上一段文件可读，这套组合拳帮我提前拦截了大部分现场故障。希望这个习惯也能帮到你。

本文还有配套的精品资源，点击获取