2.1 KiB
PKG-MB-09：长测中的 AV 阈值越界
这是一份运行中检查点，不是终结报告。长测进程继续运行，被测源码、产物、素材和 原有阈值没有修改，也没有重启用例或将结果标为通过。
已观察到的事实
首批两个 Chromium 场景都使用已安装的 MediaBunny 2.0.0，分别搭配发布核心和候选核心。 约第 1762 秒，累计最大解码帧时间戳/AudioContext 主时钟偏差从约 25ms 增至 229ms / 156ms；约第 1767 秒，两组分别升至约 549ms / 570ms，超过原有 250ms 门槛。 对应采样仍为 visible、1×、未暂停、无媒体错误；媒体时钟和绘制计数继续增加，活动 音频节点和迭代器未突破原上限。参见固定采样快照。
两组几乎同时发生越界，但都使用同一候选 proxy；这不能证明历史 proxy 也失败， 不能归因于特定核心，也不能仅据同时出现就认定是系统调度问题。 观察后的 CPU/内存读数不是事发时剖析，不用它推导根因。
源码核对及后续
当前默认 dropLateFrames 为 false；video-frames.ts 的默认策略允许读取并绘制
落后帧，开启丢帧才会按容差跳过。video-renderer.ts 的已排队帧绘制还需结合实际
调度进一步诊断。这是现有源码事实，不足以证明本次偏差的具体来源。
测试统计的是每次 drawImage 的帧时间戳/音频时钟差，不是声音输出测量或用户可见
帧呈现的独立测量；短暂追赶、持续漂移与宿主阻塞需要分别验证。
登记 MB-SYNC-01，保持 PKG-MB-09 doing。等待当前运行产生阶段统计、清理结果和 最终报告后，再设计有限的调度/帧追赶对照，复现后修复项目缺陷并回归。 不得直接更改公开默认丢帧行为、扩大 250ms 门槛、缩短长测，或重跑直到通过。 当前已足以拒绝将这两个场景称为长播放通过，但最终进程退出状态仍需实际观察。
本检查点只改证据、风险和文档；计划/风险校验及风险校验器测试完成后单独提交。 不开始正式复盘，不推送或发布。