简介：C#视频采集卡读写实例源码是一款面向C#开发者的硬件交互示例工程，聚焦通过DirectShow或Media Foundation实现视频信号的捕获、读取与写入，适合需要对采集卡进行二次开发或学习多媒体编程的读者。压缩包内共67个文件，约1012KB，包含23个cs源码文件、resx与resources界面资源、bmp与png图标位图、dll依赖库、exe可执行程序，以及mdb数据文件等，覆盖完整WinForms工程项目结构与常用窗体模块。已有921人学习下载，源码中设计了登录、注册、主监控、自动视频、播放、设置等多个功能窗体，并包含公共类和数据库操作部分，便于理解整体业务流程与调试方法。可以掌握视频采集设备的基本操作封装、实时预览与数据处理的实现思路，也能借鉴其在界面设计、多窗体协作和底层API调用方面的代码组织方式。
1. C# 视频采集卡读写到底在读写什么：别把它当成文件 I/O
做 C# 上位机的人多半会在某个节点遇到视频采集卡。卡插在主机上，HDMI 线连着相机或工控屏，系统里也就认出一个设备，但真到写代码时，你会发现它和读写一个 U 盘完全是两回事。“C# 视频采集卡读写 实例源码(硬件读写)”这个标题最常见的检索诉求，其实是两点：一，某个采集芯片或设备怎么被尽量少的代码驱动起来；二，拿到视频帧后怎么不让上位机被拖卡。很多初学者把硬件读写误认为直接对端口读字节，一上来就找错资料。所谓采集卡硬件读写，指的是设备初始化、缓冲分配、帧回调、参数下发这一整套流程，跟文件流的 open/read/write 完全不是一个操作模型。
2. 采集卡的三条 C# 落地路线：厂商 SDK、DirectShow、Media Foundation 怎么选
做采集卡方案之前，先得把链路拆开看，不然你连“读写”两个字对应哪一层都对应不上。
2.1 一条采集链路上有哪几个“读”和“写”
一张 HDMI 或 SDI 采集卡，信号从接口进来后，先由板载采集芯片做解码，HDMI 串行信号解成并行的 RGB 数据，然后放进板载缓存，再由驱动通过 USB3.0 或 PCIe 传到系统内存。应用层拿到手的是什么？是一块连续内存，里面按特定像素格式排布，可能带一个帧头结构体，标了宽、高、步长、时间戳和帧序号。
这套链路里，“写”分成两层。底层的写，是向采集芯片的寄存器写控制参数：分辨率、像素格式、帧率、曝光、增益、色彩校正、缩放。第二层是向驱动发 IOCTL 控制命令，把配置下发到固件。这两层在 C# 里都不直接暴露，也没有哪个正经采集卡允许你在应用态直接 out 到端口地址，Windows 的内存保护和驱动模型不允许，也不应该。常见做法是，厂商把整个流程封装成一个 DLL，导出 OpenDevice、SetFormat、Start、Stop、GetFrame 这类函数；C# 通过 P/Invoke 调它们，这就是标题里“硬件读写”的真实含义。
有一部分 USB 采集卡走的是 UVC 免驱协议，属于视频设备标准类，主机端会把它识别成一个“USB Video Device”。这种卡不需要厂商私有 DLL，DirectShow 和 Media Foundation 可以直接枚举并捕获。对应到 C#，你可以用 DirectShow 或 OpenCvSharp 的 VideoCapture 去读。走 UVC 路线的代价，是设备级控制参数比较少，曝光、增益、色彩矩阵这类高级控制未必能通过标准接口下发，很多免驱卡根本没有固件级寄存器可写，芯片出厂时就已经锁定了参数。
2.2 三条路线对比：设备类型决定第一选择
第一步不是选技术，是先确认手里卡的类型。PCIe 或 USB 接口的 HDMI/SDI 工业采集卡，绝大多数都带厂商私有驱动和 SDK；UVC 免驱卡则直接进系统视频框架。两条线决定了你在 C# 里只能走两条完全不同的实现方式。
| 路线 | 适用卡型 | 上手难度 | 硬件控制深度 | 主要风险 |
|---|---|---|---|---|
| 厂商 SDK + P/Invoke | SDI 卡、HDMI 工业卡、多路卡 | 中，头文件和定义比较多 | 高，能写寄存器参数 | 不同厂商接口差异大，迁移成本高 |
| DirectShow 枚举捕获 | UVC 免驱 USB 卡 | 低，AForge / DirectShow.NET 可跑通 | 低，标准接口只控制基本参数 | 缓冲区细节被封装隐藏，多路区分麻烦 |
| Media Foundation | UVC 卡、系统摄像头 | 较高，要写 COM 互操作 | 中 | 资料偏少，C# 封装难度大 |
我个人的选择逻辑很简单：只要卡带厂商 SDK，优先用厂商 SDK，哪怕它提供的接口文档写得稀烂。SDK 至少给了帧回调、丢帧计数、曝光控制这类实打实的功能；而 DirectShow 把缓冲管理藏在 FilterGraph 里，C# 拿到的往往是一张已经渲染好的 Bitmap，表面轻松，一旦要写曝光、触发、多路同步，立刻撞墙。
Media Foundation 在 C# 里落地反而最尴尬。它本身比 DirectShow 干净，也支持 UVC 多流，但微软没有对 C# 提供一等公民的封装，要么引用 COM 组件手写互操作，要么走 WinRT 的 MediaCapture 跑 UWP 库。上位机项目如果只是读一张卡、显示画面，用 MFC 尚可，C# 场景下实在不划算。
2.3 为什么“实例源码”多数是厂商 SDK 的包装
你搜到的采集卡读写源码，凡是能跑通、能改、能复制到自己项目里的，几乎都是厂商 SDK 的 P/Invoke 包装，原因很实际：硬件读写的位置，在驱动之上的 DLL 接口层。采集卡厂商只保证这一层对外稳定，不会让你的 C# 直接碰 I2C 或 SPI 总线。就算偶尔遇到能直接操作的寄存器型采集芯片，那也是在 FPGA 开发板上做嵌入式验证用的，不是 Windows 上位机场景。
所以在落地之前先确认三件事：设备索引怎么取、SDK 的像素格式枚举里有没有你要的 RGB24/YUY2、回调线程是阻塞还是非阻塞。这三个问题不搞清，后面写多少代码都是白搭。
3. 实例源码：搭一个可运行的采集回调工程，附代码与参数说明
这一节给出一个通用框架，函数名和参数结构以大多数厂商 SDK 的导出风格为准。拿到你自己的 SDK 头文件后，按名字替换即可。
3.1 用 P/Invoke 把硬件设备的 DLL 接口包进 C# 类
先建一个静态类，集中管理 DLL 导入，避免每个业务类各写一遍 DllImport，也方便统一换调用约定。
// VendorSdk.cs — P/Invoke 声明，函数名按实际 SDK 头文件替换 using System; using System.Runtime.InteropServices; internal static class VendorSdk { [DllImport("vendor_capture.dll", CallingConvention = CallingConvention.StdCall)] internal static extern int OpenDevice(int devIndex, ref DeviceConfig cfg, out IntPtr handle); [DllImport("vendor_capture.dll", CallingConvention = CallingConvention.StdCall)] internal static extern int SetFrameCallback(IntPtr handle, FrameCallback cb, IntPtr user); [DllImport("vendor_capture.dll", CallingConvention = CallingConvention.StdCall)] internal static extern int Start(IntPtr handle); [DllImport("vendor_capture.dll", CallingConvention = CallingConvention.StdCall)] internal static extern int Stop(IntPtr handle); [DllImport("vendor_capture.dll", CallingConvention = CallingConvention.StdCall)] internal static extern int CloseDevice(IntPtr handle); }逻辑说明：DllImport 里的函数名必须是厂商 DLL 实际导出的名字，不能凭感觉编。多数厂商会提供一个.h头文件，里面同时写了函数声明和结构体定义，照着抄即可。调用约定一般用 StdCall，x64 编译条件下这个影响不大，但 x86 下差别很明显，函数参数入栈顺序错了会把栈搞乱，表现为大概率一调就崩。
参数说明：OpenDevice 的 devIndex 是设备索引，有多个采集卡时依次传 0、1、2，部分厂商支持用序列号字符串打开；DeviceConfig 里主要有宽、高、像素格式、帧率这几项，很多 SDK 还要求传入回调缓冲数量，建议先取默认值，跑通后再改；handle 是返回的设备句柄，后续所有操作都靠它。
3.2 帧回调与缓冲复用：核心的采集控制逻辑
DLL 层包好后，写一个 CaptureDevice 封装类。这个类要做的事很简单：打开设备、注册回调、启动采集，然后把回调帧塞进队列供业务线程消费。
// CaptureDevice.cs — 封装厂商 SDK 的采集流程 public sealed class CaptureDevice : IDisposable { private IntPtr _handle; private FrameCallback _cb; // 委托必须存字段，防止被 GC 提前回收 private readonly ConcurrentQueue<byte[]> _queue = new(); private volatile bool _running; public int Width { get; private set; } public int Height { get; private set; } public void Start(int deviceIndex, int width, int height) { var cfg = new DeviceConfig { width = width, height = height, pixelFormat = (int)PixelFormat.BGR24, // 3 字节每像素 frameRate = 30 }; int ret = VendorSdk.OpenDevice(deviceIndex, ref cfg, out _handle); if (ret != 0) throw new InvalidOperationException($"OpenDevice 失败，错误码 {ret}"); _cb = OnFrame; ret = VendorSdk.SetFrameCallback(_handle, _cb, IntPtr.Zero); if (ret != 0) throw new InvalidOperationException($"SetFrameCallback 失败，错误码 {ret}"); ret = VendorSdk.Start(_handle); if (ret != 0) throw new InvalidOperationException($"Start 失败，错误码 {ret}"); Width = width; Height = height; _running = true; } private void OnFrame(IntPtr buffer, int length, uint sequence, IntPtr user) { // 回调线程不能做耗时操作，这里只拷贝并入队 if (!_running) return; byte[] copy = new byte[length]; Marshal.Copy(buffer, copy, 0, length); _queue.Enqueue(copy); } public bool TryGetFrame(out byte[] frame, int timeoutMs = 100) { while (_queue.TryDequeue(out var item)) { frame = item; return true; } frame = null; return false; } public void Dispose() { // 释放逻辑见 3.3 } }逻辑说明：OnFrame 是厂商驱动回调线程上执行的方法。这个线程由 DLL 内部创建，C# 只负责实现委托签名。回调里最容易犯的错是做 UI 操作、写文件、转码，这些动作会让回调线程变慢，驱动缓冲区会被占满，接着就开始丢帧。这里只做 Marshal.Copy 拷贝和 ConcurrentQueue 入队，耗时控制在微秒级，是标准做法。
参数说明：timeoutMs = 100是按 30fps 估算的。一帧间隔约 33ms，100ms 可以覆盖偶尔的调度抖动；如果经常超时，说明回调没正常进来，先去查驱动或设备连接，而不是调大超时麻痹自己。length是帧大小，BGR24 分辨率 1920x1080 时理论值是 192010803，但如果驱动有行对齐，实际会偏大，具体在第 4 章讲。
3.3 释放顺序：Stop 采集、卸掉回调、再关设备
采集卡的释放顺序比启动更容易出问题。很多“关闭程序时崩溃”的案例，都是释放顺序反了。
public void Dispose() { if (_handle == IntPtr.Zero) return; _running = false; int ret = VendorSdk.Stop(_handle); // 先停 DMA 传输 if (ret != 0) System.Diagnostics.Debug.WriteLine($"Stop 返回 {ret}"); VendorSdk.SetFrameCallback(_handle, null, IntPtr.Zero); // 再摘回调 VendorSdk.CloseDevice(_handle); // 最后关设备 _handle = IntPtr.Zero; }逻辑说明：顺序不能乱。先 Stop 是为了让驱动停止向内存写数据；再 SetFrameCallback 传 null，打断回调线程与托管侧的联系；最后 CloseDevice 释放设备句柄。反过来，如果先 CloseDevice 再摘回调，驱动可能在关闭过程中尝试回调一个已经释放的委托指针，直接触发 AccessViolation。这属于玄学现场的重灾区，稳妥做法永远是先停再摘。
注意：如果你的 SDK 还提供专门的回调取消函数，应该在 Stop 之后、CloseDevice 之前调用，顺序一样。
4. 视频采集卡读写的高频坑与排查备忘：现象、原因、解决
这一章的内容全部来自实际项目里反复踩过的坑，每一条都按“现象、原因、解决”三件事写清楚。
4.1 花屏或图像左移：行对齐与像素格式不匹配
现象：画面整体呈阶梯状偏移，右侧多出绿边或灰边，图像看起来像被斜着切了一刀。原因：最常见的是行对齐算法没算对。很多采集芯片输出时会把每一行的字节数对齐到 4、16 或 32 字节，1920x1080 的 BGR24，一行本来是 5760 字节，对齐到 16 字节后变成 5760，但有些格式对齐后是 5776 或 5792。你如果仍然按 5760 计算每行起点去显示，整幅图就会从第二行开始逐步错位。
解决：先查帧头结构体里的 stride 字段，厂商 SDK 一般会返回真实行宽；没有帧头时，手动计算对齐值：stride = (width * bytesPerPixel + 15) & ~15。显示时用 Bitmap 的带 stride 构造函数，把算出来的 stride 传进去，而不是让 GDI+ 自己去猜。
4.2 帧率只有标称一半甚至掉帧严重，CPU 占用还高
现象：设置为 30fps，实际只有 15fps，任务管理器里 CPU 占用率却不低。原因：回调线程里做了耗时操作。最常见的三个：把 byte[] 转成 Bitmap 并保存到磁盘、在回调里做图像处理算法、把帧推送到 UI 控件。这些操作任何一个超过几十毫秒，就会把下一帧的缓冲堵住，驱动丢帧。
解决：回调只做拷贝和入队，消费线程单独处理图像。用帧序号 sequence 做丢帧检测：相邻两次回调的序号差大于 1，说明中间有帧被驱动丢弃了。如果序号连续但帧率仍然上不去，问题在设备配置或带宽，比如 USB 3.0 卡插在了 USB 2.0 口上，这种硬件问题代码层解决不了。
4.3 DirectShow/UVC 多路摄像头在回调里分不清是哪一路
现象：两三个 UVC 摄像头同时插入，DirectShow 枚举出来的顺序每次开机都不一样，回调里拿到的帧到底属于哪个设备，完全没法从帧数据本身判断。原因：UVC 设备没有可靠固定的枚举顺序，系统按总线探测顺序分配，换插口、重启都可能变化。这正好对应常搜的“c# directshow uvc 回调里区分多个摄像头”问题，核心解法不是靠枚举索引，而是靠设备实例标识。
解决：通过 System.Management 读取 PnP 设备的 DeviceInstancePath，用这个字符串作为设备唯一标识，再从该标识反向绑定 DirectShow 的枚举项。这样即使枚举顺序变了，逻辑上也不会认错设备。
using System.Management; static string GetDeviceInstancePath(string deviceNamePart) { using var searcher = new ManagementObjectSearcher( "SELECT * FROM Win32_PnPEntity WHERE Name LIKE '%" + deviceNamePart + "%'"); foreach (var o in searcher.Get()) { using var mo = (ManagementObject)o; var pnpId = mo["PNPDeviceID"]?.ToString(); if (!string.IsNullOrEmpty(pnpId)) return pnpId; } return null; }代码说明：这里的 deviceNamePart 填 DirectShow 枚举到的名称，比如 “USB Camera”。取出来的 PNPDeviceID 格式类似USB\VID_XXXX&PID_XXXX\SN001，后段序列号是出厂烧录的，稳定不变。注意 Management 查询有性能损耗，初始化时调用一次保存结果即可，不要在每帧回调里执行。
4.4 退出程序时崩溃：释放顺序与委托生命周期同时出问题
现象：关闭窗口时偶发 AccessViolation，有时进程看似退出了，但摄像头指示灯还亮着。原因：两个问题叠一起。一，释放顺序错了，CloseDevice 之后驱动层还在等回调返回。二，FrameCallback 委托只作为局部变量传给了 SetFrameCallback，GC 在一段时间后回收委托对象，驱动再回调时拿到的是悬垂指针。
解决：一，按 3.3 的顺序释放，先 Stop 再摘回调最后 CloseDevice。二，把委托保存在实例字段_cb中，和设备生命周期绑定，直到 CloseDevice 之后再置空。只要做到这两点，这类崩溃基本都是绝迹的。还有条件的话，在 OnFrame 开头加if (!_running) return;做双重保护。
4.5 UI 卡顿：BeginInvoke 刷得太频繁把窗口消息队列挤爆
现象：窗口能显示画面，但拖动窗口卡得厉害，鼠标反应迟钝。原因：每来一帧就调用一次 control.BeginInvoke 刷新 PictureBox，30fps 意味着每秒往 UI 线程发 30 个消息，这些消息处理如果超过帧间隔，消息队列就会越积越多。
解决：把 UI 刷新频率压到 15~25fps 就够了，做法是加一个时间戳判断，距离上次刷新超过 40ms 才发起下一次 BeginInvoke。消费线程仍然每帧都从队列取数据，但只把最新帧缓存起来，UI 定时器去取最新那帧，而不是逐帧推给 UI。C# 这里最容易犯的错是直接在采集回调里访问控件，那是死路一条，回调线程和 UI 线程根本没有同步关系。
5. 进阶：多路采集的区分与压测方法（能多做一步就多做一步）
跑通单路采集之后，项目开始进入联调阶段，这时候有两点值得提前做：设备绑定标识和性能验证。
设备标识的方法在 4.3 已经给了核心代码。往上走一步，可以建一个设备配置表，把 DeviceInstancePath、DirectShow 枚举索引、业务通道号（比如“产线 1 号相机”）三方绑定，启动时按标识自动匹配。这样系统重启、换 USB 口、驱动重装后，业务通道不会错乱。这个表存成 JSON 就行，C# 里用 System.Text.Json 反序列化即可。
性能验证方面，我惯用的指标是两个：实际帧率和丢帧率。实际帧率不用看任务管理器，直接在消费循环里统计每秒出队列的帧数；丢帧率就看回调里的 sequence 字段，每次回调记录sequence - lastSequence，差值大于 1 就累加丢帧数。如果你拿到的帧没有 sequence 字段，就改用系统时间戳评估：两次回调的系统时间差如果远大于帧间隔，说明链路已经堵塞。
压测时建议关闭 UI 刷新，只保留黑底一个统计窗口。我见过不少项目，画面明显卡顿但帧率统计正常，原因就是 UI 刷新影响了消费线程，关掉 UI 后数据立刻恢复正常。压测至少跑 10 分钟，观察丢帧曲线是否持续上升；如果前 30 秒正常、后面开始丢，多半是内存没有复用，队列积压导致 GC 压力变大。这时要做的是回收到固定的缓冲池，而不是无脑 new byte[]。
我自己在做一个四路 SDI 采集项目时，就因为迷信枚举顺序固定，导致每次设备重启后画面错位，后来把 PNPDeviceID 绑定逻辑加上，才彻底消停。能走到设备标识这一步的项目，离交付就不远了。希望帮到你。
本文还有配套的精品资源，点击获取
