简介面向具备一定 C# 与 .NET 基础、希望把 USB 摄像头接入桌面程序的开发者这份资源以实例工程的形式演示设备枚举、视频流连接、拍照抓拍、暂停恢复与释放关闭等完整流程适合做视频采集、图像抓拍类工具或课程练习时参考。压缩包共 38 个文件约 181KB包含 6 个 cs 源码文件与 1 个 sln 解决方案、1 个 csproj 工程文件另有 10 个 dll 依赖库、3 个 exe 生成的程序、2 个 resx 与 2 个 resources 界面资源以及 pdb、settings、manifest 等配置与调试附属文件可直接用 Visual Studio 打开运行并对照修改。已有 3913 人学习下载说明其在摄像头调用这一常见需求上具有较高的参考价值。工程把窗体界面、视频帧事件处理与资源释放逻辑分目录组织读者可据此理解事件驱动采集的写法并在此基础上扩展图片保存格式与异常提示。1. 从一台被办公软件占着的摄像头说起上周去现场调一个拍照存档的小工具六台工位机里有两台一开机就报设备占用第一反应是 USB 线松了拆了两次机箱才发现是我自己那版 demo 退出时没把采集对象释放干净。C# 调用 USB 摄像头写出画面十分钟写出能连续跑八小时、切分辨率不花屏、抓拍不丢帧、参数改完能存下来的模块得踩不少坑。这份资源就是把这些坑压成一套能直接跑的项目设备枚举、实时预览、定点抓拍、曝光白平衡这类参数调节以及最容易被忽略的释放清理都在里面。做桌面端工控、门禁、检测台这类需要把摄像头接进 .NET 程序的场景都能用新手照着能把第一个画面跑出来熟手可以直接看参数协商和释放顺序那几段。2. 四条调用路线怎么选AForge、OpenCvSharp、MediaCapture 与 DirectShow 裸调USB 摄像头在 Windows 上最终都落在同一套底层驱动模型上但上层封装差得很远。选错路线不是写不出来而是写到一半发现要调曝光、要切 MJPG、要拿原始帧做算法时封装层不给你口子只能推倒重来。这一章先把四条常见路线的账算清楚再用一次真实探测把设备的能力集摸出来。2.1 先算一笔账四条路线各自的代价我一般按三个维度挑要不要做图像处理、要不要精细控制相机参数、项目生命周期有多长。只是预览加拍照存盘AForge 那两个包足够后面要接模板匹配、条码识别、尺寸测量OpenCvSharp 更顺新立项且目标框架能上到net8.0-windows10.0.19041MediaCapture 的 API 设计最现代遇到 SDK 都搞不定的工业相机才轮到 DirectShow 裸调。路线依赖上手成本参数控制能力维护状态典型场景AForge.Video.DirectShow两个纯托管 NuGet 包低对 IAMCameraControl / IAMVideoProcAmp 做了封装够用多年未更新仍可运行中小型桌面工具、快速验证OpenCvSharp4托管包 原生运行时包中走 CAP_PROP 系列实际能力取决于后端活跃需要图像处理、算法链路MediaCaptureWinRT靠目标框架引入中高属性丰富异步模型官方维护新项目、UWP 或新式桌面DirectShowLib 裸调互操作封装高最全能拿到原始格式协商需要自己兜底特殊相机、封装层不够用时有个容易被忽略的点AForge 和 OpenCvSharp 在 Windows 上默认都走 DirectShow 或 Media Foundation同一时刻同一台设备只能被一个进程以独占方式打开。所以路线可以混用设备不能共享这一点在第 5 章的占用问题里还会再提。2.2 枚举设备与能力集一次探测把底牌摸清拿到项目第一步不是急着出画面而是先写个探测程序把每台设备支持的分辨率、帧率、位深全打出来。很多「切分辨率就崩」的问题根源是代码里写死了一个相机根本不支持的分辨率组合。using AForge.Video.DirectShow; using System; using System.Linq; // 枚举所有视频输入设备MonikerString 是后续打开设备的唯一凭据 var devices new FilterInfoCollection(FilterCategory.VideoInputDevice); if (devices.Count 0) { Console.WriteLine(没有检测到视频输入设备); return; } foreach (FilterInfo dev in devices) { Console.WriteLine($[设备] {dev.Name} {dev.MonikerString}); // 构造采集对象只为读取能力集读完必须释放否则这台设备就被占住了 using var probe new VideoCaptureDevice(dev.MonikerString); foreach (var cap in probe.VideoCapabilities .OrderByDescending(c c.FrameSize.Width * c.FrameSize.Height)) { Console.WriteLine($ {cap.FrameSize.Width}x{cap.FrameSize.Height} $平均{cap.AverageFrameRate}fps 最高{cap.MaximumFrameRate}fps ${cap.BitCount}bit); } }这段的关键在using。VideoCaptureDevice实现了IDisposable构造时就已经和底层滤镜图建立了关联不释放的话下一次Start()会直接失败。我见过有人在枚举循环里 new 了十几个对象不释放最后只有第一台设备能打开后面全报错查了一下午。VideoCapabilities返回的是相机在驱动层声明的所有格式组合注意它是「声明」不是「保证」——某些廉价模组会声明 2560x1440实际跑起来只有 5 帧这种虚标只能靠实测帧率验证第 5 章会讲怎么测。2.3 打开与关闭的正确顺序Start 只是开始打开设备的顺序是有讲究的先挂事件、再设分辨率、最后 Start。反过来的话第一帧可能在分辨率还没生效时就到了你会看到预览窗口先闪一下小尺寸再跳变。var source new VideoCaptureDevice(devices[0].MonikerString); // 1. 先挑分辨率挑不到就退回设备默认别硬设 var target source.VideoCapabilities .Where(c c.FrameSize.Width 1920 c.FrameSize.Height 1080) .Where(c Math.Abs((double)c.FrameSize.Width / c.FrameSize.Height - 16.0 / 9) 0.02) .OrderByDescending(c c.FrameSize.Width * c.FrameSize.Height) .FirstOrDefault(); if (target ! null) source.VideoResolution target; // 必须在 Start 之前赋值 // 2. 挂事件注意回调在采集线程不是 UI 线程 source.NewFrame Source_NewFrame; // 3. 启动 source.Start(); // 4. 关闭先通知停止再等线程退出最后解事件 source.SignalToStop(); if (!source.WaitForStop(5000)) { // 等不到就强杀否则进程退出时设备句柄可能残留 source.Stop(); } source.NewFrame - Source_NewFrame; source.Dispose();WaitForStop那个 5000 毫秒不是随便写的。相机在低帧率模式下比如曝光时间拉到 500ms一帧要等半秒才回来超时太短会在回调还没结束时就把对象释放掉直接抛访问非法内存。我给的经验值是「最长曝光时间 × 3」工业场景常设 3000 到 5000。Stop()和SignalToStop()的区别也值得说一下前者是立刻粗暴中断后者是置一个标志位让采集线程自己退出。正常流程走后者只有在超时兜底时才用前者。这套顺序写进一个CameraSession类里封装起来后面所有业务代码都只调Open()/Close()就不会有人漏掉解事件。3. 预览渲染把采集线程的帧安全地搬到界面上预览看起来最简单实际上翻车率最高。核心矛盾只有一个帧在采集线程产生控件只能在 UI 线程碰。中间这一跳怎么走决定了程序是稳如老狗还是跑两小时就崩。3.1 为什么 NewFrame 里不能直接碰控件NewFrame事件的回调跑在 AForge 内部创建的采集线程上这个线程跟 UI 线程没有任何关系。在里面直接写pictureBox1.Image e.Frame轻则抛跨线程异常重则界面假死——因为 WinForms 的控件句柄不是线程安全的两个线程同时操作窗口消息队列行为完全不可预期。还有一种更隐蔽的写法在回调里调Control.CheckForIllegalCrossThreadCalls false把检查关掉。这相当于把安全带剪了开车调试期看着一切正常上线后偶发花屏、偶发崩溃日志里什么都没有纯玄学。血泪经验是这条开关一次都别碰。正确的做法是「采集线程只负责拷贝UI 线程负责显示」。但直接每帧BeginInvoke也有问题如果 UI 线程正忙比如在写磁盘消息会堆积采集 30 帧积 30 条消息恢复后界面像快进一样抖一阵。所以要加节流——上一次渲染没完成时新帧直接丢掉。3.2 WinForms双缓冲 PictureBox 与帧复用先看 WinForms 版本这也是现场大多数工控机的实际形态。private Bitmap? _buffer; private readonly object _bufLock new(); private int _renderPending; private void Source_NewFrame(object sender, NewFrameEventArgs e) { // 采集线程里只做一件事拷一份出来。e.Frame 是内部复用的位图出了回调就被改写 lock (_bufLock) { _buffer?.Dispose(); // 上一帧没被取走就丢掉绝不累积 _buffer (Bitmap)e.Frame.Clone(); } // 节流上一次渲染还没跑完这一帧直接放弃避免消息队列堆积 if (Interlocked.Exchange(ref _renderPending, 1) 0 IsHandleCreated) { BeginInvoke(new Action(RenderFrame)); } } private void RenderFrame() { Bitmap? frame; lock (_bufLock) { frame _buffer; _buffer null; // 所有权转移给 UI 线程 } if (frame ! null) { var old pictureBox1.Image; pictureBox1.Image frame; old?.Dispose(); // 旧图必须还回去否则 GDI 句柄一路涨 } Interlocked.Exchange(ref _renderPending, 0); }几个参数值得说明。_renderPending用Interlocked.Exchange而不是普通 bool是因为采集线程只有一个但 UI 线程回写标志存在竞争用原子操作最省心。pictureBox1.SizeMode建议设成Zoom配合窗口等比缩放设成StretchImage在非 16:9 的窗口里会把画面拉扁标定过的像素尺寸全废。old?.Dispose()这一行是内存问题的分水岭。PictureBox.Image赋值不会自动释放上一张图每帧一张 1920x1080 的 24 位图是 6MB30 帧下来每秒产生 180MB 垃圾GC 根本追不上任务管理器里内存曲线会一路爬坡。加上这一行内存能压到平稳的几十兆。3.3 WPFWriteableBitmap 直写后台缓冲WPF 没有 PictureBox常见做法是Image控件配BitmapSource。如果每帧都BitmapSource.Create新建对象等于每帧分配一次非托管内存效果跟前面不释放一样糟。更合适的是WriteableBitmap——一次分配之后每帧往它的后台缓冲里写像素。using System.Windows; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Drawing.Imaging; private WriteableBitmap? _wb; private readonly object _wbLock new(); private void Source_NewFrame(object sender, NewFrameEventArgs e) { using var frame (Bitmap)e.Frame.Clone(); // 首帧或分辨率变化时重建并回 UI 线程挂载到 Image 控件 if (_wb null || _wb.PixelWidth ! frame.Width || _wb.PixelHeight ! frame.Height) { var wb new WriteableBitmap(frame.Width, frame.Height, 96, 96, PixelFormats.Bgr24, null); lock (_wbLock) { _wb wb; } Dispatcher.BeginInvoke(new Action(() PreviewImage.Source wb)); } var target _wb!; var src frame.LockBits(new Rectangle(0, 0, frame.Width, frame.Height), ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb); try { target.Lock(); unsafe { byte* dst (byte*)target.BackBuffer; byte* s (byte*)src.Scan0; int rowBytes frame.Width * 3; // 逐行拷贝不能整块 memcpyBitmap 的 Stride 会按 4 字节对齐 // 而 WriteableBitmap 的 BackBufferStride 是按自身规则算的两者不一定相等 for (int y 0; y frame.Height; y) { Buffer.MemoryCopy(s (long)y * src.Stride, dst (long)y * target.BackBufferStride, target.BackBufferStride, rowBytes); } } target.AddDirtyRect(new Int32Rect(0, 0, frame.Width, frame.Height)); } finally { target.Unlock(); frame.UnlockBits(src); } }AllowUnsafeBlocks需要在 csproj 里打开这是这段代码唯一的前置条件。逐行拷贝那几行注释是这条路线最容易翻车的地方——网上很多示例图省事用整块Marshal.Copy宽度不是 4 的倍数时比如 1366x768就会出现画面斜切错位一行错、行行错看起来像信号干扰其实是步长对不上。另外WriteableBitmap必须在 UI 线程创建所以这里是「采集线程里 new、用 Dispatcher 挂载」。严格说 new 本身也应该在 UI 线程做我为了少一次跨线程调用才这么写实际项目里如果遇到InvalidOperationException把整个重建逻辑包进Dispatcher.Invoke就好重建频率很低不心疼这点开销。4. 拍照与参数控制分辨率、曝光、白平衡落到代码预览只是看业务真正要的是那一下子按下去的抓拍以及不同光照环境下能调得动的曝光和白平衡。这一章把抓拍的所有权问题和参数调节的时序问题讲透。4.1 抓拍拷贝一份再交出去抓拍最简单的写法是在按钮事件里直接读当前帧但读不到——UI 线程拿不到采集线程的e.Frame。正确做法是在采集回调里存一份克隆按钮触发时取走。private Bitmap? _pendingShot; private readonly object _shotLock new(); // 采集回调里始终保留最新一帧作为「待抓拍候选」 private void Source_NewFrame(object sender, NewFrameEventArgs e) { lock (_shotLock) { _pendingShot?.Dispose(); _pendingShot (Bitmap)e.Frame.Clone(); } // 预览逻辑见上一章 } // 按钮点击时调用 public Bitmap? Snapshot() { lock (_shotLock) { var shot _pendingShot; _pendingShot null; // 所有权转移调用方负责 Dispose return shot; } } // 存盘显式指定 JPEG 质量别用默认的 75 public void SaveJpeg(Bitmap bmp, string path, long quality 92) { var codec ImageCodecInfo.GetImageEncoders() .First(c c.FormatID ImageFormat.Jpeg.Guid); using var ps new EncoderParameters(1); ps.Param[0] new EncoderParameter(Encoder.Quality, quality); using var fs new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, 64 * 1024); bmp.Save(fs, codec, ps); }SaveJpeg里两个参数要留意。quality我一般给 90 到 95低于 85 在文字和边缘处会出现明显振铃做 OCR 或尺寸测量的场景直接受影响。FileShare.None是防止两个抓拍任务同时写同一个文件工控机上的操作员连点两下按钮太常见了不加这个会抛文件占用异常。还有一个细节EncoderParameter的第二个参数必须是long类型传int会静默失效存出来的图一直是默认质量。这个问题网上问的人不少属于典型的「代码没错、结果不对」。如果是连续抓拍比如每 200ms 一张做运动检测上面这种「回调里一直克隆」的方式就浪费了一张 1080p 图克隆加释放每秒五次CPU 会明显吃紧。这种情况改成生产者消费者队列回调里TryAdd到一个BlockingCollectionBitmap限定容量为 3满了就丢最旧的后台线程慢慢消费。队列容量一定要限不限制就是内存泄漏的另一种写法。4.2 分辨率与像素格式带宽账要先算分辨率不是想设多高就设多高背后是 USB 带宽的硬约束。一张 1920x1080 的 YUY2 未压缩帧是 1920×1080×2 ≈ 4.1MB30 帧就是 124MB/s。USB 2.0 的理论上限 480Mbps 换算下来约 60MB/s实际能稳定跑的也就 40MB/s 左右——所以 1080p30 在 USB 2.0 上跑 YUY2 是不可能的必须走 MJPG 压缩。这也是为什么同一台相机用不同软件打开帧率差很多有的软件自动协商了 MJPG有的老老实实走 YUY2 然后掉到 10 帧。AForge 的封装层对像素格式控制很弱通常由驱动自己挑遇到帧率上不去的情况换 OpenCvSharp 显式指定 FourCC 更直接。using OpenCvSharp; // 后端必须显式指定 DSHOW 或 MSMF默认的 CAP_ANY 可能挑到不合适的后端 using var cap new VideoCapture(0, VideoCaptureAPIs.DSHOW); if (!cap.IsOpened()) { Console.WriteLine(打开失败检查设备索引或占用情况); return; } // MJPG 的整型值显式设置才能在 USB 2.0 上跑到 1080p30 cap.Set(VideoCaptureProperties.FourCC, (double)FourCC.FromString(MJPG).ToInt32()); cap.Set(VideoCaptureProperties.FrameWidth, 1920); cap.Set(VideoCaptureProperties.FrameHeight, 1080); cap.Set(VideoCaptureProperties.Fps, 30); // 设完必须回读验证驱动可能悄悄降级成它能支持的最接近值 var realW cap.Get(VideoCaptureProperties.FrameWidth); var realH cap.Get(VideoCaptureProperties.FrameHeight); var realFps cap.Get(VideoCaptureProperties.Fps); Console.WriteLine($实际生效: {realW}x{realH} {realFps}fps);回读验证这一步千万别省。我遇到过一台模组设 1920x1080 它接受回读是 1920x1080但实际出图是 1280x720 拉伸上来的边缘一圈黑边。这种只能靠肉眼比对画面和标定板确认代码层面查不出来。另外VideoCaptureAPIs.DSHOW和MSMF的选择也不只是风格问题。MSMF 对某些 UVC 相机的 MJPG 支持有 bug会返回空帧DSHOW 兼容性好但启动慢一点。我的习惯是默认 DSHOW只有在需要低延迟或新式相机时才试 MSMF。4.3 曝光、白平衡与增益Auto 与 Manual 的切换顺序参数调节的坑主要在时序。直接设曝光值而不先关自动曝光驱动会把你的值当成一次性的建议值下一帧自动曝光算法又改回去了表现出来的现象是「设了没用」。AForge 对 IAMCameraControl 和 IAMVideoProcAmp 做了封装用起来还算顺手// 先读当前状态拿到合法范围和当前 flags source.GetCameraProperty(CameraControlProperty.Exposure, out int curExposure, out CameraControlFlags curFlags); // 关键一步先切成手动再设值。顺序反了会被自动算法覆盖 source.SetCameraProperty(CameraControlProperty.Exposure, curExposure, CameraControlFlags.Manual); source.SetCameraProperty(CameraControlProperty.Exposure, -6, CameraControlFlags.Manual); // 白平衡属于 VideoProcAmp 那一组接口不一样 source.GetVideoProperty(VideoProcAmpProperty.WhiteBalance, out int curWb, out VideoProcAmpFlags wbFlags); source.SetVideoProperty(VideoProcAmpProperty.WhiteBalance, 4500, VideoProcAmpFlags.Manual);曝光值的单位不是毫秒而是一个对数刻度不同相机范围差异很大常见是 -13 到 -1或者 0 到 -11。所以代码里不能硬编码绝对值得先读回范围。AForge 没直接暴露范围要么用IAMCameraControl.GetRange自己 P/Invoke要么就做成配置项让现场调试人员自己拖滑块试后者更省事我一般选后者。白平衡对颜色一致性要求高的场景必须锁死。自动白平衡在画面里出现大面积单色物体时会把整体色调带偏同一批产品拍出来颜色不一样事后做色差检测全废。做法是先用标准灰卡在目标光源下自动白平衡一次读到数值后写进配置运行时用手动模式设回去。增益Gain和亮度Brightness的区别也值得说一句增益是模拟信号放大提亮的同时噪声一起放大亮度是数字域偏移提亮但不增加噪声。暗光环境下优先动亮度实在不够再动增益——这个顺序调反了画面会噪点密布看起来像相机坏了。5. 避坑与排查设备占用、花屏、帧率虚标的五次翻车前面讲的都是顺利路径这一章专门记录实际项目里撞过的坑。每一条都是「现象 → 原因 → 解决」的结构对号入座比看文档快。5.1 一打开就报设备被占用现象source.Start()抛异常提示无法启动设备或者枚举出来的设备列表里明明有相机打开就是失败。重启电脑能好过一会儿又复现。原因USB 摄像头在 Windows 上是独占设备任何一个进程打开后其他进程就拿不到。最常见的占用者是后台常驻的会议软件、聊天工具、浏览器里开着的视频会议页面它们会静默持有相机句柄。另一个隐形原因是自己的程序异常退出采集线程没走完释放流程句柄留在系统里。解决第一步把Open/Close封装成必须成对调用的形式用try/finally保证异常路径也走释放。第二步在AppDomain.CurrentDomain.ProcessExit和主窗口FormClosing里都挂一次兜底释放。第三步才是排查外部占用——任务管理器看不出谁占着相机得用设备管理器看「图像设备」下有没有黄色感叹号或者直接关掉可疑的后台程序逐个试。这个排查过程确实有点黑匣子但把释放顺序写对之后八成以上的「被占用」都不会再出现。5.2 高分辨率下花屏、绿条、上下撕裂现象720p 一切正常切到 1080p 后画面下半部分变成绿色或者横向条纹有时候是整屏斜切错位。原因三种可能。一是像素格式没协商成 MJPG驱动降级到 YUY2 但带宽不够数据丢包二是预览渲染时步长处理错了宽度不是 4 的倍数时整块拷贝会导致行错位三是 AForge 内部缓冲复用回调外还在读e.Frame读到一半被下一帧覆盖。解决先确认是不是格式问题——用 OpenCvSharp 显式设 MJPG 再跑一次如果好了就是带宽。如果是斜切错位回到 3.3 节的逐行拷贝检查src.Stride和BackBufferStride是否被你当成了同一个值。如果是画面局部撕裂检查所有对e.Frame的引用是不是都在Clone()之后。这三条按顺序排查基本能覆盖全部情况。5.3 标称 30 帧实际只有 5 帧现象相机规格写 1080p30能力集里也声明了 30fps实际测下来只有 5 到 8 帧画面明显卡顿。原因能力集里声明的帧率是「在理想带宽下」实际受三件事影响USB 接口版本插在 USB 2.0 口上跑 1080p压缩格式不对就必然掉帧、曝光时间低照度下自动曝光把曝光时间拉到 200ms物理上限就是 5 帧、还有其他 USB 设备抢带宽同一控制器上挂着 U 盘、采集卡。解决先算带宽账1080p30 走 YUY2 需要 124MB/sUSB 2.0 给不了必须 MJPG再查曝光把自动曝光关掉手动设一个短曝光值看帧率是否回升回升了就说明是低照度拖累最后把相机插到独立的 USB 控制器上别和移动硬盘共用。还有一个容易忽略的某些延长线是 USB 2.0 的接在 USB 3.0 口上也只跑 2.0 速率线材问题占掉帧故障的相当一部分。5.4 跑两小时内存涨到 2G现象启动时内存 80MB跑一下午涨到 2GB 以上最后 OutOfMemory 崩掉。用性能监视器看私有字节一直在涨GC 回收后也降不下来。原因几乎全是Bitmap没释放。常见三处PictureBox.Image赋值后旧图没 Dispose采集回调里Clone()出来的图在被取走前就被覆盖覆盖时忘了释放NewFrame事件在关闭窗口时没解绑采集对象还活着一直在往一个已经销毁的窗体上投帧。解决把每一处Bitmap的产生和释放都配成对Clone()后面必然跟一个Dispose()所有权转移的地方加注释说明谁负责释放。事件解绑放在Close()里和SignalToStop挨着写形成肌肉记忆。验证方法很简单跑一晚上第二天看任务管理器的私有字节曲线平的就是对的缓慢上升就还有漏点。5.5 最小化再恢复画面卡死现象程序最小化几分钟后还原预览区一片黑或者定格在最后一帧按钮还能点就是不刷新。任务管理器里 CPU 占用为 0。原因BeginInvoke在窗口最小化期间投递的消息被系统挂起节流标志_renderPending被置成 1 之后再也没有重置——因为对应的RenderFrame没执行。恢复窗口后所有新帧看到标志位是 1全部丢弃画面自然不动了。解决在窗口Resize或StateChanged事件里检测到从最小化恢复时强制把_renderPending置 0并主动投递一次渲染。更稳妥的做法是给节流加超时兜底投递时记一个时间戳超过 500ms 还没被消费就允许再次投递。这个坑很隐蔽因为只有最小化这个特定操作才会触发正常调试根本发现不了属于典型的现场才炸的问题。6. 进阶多路并发与 24 小时稳定性验证单路跑通只是及格线真上产线往往要两路甚至四路同时采还要经得起连续开机不重启。这一章讲两个我每次交付前必做的动作。6.1 多摄像头并发一路一线程与带宽预算多路的核心约束还是带宽。四路 1080p30 走 MJPG压缩后每路大约 8 到 15MB/s加起来 60MB/s已经逼近 USB 3.0 控制器的实际上限如果四台相机全插在同一个控制器也就是同一组相邻的 USB 口上必然互相拖累。我的做法是物理上分散到不同控制器代码上每路独立一个VideoCaptureDevice实例和一个消费线程互不共享任何缓冲。public sealed class CameraWorker : IDisposable { private readonly VideoCaptureDevice _device; private readonly BlockingCollectionBitmap _queue new(3); // 容量 3满则丢 private readonly CancellationTokenSource _cts new(); private Task? _consumer; public CameraWorker(string moniker) { _device new VideoCaptureDevice(moniker); _device.NewFrame OnFrame; } public void Start() { // 每路独立消费线程写盘和算法处理都在这个线程里不占 UI _consumer Task.Run(ConsumeLoop); _device.Start(); } private void OnFrame(object sender, NewFrameEventArgs e) { var copy (Bitmap)e.Frame.Clone(); // TryAdd 不阻塞队列满了直接丢弃并释放绝不让采集线程等 if (!_queue.TryAdd(copy)) copy.Dispose(); } private void ConsumeLoop() { foreach (var bmp in _queue.GetConsumingEnumerable(_cts.Token)) { using (bmp) { // 业务处理存盘、推理、比对随便什么 } } } public void Dispose() { _device.SignalToStop(); _device.WaitForStop(8000); _device.NewFrame - OnFrame; _device.Dispose(); _queue.CompleteAdding(); _cts.Cancel(); _consumer?.Wait(2000); _queue.Dispose(); } }BlockingCollection容量设 3 是权衡结果1 太容易丢帧5 以上在 1080p 下就是三十多兆的内存常驻。TryAdd而非Add是关键Add在队列满时会阻塞采集线程采集线程一阻塞驱动层的缓冲很快溢出表现为整路画面卡住而不是丢几帧——后者可以接受前者不可接受。6.2 三个指标跑一晚上帧率、内存、句柄功能跑通不等于能交付。我交付前的固定动作是挂一晚上采三个指标实际帧率、进程私有字节、GDI 句柄数。前两个看资源泄漏第三个看 GDI 对象有没有漏释放。// 每 10 秒采样一次写 CSV第二天直接拉曲线看 private async Task MonitorAsync(CancellationToken token) { var proc Process.GetCurrentProcess(); using var writer new StreamWriter(stability.csv, append: true); writer.WriteLine(time,fps,privateMB,gdiHandles); long lastFrames 0; var lastTime DateTime.Now; while (!token.IsCancellationRequested) { await Task.Delay(10_000, token); var now DateTime.Now; long frames Interlocked.Read(ref _frameCounter); // 采集回调里递增 double fps (frames - lastFrames) / (now - lastTime).TotalSeconds; proc.Refresh(); writer.WriteLine(${now:HH:mm:ss},{fps:F1}, ${proc.PrivateMemorySize64 / 1024 / 1024}, ${proc.HandleCount}); writer.Flush(); lastFrames frames; lastTime now; } }判读标准很明确帧率曲线应该在目标值上下小幅波动如果每隔几分钟出现一个掉到 0 的谷底说明有阻塞私有字节在跑了两小时后应该基本持平缓慢上升说明还有Bitmap或事件没释放GDI 句柄数稳定在几百以内如果持续上涨回去查Graphics对象和Font、Pen这些有没有using。那次现场事故之后我每接一个新相机型号都先跑一晚上这套指标采集看曲线平不平再谈功能。软件这东西白天看着好好的出问题的永远是凌晨三点的那一次崩溃。希望帮到你。本文还有配套的精品资源点击获取
简介面向具备一定 C# 与 .NET 基础、希望把 USB 摄像头接入桌面程序的开发者这份资源以实例工程的形式演示设备枚举、视频流连接、拍照抓拍、暂停恢复与释放关闭等完整流程适合做视频采集、图像抓拍类工具或课程练习时参考。压缩包共 38 个文件约 181KB包含 6 个 cs 源码文件与 1 个 sln 解决方案、1 个 csproj 工程文件另有 10 个 dll 依赖库、3 个 exe 生成的程序、2 个 resx 与 2 个 resources 界面资源以及 pdb、settings、manifest 等配置与调试附属文件可直接用 Visual Studio 打开运行并对照修改。已有 3913 人学习下载说明其在摄像头调用这一常见需求上具有较高的参考价值。工程把窗体界面、视频帧事件处理与资源释放逻辑分目录组织读者可据此理解事件驱动采集的写法并在此基础上扩展图片保存格式与异常提示。1. 从一台被办公软件占着的摄像头说起上周去现场调一个拍照存档的小工具六台工位机里有两台一开机就报设备占用第一反应是 USB 线松了拆了两次机箱才发现是我自己那版 demo 退出时没把采集对象释放干净。C# 调用 USB 摄像头写出画面十分钟写出能连续跑八小时、切分辨率不花屏、抓拍不丢帧、参数改完能存下来的模块得踩不少坑。这份资源就是把这些坑压成一套能直接跑的项目设备枚举、实时预览、定点抓拍、曝光白平衡这类参数调节以及最容易被忽略的释放清理都在里面。做桌面端工控、门禁、检测台这类需要把摄像头接进 .NET 程序的场景都能用新手照着能把第一个画面跑出来熟手可以直接看参数协商和释放顺序那几段。2. 四条调用路线怎么选AForge、OpenCvSharp、MediaCapture 与 DirectShow 裸调USB 摄像头在 Windows 上最终都落在同一套底层驱动模型上但上层封装差得很远。选错路线不是写不出来而是写到一半发现要调曝光、要切 MJPG、要拿原始帧做算法时封装层不给你口子只能推倒重来。这一章先把四条常见路线的账算清楚再用一次真实探测把设备的能力集摸出来。2.1 先算一笔账四条路线各自的代价我一般按三个维度挑要不要做图像处理、要不要精细控制相机参数、项目生命周期有多长。只是预览加拍照存盘AForge 那两个包足够后面要接模板匹配、条码识别、尺寸测量OpenCvSharp 更顺新立项且目标框架能上到net8.0-windows10.0.19041MediaCapture 的 API 设计最现代遇到 SDK 都搞不定的工业相机才轮到 DirectShow 裸调。路线依赖上手成本参数控制能力维护状态典型场景AForge.Video.DirectShow两个纯托管 NuGet 包低对 IAMCameraControl / IAMVideoProcAmp 做了封装够用多年未更新仍可运行中小型桌面工具、快速验证OpenCvSharp4托管包 原生运行时包中走 CAP_PROP 系列实际能力取决于后端活跃需要图像处理、算法链路MediaCaptureWinRT靠目标框架引入中高属性丰富异步模型官方维护新项目、UWP 或新式桌面DirectShowLib 裸调互操作封装高最全能拿到原始格式协商需要自己兜底特殊相机、封装层不够用时有个容易被忽略的点AForge 和 OpenCvSharp 在 Windows 上默认都走 DirectShow 或 Media Foundation同一时刻同一台设备只能被一个进程以独占方式打开。所以路线可以混用设备不能共享这一点在第 5 章的占用问题里还会再提。2.2 枚举设备与能力集一次探测把底牌摸清拿到项目第一步不是急着出画面而是先写个探测程序把每台设备支持的分辨率、帧率、位深全打出来。很多「切分辨率就崩」的问题根源是代码里写死了一个相机根本不支持的分辨率组合。using AForge.Video.DirectShow; using System; using System.Linq; // 枚举所有视频输入设备MonikerString 是后续打开设备的唯一凭据 var devices new FilterInfoCollection(FilterCategory.VideoInputDevice); if (devices.Count 0) { Console.WriteLine(没有检测到视频输入设备); return; } foreach (FilterInfo dev in devices) { Console.WriteLine($[设备] {dev.Name} {dev.MonikerString}); // 构造采集对象只为读取能力集读完必须释放否则这台设备就被占住了 using var probe new VideoCaptureDevice(dev.MonikerString); foreach (var cap in probe.VideoCapabilities .OrderByDescending(c c.FrameSize.Width * c.FrameSize.Height)) { Console.WriteLine($ {cap.FrameSize.Width}x{cap.FrameSize.Height} $平均{cap.AverageFrameRate}fps 最高{cap.MaximumFrameRate}fps ${cap.BitCount}bit); } }这段的关键在using。VideoCaptureDevice实现了IDisposable构造时就已经和底层滤镜图建立了关联不释放的话下一次Start()会直接失败。我见过有人在枚举循环里 new 了十几个对象不释放最后只有第一台设备能打开后面全报错查了一下午。VideoCapabilities返回的是相机在驱动层声明的所有格式组合注意它是「声明」不是「保证」——某些廉价模组会声明 2560x1440实际跑起来只有 5 帧这种虚标只能靠实测帧率验证第 5 章会讲怎么测。2.3 打开与关闭的正确顺序Start 只是开始打开设备的顺序是有讲究的先挂事件、再设分辨率、最后 Start。反过来的话第一帧可能在分辨率还没生效时就到了你会看到预览窗口先闪一下小尺寸再跳变。var source new VideoCaptureDevice(devices[0].MonikerString); // 1. 先挑分辨率挑不到就退回设备默认别硬设 var target source.VideoCapabilities .Where(c c.FrameSize.Width 1920 c.FrameSize.Height 1080) .Where(c Math.Abs((double)c.FrameSize.Width / c.FrameSize.Height - 16.0 / 9) 0.02) .OrderByDescending(c c.FrameSize.Width * c.FrameSize.Height) .FirstOrDefault(); if (target ! null) source.VideoResolution target; // 必须在 Start 之前赋值 // 2. 挂事件注意回调在采集线程不是 UI 线程 source.NewFrame Source_NewFrame; // 3. 启动 source.Start(); // 4. 关闭先通知停止再等线程退出最后解事件 source.SignalToStop(); if (!source.WaitForStop(5000)) { // 等不到就强杀否则进程退出时设备句柄可能残留 source.Stop(); } source.NewFrame - Source_NewFrame; source.Dispose();WaitForStop那个 5000 毫秒不是随便写的。相机在低帧率模式下比如曝光时间拉到 500ms一帧要等半秒才回来超时太短会在回调还没结束时就把对象释放掉直接抛访问非法内存。我给的经验值是「最长曝光时间 × 3」工业场景常设 3000 到 5000。Stop()和SignalToStop()的区别也值得说一下前者是立刻粗暴中断后者是置一个标志位让采集线程自己退出。正常流程走后者只有在超时兜底时才用前者。这套顺序写进一个CameraSession类里封装起来后面所有业务代码都只调Open()/Close()就不会有人漏掉解事件。3. 预览渲染把采集线程的帧安全地搬到界面上预览看起来最简单实际上翻车率最高。核心矛盾只有一个帧在采集线程产生控件只能在 UI 线程碰。中间这一跳怎么走决定了程序是稳如老狗还是跑两小时就崩。3.1 为什么 NewFrame 里不能直接碰控件NewFrame事件的回调跑在 AForge 内部创建的采集线程上这个线程跟 UI 线程没有任何关系。在里面直接写pictureBox1.Image e.Frame轻则抛跨线程异常重则界面假死——因为 WinForms 的控件句柄不是线程安全的两个线程同时操作窗口消息队列行为完全不可预期。还有一种更隐蔽的写法在回调里调Control.CheckForIllegalCrossThreadCalls false把检查关掉。这相当于把安全带剪了开车调试期看着一切正常上线后偶发花屏、偶发崩溃日志里什么都没有纯玄学。血泪经验是这条开关一次都别碰。正确的做法是「采集线程只负责拷贝UI 线程负责显示」。但直接每帧BeginInvoke也有问题如果 UI 线程正忙比如在写磁盘消息会堆积采集 30 帧积 30 条消息恢复后界面像快进一样抖一阵。所以要加节流——上一次渲染没完成时新帧直接丢掉。3.2 WinForms双缓冲 PictureBox 与帧复用先看 WinForms 版本这也是现场大多数工控机的实际形态。private Bitmap? _buffer; private readonly object _bufLock new(); private int _renderPending; private void Source_NewFrame(object sender, NewFrameEventArgs e) { // 采集线程里只做一件事拷一份出来。e.Frame 是内部复用的位图出了回调就被改写 lock (_bufLock) { _buffer?.Dispose(); // 上一帧没被取走就丢掉绝不累积 _buffer (Bitmap)e.Frame.Clone(); } // 节流上一次渲染还没跑完这一帧直接放弃避免消息队列堆积 if (Interlocked.Exchange(ref _renderPending, 1) 0 IsHandleCreated) { BeginInvoke(new Action(RenderFrame)); } } private void RenderFrame() { Bitmap? frame; lock (_bufLock) { frame _buffer; _buffer null; // 所有权转移给 UI 线程 } if (frame ! null) { var old pictureBox1.Image; pictureBox1.Image frame; old?.Dispose(); // 旧图必须还回去否则 GDI 句柄一路涨 } Interlocked.Exchange(ref _renderPending, 0); }几个参数值得说明。_renderPending用Interlocked.Exchange而不是普通 bool是因为采集线程只有一个但 UI 线程回写标志存在竞争用原子操作最省心。pictureBox1.SizeMode建议设成Zoom配合窗口等比缩放设成StretchImage在非 16:9 的窗口里会把画面拉扁标定过的像素尺寸全废。old?.Dispose()这一行是内存问题的分水岭。PictureBox.Image赋值不会自动释放上一张图每帧一张 1920x1080 的 24 位图是 6MB30 帧下来每秒产生 180MB 垃圾GC 根本追不上任务管理器里内存曲线会一路爬坡。加上这一行内存能压到平稳的几十兆。3.3 WPFWriteableBitmap 直写后台缓冲WPF 没有 PictureBox常见做法是Image控件配BitmapSource。如果每帧都BitmapSource.Create新建对象等于每帧分配一次非托管内存效果跟前面不释放一样糟。更合适的是WriteableBitmap——一次分配之后每帧往它的后台缓冲里写像素。using System.Windows; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Drawing.Imaging; private WriteableBitmap? _wb; private readonly object _wbLock new(); private void Source_NewFrame(object sender, NewFrameEventArgs e) { using var frame (Bitmap)e.Frame.Clone(); // 首帧或分辨率变化时重建并回 UI 线程挂载到 Image 控件 if (_wb null || _wb.PixelWidth ! frame.Width || _wb.PixelHeight ! frame.Height) { var wb new WriteableBitmap(frame.Width, frame.Height, 96, 96, PixelFormats.Bgr24, null); lock (_wbLock) { _wb wb; } Dispatcher.BeginInvoke(new Action(() PreviewImage.Source wb)); } var target _wb!; var src frame.LockBits(new Rectangle(0, 0, frame.Width, frame.Height), ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb); try { target.Lock(); unsafe { byte* dst (byte*)target.BackBuffer; byte* s (byte*)src.Scan0; int rowBytes frame.Width * 3; // 逐行拷贝不能整块 memcpyBitmap 的 Stride 会按 4 字节对齐 // 而 WriteableBitmap 的 BackBufferStride 是按自身规则算的两者不一定相等 for (int y 0; y frame.Height; y) { Buffer.MemoryCopy(s (long)y * src.Stride, dst (long)y * target.BackBufferStride, target.BackBufferStride, rowBytes); } } target.AddDirtyRect(new Int32Rect(0, 0, frame.Width, frame.Height)); } finally { target.Unlock(); frame.UnlockBits(src); } }AllowUnsafeBlocks需要在 csproj 里打开这是这段代码唯一的前置条件。逐行拷贝那几行注释是这条路线最容易翻车的地方——网上很多示例图省事用整块Marshal.Copy宽度不是 4 的倍数时比如 1366x768就会出现画面斜切错位一行错、行行错看起来像信号干扰其实是步长对不上。另外WriteableBitmap必须在 UI 线程创建所以这里是「采集线程里 new、用 Dispatcher 挂载」。严格说 new 本身也应该在 UI 线程做我为了少一次跨线程调用才这么写实际项目里如果遇到InvalidOperationException把整个重建逻辑包进Dispatcher.Invoke就好重建频率很低不心疼这点开销。4. 拍照与参数控制分辨率、曝光、白平衡落到代码预览只是看业务真正要的是那一下子按下去的抓拍以及不同光照环境下能调得动的曝光和白平衡。这一章把抓拍的所有权问题和参数调节的时序问题讲透。4.1 抓拍拷贝一份再交出去抓拍最简单的写法是在按钮事件里直接读当前帧但读不到——UI 线程拿不到采集线程的e.Frame。正确做法是在采集回调里存一份克隆按钮触发时取走。private Bitmap? _pendingShot; private readonly object _shotLock new(); // 采集回调里始终保留最新一帧作为「待抓拍候选」 private void Source_NewFrame(object sender, NewFrameEventArgs e) { lock (_shotLock) { _pendingShot?.Dispose(); _pendingShot (Bitmap)e.Frame.Clone(); } // 预览逻辑见上一章 } // 按钮点击时调用 public Bitmap? Snapshot() { lock (_shotLock) { var shot _pendingShot; _pendingShot null; // 所有权转移调用方负责 Dispose return shot; } } // 存盘显式指定 JPEG 质量别用默认的 75 public void SaveJpeg(Bitmap bmp, string path, long quality 92) { var codec ImageCodecInfo.GetImageEncoders() .First(c c.FormatID ImageFormat.Jpeg.Guid); using var ps new EncoderParameters(1); ps.Param[0] new EncoderParameter(Encoder.Quality, quality); using var fs new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, 64 * 1024); bmp.Save(fs, codec, ps); }SaveJpeg里两个参数要留意。quality我一般给 90 到 95低于 85 在文字和边缘处会出现明显振铃做 OCR 或尺寸测量的场景直接受影响。FileShare.None是防止两个抓拍任务同时写同一个文件工控机上的操作员连点两下按钮太常见了不加这个会抛文件占用异常。还有一个细节EncoderParameter的第二个参数必须是long类型传int会静默失效存出来的图一直是默认质量。这个问题网上问的人不少属于典型的「代码没错、结果不对」。如果是连续抓拍比如每 200ms 一张做运动检测上面这种「回调里一直克隆」的方式就浪费了一张 1080p 图克隆加释放每秒五次CPU 会明显吃紧。这种情况改成生产者消费者队列回调里TryAdd到一个BlockingCollectionBitmap限定容量为 3满了就丢最旧的后台线程慢慢消费。队列容量一定要限不限制就是内存泄漏的另一种写法。4.2 分辨率与像素格式带宽账要先算分辨率不是想设多高就设多高背后是 USB 带宽的硬约束。一张 1920x1080 的 YUY2 未压缩帧是 1920×1080×2 ≈ 4.1MB30 帧就是 124MB/s。USB 2.0 的理论上限 480Mbps 换算下来约 60MB/s实际能稳定跑的也就 40MB/s 左右——所以 1080p30 在 USB 2.0 上跑 YUY2 是不可能的必须走 MJPG 压缩。这也是为什么同一台相机用不同软件打开帧率差很多有的软件自动协商了 MJPG有的老老实实走 YUY2 然后掉到 10 帧。AForge 的封装层对像素格式控制很弱通常由驱动自己挑遇到帧率上不去的情况换 OpenCvSharp 显式指定 FourCC 更直接。using OpenCvSharp; // 后端必须显式指定 DSHOW 或 MSMF默认的 CAP_ANY 可能挑到不合适的后端 using var cap new VideoCapture(0, VideoCaptureAPIs.DSHOW); if (!cap.IsOpened()) { Console.WriteLine(打开失败检查设备索引或占用情况); return; } // MJPG 的整型值显式设置才能在 USB 2.0 上跑到 1080p30 cap.Set(VideoCaptureProperties.FourCC, (double)FourCC.FromString(MJPG).ToInt32()); cap.Set(VideoCaptureProperties.FrameWidth, 1920); cap.Set(VideoCaptureProperties.FrameHeight, 1080); cap.Set(VideoCaptureProperties.Fps, 30); // 设完必须回读验证驱动可能悄悄降级成它能支持的最接近值 var realW cap.Get(VideoCaptureProperties.FrameWidth); var realH cap.Get(VideoCaptureProperties.FrameHeight); var realFps cap.Get(VideoCaptureProperties.Fps); Console.WriteLine($实际生效: {realW}x{realH} {realFps}fps);回读验证这一步千万别省。我遇到过一台模组设 1920x1080 它接受回读是 1920x1080但实际出图是 1280x720 拉伸上来的边缘一圈黑边。这种只能靠肉眼比对画面和标定板确认代码层面查不出来。另外VideoCaptureAPIs.DSHOW和MSMF的选择也不只是风格问题。MSMF 对某些 UVC 相机的 MJPG 支持有 bug会返回空帧DSHOW 兼容性好但启动慢一点。我的习惯是默认 DSHOW只有在需要低延迟或新式相机时才试 MSMF。4.3 曝光、白平衡与增益Auto 与 Manual 的切换顺序参数调节的坑主要在时序。直接设曝光值而不先关自动曝光驱动会把你的值当成一次性的建议值下一帧自动曝光算法又改回去了表现出来的现象是「设了没用」。AForge 对 IAMCameraControl 和 IAMVideoProcAmp 做了封装用起来还算顺手// 先读当前状态拿到合法范围和当前 flags source.GetCameraProperty(CameraControlProperty.Exposure, out int curExposure, out CameraControlFlags curFlags); // 关键一步先切成手动再设值。顺序反了会被自动算法覆盖 source.SetCameraProperty(CameraControlProperty.Exposure, curExposure, CameraControlFlags.Manual); source.SetCameraProperty(CameraControlProperty.Exposure, -6, CameraControlFlags.Manual); // 白平衡属于 VideoProcAmp 那一组接口不一样 source.GetVideoProperty(VideoProcAmpProperty.WhiteBalance, out int curWb, out VideoProcAmpFlags wbFlags); source.SetVideoProperty(VideoProcAmpProperty.WhiteBalance, 4500, VideoProcAmpFlags.Manual);曝光值的单位不是毫秒而是一个对数刻度不同相机范围差异很大常见是 -13 到 -1或者 0 到 -11。所以代码里不能硬编码绝对值得先读回范围。AForge 没直接暴露范围要么用IAMCameraControl.GetRange自己 P/Invoke要么就做成配置项让现场调试人员自己拖滑块试后者更省事我一般选后者。白平衡对颜色一致性要求高的场景必须锁死。自动白平衡在画面里出现大面积单色物体时会把整体色调带偏同一批产品拍出来颜色不一样事后做色差检测全废。做法是先用标准灰卡在目标光源下自动白平衡一次读到数值后写进配置运行时用手动模式设回去。增益Gain和亮度Brightness的区别也值得说一句增益是模拟信号放大提亮的同时噪声一起放大亮度是数字域偏移提亮但不增加噪声。暗光环境下优先动亮度实在不够再动增益——这个顺序调反了画面会噪点密布看起来像相机坏了。5. 避坑与排查设备占用、花屏、帧率虚标的五次翻车前面讲的都是顺利路径这一章专门记录实际项目里撞过的坑。每一条都是「现象 → 原因 → 解决」的结构对号入座比看文档快。5.1 一打开就报设备被占用现象source.Start()抛异常提示无法启动设备或者枚举出来的设备列表里明明有相机打开就是失败。重启电脑能好过一会儿又复现。原因USB 摄像头在 Windows 上是独占设备任何一个进程打开后其他进程就拿不到。最常见的占用者是后台常驻的会议软件、聊天工具、浏览器里开着的视频会议页面它们会静默持有相机句柄。另一个隐形原因是自己的程序异常退出采集线程没走完释放流程句柄留在系统里。解决第一步把Open/Close封装成必须成对调用的形式用try/finally保证异常路径也走释放。第二步在AppDomain.CurrentDomain.ProcessExit和主窗口FormClosing里都挂一次兜底释放。第三步才是排查外部占用——任务管理器看不出谁占着相机得用设备管理器看「图像设备」下有没有黄色感叹号或者直接关掉可疑的后台程序逐个试。这个排查过程确实有点黑匣子但把释放顺序写对之后八成以上的「被占用」都不会再出现。5.2 高分辨率下花屏、绿条、上下撕裂现象720p 一切正常切到 1080p 后画面下半部分变成绿色或者横向条纹有时候是整屏斜切错位。原因三种可能。一是像素格式没协商成 MJPG驱动降级到 YUY2 但带宽不够数据丢包二是预览渲染时步长处理错了宽度不是 4 的倍数时整块拷贝会导致行错位三是 AForge 内部缓冲复用回调外还在读e.Frame读到一半被下一帧覆盖。解决先确认是不是格式问题——用 OpenCvSharp 显式设 MJPG 再跑一次如果好了就是带宽。如果是斜切错位回到 3.3 节的逐行拷贝检查src.Stride和BackBufferStride是否被你当成了同一个值。如果是画面局部撕裂检查所有对e.Frame的引用是不是都在Clone()之后。这三条按顺序排查基本能覆盖全部情况。5.3 标称 30 帧实际只有 5 帧现象相机规格写 1080p30能力集里也声明了 30fps实际测下来只有 5 到 8 帧画面明显卡顿。原因能力集里声明的帧率是「在理想带宽下」实际受三件事影响USB 接口版本插在 USB 2.0 口上跑 1080p压缩格式不对就必然掉帧、曝光时间低照度下自动曝光把曝光时间拉到 200ms物理上限就是 5 帧、还有其他 USB 设备抢带宽同一控制器上挂着 U 盘、采集卡。解决先算带宽账1080p30 走 YUY2 需要 124MB/sUSB 2.0 给不了必须 MJPG再查曝光把自动曝光关掉手动设一个短曝光值看帧率是否回升回升了就说明是低照度拖累最后把相机插到独立的 USB 控制器上别和移动硬盘共用。还有一个容易忽略的某些延长线是 USB 2.0 的接在 USB 3.0 口上也只跑 2.0 速率线材问题占掉帧故障的相当一部分。5.4 跑两小时内存涨到 2G现象启动时内存 80MB跑一下午涨到 2GB 以上最后 OutOfMemory 崩掉。用性能监视器看私有字节一直在涨GC 回收后也降不下来。原因几乎全是Bitmap没释放。常见三处PictureBox.Image赋值后旧图没 Dispose采集回调里Clone()出来的图在被取走前就被覆盖覆盖时忘了释放NewFrame事件在关闭窗口时没解绑采集对象还活着一直在往一个已经销毁的窗体上投帧。解决把每一处Bitmap的产生和释放都配成对Clone()后面必然跟一个Dispose()所有权转移的地方加注释说明谁负责释放。事件解绑放在Close()里和SignalToStop挨着写形成肌肉记忆。验证方法很简单跑一晚上第二天看任务管理器的私有字节曲线平的就是对的缓慢上升就还有漏点。5.5 最小化再恢复画面卡死现象程序最小化几分钟后还原预览区一片黑或者定格在最后一帧按钮还能点就是不刷新。任务管理器里 CPU 占用为 0。原因BeginInvoke在窗口最小化期间投递的消息被系统挂起节流标志_renderPending被置成 1 之后再也没有重置——因为对应的RenderFrame没执行。恢复窗口后所有新帧看到标志位是 1全部丢弃画面自然不动了。解决在窗口Resize或StateChanged事件里检测到从最小化恢复时强制把_renderPending置 0并主动投递一次渲染。更稳妥的做法是给节流加超时兜底投递时记一个时间戳超过 500ms 还没被消费就允许再次投递。这个坑很隐蔽因为只有最小化这个特定操作才会触发正常调试根本发现不了属于典型的现场才炸的问题。6. 进阶多路并发与 24 小时稳定性验证单路跑通只是及格线真上产线往往要两路甚至四路同时采还要经得起连续开机不重启。这一章讲两个我每次交付前必做的动作。6.1 多摄像头并发一路一线程与带宽预算多路的核心约束还是带宽。四路 1080p30 走 MJPG压缩后每路大约 8 到 15MB/s加起来 60MB/s已经逼近 USB 3.0 控制器的实际上限如果四台相机全插在同一个控制器也就是同一组相邻的 USB 口上必然互相拖累。我的做法是物理上分散到不同控制器代码上每路独立一个VideoCaptureDevice实例和一个消费线程互不共享任何缓冲。public sealed class CameraWorker : IDisposable { private readonly VideoCaptureDevice _device; private readonly BlockingCollectionBitmap _queue new(3); // 容量 3满则丢 private readonly CancellationTokenSource _cts new(); private Task? _consumer; public CameraWorker(string moniker) { _device new VideoCaptureDevice(moniker); _device.NewFrame OnFrame; } public void Start() { // 每路独立消费线程写盘和算法处理都在这个线程里不占 UI _consumer Task.Run(ConsumeLoop); _device.Start(); } private void OnFrame(object sender, NewFrameEventArgs e) { var copy (Bitmap)e.Frame.Clone(); // TryAdd 不阻塞队列满了直接丢弃并释放绝不让采集线程等 if (!_queue.TryAdd(copy)) copy.Dispose(); } private void ConsumeLoop() { foreach (var bmp in _queue.GetConsumingEnumerable(_cts.Token)) { using (bmp) { // 业务处理存盘、推理、比对随便什么 } } } public void Dispose() { _device.SignalToStop(); _device.WaitForStop(8000); _device.NewFrame - OnFrame; _device.Dispose(); _queue.CompleteAdding(); _cts.Cancel(); _consumer?.Wait(2000); _queue.Dispose(); } }BlockingCollection容量设 3 是权衡结果1 太容易丢帧5 以上在 1080p 下就是三十多兆的内存常驻。TryAdd而非Add是关键Add在队列满时会阻塞采集线程采集线程一阻塞驱动层的缓冲很快溢出表现为整路画面卡住而不是丢几帧——后者可以接受前者不可接受。6.2 三个指标跑一晚上帧率、内存、句柄功能跑通不等于能交付。我交付前的固定动作是挂一晚上采三个指标实际帧率、进程私有字节、GDI 句柄数。前两个看资源泄漏第三个看 GDI 对象有没有漏释放。// 每 10 秒采样一次写 CSV第二天直接拉曲线看 private async Task MonitorAsync(CancellationToken token) { var proc Process.GetCurrentProcess(); using var writer new StreamWriter(stability.csv, append: true); writer.WriteLine(time,fps,privateMB,gdiHandles); long lastFrames 0; var lastTime DateTime.Now; while (!token.IsCancellationRequested) { await Task.Delay(10_000, token); var now DateTime.Now; long frames Interlocked.Read(ref _frameCounter); // 采集回调里递增 double fps (frames - lastFrames) / (now - lastTime).TotalSeconds; proc.Refresh(); writer.WriteLine(${now:HH:mm:ss},{fps:F1}, ${proc.PrivateMemorySize64 / 1024 / 1024}, ${proc.HandleCount}); writer.Flush(); lastFrames frames; lastTime now; } }判读标准很明确帧率曲线应该在目标值上下小幅波动如果每隔几分钟出现一个掉到 0 的谷底说明有阻塞私有字节在跑了两小时后应该基本持平缓慢上升说明还有Bitmap或事件没释放GDI 句柄数稳定在几百以内如果持续上涨回去查Graphics对象和Font、Pen这些有没有using。那次现场事故之后我每接一个新相机型号都先跑一晚上这套指标采集看曲线平不平再谈功能。软件这东西白天看着好好的出问题的永远是凌晨三点的那一次崩溃。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
