本案例讲清硬件链路和证据边界。当前课件不把静态前端截图、HTTP 服务或一次 OM smoke 提升为完整 WebRTC 验收。
先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。
先建立分层意识。页面显示“HTTP 检查中”或“Peer 未建立”时，不能继续声称摄像头、OM、检测叠加或 VENC 已经通过。
模型输入尺寸不是网页运行参数。摄像头分辨率变化只影响预处理，最终必须变成 640×640 的 NCHW 张量。
强调 ONNX 验证与 OM 验证是两个层。CPU ONNX 推理成功、ATC 打印成功和 ACL 执行成功分别记录，不能互相替代。
本页只讲证据顺序，不宣称当前模型文件或所有资产已经存在。模型、ONNX、OM 和报告默认都不进入 Git。
后处理不是绘图附属品，而是检测结果的一部分。预处理、输出解码和绘制必须使用同一套缩放与标签信息。
带学生区分工作站、板端和浏览器。模型文件从工作站到板端只解决交付位置，不证明板端已经加载和执行。
图中的“CPU 回退”必须按代码实际行为理解：默认不自动回退。只有用户明确选择 CPU libx264 时才走另一条编码路径。
CPU 编码是显式对照，不是自动降级。验收 CANN VENC 时，必须证明连接使用的是硬件编码路径。
页面明确显示 HTTP“检查中”、Peer“未建立”，模型、摄像头、编码和画面指标均为空。它只能证明静态页面与资产由 8T HTTP 服务加载。
截图清单同时记录 HTML 成功和 JS/CSS 404。缺失资源说明页面没有完成交互初始化，不能把“HTTP 检查中”解释成服务正在做端到端验收。
权限、设备节点、FourCC 和实际尺寸是四条证据。截图中的摄像头下拉框只是静态控件，不能证明 V4L2 打开成功。
官方 Atlas 的固件、驱动和 CANN 必须作为一组记录。不能把这里的成功改写成 Orange Pi 同版本通过，也不能省略硬件平台。
Orange Pi 的记录必须连同系统日期、驱动、固件和 CANN 一起读。旧系统通过不能覆盖新系统失败，也不能把“固件 B309”当成单独充分条件。
命令顺序就是证据顺序。OM benchmark 失败时不要启动 WebRTC；摄像头失败时不要用 CPU 编码结果掩盖；HTTP 健康不能代替 Offer/Answer。
每层只用自己的证据判断。当前静态截图停在 HTTP/Peer 层，因此既没有摄像头证据，也没有 OM 或 VENC 证据。
最终报告必须写清每一层停在哪里。历史官方 Atlas 通过不等于当前 Orange Pi 通过，静态前端截图也不等于 WebRTC 实时识别通过。
收束时必须区分“能打开静态页面”和“浏览器持续收到带检测框的 H.264 视频”。后者需要信令、摄像头、OM 推理和 VENC 同时成立。