本讲的主线是媒体数据如何经过 DVPP 通道、内存约束和异步回调，而不是背一组 API 名称。

先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。

先让学生区分 AI Core 和媒体处理单元。DVPP 的通过不能直接证明模型推理通过，模型推理通过也不能替代媒体链路验证。

带学生从应用层向下定位。Python 报错可能来自导入、Runtime、驱动或某个媒体模块，不能一律归因于硬件故障。

强调“创建通道”和“提交任务”是不同阶段。507018 发生在通道创建阶段，不应该被描述成编码质量或推理精度问题。

用 640 宽举例：640 已经 16 对齐；638 要补到 640。NV12 还必须考虑 UV 平面，因此不能只分配 width×height。

本页只解释设计上的编码链路，不代表当前双板已经编码成功。当前运行结果在下一页，必须明确是失败。

逐项对照代码中的 create_venc_channel。码率单位、GOP、NV12 和 stride 是最容易在通道创建前就出错的四个对象。

这是本章最重要的边界：H.264 Baseline 在 venc_create_channel 阶段失败，失败码 507018。通道没有建立，就没有后续编码帧可谈。

不要把 VENC 和 VDEC 写成同一个通道。它们方向相反，回调参数顺序、码流描述和清理顺序都不同。

两项 VPC 输出是本次双板实测。不要把“VPC 通过”扩大成所有媒体模块都通过，也不要把不支持 CSC 写成整个 VPC 不可用。

JPEGE 的输出是 JPEG 字节，不是 stream_desc；JPEGD 则从 JPEG 信息推导输出 NV12 大小。两者共用 NV12，但 API 合同不同，也没有 VENC 视频编码的语义。

这页把 UI、信令、采集、预处理和编码分成五层。当前 507018 阻断的是编码层，浏览器能画出来并不代表后四层通过。

截图来自 8T 的静态 HTTP 页面。画面中的 HTTP 服务“不可用”和 PeerConnection“未建立”必须保留，不能用页面存在推导 aiortc、RTP、媒体接收或 VENC 成功。

字节数和 SHA-256 用于绑定这张 PNG。清单中的 application digest 绑定 HTTP、client.js 与 styles.css 的组合；它们证明页面资产身份，仍不证明 WebRTC 媒体通过。

让学生从表中指出每个“通过”的最小证明。VENC 同行同错误码不是硬件排名；前端截图也不是媒体链通过。

先运行 check_cann，再按 VPC、VENC、VDEC、JPEG 顺序验证。VENC 失败时不要删除日志，也不要把后续 WebRTC 启动当作 VENC 恢复。

507018 先停在通道创建层。不要因为日志里出现 venc 就继续分析 H.264 码流，因为通道还没有建立。

最后要求学生同时提交失败证据。当前正确结论是 VPC 通过、H.264 Baseline 两板 `507018`、H.265 与 WebRTC 媒体链 `untested`，而不是“VENC 通过”。