简介：本资源面向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.win（Windows）或对应平台的 runtime 包，少装一个，VideoCapture直接抛异常或者返回空帧。
# 查看已安装的 OpenCvSharp 相关包，确认 runtime 包在不在 dotnet list package | findstr OpenCvSharp逻辑说明：OpenCvSharp4只提供托管 API，OpenCvSharp4.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:pass@192.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 | 编码 | 兼容性 | 文件体积 | 适用场景 |
|---|---|---|---|---|
| mp4v | MPEG-4 Part 2 | 高 | 中 | 通用留存、兼容优先 |
| avc1 / H264 | H.264 | 中 | 小 | 长时间录制、存储敏感 |
| MJPG | Motion 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 录制这件事，代码本身不难，难的是对网络、编码、内存这三件事保持敬畏。希望帮到你。
本文还有配套的精品资源，点击获取
