简介C#视频监控上位机源码包定位于帮助C#/.NET开发者和安防监控从业者快速实现视频流的实时采集、处理与界面展示可用于本地监控演示、远程查看及基础智能化分析场景。程序基于C#编写集成摄像头调用与画面显示逻辑下载后可直接编译运行插入摄像头即可看到监控画面无需繁琐配置即可作为入门参考或二次开发基底。压缩包大小约5.28MB整体轻量便于下载与部署当前已有313人学习下载适合用于课程设计、毕业设计或企业内部演示。实现上围绕.NET多媒体处理展开可借助AForge.NET完成图像滤波、边缘检测等预处理也可利用Media Foundation进行底层视频流解码并通过RTSP、HTTP等方式扩展远程监控能力。开发者能从中获取完整的C#工程代码掌握摄像头API调用、视频帧循环刷新、控件绑定显示以及上位机与视频源交互的通用思路对从零搭建监控原型有直接参考价值。1. C#视频监控先搞清楚它到底在解决什么问题“C#视频监控”这几个字听起来像“在 C# 里放一个视频画面”真正落地过的人会告诉你它至少横跨四条战线拉流、解码、存储、多路并发。很多团队第一天就把播放器跑通了等接入真实摄像头、连续跑上一周卡顿、花屏、录像丢失、内存只涨不降这些问题全冒出来。标题里的 C# 只是语言外壳真正的难点在于怎么把一路 RTSP 流稳定地变成可显示、可存储、可分析的数据。这篇笔记直接拆落地路径先定架构和选型再用最小代码跑通第一路画面接着把录像、多路并发、告警和 AI 接入逐个补齐。适合谁看用 WinForms/WPF 做桌面监控工具的开发者以及想把摄像头数据接进现有系统的服务端工程师。内容不求大而全只求每一步你都能照着写、照着调、照着避坑。2. 架构选型C#视频监控的四层链路先把解码和存储定下来别急着写代码。我见过太多项目上来就拖一个播放控件等需要录像和抓拍时发现解码链路根本走不通只能推倒重来。C# 视频监控的第一件事是把系统拆成四层每一层独立设计、独立换实现后面才不会互相拖累。2.1 四层链路采集、解码、处理、存储的职责边界采集层负责从摄像头拉流最常见的是 RTSP如果是国标平台需要先做 GB28181 的信令协商拿到媒体流再走同样的链路。采集层要关注的是网络超时、断线重连、主码流和子码流的选择。大多数摄像头的 RTSP 地址会同时提供主码流和子码流主码流分辨率高适合存储和分析子码流分辨率低适合预览。解码层是 C# 视频监控里最绕不开的坎。C# 本身不内置 H.264/H.265 解码能力必须借助原生库。解码后的产物是原始帧可能是一张 YUV 图也可能直接转成 RGB/BGR 的 Bitmap。这一层决定了你在上层能做多少事能拿帧才能做抓拍和图像算法只拿句柄的话就只能在控件里显示。处理层负责显示预览、录像落盘、抓拍、AI 检测。这一层的设计准则是解码线程和 UI 线程必须分离。处理层一旦阻塞解码线程跟着堵画面就会卡反过来 UI 线程一旦阻塞画面也不动但 CPU 占用并不高很多人在这里排查半天。存储层则包括视频分片文件、录像索引数据库、按天数的清理策略它和数据采集是异步关系不能因为写磁盘慢而影响实时画面。2.2 解码方案怎么选LibVLC、OpenCvSharp 与 FFmpeg 封装的选择逻辑C# 生态里没有“官方”的视频解码方案常见做法是在三个方向里选LibVLCSharp、OpenCvSharp、FFmpeg.AutoGen。选错了后面会非常难受所以先把差异摆出来。对比项LibVLCSharpOpenCvSharpFFmpeg.AutoGen上手难度低有控件可直接拖中显示部分要自己写高P/Invoke 裸调典型场景实时预览、回放、需要音频抓拍、图像处理、AI 分析定制播放内核、特殊封装格式隐藏成本原生插件部署麻烦调试信息少没有现成播放器界面声音要另做内存、线程、时间戳全自己管理帧访问能力弱拿帧要绕事件回调强每一帧都能拿到 Mat强但要自己处理 AVFrame如果项目以显示为主选 LibVLCSharp 最省钱几行代码就能出画面还自带音频和网络缓冲。如果项目要做抓拍、移动检测、AI 识别选 OpenCvSharp 更顺帧直接以 Mat 形式交到你手里。两个都要怎么办我一般会做成双链路预览走 LibVLC 的子码流分析和录像走 OpenCvSharp 拉主码流。代价是同一路摄像头要占用两个并发会话选型时要确认摄像头支持的路数够不够。还有一个隐藏选项是 FFmpeg.AutoGen能完全控制解码过程但工程量非常大只适合要做播放内核的团队。大部分视频监控项目不需要自己造解码轮子LibVLC 和 OpenCV 各管一段比什么都能作者更可控。2.3 存储与录像策略分段、磁盘占用与索引设计录像存储设计不好系统跑一个月就会被磁盘塞满回放功能也形同虚设。常见做法是分段录像把视频流按时间切成小块每段 1 到 5 分钟。分段最大的好处是抗损坏某一段文件坏了前面和后面的录像还在如果一整天写一个 MP4断电或者进程崩溃整个文件都可能打不开。磁盘占用可以按码率估算。公式很简单码率Mbps除以 8 再乘以 3600就是每小时产生的数据量大约是“码率 × 450”MB。码率每小时占用每天单路占用2 Mbps约 0.9 GB约 21.6 GB4 Mbps约 1.8 GB约 43.2 GB8 Mbps约 3.6 GB约 86.4 GB1080P 的摄像头H.264 码率一般配 4 到 8 Mbps按 4 Mbps 算16 路摄像头的监控系统一天就要写掉近 700 GB。所以存储策略必须一开始就定保留几天、用不用子码流做备用时段、要不要开启移动侦测录像来压缩无效时段。索引层用数据库记录每一段录像的元信息我一般用 SQLite 就够了字段就是摄像机 ID、开始时间、结束时间、文件路径、文件大小。回放时按时间范围查记录再顺序拉取对应分片文件清理任务按保留天数删文件并同步删除数据库记录保证索引不会变成脏数据。2.4 多路与并发这是 Demo 和产品的分界线单路画面跑通只能叫 Demo能稳定跑 8 路、16 路才谈得上产品。桌面端做多路最容易踩的坑是在 UI 线程里同时创建多个播放控件。WinForms 的控件渲染依赖窗口消息循环每路视频的解码和渲染都在同一个 UI 线程转悠4 路以上就会明显掉帧8 路以上界面基本操作不动。我一般这样定边界桌面客户端最多承担 16 路预览超过就上服务端解码客户端只接收处理后的帧或转码流。单机解码路数还受硬件限制软解 4 路 1080P 能把 CPU 吃满开硬解后能多扛几路但这要看显卡和摄像头编码格式。多路并发的另一个隐藏瓶颈是摄像头并发会话数。低端摄像头往往只允许同时拉 4 到 6 路流你一个画面预览拉一路、录像拉一路、AI 分析再拉一路很快触发会话上限摄像头直接拒绝连接。设计拉流管理器时必须统计每一路的 RTSP 会话数超限就复用已有流而不是无脑新建连接。3. 把第一路实时视频跑起来C#最小实现与三个关键参数选型定了链路清了接下来动手。这一章直接给出两套最小实现一套用 LibVLCSharp 做预览一套用 OpenCvSharp 拉帧做处理和录像。跑通之后再调三个关键参数网络缓存、帧率、编码器。3.1 用 LibVLCSharp 在 WinForms 里打开 RTSP 流先建一个 WinForms 窗体项目里引入 LibVLCSharp 和 LibVLCSharp.WinForms 两个包。注意 MediaPlayer 和 Media 不要用局部变量要存成窗体字段否则方法一结束播放器被回收画面直接黑掉。public partial class MainForm : Form { private LibVLC _libVlc; private MediaPlayer _player; private Media _media; protected override void OnLoad(EventArgs e) { base.OnLoad(e); // 网络缓存单位是毫秒局域网调小公网/无线环境调大 _libVlc new LibVLC(--network-caching150); _player new MediaPlayer(_libVlc); var videoView new VideoView { MediaPlayer _player, Dock DockStyle.Fill }; Controls.Add(videoView); // 确保控件句柄先创建避免播放器绑定失败 videoView.CreateControl(); _media new Media( _libVlc, rtsp://192.168.1.108:554/stream1, MediaFromType.FromLocation); _player.Play(_media); } }这段代码里有两个容易翻车的地方。第一创建播放器和绑定控件的动作要放在 OnLoad 里不要在构造函数里做否则控件的句柄还没准备好播放器拿不到渲染窗口。第二--network-caching这个参数非常关键局域网内摄像头通常 150 到 200 毫秒延迟就够了走公网或者 WiFi 环境建议调到 500 到 1000 毫秒否则画面会频繁停顿。这个参数不是越大越好调大了延迟变高语音对讲几乎没法用。注意不同摄像头厂商的 RTSP 地址路径规则不一样接入新设备时先用 VLC 播放器手工验证地址能出流再写进代码。3.2 用 OpenCvSharp 拉帧并处理画面LibVLC 适合显示但要做抓拍、图像处理、运动检测就必须拿原始帧。这里用 OpenCvSharp 拉 RTSP 流每一帧都是 Mat想怎么处理都行。using OpenCvSharp; using OpenCvSharp.Extensions; using var capture new VideoCapture( rtsp://192.168.1.108:554/stream1, VideoCaptureAPIs.FFMPEG); using var frame new Mat(); while (!cancellationToken.IsCancellationRequested) { if (!capture.Read(frame)) { // 读到结尾或断流等待 3 秒后重连 await Task.Delay(TimeSpan.FromSeconds(3)); continue; } using var resized frame.Resize(new Size(960, 540)); using var bmp BitmapConverter.ToBitmap(resized); pictureBox.Image?.Dispose(); pictureBox.Image (Bitmap)bmp.Clone(); // 控制刷新频率约 30fps await Task.Delay(TimeSpan.FromMilliseconds(33)); }这里指定了VideoCaptureAPIs.FFMPEG强制走 FFmpeg 后端拉流避免某些 Windows 环境下 OpenCV 自带后端对 RTSP 支持不完整。capture.Read返回 false 时不一定是断流也可能是临时网络抖动所以不要立刻销毁 capture等几秒再重连更稳。Resize的作用是把 1080P 帧缩小到 960x540UI 刷新的开销会小很多。你可能会想为什么每帧都 Resize 而不是让摄像头直接出子码流因为分析端有时需要主码流的细节显示端又不需要那么大的图在内存里缩放比多拉一路子码流更省摄像头并发会话。pictureBox.Image替换前一定要 Dispose 旧图否则内存涨得飞快这一行能省后面一整章的血泪排查。3.3 录像落盘与抓拍编码器、帧率与文件切割拉帧到手之后录像就是水到渠成的事。OpenCvSharp 的VideoWriter可以直接把 Mat 写入 MP4 文件但编码器选择有讲究。string videoPath Path.Combine( saveDir, ${DateTime.Now:HHmmss}.mp4); using var writer new VideoWriter( videoPath, new FourCC(m, p, 4, v), fps: 25, new Size(frame.Width, frame.Height)); while (isRecording) { if (!capture.Read(frame)) break; writer.Write(frame); // 每 5 分钟切一个文件先 Dispose 再创建新 writer } // 抓拍保存为 JPEG Cv2.ImWrite(Path.Combine(saveDir, snapshot.jpg), frame);编码器用mp4v是最稳的兼容性最好Windows 和手机端都能直接播放。别在 VideoWriter 里硬写 H.264OpenCV 自带的 FFmpeg 不一定带编码器一旦编码初始化失败Writer 会静默地不写一帧你得到的是一个 0 字节文件。如果业务必须出 H.264 录像常见做法是先落成裸帧序列再用 FFmpeg 命令行转封装虽然多一道步骤但可编排、可重试不容易在运行中翻车。fps参数要和摄像头实际输出帧率匹配。摄像头出 25 帧这里写 25如果摄像头实际只有 20 帧而你写 25录制文件播放时会加速。切文件的逻辑不要依赖 UI 定时器最好用帧计数每累计 7500 帧且帧率 25 时切一个 5 分钟的分片这样录像时间相对准确。4. C#视频监控避坑指南延迟、卡顿与内存泄漏的五个现场这一章的内容全是真实项目里反复出现的现场每条都按“现象 → 原因 → 解决”来讲。你大概率会在上线的第一周撞上其中至少两个。4.1 画面卡住不动CPU 占用却不高现象单路画面正常窗口最小化再恢复后画面停在最后一帧或者切换标签页回来画面要好几秒才开始动。任务管理器里 CPU 占用并不高看起来不像是性能问题。原因LibVLC 的渲染依赖 UI 线程的窗口消息循环。窗体被遮挡或最小化时系统不再派发绘制消息画面自然不刷新但解码线程还在继续跑所以 CPU 不高。这不是解码性能问题是渲染触发机制问题。解决如果预览用 LibVLC 控件在窗口最小化时暂停播放恢复时重新 Seek 到最新位置如果画面是 PictureBox 配合后台拉帧就保证 UI 线程只做“取最新帧 刷新图片”不要参与任何网络和解码操作。我通常把刷新频率限制在 25 到 30fps肉眼完全够用CPU 却降下来一大截。4.2 VLC 控件白屏或者句柄报错现象代码运行不报异常但窗口打开后播放区域是纯白的部分机器在日志里能看到句柄相关的警告。原因MediaPlayer 在控件句柄还没有创建时就把渲染目标绑定进去了等于把画面画到了一个不存在的窗口上。解决把播放器的创建和绑定动作全部挪到 Form 的 OnLoad 里并且在绑定前显式调用CreateControl()。这一条是 LibVLC 集成 WinForms 最常见的坑十次里有七次是它。protected override void OnLoad(EventArgs e) { base.OnLoad(e); _videoView.CreateControl(); _player.Play(_media); }还有一个附带问题有些开发者会在Shown事件里才创建播放器导致窗口先显示出来、再黑屏闪一下。OnLoad 时机更合适因为这时控件已经完成句柄创建但窗口还没真正显示给用户。4.3 录像文件打不开、时长不对、播放到一半跳秒现象用 VLC 播放录像文件正常但发到手机上时长显示 0 或者打不开断电重启后最后一段录像文件整个废掉两个分片文件之间有明显的时间空洞。原因MP4 的索引信息moov写在文件尾部必须等 Writer 正常关闭后才完整。进程崩溃或断电moov 丢失整个文件都无法播放。另一个原因是 VideoWriter 的fps参数和实际帧率不一致播放器按错的时间轴播放看起来就是跳秒或时长不对。解决保证VideoWriter一定走using或 try-finally 释放不要在代码里依赖 GC。对断电场景要求高的系统把录像封装从 MP4 换成 TS 流TS 是流式封装头部和索引不集中在文件末尾损坏后还能救回大部分画面。日常系统至少做到分段 5 分钟以内损坏一个文件只损失 5 分钟录像而不是一整天。4.4 多路同开进程崩溃单路却一直正常现象单路预览跑几个小时都没事打开第 3 路时进程突然崩溃堆栈停在 native 层托管代码里根本看不到异常。原因多个 MediaPlayer 共用一个 LibVLC 实例时内部解码器和输出模块存在资源竞争另外很多摄像头对同一 IP 的 RTSP 并发会话数有限制超过上限会直接断开或异常。解决给每一路视频创建独立的 LibVLC 实例实例之间不共享状态。这个方案虽然占一点内存但稳定性和排查成本都更低。同时在拉流管理器里做会话计数同一台摄像头不超过 2 路并发超过就用已有的帧流做分发而不是重新拉路。4.5 长时间运行内存只涨不降现象程序跑一天内存从 300MB 慢慢涨到 1.5GB再往后连界面操作都开始卡。原因典型的三处泄漏。一是 PictureBox.Image 每次赋值前没有 Dispose 旧图二是 Mat 或 Bitmap 没有释放GC 来不及回收非托管资源三是 MediaPlayer 的事件处理器和 Media 对象没有在窗口关闭时释放。解决统一遵守三个习惯。刷新图片前先 Dispose 旧图所有 Mat 用 using 或手动 Dispose窗体关闭时按顺序释放监控资源。protected override void OnFormClosed(FormClosedEventArgs e) { _player.Stop(); _media.Dispose(); _player.Dispose(); _libVlc.Dispose(); base.OnFormClosed(e); }释放顺序也有讲究先 Stop再 Dispose Media再 Dispose Player最后释放 LibVLC。顺序反了有时候会触发原生层的空引用崩溃。录像文件、日志这些资源也要在关闭流程里统一收口别让窗口一关线程还在后台写数据。5. 从单路到多路C#视频监控的项目化改造与告警接入单路跑通之后下一步是把它改造成可以接 8 路、16 路的结构。这个阶段的核心工作是解耦采集、解码、消费各干各的互不阻塞。5.1 用 Channel 解耦采集、解码与显示多路视频最怕的是每路自己开一个线程然后在线程里直接改 UI。WinForms 的 UI 控件不是线程安全的跨线程赋值会让你花大量时间在处理 Invoke 上。更好的模式是每个通道一条采集链路把帧写进独立 ChannelUI 线程统一从 Channel 里取最新帧刷新。public sealed class FramePayload { public Mat Frame { get; init; } null!; public DateTime Timestamp { get; init; } } ChannelFramePayload CreateFrameChannel(int capacity 30) { return Channel.CreateBoundedFramePayload( new BoundedChannelOptions(capacity) { FullMode BoundedChannelFullMode.DropOldest, SingleReader true }); }DropOldest是最关键的选择当消费者来不及处理时新帧直接覆盖旧帧保证 UI 看到的总是最新画面。视频监控里一帧旧画面比丢一帧的损失更大因为延迟比掉帧更让人难受。消费端用await foreach读取await foreach (var payload in channel.Reader.ReadAllAsync(ct)) { using var bitmap BitmapConverter.ToBitmap(payload.Frame); pictureBox.Image?.Dispose(); pictureBox.Image (Bitmap)bitmap.Clone(); payload.Frame.Dispose(); }每个通道配一个消费者任务显示做成一个消费者录像做成另一个消费者AI 检测再做第三个消费者。这样录像时磁盘抖动不会阻塞显示AI 推理耗时不会拖垮实时预览。capacity设成 30 就够了按 25fps 算相当于 1 秒多的缓冲太大反而会增加延迟。5.2 断线重连与健康检查让监控系统具备自愈能力摄像头断线是常态不是异常。网络摄像头在弱电环境里经常掉线不需要人工去重启系统但要有自愈逻辑。private static async Task ReconnectLoopAsync( string rtspUrl, ChannelFramePayload channel, CancellationToken ct) { var retry TimeSpan.FromSeconds(2); while (!ct.IsCancellationRequested) { try { using var capture new VideoCapture(rtspUrl, VideoCaptureAPIs.FFMPEG); if (capture.IsOpened()) { retry TimeSpan.FromSeconds(2); using var frame new Mat(); while (capture.Read(frame)) { channel.Writer.TryWrite(new FramePayload { Frame frame.Clone(), Timestamp DateTime.UtcNow }); } } } catch (Exception ex) { // 记录断线次数和错误信息便于排查哪些通道频繁掉线 } await Task.Delay(retry, ct); retry retry TimeSpan.FromSeconds(30) ? retry * 2 : TimeSpan.FromSeconds(30); } }重连间隔用指数退避第一次断了等 2 秒再断等 4 秒、8 秒最多 30 秒封顶。如果 8 路摄像头同时离线重启后一起重连对网络和摄像头都会造成冲击退避策略能把“风暴”摊开。TryWrite在 Channel 满时返回 false不会阻塞拉流线程这个细节能保证断线期间 UI 线程不会被写帧卡住。健康检查不要只靠拉流线程。实际项目里我习惯每 30 秒做一次心跳检测用轻量级的 RTSP 请求去探测摄像头是否存活如果 3 次探测失败再触发重连。这样可以避免一种尴尬情况网络断开后拉流线程阻塞在某个底层调用里迟迟察觉不到掉线。5.3 告警事件接入先做运动检测再升级 AI告警是视频监控的刚需。绝大多数场景先从运动检测开始帧差法是最容易落地、也是效果最稳定的。using var gray new Mat(); Cv2.CvtColor(currentFrame, gray, ColorConversionCodes.BGR2GRAY); using var blurred gray.GaussianBlur(new Size(21, 21), 0); Cv2.Absdiff(previousGray, blurred, diff); Cv2.Threshold(diff, diff, 25, 255, ThresholdTypes.Binary); Cv2.FindContours(diff, out var contours, out _, RetrievalModes.External, ContourApproximationModes.ApproxSimple); bool hasAlarm contours.Any(c Cv2.ContourArea(c) minArea); if (hasAlarm) { // 写入告警事件表同时保存抓拍图片 }帧差法适合固定机位摄像头只要轻微晃动全屏都会触发报警。两个参数要调Threshold的 25 是灰度差分阈值值越大越不敏感适合光线稳定的室内minArea按画面尺寸设置1080P 画面建议先给 2000观察一天再往下调。我习惯给检测逻辑加一个冷却时间触发告警后 5 秒内不再重复上报防止画面里一个人走过产生几十条告警记录。运动检测只告诉你“画面动了”不告诉你“是什么在动”。等运动检测稳定跑一周积累了真实场景的报警截图后再升级到 AI 目标检测这才是比较稳的节奏。6. 进阶实测给C#视频监控接入AI检测让画面自己报警如果运动检测的误报让你夜里被猫叫吵醒过就该上目标检测了。C# 这边最成熟的路径是把模型导出成 ONNX再用 ONNX Runtime 做推理帧还是从 OpenCV 拉推理结果叠加到画面上。using var session new InferenceSession(model.onnx); var inputName session.InputMetadata.Keys.First(); var outputName session.OutputMetadata.Keys.First(); // 每2秒取1帧做分析Resize到模型输入尺寸 归一化 var inputTensor Preprocess(currentFrame); var results session.Run(new[] { NamedOnnxValue.CreateFromTensor(inputName, inputTensor) }); var boxes Postprocess(results, confidence: 0.4f, iou: 0.45f); if (boxes.Any(b b.Label person)) { SaveSnapshot(currentFrame, boxes); }这里Preprocess和Postprocess是把一个完整目标检测链路省略成了两个方法实际代码里要处理的细节是等比缩放后填充灰边、归一化到 0 到 1、解析模型输出的坐标和类别、做一次 NMS 去重。四个参数我觉得可以先死记输入分辨率 640x640置信度阈值 0.4IoU 阈值 0.45分析间隔 2 秒。前两个直接影响误报率后半部分影响检测速度。AI 接入有一个容易忽略的前提先用离线录好的视频验证模型效果再接到实时链路。我现在的习惯是任何算法改动都先对着一个小时的真实录像回放调试而不是拿着实时画面边看边调。实时流一断你根本分不清是模型慢了还是拉流断了排查成本高好几倍。另外别让 AI 推理阻塞视频链路。推理放独立消费者任务里输入帧用第 5 章的 Channel 传递推理完的结果再通过另一个 Channel 回传给 UI。目标检测很吃 CPU如果是 16 路同时分析建议把推理服务拆出去客户端只负责展示告警结果这样整个视频监控系统才不会因为一个模型拖垮全部预览画面。希望帮到你。本文还有配套的精品资源点击获取