一次播放和录像的路径

用户在网页点击“播放”，AKStream.Next 先确认通道和观看权限，再让对应 MediaServer 提供可用的媒体出口。浏览器连接出口并开始解码后，用户才真正看到画面。HTTP 请求成功只说明前面的动作被接受，不能代替最后一步。

sequenceDiagram
    participant User as 浏览器或 App
    participant API as AKStream.Next
    participant Media as MediaServer
    participant Camera as 摄像机
    User->>API: 选择通道并请求播放
    API->>API: 检查通道与权限
    API->>Media: 查询或启动目标流
    Media->>Camera: 拉流或接收设备推流
    Camera-->>Media: 发送音视频
    Media-->>User: HLS / HTTP-FLV / WebRTC 等输出
    User-->>User: 解码并显示画面

录像多出几步：计划或人工命令命中 → 录像会话开始 → 文件落盘 → 平台建立索引 → 用户在录像中心查到并播放文件。任一步未完成，都可能出现“显示正在录制却找不到文件”。录像文件找不到给出逐步检查顺序。

播放协议解决的是不同终端怎样读取视频：HLS 通常更兼容但延迟较高；HTTP-FLV 常用于桌面浏览器监看；WebRTC 适合低延迟互动并依赖 HTTPS、ICE 和网络条件；RTSP 通常交给 VLC、NVR 或 SDK，浏览器不能直接原生播放。当前接入源的编码和播放器的解码能力仍需匹配；不要把“接口给了 URL”理解为服务器会自动转码。

要亲自走一遍这条链路，按接入第一路视频操作；需要查平台、媒体节点和网络问题时，进入功能使用。