768p → 2× 超分方法对比

W / T / L = A 在 20 条里赢 / 平 / 输的条数（按该指标自己的方向）。 粗体行表示 95% CI 不跨 0，即差异在这 20 条上稳定成立。

• 图像 IQA（MUSIQ / CLIP-IQA / MANIQA / NIQE）：每条视频均匀抽样 24 帧， 所有方法用完全相同的帧号，帧号来自 manifest.json，由完整性检查一次性冻结。 每个指标共 20 × 24 × 6 = 2880 次评测。
• Downsample LPIPS：不抽样，逐帧全跑（每个方法 3724 帧）。协议是 2× 输出 → torch F.interpolate(mode="area") 缩回源分辨率 → 与 MiniMax 原片做 LPIPS(AlexNet)。 两路视频锁步解码，任何一路读短立即报错中止，绝不允许因帧数不齐而静默错位。
• 这不是画质分。Downsample LPIPS 衡量的是「修复有没有改掉原内容」： 低 = 忠于原片，高 = 大量重写。它无法判断重写得好不好看。
• 公共帧数取 min。SwiftVR 在 14 条片子上比原片少 1–3 帧（clip_len 分块的尾巴对不齐）， 所以每条片子的评测长度取所有方法的最小值，逐条记录在 manifest.json。
• 两个参照系也编码成真实 mp4 再评（libx264 CRF 17）。如果按无损数组评， 它们会白拿一个所有已发布方法都没有的编码优势。
• 已知混淆项：四个方法的交付编码设置并不一致（SwiftVR 用 imageio quality=85， CDA-VSR 用 CRF 17）。这是各自实际发布管线的属性，我们评的就是真实交付产物， 但它确实会影响无参考 IQA。20 条片子的码率分布都记在 issues.csv 里。
• 完整性检查先于评测：逐条核对每个方法是否都有产出、分辨率是否严格等于源 ×2、 fps 是否一致、帧数是否一致、文件是否可解码。0 个 fatal，28 个 warn（全是上面那条帧数差）， 全部落在 issues.csv，没有静默忽略。

我们的生产任务是 768p → 2×，不是论文里的 ×4，所以没有直接用数据集自带的 LQ （UDM10 自带的是 ×4 的 318×180，用它会答非所问）。统一从 GT 自己造 ×2 输入：

GT png  ──(居中裁到 32 的倍数)──▶  对齐后的 GT      ← 评分基准，无损 png
   │
   └──(bicubic 0.5×)──▶  LQ ──(libx264 crf23, GOP=25, 无 B 帧, refs=1)──▶  唯一共享的 LQ.mp4
                                                                              │
                    ┌─────────────────────────────┬───────────────────────────┤
                    ▼                             ▼                           ▼
              nearest/bicubic ×2            SwiftVR ×2              CDA-VSR 原生×4→area→×2
                    │                             │                           │
                    └──────────── 全部输出无损 png，分辨率 = GT ────────────────┘

• 六个方法读的是同一个 LQ 文件（md5 记录在 bench_manifest.json 里）。 LQ 必须是压缩视频，因为 CDA-VSR 是压缩域模型、要从码流里取运动矢量； 它的 deLR/mvs/residual 全部解自这一个文件。 顺带修掉了 MiniMax 那轮的一个不对等：那次 SwiftVR 读的是原始 mp4、CDA-VSR 读的是重编码版本。
• 评分两侧都是 PNG，量化指标从不经过有损容器。（DOVER 例外：它是视频模型， 必须给容器，所以六个方法统一用 libx264 -crf 0 yuv420p 编码后再评， 色度下采样对六者完全一致。）
• GT 居中裁到 32 的倍数，理由见下面那条 SwiftVR 的 bug。YouHQ40 1080→1056、 UDM10 720→704 / 1272→1248，逐条记录在 manifest 的 native_size / crop_yx。
• GT 无损性是验证过的，不是假定的：GT png → 无损视频 → 解码回来逐像素比对， max|diff| 必须为 0，否则该条直接判失败。

横轴按帧数排序。片子越长四条线越收敛 —— 两边的固定 warmup 开销都被摊薄了。

SwiftVR — 2.91×，显存 −7.6 GiB

• clip_len 24 → 4。贡献最大的一步。官方 UI 写的是「Larger = more context」，实测反了： 小 chunk 更快、更省显存，闪烁更低、锐度更高。
• 弃用官方 restore_video 的四线程流水线，改单线程顺序驱动（官方 Space 的 app.py 用的就是后者）。又快又省 3–4 GiB，还绕开了下面那个死锁 bug。
• torch.compile，常驻只付一次编译代价。

CDA-VSR — 2.29×

• 把 mmcv 的 ModulatedDeformConv2d 换成 torchvision 原生 deform_conv2d。 最关键的一步：mmcv 是 C 扩展，dynamo 无法追踪、必然 graph break；换成原生算子后 torch.compile 才能吃下整图。该替换经过逐位等价验证（整网 max|diff| = 0.000e+00），不是「能跑就行」。
• bf16 autocast + channels_last + torch.compile。
• 后台预取线程 + pinned memory + 异步 H2D。压缩域先验每帧要读 2.4–4.1 MB 运动矢量，IO 很重。
• ×4→2× 的降采样放到 GPU 上、在回传主机之前做。×4 输出是实际需要的 4 倍像素， 先降再传省掉 75% 的 D2H 和编码量。

16:9 与 9:16 那两档，CDA-VSR 内部要算到 5376×3072 = 16.5 Mpx，是最终所需 4.13 Mpx 的 4 倍。 这部分额外算力全部计入了它的耗时。SwiftVR 的显存峰值严格随输出像素线性增长 （12.03 + 2.44×Mpx，20 条实测最大残差 0.006 GiB），其中 12.03 GiB 是 bf16 权重常驻。

SwiftVR：GPU 主导（73–80% 在 GPU 上）

解码几乎免费（0.2–0.7 秒，占比 1–2%），编码占 8–12%。加 CPU 对 SwiftVR 没意义 —— 换更快的卡才有效。

CDA-VSR：CPU / IO 主导（官方配置只有 38% 在 GPU 上）

已知的两处硬件口径瑕疵

• PyTorch 任何 wheel 都不含 sm_89 cubin。4090（sm_89）实际执行的是 sm_86 的 cubin， 靠 CUDA 大版本内二进制兼容；5090 执行的是原生 sm_120。 （CDA-VSR 优化版走 inductor/triton，那部分是为 sm_89 原生编译的。）
• 5090 用 torch 2.10.0+cu130，4090 用 +cu128（驱动 535 限制）。torch 版本相同。

其余全部对齐并逐项核验：仓库 rev 相同、checkpoint 字节数相同、跑分脚本与打过补丁的 runner.py md5 一致、CDA-VSR 的 LR 重编码码流逐字节相同、 两边 DCN 后端一一对应（官方都用 mmcv、优化都用 tv shim，max|diff| = 0.000e+00）。

本页 5090 的数字全部重测过。最初那版把 official（GPU 0–3）和 optimised（GPU 4–7） 同时启动了 8 个进程，而 official 是 CPU 重的配置，两者抢 CPU。 4090 那边只有 4 张卡可用、是顺序跑的，协议不一致。

线索是按输入像素归一化后的吞吐形状：4090 在五种分辨率上是平的（7.47–7.71）， 5090 却浮动 1.85 倍、且在 768×768 那档绝对值反而低于 4090 —— 而 optimised 下 5090 每档都赢。 这不是硬件差异该有的形状。

• CDA-VSR 在 ×4 劣势下参赛。它的重建头是 Conv2d(num_feat,48)+PixelShuffle(4)， 发布的权重按 ×4 训练。要原生 ×2 得改重建头并重训或微调 —— 不在本次范围内。 所以它走「真实 768p → 原生 ×4 → 3072p → 降到 1536p」，额外算力如实计入。
• CDA-VSR 官方脚本改了一行才能跑。 basicsr/models/video_recurrent_model.py:310 的 t = 100 是写死的字面量， 在 REDS4 上看不出来（每 clip 正好 100 帧）。我们的片子是 73–362 帧：73 帧的会 IndexError， 241/362 帧的会静默只算前 100 帧。改成 t = len(frames)，其余一字未动。 注意这是发布脚本的问题，不是模型的限制 —— 模型是在线递归的，可处理任意长度流。
• SwiftVR 官方配置有 8 条在 clip_len=24 直接 OOM（4.13 Mpx 那两个比例）， 自动回退到 20 才跑通。这是给官方配置放宽后的结果。
• SwiftVR 上游有一个会静默挂死的 bug。runner.py 的 record_error() 用阻塞式 q.put() 往 maxsize=3 的有界队列发停止信号， OOM 时队列必满 → put 永不返回 → 主线程卡死在 join()。表现是 GPU 0% 占着显存挂住， 而不是崩溃退出。已打补丁；改用单线程驱动可整个绕开。
• CDA-VSR 的残差是近似的。libavcodec 不暴露真实变换域残差，除非改 ffmpeg 解码器。 我们用运动补偿后的 Y 通道差值，与真实 warp 误差相关性 0.67–0.94。 运动矢量的符号约定经实证确认（用模型自己的 warp 函数：正号比反号的对齐 PSNR 高 4.4–10.4 dB）。
• 帧类型不在磁盘上。README 说数据集含 frame-type 信息，实际代码是按位置硬编码 fi % 25 == 0 判 I 帧。所以 LR 必须重编码成 GOP=25、I 帧落在 25 的倍数上、且无 B 帧 （-bf 0 -refs 1 -sc_threshold 0）。这一步的重编码是第二代压缩，计入了 CDA-VSR 的输入质量。
• 两边都用视频编码输出（CDA-VSR 官方脚本原本逐帧写 PNG，那样更慢）—— 这个选择对官方版有利。