简介这是一份面向C#开发者的RTSP视频流录制示例基于OpenCvSharp实现从网络摄像头、监控设备或流媒体服务器读取RTSP流并输出为MP4文件的完整Demo。资源适合有基础C#知识、希望在WinForm/WPF或控制台项目中快速接入视频采集与存储的开发者参考。压缩包内共261个文件整体大小约161.67MB主要包含dll依赖库OpenCvSharp相关、cs源码工程、xml文档与配置文件、nupkg包管理文件以及用于演示的mp4测试视频和txt说明文档目录结构清晰便于定位代码与依赖。示例可直接运行涉及视频流获取、帧处理、编码封装等关键环节可帮助读者理解OpenCvSharp操作视频文件的核心流程并迁移到自己的项目中。目前已有1106人学习下载是一个兼具入门指导与实战参考价值的资源。1. 用 C# 和 OpenCvSharp 拉取 RTSP 流并录制 MP4一份可直接改的实践模板在生产环境里用 C# 和 OpenCvSharp 读取 RTSP 流并录制 mp4最坑的不是代码逻辑而是你对底层视频协议的认知。我接过一个海康摄像头的项目主码流 1080p子码流 720p地址配错一位就连不上明明摄像头一直在输出程序就是录不出文件。折腾一晚上后把整个流程拆成了环境、拉流、写文件、调参、排错五个环节才算真正跑通。这份资源是一套 VS 工程示例核心解决一件事用 OpenCvSharp 的 VideoCapture 拉 RTSP 流把 Mat 帧写进 VideoWriter落盘成 MP4。适合正在做 C# 上位机、监控录像、视觉检测数据采集的开发者尤其是那些不想引入重量级 FFmpeg 封装库只想在托管代码里快速出结果的人。下面按我实际调试的顺序讲先过了环境这关再谈录制逻辑。2. 环境配置OpenCvSharp 的 NuGet 包、原生 DLL 与平台位数2.1 为什么选 OpenCvSharp托管 API 与底层 FFmpeg 后端C# 生态里能处理 RTSP 的方案并不少。老牌的有 VLC.DotNet、AForge.NET工业上有用 FFmpeg.AutoGen 自己封装的还有直接用 P/Invoke 调 opencv_ffmpeg 的。OpenCvSharp 的定位比较特殊它是 OpenCV C API 的 C# 封装VideoCapture 底层走的是 OpenCV 自己的 videoio 模块后端默认就是 FFmpeg。这意味着你不必自己去管理 FFmpeg 的命令行参数也不用手写 AVFrame 到 Bitmap 的转换。我一般选它的理由很实际帧数据是 Mat可以直接给 OpenCV 的检测函数用再往上接自己训练的 YOLO 模型时Mat 转 byte[] 没有中间损耗。而且 OpenCvSharp 支持 Window 和 WinForms/WPF 直接显示 Mat预览和录制可以复用同一个帧对象。这套 .rar 里的代码就是基于这个特点组织起来的。需要清醒一点OpenCvSharp 是托管封装层真正的解码、解复用、编码都在原生 DLL 里。很多人第一次编译通过运行时报 DllNotFoundException是因为原生库没有放到输出目录。所以环境配置的第一步不是写代码而是搞清楚 NuGet 包到底往 bin 里放了什么。2.2 从 .rar 到可编译项目引用、运行时包和输出目录检查这份资源解压后是一个完整的 VS 解决方案csproj 里已经引好了两个关键包PackageReference IncludeOpenCvSharp4 Version4.8.0 / PackageReference IncludeOpenCvSharp4.runtime.win Version4.8.0 /示例里的版本号以你实际 nuget 还原到的版本为准两个包的版本必须一致。第一个包是托管代码包含 VideoCapture、VideoWriter、Mat 这些类第二个是 Windows 原生运行时包含 opencv_world*.dll 和 opencv_videoio_ffmpeg*.dll。NuGet 还原后会自动把对应原生 DLL 复制到输出目录但有一个前提目标平台位数必须匹配。我遇到过最典型的翻车现场项目平台目标是 AnyCPU机器是 64 位系统NuGet 按 x64 复制了原生 DLL程序能正常启动换到 32 位测试机AnyCPU 选了 x86 模式却找不到 x86 原生库瞬间崩溃。所以拿到工程后第一件事右键项目 → 属性 → 生成 → 平台目标直接锁定 x64。如果团队里还有老机器必须跑 x86就要换成 x86 运行时包并把所有依赖项目都改成 x86否则会在某个深层调用里悄悄失败而不是在启动时报错。输出目录也要养成检查习惯。正常编译后bin\Debug 下应该有 opencv_world*.dll、opencv_videoio_ffmpeg*.dll、OpenCvSharp.dll、OpenCvSharp.Extensions.dll 四个关键文件。如果缺文件先清理再重建仍缺就从 NuGet 缓存手动复制到输出目录并设置“如果较新则复制”。2.3 初始化代码先让预览窗口亮起来环境配好之后先跑最小验证不要急着加录制。我只写十几行目标是打开本地视频或 RTSP 地址弹一个窗口显示画面。这一步通过说明 DLL 加载和后端初始化都正常。using OpenCvSharp; // 限制解码线程数避免拉流吃满 CPU Cv2.SetNumThreads(2); var source rtsp://admin:admin123192.168.1.64:554/h264/ch1/main/av_stream; using var capture new VideoCapture(source); if (!capture.IsOpened()) { Console.WriteLine(摄像头上线失败先检查网络和地址); return; } using var window new Window(preview, WindowFlags.AutoSize); using var frame new Mat(); while (capture.Read(frame)) { if (frame.Empty()) break; window.ShowImage(frame); if (Cv2.WaitKey(30) q) break; }Cv2.SetNumThreads(2) 是我在上位机上的习惯写法。OpenCV 解码后端默认按 CPU 核心数开线程在四核以上机器上光拉流预览就可能吃掉三四个核心工业上位机还要同时跑检测和界面刷新把线程数目压到 2 比较划算。参数说明VideoCapture 构造直接传 RTSP 地址时OpenCvSharp 会用带 FFmpeg 的 videoio 后端自动识别协议IsOpened 只是同步检查句柄底层打开耗时可能从几百毫秒到几秒不要放 UI 线程里直接调否则界面会卡住。WaitKey(30) 控制预览刷新间隔不是录制帧率30 毫秒接近 33fps 上限实际刷新还受解码速度影响。这一章不写业务代码但它是整套方案的地基。预览窗口都亮不起来后面所有写入 MP4 的逻辑都是白搭。3. 核心录制流程VideoCapture 拉流 VideoWriter 写 MP4 的完整代码3.1 打开 RTSP 流地址格式、超时参数与 TCP/UDP 协议RTSP 拉流协议本身只负责会话控制真正的视频数据走 RTP。OpenCV 后端默认会尝试 UDP 传输因为 UDP 延迟低但跨网段或无线网络环境下丢包率高得吓人画面马赛克、断流是家常便饭。海康摄像头最常翻车的点就在这里同一台摄像头VLC 能播OpenCvSharp 打不开多半就是 UDP 拉流不稳。我的经验是把传输协议显式指定为 TCPURL 写法如下rtsp://admin:密码192.168.1.64:554/h264/ch1/main/av_stream?tcp这是海康的标准主码流地址子码流地址一般是 /h264/ch1/sub/av_stream。萤石云的取流地址路径略有区别但同样支持在末尾追加 ?tcp。建议先用 VLC 或专用工具验证一遍原始地址能不能出画面再用到代码里。地址里如果有特殊字符比如 或 :需要做 URL 编码这是另一个常见坑。3.2 生产者消费者队列把拉流与录制解耦简单地在循环里 capture.Read writer.Write 也能跑但一旦录制端 IO 抖动Read 的帧就会积压到内存里。我习惯做一个有界队列采集线程只管往队列塞 Mat录制线程从队列取帧并写入文件队列满就丢最旧的一帧。using OpenCvSharp; using System.Collections.Concurrent; public class RtspRecorder { private readonly string _rtspUrl; private readonly string _outputPath; private readonly ConcurrentQueueMat _queue new(); private readonly int _maxQueueSize 60; private readonly int _fps 25; private CancellationTokenSource _cts new(); public RtspRecorder(string rtspUrl, string outputPath) { _rtspUrl rtspUrl; _outputPath outputPath; } public void Start() { _cts new CancellationTokenSource(); // 拉流线程只管往队列里放帧 var taskGrab Task.Run(GrabLoop, _cts.Token); // 录制线程从队列取帧写文件 var taskWrite Task.Run(WriteLoop, _cts.Token); } private void GrabLoop() { using var cap new VideoCapture(_rtspUrl); if (!cap.IsOpened()) return; while (!_cts.IsCancellationRequested) { var frame new Mat(); if (!cap.Read(frame) || frame.Empty()) { frame.Dispose(); Thread.Sleep(2000); // 拉流中断后等待重试 continue; } // 队列满时丢最旧的一帧优先保留新帧 if (_queue.Count _maxQueueSize) { if (_queue.TryDequeue(out var old)) old.Dispose(); } _queue.Enqueue(frame); } } private void WriteLoop() { using var writer new VideoWriter(_outputPath, VideoWriter.FourCC(m, p, 4, v), _fps, new Size(1920, 1080)); if (!writer.IsOpened()) return; while (!_cts.IsCancellationRequested) { if (_queue.TryDequeue(out var frame)) { writer.Write(frame); frame.Dispose(); } else { Thread.Sleep(10); // 队空时让出 CPU } } } public void Stop() { _cts.Cancel(); // 清空队列防止 writer 关闭后仍有未写入帧 while (!_queue.IsEmpty) { if (_queue.TryDequeue(out var f)) f.Dispose(); } } }逻辑说明GrabLoop 每读到一帧就 new 一个 Mat 并塞进队列WriteLoop 只要队列有货就取出来写进 VideoWriter。两个线程通过 ConcurrentQueue 解耦帧率抖动时不会阻塞拉流线程。队列上限设 60 帧在 25fps 下约等于 2.4 秒缓冲再多只会拖垮内存。参数说明_maxQueueSize 是内存与流畅度的平衡点。工业项目里我常用 60如果摄像头帧率是 15fps改成 30 就够。VideoWriter 最后一个参数 new Size(1920, 1080) 必须和拉流得到的 frame.Size() 完全一致不一致时 OpenCV 不会报错写出来的 MP4 会花屏。这一点是录制类项目最容易踩的坑下一章会专门说。3.3 收尾与释放Mat 生命周期决定内存安全OpenCvSharp 的 Mat 是 IDisposable但很多人写循环时忘记释放。拉流线程每帧 new Mat如果不 dispose内存会像漏水一样涨上去。上面的代码里丢旧帧、写完帧、停止时清空队列三处都有 Dispose。这不是洁癖是止血行为。VideoWriter 的关闭可以在 finally 里调用 writer.Release()不过 using 语法已经能保证退出作用域时释放。比较需要注意的是 Stop() 方法Cancel 之后两个线程可能在某个非阻塞点上退出队列里还会有未写完的帧。一定要把队列清空的逻辑放在 Stop 里否则最后一个 MP4 文件会缺末尾几秒。4. 录制参数调优帧率、分辨率和编码器怎么组合才不翻车4.1 FourCC 编码器对照mp4v、avc1 与 MJPG 的差异OpenCV VideoWriter 用 FourCC 指定编码器常见的是 mp4v 和 avc1。mp4v 对应 MPEG-4 Part 2兼容性最好几乎所有播放器都能开但压缩率一般同样画质下文件偏大。avc1 对应 H.264体积小、画质好但 OpenCV 官方包不一定带 H.264 编码器写完 writer.IsOpened() 可能返回 false。FourCC编码标准文件体积兼容性CPU 开销适用场景mp4vMPEG-4 Part 2大高中本地存档、快速验证avc1H.264小中高平台对接、长期存储MJPGJPEG 帧内压缩很大高低测试流、低分辨率录制我的判断是第一次先把 mp4v 跑通文件大点没关系稳定优先。项目对体积有硬要求再切 avc1切完必须在本机实测写 10 秒片段确认能播。MJPG 适合做测试流帧内压缩对写盘速度要求低但要长期录像不建议一小时能占好几 GB 空间。4.2 帧率匹配源 15 帧写入 25 帧会发生什么VideoWriter 构造里的 fps 参数决定 MP4 容器时间基准。把 15fps 输入当 25fps 写入OpenCV 不会补帧它只是按帧计数封包最后文件时长被压缩到原来的 60%。反过来把 25fps 源写成 15fps文件时长拉长但帧间时间戳错位播放器进度条和画面内容对不上。这两种错误都不报异常不开播放器根本看不出来属于隐蔽的翻车。正确做法是实测帧率。先读 capture.Get(VideoCaptureProperties.Fps)再采样前 50 帧用 Stopwatch 统计真实间隔var probeSw Stopwatch.StartNew(); int probeFrames 0; using var probeFrame new Mat(); while (probeFrames 50 capture.Read(probeFrame)) { probeFrames; } probeSw.Stop(); double realFps probeFrames * 1000.0 / probeSw.ElapsedMilliseconds; Console.WriteLine($实测帧率: {realFps:F2});这里 realFps 用于初始化 VideoWriter。50 帧在 1080p 下大约耗时 2 秒对工业采集可以接受。如果 RTSP 源是海康摄像机主码流和子码流的帧率配置可以不同——主码流可能限制 25 帧子码流可能只有 10 帧换一路码流就必须重新采样一次我一般把这一逻辑做成公共函数避免每次手敲。提示不要永远依赖标称帧率。摄像头在夜间会因自动降低码率导致实际帧率掉到标称值以下录久了时长偏差会累积到无法忽略。4.3 文件时长不对用帧序号代替系统时钟另一个隐蔽问题是时间戳。许多开发者以为 VideoWriter 会自动打 PTS其实它只记录帧计数播放时间由容器帧率和总帧数推算。如果你用 DateTime.Now 来做“写不写这一帧”的判断文件时长会受线程调度和系统休眠影响出现每小时差两三秒的漂移。常见做法是维护单调递增的帧计数用帧数除以实测帧率得到 elapsed 时间long frameIndex 0; double realFps 25.0; TimeSpan lastSliceTime TimeSpan.Zero; while (capture.Read(frame)) { frameIndex; var elapsed TimeSpan.FromSeconds(frameIndex / realFps); // 示例按分钟切换录像文件 if (elapsed - lastSliceTime TimeSpan.FromMinutes(1)) { writer.Dispose(); writer CreateNewWriter(elapsed); lastSliceTime elapsed; } writer.Write(frame); }elapsed 只用于切片和显示判断不需要回写 VideoWriter 本身。这样切出来的片段时长相加等于总时长不会因为 DateTime.Now 被 NTP 校准而对不上。这个习惯后来救了我一次客户要求按小时归档录像起初用 DateTime.Now 算切片点每隔几天就会多出或者少了几秒换成帧序号之后连续跑了一个星期没有对不上的问题。5. 避坑排查五个高频问题与现场解决记录5.1 问题一找不到 opencv_world 原生 DLL现象程序编译通过点运行时弹出 System.DllNotFoundException异常消息明确写着“无法加载 DLL ‘opencv_world450.dll’”调用栈指到 VideoCapture 构造函数。代码刚从仓库拉下来换了一台机器就翻车。原因bin 目录里没有原生 DLL。常见原因有三个项目只引用了 OpenCvSharp4漏了 OpenCvSharp4.runtime.winNuGet 还原不完整原生 DLL 没有复制出来平台目标位数为 AnyCPU运行时选择了和原生 DLL 不匹配的 CPU 模式。解决打开项目属性把平台目标锁定为 x64 或 x86然后彻底清理并重新生成。检查 bin 目录里是否出现 opencv_world*.dll 和 opencv_videoio_ffmpeg*.dll。如果还没有打开 NuGet 包管理器确认 runtime.win 包已安装版本号和 OpenCvSharp4 一致实在不行就从 NuGet 缓存把 DLL 手动复制到输出目录并设置“如果较新则复制”。5.2 问题二RTSP 打开缓慢或直接失败现象capture.IsOpened() 返回 false或者打开过程要 5 秒以上同一地址用 VLC 播放器试却正常。日志里没有任何报错只有“打不开”这个结果。原因OpenCV videoio 默认优先走 UDP/RTP在跨网段或无线网络下丢包严重花屏继而断流。另一个常见原因是摄像头码流数量达到上限比如主码流同时被两台电脑占住第三个连接被拒。地址路径写错也会这样海康的主码流路径是 /h264/ch1/main/av_stream子码流是 /h264/ch1/sub/av_stream把两者记混了就会打不开。解决在 URL 末尾追加 ?tcp 强制走 TCP。标准地址改成 rtsp://admin:密码IP:554/h264/ch1/main/av_stream?tcp。其次确认摄像头在线用户数没有超限预留一个给程序用的账号不要和测试人员共用。最后如果仍然打不开先用 VLC 验证原始地址再检查特殊字符是否做过 URL 编码密码里带 或 : 时尤其容易踩。5.3 问题三MP4 文件花屏、时长异常现象录制结束MP4 文件拖进播放器花屏、马赛克或者时长只有实际采集时间的一半。文件大小看起来正常但播放进度一跳一跳。原因VideoWriter 初始化时的 Size 和 fps 与真实帧不一致。尺寸不一致时编码器不知道画面边界会胡涂帧率不一致时容器时间轴对不上还有一种是 FourCC 写了 avc1 而本机没有 H.264 编码器VideoWriter 默默降级。解决初始化 writer 时不要手写数字从 capture 对象上读属性capture.Get(VideoCaptureProperties.FrameWidth)、capture.Get(VideoCaptureProperties.FrameHeight)、capture.Get(VideoCaptureProperties.Fps)。先写 mp4v 做验证等稳定了再考虑 avc1。写入前加一个 if (frame.Empty()) continue把空帧挡在编码器外面。5.4 问题四长时间运行内存暴涨现象内存曲线持续上升从启动时的 200MB 涨到 6 小时后的数 GB最后程序卡死。任务管理器里看到句柄数也在涨。原因每帧 new Mat 没有 Dispose。拉流线程一秒钟产生 25 个新 Mat不及时释放就成了内存泄漏。另一方面生产者消费者队列没有设置上限写盘速度跟不上时队列无限积压内存自然起飞。解决给所有 Mat 加上 using 或手动 Dispose特别是从队列里丢弃的老帧。队列加上限比如 60 帧满了就丢最旧帧保新帧。用性能计数器监控 OpenCvSharp 的 Mat 句柄数量连续两小时未见回调说明释放路径是通的。5.5 问题五CPU 占用居高不下现象录 1080p 码流时 CPU 占用 90% 以上界面拖动卡顿风扇转得像起飞。原因循环里用了 WaitKey(1)预览线程空转解码和绘制都在跑MJPG 编码在 CPU 上软压 1080p 非常吃力解码线程数没有被限制四核八线程机器会被拉满。解决预览和录制分开预览走低分辨率比如把 Mat resize 到 640×360 再显示录制仍写原始帧。WaitKey 从 1 改成 30限制预览刷新率。全局加 Cv2.SetNumThreads(2)把解码线程数压下来。如果还是高检查你的 FourCC 是不是 MJPG换 mp4v 再看。6. 断线重连与录制验证把示例改成 7×24 小时稳定运行6.1 断线自动重连失败计数与重建 VideoCapture摄像头断网、NVR 重启都会导致拉流中断简单跳出循环是录不长久的。我常用的模式是内层循环读帧连续失败 20 次就重建 VideoCapture重建前停 2 秒。int failCount 0; while (!_cts.IsCancellationRequested) { using var capture new VideoCapture(url); if (!capture.IsOpened()) { Thread.Sleep(2000); continue; } failCount 0; using var frame new Mat(); while (capture.Read(frame)) { if (frame.Empty()) break; writer.Write(frame); failCount 0; } if (failCount 20) { Thread.Sleep(2000); failCount 0; } }重连时务必用 using 释放旧 capture再 new 新实例在同一实例上反复 Open容易让 FFmpeg 句柄卡死。重连后帧率和分辨率可能变化writer 也要按新参数重建否则继续花屏。6.2 验证 MP4 完整性文件大小、首帧非零和播放器实测录制逻辑跑通后最可靠的验证不是看代码是直接打开 MP4。我用 ffprobe 查看时长和总帧数用播放器快进到中段看是否花屏顺便确认有没有音轨。RTSP 源如果只有视频写出来的 MP4 没有音轨是正常的别当成损坏。时长误差超过 1%回查 VideoWriter 的 fps 参数。6.3 进阶方向把帧推给 FFmpeg 编码或接入显示控件录制稳定后想压缩体积或切片可以把 Mat 帧交给 FFmpeg 编码器。OpenCvSharp 拿到的是 BGR 排列推给 FFmpeg 前用 Cv2.CvtColor 转成 RGB/YUV开销很小。只做监控展示的话把解码帧直接绑定到控件背景比每次都转 Bitmap 高效。这份 .rar 里的示例正是按这套流程组织的解压后打开方案把 RTSP 地址和输出路径改成本地值就能跑通。第一次做摄像头录制项目时我以为会写窗口、把帧塞进 VideoWriter 就完工了结果被 DLL 加载、TCP 传输、帧率漂移、断线重连轮番教育。从那以后每次搭录制服务我都强制走一遍四个验证地址能不能在播放器出画、平台位数和原生 DLL 是否匹配、VideoWriter 参数是否从 capture 读取、断网后能否自动恢复。希望帮到你。本文还有配套的精品资源点击获取