ute2e/reports/bridge-lipsync-diagnosis-20260914/diagnosis.md

桥梁讲解视频口型问题复查

本次是问题诊断，不是口型质量通过报告。上一轮仅验证了媒体编码、资源绑定、播放及回退，不能据此认定嘴型同步合格。

项目接入

TASK-VIRTUAL-005～008 保留任务 ID 86～89，分别使用已发布内容版本 533～536。39 段 MP4 通过数字人视频导入接口进入受控文件存储，步骤 audio.narrationVideoAssetCode 引用 VIDEO 资产。任务预览和正式运行分别从教学 assignment/run 资产接口下载，转为 Blob URL 交给同一个 video 元素播放。原 WAV 仅在选择语音模式或视频失败时播放，不与视频音轨并行播放。报告目录中的 MP4 是复核副本，不是项目运行时依赖的文件地址。

已验证的事实

• 取 TASK-VIRTUAL-005 第3步为样本：MP4 画面 8.480 秒，音轨 8.241333 秒，音轨 start_time=0.064 秒。单凭 64ms 起点差异不能解释严重口型不符。
• 共享服务当前 MiniLive2.js、control-bridge.js 与本地源文件内容一致（忽略换行）。
• 用样本语音重新驱动同一人物，口型参数确实随语音变化；静音对照的变化幅度明显不同。语音驱动并未完全失效。
• 同配置本地无头浏览器测试，口型更新约 24.96fps，而录制 WebM 样本只有 113 个视频帧（约8秒）。说明推理更新频率和录制帧率不是一回事。原 MP4 212 帧中，固定嘴部区域有40次相邻帧平均像素差小于0.1。此像素统计只能反映近重复画面，不能直接量化发音准确率。
• open_render_capture.js 给 Viewer 发送同一语音驱动口型，同时使用另一个 AudioContext 播放录制音轨；以 speaking-start 通知开始录制。Viewer 在 WASM 设置音频后才解码并启动声音。两个路径没有共同的逐帧音频位置校验。
• 捕获使用实时时钟、setInterval和canvas.captureStream；FFmpeg最终转25fps。现有成功条件检查编码、音轨存在和时长，不检查口型与发音是否对应，也未记录录制过程的同步偏差。

结论及边界

问题应继续沿成片生成链路排查，项目资源绑定本身没有发现把视频和旧语音混播的问题。已确认录制存在独立时钟与录制帧率不稳定的风险；还不能把严重错位唯一归因于这两点，也不能据当前实验排除人物/底层WASM口型模型质量问题。

应先用同一音轨、统一时间轴制作一段对照样片，记录口型和音频位置，再逐字检查起句、停顿、收尾及闭口音。样片合格后再重做并发布39段；现有视频暂不作口型质量合格交付。现有任务、成绩及旧语音不作修改。

证据：runtime.json（语音驱动）、../bridge-lipsync-diagnosis-20260914-silence/runtime.json（静音对照）、frame-comparison.json、原成片与复现帧截图。