OpenCV的VideoCapture读RTSP易卡死或报错，主因是后端不支持或FFmpeg未初始化；应强制指定FFMPEG后端、校验URL、加超时重连；Vlc.DotNet更稳但需手动配DLL、启用dxva2硬解并实现心跳检测重连。
用 VideoCapture 直接读 RTSP 流会卡死或报错
opencv 的 videocapture 在 c#（通过 opencvsharp）里读 rtsp，表面能打开，但大概率卡在 read()、返回空帧，或抛出 nullreferenceexception。根本原因是底层 ffmpeg 没正确初始化，或默认后端（如 msmf）根本不支持 rtsp。
- 强制指定后端：创建
VideoCapture时传入CaptureAPI.DShow或CaptureAPI.FFMPEG，Windows 上优先试FFMPEG - 加超时和重连逻辑：RTSP 是实时协议，网络抖动会导致连接中断，不能只靠一次
Open()判断成功 - 检查 URL 格式：必须带协议头，比如
rtsp://admin:12345@192.168.1.64:554/stream1，缺密码或端口常静默失败 -
OpenCvSharp4.8+ 对 FFmpeg 后端更稳定，老版本（如 4.5）容易在多路流下崩溃
用 Vlc.DotNet 播放更稳，但 NuGet 包要手动配 DLL
Vlc.DotNet 底层调 VLC，对 RTSP 兼容性远好于 OpenCV，但官方 NuGet 包不带原生 libvlc.dll，直接运行会崩在 LibVlc 构造函数，报错 System.DllNotFoundException: Unable to load DLL 'libvlc.dll'。
- 去 https://www.videolan.org/vlc/download-windows.html 下对应架构（x64/x86）的 VLC 安装包，解压出
libvlc.dll和libvlccore.dll - 把这两个文件放进项目输出目录（
bin/Debug），并设属性为“始终复制” - 初始化时指定路径：
new LibVlc(@"./");，别依赖环境变量 - 播放控件要用
VlcControl，它本质是 Windows Forms 控件，WPF 需套WindowsFormsHost，别硬塞进Image或MediaElement
硬解 H.264/H.265 必须关掉 VLC 的软件解码
监控摄像头普遍用 H.265 编码，VLC 默认软解，CPU 占用飙到 80% 以上，多路就卡成幻灯片。不是代码写得慢，是没开硬解。
- 初始化
LibVlc时传参数：new LibVlc("--avcodec-hw=dxva2")（Windows），或--avcodec-hw=qsv（Intel 核显） - 确认显卡驱动已更新，旧驱动 dxva2 会 fallback 到软解，且不报错
- 用
vlc --list查看是否识别到硬件模块，输出里有dxva2才算生效 - 硬解开启后，
VlcControl的MediaPlayer实例仍要调Play()，不能只靠设置参数
断线重连不能只靠 Media.Stopped 事件
RTSP 流断开时，Vlc.DotNet 的 Media.Stopped 事件不一定触发，尤其网络闪断或摄像头休眠。单纯监听这个事件做重连，会漏掉大量中断场景。
- 加心跳检测：每 3 秒调一次
MediaPlayer.Length，返回 -1 表示流已不可用 - 用
MediaPlayer.Time做增量判断，连续两次读值不变（且非 0），大概率卡死 - 重连前必须
MediaPlayer.Stop()+MediaPlayer.Dispose()，否则新实例打不开同一 URL - 重连间隔从 1 秒开始，指数退避（1s → 2s → 4s），避免高频请求被摄像头限速或拉黑
RTSP 的坑不在代码长短，而在每个环节都依赖外部状态：摄像头固件版本、网络 MTU、VLC 版本、显卡驱动、甚至 Windows 网络堆栈配置。调通一路不等于十路没问题，批量部署前务必在目标机器上实测解码负载和重连恢复时间。
