每个播放器都在同一个视频上卡顿，而文件本身是无辜的
一个我回答不了的问题
有个转好的视频会卡顿。不严重——每隔几秒顿一下，然后继续放。这种毛病你通常会怪到 Wi-Fi 头上。
问题是它出现在一台 离线播放的 iPad Pro M1 上、出现在 VLC 里、也出现在桌面版 Chrome 里。不同的解码器、不同的平台、同样的周期性卡顿。而原始下载的视频在所有地方都播放正常。所以网络被排除、设备被排除，剩下的嫌疑只有那个文件。
我花了很长时间测量这个文件，所有测量都说它是好的。它并不是好的。它是对一个解码器 bug 的忠实重编码。
第一步：先量容器，而不是量画面
这个转好的文件是 MP4 容器里的 HEVC Main 8-bit（hvc1）、3840×2160、25 fps、yuv420p、bt709、平均 15.49 Mbps、232.8 秒、5819 帧，moov 在 mdat 之前。
它的时间轴是教科书级别的干净：
帧间隔 5818 个全部 = 恰好 0.040000 秒
重复 PTS 0
负值 PTS 0
超过中位数 1.5 倍的缺口 0
edit list (ctts) 5796 条（不是扁平表）
has_b_frames 2
音视频起始偏移 0.000 秒
B 帧图案 I B B B P B B B ……（744 组，每组都是 3 个 B）扁平的 ctts——把每个呈现偏移都设成零——是重编码后 PTS 停留在解码顺序上的经典症状，会让播放器丢掉大约四分之一的帧。这正是我预期会找到的东西。它不在那里。
完整解码，两个详细级别都跑：
ffmpeg -v warning -i converted.mp4 -f null -
ffmpeg -v error -i converted.mp4 -f null -两条都以 0 退出、什么都不打印，232 秒的视频用了 174 秒跑完。没有损坏帧、没有缺失参考帧、没有非单调 DTS。
GOP 确实和源不同（24 个关键帧、恒定 10.0 秒，因为 hevc_nvenc 默认 -g 250；源是 59 个关键帧、平均 3.88 秒），码率也比源高 17%——但源自身的峰值比输出的峰值还高，所以两者都解释不了”每隔几秒顿一下”。
容器里所有可测的东西都是正确的。 而这恰恰是”你就该停止测量容器”的那个点。
第二步：用两个不同的解码器去比画面
如果时间轴是对的、文件看起来却仍是错的，问题就变成：画面本身对不对。我把源文件用两种方式解码，再逐帧做 SSIM 对比：
# 软件解码源文件
ffmpeg -i source.mkv -vf "scale=640:360" -f rawvideo -pix_fmt yuv420p sw.yuv
# 同一批帧走 NVDEC 的 AV1 路径
ffmpeg -c:v av1_cuvid -i source.mkv -vf "scale=640:360" -f rawvideo -pix_fmt yuv420p hw.yuv5819 帧里有 106 帧不一致——占 1.8%——SSIM 最低到 0.330。不是均匀的噪声：间隔直方图的峰值大约落在每 30 帧一次。
两个对照实验，一个让情况更糟、一个让情况更清楚：
- 确定性。 同一个源用
av1_cuvid解两次，两次之间 SSIM 是 1.000000。这不是竞争条件；每一次转换都会把同一批坏帧焊进输出里。 - 不是所有 AV1 都中招。 一个 1080p 的 AV1 样本两条路径解出来完全一致（SSIM 1.000000），而另一个 4K AV1 流不一致。这跟具体的流有关。
然后是决定性的对比——转好的文件到底跟哪一边一致？
| 对比 | 平均 SSIM | 最低 | 低于 0.98 的帧数 |
|---|---|---|---|
| 转好的 HEVC vs 源的软件解码 | 0.99091 | 0.330 | 106 |
| 转好的 HEVC vs 源的 NVDEC 解码 | 0.99742 | 0.991 | 0 |
转好的文件和错误的那一份解码逐帧吻合。它不是一次糟糕的编码，它是对错误画面的一次准确编码。
抽出一帧就能看得很清楚：第 546 帧在软件解码里是合唱团的远景；在 av1_cuvid 里是另一个时刻的特写镜头——而转好的文件里是那张特写。
第三步：修复只要一行
Bug 不在硬件，在旧的解码器包装器。av1_cuvid 属于老式的 wrapper 解码路径；现代的硬件路径要走 hwaccel：
# 修复前
-c:v av1_cuvid
# 修复后
-hwaccel cuda -hwaccel_output_format cuda -c:v av1同一个流、同一个源，1500 帧对软件参考逐帧比较：
-hwaccel cuda -c:v av1 SSIM 1.000000 （逐帧逐位一致）
vp9_cuvid vs libvpx-vp9 SSIM 0.99991 （0 帧低于 0.98——不受影响）编码速度没有变化：一段 30 秒的 4K 素材 24.1 秒编完，两种路径都是 1.24× 实时。
范围要说准确：这是这套驱动/库组合下 AV1 的 *_cuvid 包装器的 bug，可稳定复现。它与你显卡的 AV1 解码器无关——现代硬件路径是干净的。
第四步：让它再也不可能悄悄发出去
最让人不安的地方在于：我的流水线本来就有验证步骤。它检查时长、分辨率、编码器、帧率和帧节奏——全是容器属性。这些检查在一个带着 106 帧错误画面的文件上全部通过。
所以现在流水线是五步，第四步才是画面检查：
解码 -> 编码 -> 结构验证 -> 内容验证 -> 替换文件内容闸门把输出帧与源的软件解码逐帧对比（两侧都顺序解码、按时间戳裁剪取窗口），并且判的是缺陷的形状，而不是某一帧的硬线：
- 任何一帧低于 0.85 → 失败
- 低于 0.95 的帧超过 1% → 失败
- 均值低于 0.98 → 失败
- 剔除近平坦帧（对几乎全黑的帧，SSIM 没有意义——两帧几乎全黑也能算出 0.25，而它们在视觉上完全相同）
这些阈值是拿实测数据标定出来的，不是凭直觉。这个素材库里好的编码在 1500 帧里有 0 帧低于 0.95；有缺陷的文件有 2.9% 的帧低于 0.85 且均值下滑。而一段完全正常的 4K60 舞蹈视频曾经测出最低 0.949——一个硬切处只有 1 帧低于 0.95——用单帧硬线判的话，它会被永久拒绝。
范围：快照里有 AV1 原档的共 75 个文件，其中 65 个（87%）没通过内容闸门。这 65 个全部用快照里的干净原档重转（绝不用已经被弄坏的文件），每一个都以 min SSIM 0.997–0.999 落地。
我会怎么做得不一样
- “解码没有报错”不是质量检查。 一帧能解码成功，跟它是不是正确的那一帧毫无关系。找出问题的是画面比对。
- 跟第二个解码器比，而不是跟你的预期比。 软件解码是免费的，而且它就是参考基准。如果你的硬件路径跟它不一致，你就找到了值得搞清楚的东西。
- 验证输出要对着源，而不是对着源的元数据。
- 别以为现代硬件路径和旧包装器是同一条代码路径。
av1_cuvid和-hwaccel cuda -c:v av1走的是不同的管道、到的是同一块硅片。其中一个有 bug，不等于对硬件下判决。 - 一个”失败得安全”的闸门，比一个从不失败的闸门值钱得多。 我的第一版闸门拒绝了那段 4K60 编码，文件是好的、闸门是错的——但这个错误的代价只是白烧一次编码，而不是让一个坏文件进了库。
卡顿消失了。不是因为编码器变好了，而是因为解码器不再说谎了。
