现有摄像头怎样接入数字孪生：先确认播放链路
现有摄像头能否接入数字孪生，取决于已有视频平台能提供什么、目标浏览器能播放什么，以及网络和权限是否允许这条链路。先用代表性通道验证预览，再确定是否需要流媒体网关或转码。摄像机支持某个协议，不等于页面可以直接播放。
阅读目录5 个章节
先确认接摄像机，还是接已有视频平台
项目启动时先索取通道清单、设备与平台型号、可用接口、主辅码流参数、使用授权和网络区域。如果已有安防平台负责取流、录像和账号，应先评估它提供的网页播放器或受控接口，避免数字孪生另建一套录像管理，也避免增加摄像机直连负担。
ONVIF Profile T描述了 H.264、H.265 等视频能力，但不能据此认定任何浏览器都能播放某条视频。可先取得各类编码的一条测试流，由设备方确认配置，再在项目终端核对；公开资料只保留脱敏参数，不放摄像机账号或真实取流地址。
按现有输出选择播放路线
下面三种路线的工作量和责任不同。先确认“现有系统实际能输出什么”，再报价和安排联调；不要把一条在桌面播放器中可看的 RTSP 地址当成已经完成网页接入。
| 现有条件 | 可评估路线 | 先验证什么 |
|---|---|---|
| 平台提供网页播放器或SDK | 复用平台能力，绑定业务对象与通道 | 授权、嵌入限制、登录续期、目标浏览器 |
| 只提供 RTSP 等监控流 | 受控网关接入，再输出网页可用的流 | 编码兼容、网络路径、首帧和中断恢复 |
| 协议能接入，但编码不适配终端 | 调整可用辅码流，或增加转码 | 画质、时延、计算资源和并发负载 |
MediaMTX 的浏览器接入文档提供 WebRTC、HLS 等播放方式，可作为网关路线的技术参考。转封装或协议转换不等于重新编码；其 WebRTC 说明也指出浏览器的编码支持存在限制。不能只看到网关“支持 H.265”就承诺所有终端可用。
网页能打开，还要验证视频实际经过的网络
画面所在网页、视频网关、摄像机可能处于不同网络区域。联调清单应分别记录谁访问谁、使用什么地址与端口、是否经过代理，以及 HTTPS 证书由谁维护。网络申请应依据实际链路，不把摄像机管理入口直接暴露给展示终端。
WebRTC 的信令与媒体传输不是同一条请求链路，防火墙或网络地址转换可能影响媒体连接，这一点见上述 MediaMTX 官方说明。HLS 路线也要验证播放列表和分片是否都能通过网关。遇到黑屏，先分辨鉴权失败、流未就绪、编码不支持还是媒体不通，再决定改配置或更换路线。
业务角色与视频权限要落到同一个通道
三维对象编号应映射到稳定的视频通道编号，并记录位置、朝向和覆盖区域。一个设备附近有多个摄像头时，由业务人员确认默认画面；用户点击设备后进入错误通道，即使播放器正常也不算联动正确。
登录数字孪生，不代表拥有所有视频权限。服务端应按当前角色校验通道，再发放受控播放凭据；摄像机长期密码不应写进前端。MediaMTX 的鉴权机制可按动作和路径限制访问，说明读取直播、读取录像和管理接口可以分别授权，具体实现仍需与现有平台对齐。
页面关闭视频后应释放无用会话，通道切换不能无限累积连接。权限被撤销、凭据过期或平台拒绝时，应显示明确状态；保留最后一帧时也要标明已中断，避免让静止画面被当成实时现场。
首期用代表性通道确认范围
首期样本应覆盖不同平台、编码、网络区和终端，而不只是挑一条最好播放的流。按实际使用方式测试单路打开、多路同时看、连续切换、重新登录、断流恢复和无权限访问。先约定首帧、可接受时延、画质与并发口径，再记录结果；不预设脱离设备和网络的通用指标。
交付时分别写明：复用了哪些平台能力、网关与转码由谁维护、已验证的浏览器版本、允许的通道及同时播放数、失败后的处理方式。录像回看、云台控制、语音对讲若未验证，应单独列为待评估范围，不能因为实时预览已经成功就一并算作完成。