简介本资源面向C#开发者与视频监控、流媒体方向的学习者提供使用OpenCvSharp读取RTSP流并录制为MP4的完整可运行Demo帮助解决网络摄像头视频接入、实时解码与本地存储的常见工程问题。压缩包共261个文件约161.67MB包含9个cs源码文件、1个sln解决方案与1个csproj工程文件以及63个dll依赖库、50个xml文档、11个nupkg包和若干config、props、targets等配置项另附1个mp4示例与2张png截图便于直接编译调试。目前已有1106人学习下载。读者可从中获取RTSP拉流、帧解码、VideoWriter写MP4的完整代码结构理解OpenCvSharp在C#中的调用方式与依赖组织并参考工程配置快速搭建自己的录制程序适合作为流媒体录制功能的起步模板与排错参考。1. 从一路 RTSP 到一份能回放的 MP4这件事到底难在哪很多人第一次用 C# 接 RTSP 摄像头思路都很直接VideoCapture打开地址循环Read拿帧VideoWriter写文件收工。真跑起来才发现画面能出来录下来的 MP4 却要么打不开要么时长是 0 秒要么播到一半花屏要么跑几个小时内存悄悄涨到几个 G。标题里这个「C# OpenCvSharp 读取 rtsp 流录制 mp4」看着像个小工具实际踩的是三件事的交叉点RTSP 是网络实时流、OpenCV 的 VideoWriter 是本地文件封装器、而 C# 的托管内存和 FFmpeg 的原生缓冲之间还隔着一层。任何一层没对齐产物就是废文件。这篇面向的是要真交付一个录制模块的 C# 开发者可能是给某公司的检测系统加录像功能也可能是给某实验室的模拟项目做数据留存。目标很明确——用 OpenCvSharp 把一路 RTSP 稳定落成可回放的 MP4并且知道码率、帧率、编码器、缓冲这几个参数该怎么定出问题该看哪里。下面按「先跑通最小闭环再谈稳定和参数最后讲排错」的顺序推。2. 用 OpenCvSharp 跑通 RTSP 转 MP4 的最小闭环2.1 先确认环境里到底有没有可用的编码器OpenCvSharp 本身是 OpenCV 的 C# 封装VideoWriter最终调的是 OpenCV 编译时链接的 FFmpeg。所以第一件事不是写代码是确认你手上这份 OpenCvSharp 运行时到底带没带 FFmpeg、支持哪些 fourcc。很多人翻车就翻在这里NuGet 装的OpenCvSharp4是主包真正提供原生库的是OpenCvSharp4.runtime.winWindows或对应平台的 runtime 包少装一个VideoCapture直接抛异常或者返回空帧。# 查看已安装的 OpenCvSharp 相关包确认 runtime 包在不在 dotnet list package | findstr OpenCvSharp逻辑说明OpenCvSharp4只提供托管 APIOpenCvSharp4.runtime.*才带OpenCvSharpExtern.dll和 FFmpeg 动态库。参数上Windows 桌面项目一般引OpenCvSharp4.runtime.win如果跑在 Linux 容器里要引OpenCvSharp4.runtime.linux-x64并确保系统里有对应的多媒体依赖。看不到 runtime 包后面所有代码都是空谈。确认包齐了之后用一段极短的代码验证编码器可用性别急着接摄像头using OpenCvSharp; // 用一张纯色图测试 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();逻辑说明这段不碰网络只验证「本地写 MP4」这条链路。FourCC.MP4V对应 MPEG-4 Part 2几乎所有 OpenCV 构建都带如果它都打不开说明 runtime 有问题先解决环境再谈 RTSP。参数上25.0是写入帧率Size必须和Mat尺寸完全一致差一个像素都会写出花屏或直接失败。2.2 打开 RTSP 并读出第一帧真实分辨率RTSP 流的实际分辨率经常和你以为的不一样尤其是带子码流的摄像头。硬编码new Size(1920,1080)是经典翻车点摄像头实际推 1280×720你按 1080p 建 writer写出来的文件要么报错要么画面撕裂。正确做法是先读一帧用这一帧的尺寸建 writer。using OpenCvSharp; const string RtspUrl rtsp://user:pass192.168.1.10:554/stream1; using var capture new VideoCapture(RtspUrl, VideoCaptureAPIs.FFMPEG); // 关键设置超时避免网络卡死时 Read 永久阻塞 capture.Set(VideoCaptureProperties.OpenTimeout, 5000); // 毫秒 capture.Set(VideoCaptureProperties.ReadTimeout, 5000); if (!capture.IsOpened()) { Console.WriteLine(RTSP 打开失败地址、鉴权或网络); return; } using var first new Mat(); if (!capture.Read(first) || first.Empty()) { Console.WriteLine(首帧读取失败流可能还没就绪); return; } Console.WriteLine($实际分辨率 {first.Width}x{first.Height});逻辑说明VideoCaptureAPIs.FFMPEG显式指定后端避免 OpenCV 在某些平台上选到别的后端导致行为不一致。OpenTimeout和ReadTimeout是很多人忽略的参数——不设的话网络抖动时Read会一直挂着整个线程像死了一样这就是所谓「玄学卡死」的常见来源。首帧读出来后first.Width/Height才是你建 writer 该用的尺寸。2.3 把 writer 和 capture 接起来形成录制循环有了真实尺寸就可以建 writer 并进入循环。这里有个容易被忽视的点录制循环里不要做任何耗时操作比如每帧存图、写日志、更新 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)内部会把 BGR 帧交给 FFmpeg 编码尺寸必须和建 writer 时一致。count % 250只是轻量进度提示别在这里做重活。循环退出条件目前是读帧失败真实项目里要接重连逻辑下一章展开。参数上写入帧率25.0是「声明值」它不改变实际采集速度只影响播放器按什么速度回放——这点后面避坑章会重点讲。3. 让录制稳定下来的四个关键参数与重连策略3.1 帧率写入帧率和实际采集帧率对不上会怎样VideoWriter的帧率参数是个「声明」它告诉封装器「这些帧按每秒 N 帧播放」。如果你声明 25但实际因为网络慢每秒只读到 10 帧那录出来的 10 秒素材会被播放器当成 4 秒播完看起来像快进。反过来声明 10 实际读到 25 帧播放就变慢动作。这是 RTSP 录制最隐蔽的坑之一因为文件能打开、画面也正常就是时间轴不对。常见做法有两种。第一种是「按实际节奏写」统计一段时间内真实读到的帧数动态估算 fps再建 writer。第二种是「固定节奏 丢帧/补帧」声明固定 fps读快了就丢读慢了就重复上一帧。前者适合留存原始素材后者适合做实时预览录制。我一般用第一种实现简单且不引入伪造帧// 采样 3 秒估算真实帧率 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($实测帧率约 {realFps:F1});逻辑说明这段会消耗掉 3 秒的流数据所以要在正式录制前做或者接受前 3 秒不入库。realFps拿去建 writer时间轴就基本对得上了。注意 RTSP 流的帧率本身可能波动估算值取整到常用档位如 24、25、30更稳。3.2 编码器选择mp4v、avc1、H264 到底选哪个fourcc 决定封装里用什么编码。mp4v兼容性最好但压缩率一般avc1/H264压缩率高、文件小但依赖 OpenCV 构建时是否带 x264 或系统编码器很多预编译包不带会直接打开失败。选型逻辑很简单先试avc1打不开就退回mp4v别硬刚。fourcc编码兼容性文件体积适用场景mp4vMPEG-4 Part 2高中通用留存、兼容优先avc1 / H264H.264中小长时间录制、存储敏感MJPGMotion JPEG高大逐帧独立、便于抽帧// 优先 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否则可能占着文件句柄。参数上如果项目对体积敏感又必须用 H264可以考虑录完用外部 FFmpeg 转码而不是强求 OpenCV 内置编码器。3.3 断流重连别让一次网络抖动毁掉整段录制RTSP 断流是常态尤其是无线摄像头。capture.Read返回 false 不代表摄像头坏了可能只是丢了几秒。直接退出循环会让录制提前结束正确做法是带退避的重连并且决定「重连后是续写同一个文件还是新开文件」。续写同一个文件需要 writer 一直开着但断流期间没有帧写入时间轴会出现空洞新开文件更干净代价是素材被切成多段。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; // 连上就重置 // ... 进入读帧循环读失败则 break 回到这里重连 }逻辑说明退避时间随重试次数增长避免疯狂重连把摄像头打挂。retry连上后重置保证长时间运行中偶发断流不会累积到上限。参数上 5 次是经验值超过基本说明是地址或网络问题该报错而不是继续等。3.4 缓冲与内存为什么跑几小时内存就上去了OpenCV 的VideoCapture内部有解码缓冲VideoWriter内部有编码缓冲。如果读帧速度长期慢于流入速度缓冲会堆积表现为延迟越来越大、内存持续上涨。控制手段有三个一是别在循环里Clone()每一帧却不释放二是用using或显式Dispose管理Mat三是必要时设置VideoCaptureProperties.BufferSize限制缓冲帧数。// 限制内部缓冲降低延迟和内存占用 capture.Set(VideoCaptureProperties.BufferSize, 3);逻辑说明BufferSize太小可能增加丢帧太大则延迟高。3 到 5 是实时录制的常用区间。注意这个属性不是所有后端都生效FFMPEG 后端一般支持。真正要盯的是自己的代码循环里每new一个Mat都要有对应的释放路径否则 GC 跟不上原生内存分配速度这就是「内存黑匣子」的来源。4. 录制链路的避坑与排查清单4.1 录出来的 MP4 打不开或时长为 0现象文件生成了双击打不开或者属性里时长显示 0 秒。原因通常是 writer 没有正常Release——程序崩溃、异常退出、或者using作用域没走到导致 MP4 的 moov 原子没写入文件尾部。MP4 的索引信息在文件末尾没写完就是废文件。解决把writer.Release()放进finally并且给进程加异常兜底确保退出前一定释放。4.2 画面能播但时间轴明显不对现象画面正常但 10 分钟的录制播放器显示 3 分钟或者像快进。原因就是 3.1 说的写入帧率和实际采集帧率不一致。解决录制前采样估算真实 fps或者接受固定 fps 并做丢帧/补帧。别用「感觉差不多」的帧率RTSP 流的实际节奏和标称值经常差很多。4.3 跑一段时间后 Read 卡住不动现象程序还在跑但不再写帧日志停在某一行。原因多半是没设ReadTimeout网络半死状态下Read永久阻塞。解决显式设置OpenTimeout和ReadTimeout并在外层加重连。如果后端不支持超时属性就把读帧放到独立线程用Task 超时取消来兜底。4.4 多路录制时 CPU 直接拉满现象单路没问题开到 4 路、8 路 CPU 飙到 100%帧开始丢。原因每路都在做解码 编码且可能都在主线程或线程池里抢资源。解决每路用独立线程控制并发路数编码器优先选硬件加速方案如果运行环境支持或者降低录制分辨率/帧率。别指望单机软编能扛几十路 1080p。4.5 中文路径或特殊字符导致 writer 打开失败现象英文路径正常换成带中文或空格的路径就IsOpened()返回 false。原因底层 FFmpeg 对路径编码的处理在不同平台不一致。解决录制时先用临时英文路径录完再移动到目标位置或者确保传入的是完整绝对路径避免相对路径拼接带来的歧义。5. 把录制模块做成能长期跑的服务几个进阶习惯走到这里最小闭环和稳定性都覆盖了。最后说几个我实际做项目时养成的习惯能让这个模块从「能跑」变成「敢让它跑一周」。第一给录制加一个「心跳文件」或状态输出。每写入 N 帧更新一次状态帧数、当前文件大小、最后成功读帧时间外部监控读这个状态就能判断录制是否还活着。比翻日志快得多也方便做告警。第二文件切分。单个 MP4 不要无限写下去一是崩溃时损失大二是有些播放器对大文件支持不好。按时间或大小切分比如每 10 分钟一个新文件文件名带时间戳。切分点就是天然的恢复点。// 按时间切分每 10 分钟换一个文件 var segmentStart DateTime.Now; string NewPath() $record_{DateTime.Now:yyyyMMdd_HHmmss}.mp4; // 循环内判断 if ((DateTime.Now - segmentStart).TotalMinutes 10) { writer.Release(); writer OpenWriter(NewPath(), realFps, size); segmentStart DateTime.Now; }逻辑说明切分时先Release旧 writer 保证文件完整再开新的。realFps和size沿用之前的值避免中途尺寸变化导致失败。参数上 10 分钟是经验值存储紧张可以缩短需要连续素材可以拉长。第三验证产物而不是假设产物。每次录制结束用VideoCapture重新打开录好的文件读几帧确认能解码、确认帧数和预期接近。这一步能挡住绝大多数「文件生成了但其实是坏的」问题。// 录完后自检能否重新打开并读到帧 using var check new VideoCapture(record.mp4); if (!check.IsOpened() || !check.Read(new Mat())) Console.WriteLine(产物自检失败文件可能损坏);逻辑说明VideoCapture打开本地 MP4 走的是解码路径能打开且能读帧基本说明封装和编码都正常。这个自检成本极低但能省掉大量「交付后才发现文件打不开」的后悔药。我自己的习惯是任何录制模块上线前先让它空跑 24 小时中间人为拔一次网线、改一次系统时间、塞满一次磁盘看它怎么反应。能扛过这三样的才敢放到生产环境。RTSP 录制这件事代码本身不难难的是对网络、编码、内存这三件事保持敬畏。希望帮到你。本文还有配套的精品资源点击获取