簡介面向在.NET平臺使用C#操作USB攝像頭的開發(fā)者這份資源提供一套可直接運行的完整示例覆蓋攝像頭枚舉、連接、視頻流啟停、拍照抓幀與圖片保存等關(guān)鍵環(huán)節(jié)。壓縮包內(nèi)共38個文件包括6個C#源文件、10個動態(tài)庫、3個可執(zhí)行程序以及工程配置文件整體僅181KB便于下載與閱讀。資源代碼基于AForge.NET框架編寫通過事件驅(qū)動方式處理視頻幀并給出暫停、恢復、釋放攝像頭等完整操作方法同時附帶Visual Studio解決方案和可執(zhí)行程序可直接編譯運行方便對照驗證。已有3910人學習特別適合剛接觸攝像頭開發(fā)、希望快速搭建測試程序的C#初學者可從中理解設(shè)備調(diào)用流程、圖像數(shù)據(jù)類型轉(zhuǎn)換及資源釋放等常見細節(jié)也能為后續(xù)擴展圖像處理功能提供基礎(chǔ)。1. C#調(diào)用USB攝像頭先解決能不能拍到再談怎么拍得更好做.NET上位機開發(fā)的人遲早會遇到一個需求用C#調(diào)起USB攝像頭實時預覽、抓圖、甚至錄像?？雌饋砗芎唵巍痪褪谴蜷_攝像頭、取幀、顯示嗎但實際動手你會發(fā)現(xiàn)Cameras不是new一下就能用的設(shè)備被占用、畫面黑屏、分辨率設(shè)置不生效、預覽卡頓哪個都夠折騰半天。這篇文章把一個完整的C#調(diào)用USB攝像頭的技術(shù)方案拆開講清楚從DirectShow、AForge、OpenCvSharp的選型到枚舉設(shè)備、設(shè)置參數(shù)、拍照保存、錄像落盤再到我踩過的幾個默認坑。適合要寫上位機、機器視覺標定、工裝檢測程序的C#開發(fā)者新手能照著寫熟手可以直接跳過前半段看避坑章節(jié)。2. 底層方案選型DirectShow、AForge與OpenCvSharp的邊界2.1 三套方案的適用場景與短板C#本身不直接提供USB攝像頭操作API所有調(diào)用最終都要落到Windows媒體底層也就是DirectShow。基于DirectShow業(yè)界形成了三套主流的C#封裝方案選型直接決定了后面代碼的寫法。方案封裝方式預覽幀率圖像預處理適合場景原生DirectShowCOM接口直調(diào)高無需要極致控制不建議新手AForge.NETDirectShow封裝中高弱需自轉(zhuǎn)RGBWinForm傳統(tǒng)項目事件驅(qū)動順手OpenCvSharpVideoCapture封裝高強直接上Mat機器視覺、需要濾波/檢測的場景我的建議很直接如果是給車間寫拍照存檔工具AForge夠了如果后面要做輪廓識別、二維碼讀取、圖像算法直接上OpenCvSharp省得中間轉(zhuǎn)Mat來回倒騰。原生DirectShow適合你發(fā)現(xiàn)封裝庫滿足不了特殊需求比如多路采集同步時再研究平時別碰那東西的過濾器圖能把人繞暈。2.2 OpenCvSharp的實用幀循環(huán)寫法OpenCvSharp是OpenCV的C#封裝nuget直接裝包就能用用法上最接近Python那邊OpenCV的習慣。先看最核心的幀循環(huán)怎么寫using OpenCvSharp; var capture new VideoCapture(0); // 0號設(shè)備一般就是第一個USB攝像頭 if (!capture.IsOpened()) { Console.WriteLine(攝像頭打開失敗可能是被占用或驅(qū)動異常); return; } capture.Set(VideoCaptureProperties.FrameWidth, 1280); capture.Set(VideoCaptureProperties.FrameHeight, 720); capture.Set(VideoCaptureProperties.Fps, 30); using (var window new Window(preview)) using (var frame new Mat()) { while (true) { if (!capture.Read(frame) || frame.Empty()) { Thread.Sleep(50); continue; } window.ShowImage(frame); if (Cv2.WaitKey(1) q) break; } } capture.Release();這里capture.Read(frame)是阻塞式抓幀讀到的frame是BGR格式的Mat對象。注意FrameWidth和FrameHeight的設(shè)置必須在打開設(shè)備之后、讀取第一幀之前否則部分攝像頭驅(qū)動會忽略你的請求。Fps設(shè)置在某些UVC協(xié)議設(shè)備上無效原因是協(xié)議里根本沒這個控制項后面避坑章節(jié)細說。WaitKey(1)這個調(diào)用不能省它同時承擔兩個職責刷新OpenCV窗口事件、響應鍵盤輸入。去掉它預覽窗口會假死這是新手最容易踩的坑之一。2.3 AForge與WinForm事件模型的配合如果你的歷史項目是WinFormAForge的接入更貼合C#開發(fā)習慣。它的取幀是事件驅(qū)動的不需要你手動開線程循環(huán)using AForge.Video; using AForge.Video.DirectShow; using System.Drawing; VideoCaptureDevice videoSource; Bitmap currentFrame; void StartCamera(int deviceIndex) { videoSource new VideoCaptureDevice(devices[deviceIndex].MonikerString); videoSource.NewFrame OnNewFrame; videoSource.Start(); } private void OnNewFrame(object sender, NewFrameEventArgs eventArgs) { if (currentFrame ! null) { currentFrame.Dispose(); } currentFrame (Bitmap)eventArgs.Frame.Clone(); // 這里用BeginInvoke回UI線程 pictureBox1.BeginInvoke((MethodInvoker)(() pictureBox1.Image currentFrame)); }AForge的NewFrame事件線程和UI線程不是同一個直接在事件里操作PictureBox會拋跨線程異常。BeginInvoke是標準解法但要注意Clone出來的Bitmap每幀都要Dispose否則內(nèi)存會勻速上漲跑一晚上直接OOM。AForge的優(yōu)勢是事件模型簡單劣勢是幀格式已經(jīng)是Bitmap后面要做顏色空間轉(zhuǎn)換或圖像算法還得轉(zhuǎn)成其它格式多一層開銷。這也是為什么我后來新項目基本都用OpenCvSharp。2.4 線程模型與跨線程訪問不管是哪個方案攝像頭的圖像采集線程都獨立于UI線程這是DirectShow的底層行為決定的。拆解一下線程的流轉(zhuǎn)過程采集線程從設(shè)備驅(qū)動讀到一幀圖像經(jīng)過封裝庫回調(diào)到你的代碼這一段要走得盡量輕不要在回調(diào)里做耗時操作寫文件、跑算法、深度學習推理否則幀積壓預覽延遲會越來越大。常見做法是把耗時操作扔到后臺隊列或獨立線程回調(diào)里只復制幀和投遞消息。用Channel 也好、用BlockingCollection也罷核心原則就一條采集線程不阻塞。我在一個掃碼項目中試過直接在NewFrame里做二維碼識別結(jié)果預覽幀率從30掉到8UI還一卡一卡的改成隊列后穩(wěn)定輸出25幀識別不丟幀。3. 設(shè)備枚舉、分辨率與拍照OpenCvSharp落地操作3.1 枚舉USB攝像頭的穩(wěn)健做法OpenCvSharp的VideoCapture本身不能枚舉設(shè)備索引你只能從0開始試試到打不開為止。但這個辦法有個隱患電腦有藍牙攝像頭、虛擬攝像頭的時候設(shè)備索引不是連續(xù)的比如0是USB攝像頭、1是虛擬攝像頭、2是USB攝像頭你用2也能打開。所以穩(wěn)健做法是掃描0到9的索引把能打開的記錄下來using OpenCvSharp; public static Listint EnumerateCameras(int maxIndex 9) { var available new Listint(); for (int i 0; i maxIndex; i) { var cap new VideoCapture(i); if (cap.IsOpened()) { available.Add(i); cap.Release(); } } return available; }注意如果某索引被其它程序占用IsOpened也會返回false所以枚舉結(jié)果只是“當前可用的設(shè)備”不是“物理存在的設(shè)備”。另外打開過的VideoCapture必須Release否則句柄泄漏下一次打開同一個設(shè)備會失敗。這個Release不是可選項是必須項。3.2 分辨率、幀率與拍照參數(shù)設(shè)置攝像頭參數(shù)設(shè)置的核心是VideoCaptureProperties常用的有FrameWidth、FrameHeight、Fps、Exposure曝光、Brightness亮度。給一段帶驗證的寫法capture.Set(VideoCaptureProperties.FrameWidth, 1920); capture.Set(VideoCaptureProperties.FrameHeight, 1080); int actualW (int)capture.Get(VideoCaptureProperties.FrameWidth); int actualH (int)capture.Get(VideoCaptureProperties.FrameHeight); Console.WriteLine($請求1920x1080實際為{actualW}x{actualH});這段代碼的用意是很多USB攝像頭尤其是廉價模組并不真正支持1920x1080驅(qū)動可能給你一個拉伸后的畫面也可能直接降到640x480。設(shè)置完立刻讀回實際值如果你的業(yè)務(wù)對分辨率敏感比如二維碼最小尺寸必須以actualW和actualH為準而不是以你請求的值為準。拍照時如果發(fā)現(xiàn)畫面模糊或視野不對先用這個驗證方法排查。曝光參數(shù)Exposure是個容易翻車的點Auto模式下設(shè)固定曝光值不生效需要先把Exposure設(shè)為手動一般設(shè)值為負或零表示自動為正表示手動再Set具體值。不同攝像頭廠商對Exposure的解釋不一致有的驅(qū)動里0是手動、-1是自動這個沒有統(tǒng)一標準只能按設(shè)備實測。我一般會把曝光控制做成下拉框把可選項寫死不依賴自動檢測。3.3 拍照與保存格式拍照的本質(zhì)就是抓當前幀并保存注意Mat的格式和圖像編碼。看代碼public bool CapturePhoto(VideoCapture capture, string filePath) { using (var frame new Mat()) { if (!capture.Read(frame) || frame.Empty()) return false; // OpenCvSharp缺省是BGR順序ImWrite會按擴展名編碼 bool saved Cv2.ImWrite(filePath, frame); return saved; } }ImWrite的編碼格式由擴展名決定.jpg走JPEG編碼.png走PNG編碼。JPEG質(zhì)量默認95如果需要壓縮到80可以這樣var paramsList new ImageEncodingParam[] { new ImageEncodingParam(ImwriteFlags.JpegQuality, 80) }; Cv2.ImWrite(filePath, frame, paramsList);這兩個細節(jié)要注意第一frame必須是BGR格式如果你的幀被轉(zhuǎn)成了GrayImWrite會保存成灰度圖記得轉(zhuǎn)回BGR再寫。第二保存路徑的目錄必須先創(chuàng)建ImWrite不會自動建目錄。4. 攝像頭實操避坑五個高頻故障與排查思路現(xiàn)象new VideoCapture(0)返回的IsOpened是true但Read出來的第一幀是空的或者屏幕黑屏一閃而過。 原因攝像頭在上電初始化階段USB帶寬協(xié)商未完成立刻讀幀會拿到空數(shù)據(jù)。C#代碼里沒有等設(shè)備就緒的概念這是個時序問題。 解決循環(huán)抓幀直到frame.Empty()為false加超時控制。我一般寫10秒內(nèi)連續(xù)嘗試60次全失敗才報錯成功后就穩(wěn)定了。此外檢查設(shè)備是否正被相機App占用Windows下部分攝像頭驅(qū)動只允許單一進程打開?，F(xiàn)象設(shè)置1920x1080后Get回來只有640x480畫面拉伸變形。 原因攝像頭的固件固化了傳感器輸出分辨率超過上限的請求會被驅(qū)動降級。 解決別跟它硬剛采用枚舉模式。把1280x720、1920x1080、640x480都Set一遍每次讀回Get值找到實際生效的最高分辨率而不是默認用戶選了哪個就用哪個。實測很多標稱1080P的攝像頭1080P下FPS只有15720P反而能跑到30看你的業(yè)務(wù)要清晰度還是流暢度?，F(xiàn)象程序關(guān)閉后攝像頭燈還亮著下次啟動打不開設(shè)備。 原因VideoCapture沒有Release或者進程異常退出導致DirectShow過濾器未釋放。 解決在窗體Closing事件里統(tǒng)一執(zhí)行capture.Release()并置null。更進一步用using語句包裹整個采集對象生命周期。PowerShell里跑Get-Process | Where-Object {$_.MainWindowTitle -eq }找出殘留進程的話說明你的代碼沒走正常關(guān)閉流程先檢查這里?，F(xiàn)象預覽約30分鐘后內(nèi)存占用從80MB漲到400MB。 原因每秒30幀的NewFrame事件里每幀都new了Bitmap或Mat上一幀沒有Dispose。AForge方案最常見其次是回調(diào)里Clone出來的幀沒釋放。 解決采集回調(diào)中統(tǒng)一使用復用邏輯——幀對象用完即Dispose或者用一個固定大小的環(huán)形緩沖池復用內(nèi)存。我的經(jīng)驗是代碼里每次出現(xiàn)new Mat()就要警覺檢查它是不是在循環(huán)里。現(xiàn)象USB攝像頭用著用著突然斷流Read一直返回false重連USB接口又恢復正常。 原因多半是USB供電不足或線纜質(zhì)量差攝像頭在高分辨率高幀率下功耗增大導致掉線。Windows日志里能查到事件ID 219的USB錯誤。 解決先降分辨率到720P和25幀排除帶寬問題如果穩(wěn)定換帶屏蔽層的USB線或換直連主板的USB接口不要通過前置USB Hub。軟件側(cè)處理是斷線自動重連檢測到連續(xù)N幀失敗就重新new VideoCapture這個兜底邏輯建議必須寫車間環(huán)境USB干擾太常見了。5. 進階實時預覽性能優(yōu)化與視頻錄制落地預覽卡頓通常不是攝像頭的問題而是你的代碼在UI線程干了太多事。優(yōu)化思路有三個方向。第一把PictureBox的Image賦值改成雙緩沖繪圖直接繪制到控件的緩沖畫布上避免整圖每次重新分配GDI句柄。第二把圖像縮放到顯示區(qū)域再繪而不是把原始Mat直接扔給控件——1920x1080的幀在1080P屏幕上其實用不著全尺寸渲染按控件寬高等比縮放能省掉一多半繪制時間。第三采集線程只負責抓幀和投遞渲染由UI線程定時器去隊列取最新幀中間丟幀沒關(guān)系保證顯示流暢即可。視頻錄制這一塊OpenCvSharp的VideoWriter可以直接出AVIusing (var writer new VideoWriter( output.avi, FourCC.MJPG, 25.0, new Size(1280, 720))) { using (var frame new Mat()) { while (capture.Read(frame) !frame.Empty()) { writer.Write(frame); } } }FourCC選MJPG是視頻壓縮的關(guān)鍵MJPG壓縮率高AVI體積可控如果你用裸的YUYV格式寫一分鐘720P視頻能上1GB沒人受得了。錄制的幀率盡量與捕獲FPS保持一致25或30都行。不匹配的時候VideoWriter會按時間戳跳幀或重復幀播放時要么拖影要么跳幀這是常見翻車點。再講一個幀處理的小技巧在顯示和保存走同一套處理管線的時候調(diào)整好格式流轉(zhuǎn)順序。OpenCvSharp讀出來是BGR你顯示到控件前不用轉(zhuǎn)色但保存JPEG就是BGR沒問題一旦要做顏色識別先用Cv2.CvtColor轉(zhuǎn)成HSV再處理別在BGR空間里手動判顏色范圍又慢又容易漏判。這個順序定了就別來回改我見過同事寫代碼把BGR轉(zhuǎn)RGB又轉(zhuǎn)回BGR白白丟精度還沒意義。優(yōu)化落到最后我的習慣是每次寫完攝像頭程序都強制走一遍完整驗收流程枚舉設(shè)備、設(shè)置參數(shù)后讀回校驗、連續(xù)采集5分鐘看內(nèi)存曲線、拔掉USB線再插上驗證重連邏輯。這一套下來基本能覆蓋現(xiàn)場90%的故障。從那以后我交付的攝像頭模塊到現(xiàn)場出問題的次數(shù)明顯少了希望幫到你。本文還有配套的精品資源點擊獲取