簡(jiǎn)介本資源面向C#開發(fā)者與視頻監(jiān)控、流媒體方向的學(xué)習(xí)者提供使用OpenCvSharp讀取RTSP流并錄制為MP4的完整可運(yùn)行Demo幫助解決網(wǎng)絡(luò)攝像頭視頻接入、實(shí)時(shí)解碼與本地存儲(chǔ)的常見工程問題。壓縮包共261個(gè)文件約161.67MB包含9個(gè)cs源碼文件、1個(gè)sln解決方案與1個(gè)csproj工程文件以及63個(gè)dll依賴庫、50個(gè)xml文檔、11個(gè)nupkg包和若干config、props、targets等配置項(xiàng)另附1個(gè)mp4示例與2張png截圖便于直接編譯調(diào)試。目前已有1106人學(xué)習(xí)下載。讀者可從中獲取RTSP拉流、幀解碼、VideoWriter寫MP4的完整代碼結(jié)構(gòu)理解OpenCvSharp在C#中的調(diào)用方式與依賴組織并參考工程配置快速搭建自己的錄制程序適合作為流媒體錄制功能的起步模板與排錯(cuò)參考。1. 從一路 RTSP 到一份能回放的 MP4這件事到底難在哪很多人第一次用 C# 接 RTSP 攝像頭思路都很直接VideoCapture打開地址循環(huán)Read拿幀VideoWriter寫文件收工。真跑起來才發(fā)現(xiàn)畫面能出來錄下來的 MP4 卻要么打不開要么時(shí)長(zhǎng)是 0 秒要么播到一半花屏要么跑幾個(gè)小時(shí)內(nèi)存悄悄漲到幾個(gè) G。標(biāo)題里這個(gè)「C# OpenCvSharp 讀取 rtsp 流錄制 mp4」看著像個(gè)小工具實(shí)際踩的是三件事的交叉點(diǎn)RTSP 是網(wǎng)絡(luò)實(shí)時(shí)流、OpenCV 的 VideoWriter 是本地文件封裝器、而 C# 的托管內(nèi)存和 FFmpeg 的原生緩沖之間還隔著一層。任何一層沒對(duì)齊產(chǎn)物就是廢文件。這篇面向的是要真交付一個(gè)錄制模塊的 C# 開發(fā)者可能是給某公司的檢測(cè)系統(tǒng)加錄像功能也可能是給某實(shí)驗(yàn)室的模擬項(xiàng)目做數(shù)據(jù)留存。目標(biāo)很明確——用 OpenCvSharp 把一路 RTSP 穩(wěn)定落成可回放的 MP4并且知道碼率、幀率、編碼器、緩沖這幾個(gè)參數(shù)該怎么定出問題該看哪里。下面按「先跑通最小閉環(huán)再談穩(wěn)定和參數(shù)最后講排錯(cuò)」的順序推。2. 用 OpenCvSharp 跑通 RTSP 轉(zhuǎn) MP4 的最小閉環(huán)2.1 先確認(rèn)環(huán)境里到底有沒有可用的編碼器OpenCvSharp 本身是 OpenCV 的 C# 封裝VideoWriter最終調(diào)的是 OpenCV 編譯時(shí)鏈接的 FFmpeg。所以第一件事不是寫代碼是確認(rèn)你手上這份 OpenCvSharp 運(yùn)行時(shí)到底帶沒帶 FFmpeg、支持哪些 fourcc。很多人翻車就翻在這里NuGet 裝的OpenCvSharp4是主包真正提供原生庫的是OpenCvSharp4.runtime.winWindows或?qū)?yīng)平臺(tái)的 runtime 包少裝一個(gè)VideoCapture直接拋異?；蛘叻祷乜諑?。# 查看已安裝的 OpenCvSharp 相關(guān)包確認(rèn) runtime 包在不在 dotnet list package | findstr OpenCvSharp邏輯說明OpenCvSharp4只提供托管 APIOpenCvSharp4.runtime.*才帶OpenCvSharpExtern.dll和 FFmpeg 動(dòng)態(tài)庫。參數(shù)上Windows 桌面項(xiàng)目一般引OpenCvSharp4.runtime.win如果跑在 Linux 容器里要引OpenCvSharp4.runtime.linux-x64并確保系統(tǒng)里有對(duì)應(yīng)的多媒體依賴。看不到 runtime 包后面所有代碼都是空談。確認(rèn)包齊了之后用一段極短的代碼驗(yàn)證編碼器可用性別急著接攝像頭using OpenCvSharp; // 用一張純色圖測(cè)試 VideoWriter 能否正常寫出 mp4 using var probe new Mat(new Size(640, 480), MatType.CV_8UC3, Scalar.All(60)); using var writer new VideoWriter( probe.mp4, FourCC.MP4V, // 先試 mp4v兼容性最好 25.0, // 幀率 new Size(640, 480)); if (!writer.IsOpened()) { Console.WriteLine(VideoWriter 打開失敗檢查 runtime 包和 fourcc); return; } for (int i 0; i 50; i) writer.Write(probe); writer.Release();邏輯說明這段不碰網(wǎng)絡(luò)只驗(yàn)證「本地寫 MP4」這條鏈路。FourCC.MP4V對(duì)應(yīng) MPEG-4 Part 2幾乎所有 OpenCV 構(gòu)建都帶如果它都打不開說明 runtime 有問題先解決環(huán)境再談 RTSP。參數(shù)上25.0是寫入幀率Size必須和Mat尺寸完全一致差一個(gè)像素都會(huì)寫出花屏或直接失敗。2.2 打開 RTSP 并讀出第一幀真實(shí)分辨率RTSP 流的實(shí)際分辨率經(jīng)常和你以為的不一樣尤其是帶子碼流的攝像頭。硬編碼new Size(1920,1080)是經(jīng)典翻車點(diǎn)攝像頭實(shí)際推 1280×720你按 1080p 建 writer寫出來的文件要么報(bào)錯(cuò)要么畫面撕裂。正確做法是先讀一幀用這一幀的尺寸建 writer。using OpenCvSharp; const string RtspUrl rtsp://user:pass192.168.1.10:554/stream1; using var capture new VideoCapture(RtspUrl, VideoCaptureAPIs.FFMPEG); // 關(guān)鍵設(shè)置超時(shí)避免網(wǎng)絡(luò)卡死時(shí) Read 永久阻塞 capture.Set(VideoCaptureProperties.OpenTimeout, 5000); // 毫秒 capture.Set(VideoCaptureProperties.ReadTimeout, 5000); if (!capture.IsOpened()) { Console.WriteLine(RTSP 打開失敗地址、鑒權(quán)或網(wǎng)絡(luò)); return; } using var first new Mat(); if (!capture.Read(first) || first.Empty()) { Console.WriteLine(首幀讀取失敗流可能還沒就緒); return; } Console.WriteLine($實(shí)際分辨率 {first.Width}x{first.Height});邏輯說明VideoCaptureAPIs.FFMPEG顯式指定后端避免 OpenCV 在某些平臺(tái)上選到別的后端導(dǎo)致行為不一致。OpenTimeout和ReadTimeout是很多人忽略的參數(shù)——不設(shè)的話網(wǎng)絡(luò)抖動(dòng)時(shí)Read會(huì)一直掛著整個(gè)線程像死了一樣這就是所謂「玄學(xué)卡死」的常見來源。首幀讀出來后first.Width/Height才是你建 writer 該用的尺寸。2.3 把 writer 和 capture 接起來形成錄制循環(huán)有了真實(shí)尺寸就可以建 writer 并進(jìn)入循環(huán)。這里有個(gè)容易被忽視的點(diǎn)錄制循環(huán)里不要做任何耗時(shí)操作比如每幀存圖、寫日志、更新 UI否則讀幀速度跟不上RTSP 緩沖堆積延遲越來越大。using var writer new VideoWriter( record.mp4, FourCC.MP4V, 25.0, new Size(first.Width, first.Height)); if (!writer.IsOpened()) { Console.WriteLine(writer 打開失敗檢查 fourcc 與尺寸); return; } using var frame new Mat(); int count 0; while (true) { if (!capture.Read(frame) || frame.Empty()) { Console.WriteLine(讀幀中斷嘗試重連); break; } writer.Write(frame); count; if (count % 250 0) Console.WriteLine($已寫入 {count} 幀); } writer.Release(); capture.Release();邏輯說明writer.Write(frame)內(nèi)部會(huì)把 BGR 幀交給 FFmpeg 編碼尺寸必須和建 writer 時(shí)一致。count % 250只是輕量進(jìn)度提示別在這里做重活。循環(huán)退出條件目前是讀幀失敗真實(shí)項(xiàng)目里要接重連邏輯下一章展開。參數(shù)上寫入幀率25.0是「聲明值」它不改變實(shí)際采集速度只影響播放器按什么速度回放——這點(diǎn)后面避坑章會(huì)重點(diǎn)講。3. 讓錄制穩(wěn)定下來的四個(gè)關(guān)鍵參數(shù)與重連策略3.1 幀率寫入幀率和實(shí)際采集幀率對(duì)不上會(huì)怎樣VideoWriter的幀率參數(shù)是個(gè)「聲明」它告訴封裝器「這些幀按每秒 N 幀播放」。如果你聲明 25但實(shí)際因?yàn)榫W(wǎng)絡(luò)慢每秒只讀到 10 幀那錄出來的 10 秒素材會(huì)被播放器當(dāng)成 4 秒播完看起來像快進(jìn)。反過來聲明 10 實(shí)際讀到 25 幀播放就變慢動(dòng)作。這是 RTSP 錄制最隱蔽的坑之一因?yàn)槲募艽蜷_、畫面也正常就是時(shí)間軸不對(duì)。常見做法有兩種。第一種是「按實(shí)際節(jié)奏寫」統(tǒng)計(jì)一段時(shí)間內(nèi)真實(shí)讀到的幀數(shù)動(dòng)態(tài)估算 fps再建 writer。第二種是「固定節(jié)奏 丟幀/補(bǔ)幀」聲明固定 fps讀快了就丟讀慢了就重復(fù)上一幀。前者適合留存原始素材后者適合做實(shí)時(shí)預(yù)覽錄制。我一般用第一種實(shí)現(xiàn)簡(jiǎn)單且不引入偽造幀// 采樣 3 秒估算真實(shí)幀率 var sw System.Diagnostics.Stopwatch.StartNew(); int sampled 0; using var tmp new Mat(); while (sw.ElapsedMilliseconds 3000) { if (capture.Read(tmp) !tmp.Empty()) sampled; } double realFps sampled / (sw.ElapsedMilliseconds / 1000.0); Console.WriteLine($實(shí)測(cè)幀率約 {realFps:F1});邏輯說明這段會(huì)消耗掉 3 秒的流數(shù)據(jù)所以要在正式錄制前做或者接受前 3 秒不入庫。realFps拿去建 writer時(shí)間軸就基本對(duì)得上了。注意 RTSP 流的幀率本身可能波動(dòng)估算值取整到常用檔位如 24、25、30更穩(wěn)。3.2 編碼器選擇mp4v、avc1、H264 到底選哪個(gè)fourcc 決定封裝里用什么編碼。mp4v兼容性最好但壓縮率一般avc1/H264壓縮率高、文件小但依賴 OpenCV 構(gòu)建時(shí)是否帶 x264 或系統(tǒng)編碼器很多預(yù)編譯包不帶會(huì)直接打開失敗。選型邏輯很簡(jiǎn)單先試avc1打不開就退回mp4v別硬剛。fourcc編碼兼容性文件體積適用場(chǎng)景mp4vMPEG-4 Part 2高中通用留存、兼容優(yōu)先avc1 / H264H.264中小長(zhǎng)時(shí)間錄制、存儲(chǔ)敏感MJPGMotion JPEG高大逐幀獨(dú)立、便于抽幀// 優(yōu)先 H264失敗退回 mp4v VideoWriter OpenWriter(string path, double fps, Size size) { var w new VideoWriter(path, FourCC.FromString(avc1), fps, size); if (w.IsOpened()) return w; w.Dispose(); Console.WriteLine(avc1 不可用退回 mp4v); return new VideoWriter(path, FourCC.MP4V, fps, size); }邏輯說明FourCC.FromString(avc1)比枚舉更靈活方便試不同編碼。退回邏輯要顯式Dispose掉失敗的 writer否則可能占著文件句柄。參數(shù)上如果項(xiàng)目對(duì)體積敏感又必須用 H264可以考慮錄完用外部 FFmpeg 轉(zhuǎn)碼而不是強(qiáng)求 OpenCV 內(nèi)置編碼器。3.3 斷流重連別讓一次網(wǎng)絡(luò)抖動(dòng)毀掉整段錄制RTSP 斷流是常態(tài)尤其是無線攝像頭。capture.Read返回 false 不代表攝像頭壞了可能只是丟了幾秒。直接退出循環(huán)會(huì)讓錄制提前結(jié)束正確做法是帶退避的重連并且決定「重連后是續(xù)寫同一個(gè)文件還是新開文件」。續(xù)寫同一個(gè)文件需要 writer 一直開著但斷流期間沒有幀寫入時(shí)間軸會(huì)出現(xiàn)空洞新開文件更干凈代價(jià)是素材被切成多段。int retry 0; while (retry 5) { using var cap new VideoCapture(RtspUrl, VideoCaptureAPIs.FFMPEG); cap.Set(VideoCaptureProperties.OpenTimeout, 5000); if (!cap.IsOpened()) { retry; Thread.Sleep(1000 * retry); // 退避1s,2s,3s... continue; } retry 0; // 連上就重置 // ... 進(jìn)入讀幀循環(huán)讀失敗則 break 回到這里重連 }邏輯說明退避時(shí)間隨重試次數(shù)增長(zhǎng)避免瘋狂重連把攝像頭打掛。retry連上后重置保證長(zhǎng)時(shí)間運(yùn)行中偶發(fā)斷流不會(huì)累積到上限。參數(shù)上 5 次是經(jīng)驗(yàn)值超過基本說明是地址或網(wǎng)絡(luò)問題該報(bào)錯(cuò)而不是繼續(xù)等。3.4 緩沖與內(nèi)存為什么跑幾小時(shí)內(nèi)存就上去了OpenCV 的VideoCapture內(nèi)部有解碼緩沖VideoWriter內(nèi)部有編碼緩沖。如果讀幀速度長(zhǎng)期慢于流入速度緩沖會(huì)堆積表現(xiàn)為延遲越來越大、內(nèi)存持續(xù)上漲?？刂剖侄斡腥齻€(gè)一是別在循環(huán)里Clone()每一幀卻不釋放二是用using或顯式Dispose管理Mat三是必要時(shí)設(shè)置VideoCaptureProperties.BufferSize限制緩沖幀數(shù)。// 限制內(nèi)部緩沖降低延遲和內(nèi)存占用 capture.Set(VideoCaptureProperties.BufferSize, 3);邏輯說明BufferSize太小可能增加丟幀太大則延遲高。3 到 5 是實(shí)時(shí)錄制的常用區(qū)間。注意這個(gè)屬性不是所有后端都生效FFMPEG 后端一般支持。真正要盯的是自己的代碼循環(huán)里每new一個(gè)Mat都要有對(duì)應(yīng)的釋放路徑否則 GC 跟不上原生內(nèi)存分配速度這就是「內(nèi)存黑匣子」的來源。4. 錄制鏈路的避坑與排查清單4.1 錄出來的 MP4 打不開或時(shí)長(zhǎng)為 0現(xiàn)象文件生成了雙擊打不開或者屬性里時(shí)長(zhǎng)顯示 0 秒。原因通常是 writer 沒有正常Release——程序崩潰、異常退出、或者using作用域沒走到導(dǎo)致 MP4 的 moov 原子沒寫入文件尾部。MP4 的索引信息在文件末尾沒寫完就是廢文件。解決把writer.Release()放進(jìn)finally并且給進(jìn)程加異常兜底確保退出前一定釋放。4.2 畫面能播但時(shí)間軸明顯不對(duì)現(xiàn)象畫面正常但 10 分鐘的錄制播放器顯示 3 分鐘或者像快進(jìn)。原因就是 3.1 說的寫入幀率和實(shí)際采集幀率不一致。解決錄制前采樣估算真實(shí) fps或者接受固定 fps 并做丟幀/補(bǔ)幀。別用「感覺差不多」的幀率RTSP 流的實(shí)際節(jié)奏和標(biāo)稱值經(jīng)常差很多。4.3 跑一段時(shí)間后 Read 卡住不動(dòng)現(xiàn)象程序還在跑但不再寫幀日志停在某一行。原因多半是沒設(shè)ReadTimeout網(wǎng)絡(luò)半死狀態(tài)下Read永久阻塞。解決顯式設(shè)置OpenTimeout和ReadTimeout并在外層加重連。如果后端不支持超時(shí)屬性就把讀幀放到獨(dú)立線程用Task 超時(shí)取消來兜底。4.4 多路錄制時(shí) CPU 直接拉滿現(xiàn)象單路沒問題開到 4 路、8 路 CPU 飆到 100%幀開始丟。原因每路都在做解碼 編碼且可能都在主線程或線程池里搶資源。解決每路用獨(dú)立線程控制并發(fā)路數(shù)編碼器優(yōu)先選硬件加速方案如果運(yùn)行環(huán)境支持或者降低錄制分辨率/幀率。別指望單機(jī)軟編能扛幾十路 1080p。4.5 中文路徑或特殊字符導(dǎo)致 writer 打開失敗現(xiàn)象英文路徑正常換成帶中文或空格的路徑就IsOpened()返回 false。原因底層 FFmpeg 對(duì)路徑編碼的處理在不同平臺(tái)不一致。解決錄制時(shí)先用臨時(shí)英文路徑錄完再移動(dòng)到目標(biāo)位置或者確保傳入的是完整絕對(duì)路徑避免相對(duì)路徑拼接帶來的歧義。5. 把錄制模塊做成能長(zhǎng)期跑的服務(wù)幾個(gè)進(jìn)階習(xí)慣走到這里最小閉環(huán)和穩(wěn)定性都覆蓋了。最后說幾個(gè)我實(shí)際做項(xiàng)目時(shí)養(yǎng)成的習(xí)慣能讓這個(gè)模塊從「能跑」變成「敢讓它跑一周」。第一給錄制加一個(gè)「心跳文件」或狀態(tài)輸出。每寫入 N 幀更新一次狀態(tài)幀數(shù)、當(dāng)前文件大小、最后成功讀幀時(shí)間外部監(jiān)控讀這個(gè)狀態(tài)就能判斷錄制是否還活著。比翻日志快得多也方便做告警。第二文件切分。單個(gè) MP4 不要無限寫下去一是崩潰時(shí)損失大二是有些播放器對(duì)大文件支持不好。按時(shí)間或大小切分比如每 10 分鐘一個(gè)新文件文件名帶時(shí)間戳。切分點(diǎn)就是天然的恢復(fù)點(diǎn)。// 按時(shí)間切分每 10 分鐘換一個(gè)文件 var segmentStart DateTime.Now; string NewPath() $record_{DateTime.Now:yyyyMMdd_HHmmss}.mp4; // 循環(huán)內(nèi)判斷 if ((DateTime.Now - segmentStart).TotalMinutes 10) { writer.Release(); writer OpenWriter(NewPath(), realFps, size); segmentStart DateTime.Now; }邏輯說明切分時(shí)先Release舊 writer 保證文件完整再開新的。realFps和size沿用之前的值避免中途尺寸變化導(dǎo)致失敗。參數(shù)上 10 分鐘是經(jīng)驗(yàn)值存儲(chǔ)緊張可以縮短需要連續(xù)素材可以拉長(zhǎng)。第三驗(yàn)證產(chǎn)物而不是假設(shè)產(chǎn)物。每次錄制結(jié)束用VideoCapture重新打開錄好的文件讀幾幀確認(rèn)能解碼、確認(rèn)幀數(shù)和預(yù)期接近。這一步能擋住絕大多數(shù)「文件生成了但其實(shí)是壞的」問題。// 錄完后自檢能否重新打開并讀到幀 using var check new VideoCapture(record.mp4); if (!check.IsOpened() || !check.Read(new Mat())) Console.WriteLine(產(chǎn)物自檢失敗文件可能損壞);邏輯說明VideoCapture打開本地 MP4 走的是解碼路徑能打開且能讀幀基本說明封裝和編碼都正常。這個(gè)自檢成本極低但能省掉大量「交付后才發(fā)現(xiàn)文件打不開」的后悔藥。我自己的習(xí)慣是任何錄制模塊上線前先讓它空跑 24 小時(shí)中間人為拔一次網(wǎng)線、改一次系統(tǒng)時(shí)間、塞滿一次磁盤看它怎么反應(yīng)。能扛過這三樣的才敢放到生產(chǎn)環(huán)境。RTSP 錄制這件事代碼本身不難難的是對(duì)網(wǎng)絡(luò)、編碼、內(nèi)存這三件事保持敬畏。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取