hoelee-blog/src/content/posts/zh/every-player-stuttered-the-file-was-fine.md

title, description, pubDate, category, dynamicCta, tags, ogImage, banner, draft

title	description	pubDate	category	dynamicCta	tags	ogImage	banner	draft
每个播放器都在同一个视频上卡顿，而文件本身是无辜的	同一个 HEVC 文件，在 VLC、Chrome 和 iPad 上（离线）都出现同样的周期卡顿。容器层时间轴完美无缺，画面却不是——NVDEC 的旧版 AV1 包装器返回了错误时间点的帧。	2026-10-08	devops	true	ffmpeg nvdec hevc transcoding video	/og/zh-every-player-stuttered-the-file-was-fine.jpg	/banners/every-player-stuttered-the-file-was-fine.jpg	false

一个我回答不了的问题

有个转好的视频会卡顿。不严重——每隔几秒顿一下，然后继续放。这种毛病你通常会怪到 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.yuv

5819 帧里有 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 不在硬件（实测环境为 NVIDIA RTX 3060 12GB + FFmpeg 6.1/7.0），而在旧的解码器包装器。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 落地。

我会怎么做得不一样

1. "解码没有报错"不是质量检查。 一帧能解码成功，跟它是不是正确的那一帧毫无关系。找出问题的是画面比对。
2. 跟第二个解码器比，而不是跟你的预期比。 软件解码是免费的，而且它就是参考基准。如果你的硬件路径跟它不一致，你就找到了值得搞清楚的东西。
3. 验证输出要对着源，而不是对着源的元数据。
4. 别以为现代硬件路径和旧包装器是同一条代码路径。 av1_cuvid 和 -hwaccel cuda -c:v av1 走的是不同的管道、到的是同一块硅片。其中一个有 bug，不等于对硬件下判决。
5. 一个"失败得安全"的闸门，比一个从不失败的闸门值钱得多。 我的第一版闸门拒绝了那段 4K60 编码，文件是好的、闸门是错的——但这个错误的代价只是白烧一次编码，而不是让一个坏文件进了库。

卡顿消失了。不是因为编码器变好了，而是因为解码器不再说谎了。

---

需要构建高可靠的媒体转码或自动化质检管线？

如果你正在运营自动化音视频处理流水线、自托管流媒体基础设施，或遇到了常规日志无法解释的底层软硬件排障难题，这正是我日常交付的工作：

• WhatsApp：+60 12-797 2969
• Email：[email protected]
• 网站：hoelee.com