系统：飞牛1.2.0505
处理器：j1800
easynvr版本：EasyNVR/v7.7.412 (platfrom/linux_amd64)
go2rtc版本： 1.9.14+dev.dc1685e
bug情况：
家中有小米室外摄像机4双摄版、小米云台版2K，两个摄像头通过go2rtc转换后接入easynvr。
1.如果取流模式，设置为native，则正常调阅与录制一段时间之后，就会无法显示画面也无法录制。
2.而如果取流模式，设置为ffmpg模式，则云台版2K能正常使用，而摄像机4双摄版无法正常工作，甚至导致easynvr卡死、关闭，需在飞牛重启，立刻将摄像机4双摄版取流模式，设置为native才不再卡死。
3.重启easynvr，刚开始可以正常使用，但过了一段时间，虽然摄像头依旧像是正常连接，检测也正常，但是就是不显示画面。
以下豆包总结的分析：
EasyNVR 问题反馈描述
版本：EasyNVR v7.7.412（Linux amd64）
场景：接入 go2rtc 中转输出的 RTSP 流，前端设备为小米摄像机 4 双摄版、小米云台版 2K
问题 1：ffmpeg 取流模式下，遇到携带非标异常音频的 RTSP 流，ffmpeg 子进程卡死
- 部分 IPC 经过第三方中转（go2rtc）输出 RTSP，音频存在时间戳错乱、异常帧、静音帧等非标情况。
- 即使 EasyNVR 界面上把【启用音频】设置为关闭，ffmpeg 取流模式依旧会去解析 RTSP 流内原始音频轨道，造成 ffmpeg 子进程阻塞卡死，视频无法正常播放。
- 对比：同一套流，native 取流模式可以正常播放；另一台音视频输出标准的摄像头，ffmpeg 模式工作正常。
期望：界面关闭音频时，ffmpeg 侧应当忽略、不解析流中的音频轨道，不因为音频异常导致整个取流进程卡死。
问题 2：native 内置 RTSP 取流模式，无法识别 TCP 会话僵死，无自动恢复能力
- RTSP‑TCP 长时间运行后，中转服务（go2rtc）发生 socket 会话老化僵死，链路实际已经中断。
- native 内置 RTSP 解析器不能识别这种僵死连接：设备状态依旧显示在线，不会判定流异常，不会触发断开重建连接，表现为画面黑屏冻结。
- 当前 v7.7.412 版本 WEB 管理界面没有提供流自动重连的配置开关，僵死后只能人工手动重启流恢复，无法自动兜底。
期望：native 模式增加链路僵死检测，会话异常时自动断流重拉；WEB 页面提供自动重连相关配置项。
补充环境说明
- 传输方式：RTSP over TCP
- 现象复现条件：上游 RTSP 来自第三方中转服务，且源设备音频流非标。
- 对比设备：小米云台版 2K 音视频输出标准，ffmpeg、native 模式均运行稳定；摄像机 4 双摄版存在上述两类问题。
