要点
- 两类方法,排序相反。保真组(SparkVSR-fast、ReCaVSR、RelayVSR)的 PSNR ≥ 27、LPIPS 最好;感知组(FlashVSR、SwiftVR、FastVR)的 MUSIQ 在 65–68,比 GT 本身(60.8)还高,但 PSNR 低于 bicubic,说明它们在"脑补"锐利纹理。
- 时序稳定性(E*warp,用 GT 光流):SparkVSR-fast 最稳;RelayVSR、SwiftVR、FastVR 比 bicubic 还差,可能有闪烁。
- FlashVSR+(2026-10-13,FlashVSR 原团队):Turbo 比 FlashVSR-v1.1 tiny 的 PSNR 高 1.0 dB(26.60,10 段里 9 段更高)、LPIPS / DISTS / E*warp-GT 都更好,MUSIQ 低 2 分(63.1,仍高于 GT),落在保真组和感知组之间。但同一张 H200 上它更慢:2560×1536 的 129 帧 Turbo 用 30.3 s(4.3 FPS),v1.1 tiny 是 17.2 s;峰值显存则从 36 GB 降到 15 GB。用 FlashVSR+ 的代码跑 v1.1 权重也要 37 s,所以慢在推理代码,不在模型。
- 初步结论:n = 10 clip,而且这份 UDM10 的 LQ 带真实退化(bicubic 只有 26.02 dB),绝对数值不能和其他论文里的 UDM10 直接比。
效果对比
拖动画面上的分割线对比两个方法;视频模式下两路同步播放;放大网格用来对比同一位置的细节。
每段只有 32 帧(24 fps 下约 1.3 s),默认 0.5× 循环播放。视频是 H.264 CRF 16 编码,做精细对比请用静帧。
放大网格:点击参考图选择位置(帧与 clip 同上方)
保真 vs 感知
横轴 PSNR(保真,越右越好),纵轴 MUSIQ(无参考感知质量,越上越"锐")。虚线是 GT 自身的 MUSIQ。
指标表
点列名排序。每列最好的值加粗(只在完整跑完的方法里比,不含 GT)。↑ 越大越好,↓ 越小越好。
效率
同一段视频:fox 前 129 帧,640×384 → ×4 = 2560×1536(8k+1 帧);每个方法独占一张 H200,bf16,官方默认参数,注意力用 SDPA 或方法自带的核(不装 FA3)。1 次不计时预热 + 3 次计时,取中位数。
干净的单卡数字,但只测了一段视频。
每个计时都在一张没有其他用户进程的 H200 上完成:开跑前用 nvidia-smi 检查,计时过程中每 5–10 s 再查一次;一旦有别人的进程出现,这次运行作废、等卡空了重跑("干净"列)。一张卡同时只跑我们的一个任务,但不同方法可能同时在不同的卡上跑(CPU 和磁盘是共享的)。t_infer 是从 LQ 张量到 HQ 张量的模型时间(含 VAE 编解码,cuda 同步),不含读写盘和模型加载;预热 / compile 单列。进程显存上限 90 GB(模拟 96 GB 的卡),超出记为 OOM,再试官方的省显存选项(单独一行标出)。只有一段 129 帧、2560×1536 的视频,换内容或分辨率排序可能会变;H200 上的数字也不能直接换算到 RTX PRO 6000。
全景 R0 端到端:一段 8 s clip
AI_Generated_Panorama_1(192 帧,3840×2160)→ cube 6 面 N=1468 / FOV 100.4° → FlashVSR-v1.1 tiny(wavelet color-fix,每面 3×3 块 544²,重叠 64)→ ±1.75° cos² 拼回 15360×8640 → ProRes LT 10-bit(16 路并行编码)。一次只用一张 H200,按阶段计墙钟时间,生产流程不预热(冷启动)。
UDM10 per-clip (not clean):UDM10 单个 clip 的旧计时(32 帧,1272×720),仅供参考
质量评测时顺带记下的时间:720p × 32 帧太短,固定开销占比大;有的方法测前预热、有的冷启动;约 20:10 UTC 起 GPU 和其他用户共享。不要拿它当速度结论。
高分辨率的初步发现(5872² 全景单面)
- FlashVSR-tiny:1468² 的面(输出 5872²)整面跑会 OOM。KV cache 在
kv_ratio=3、5888² 下常驻约 200 GB,和帧数无关,单卡 141 GB 也放不下。必须做空间切块:R0 用的是每面 3×3 块 544²(--tile 640)。 - InfVSR:DiT 不切块;5872² 下每个 12 帧 chunk 约 404K token,只是上一个 chunk 的 cache 就约 75 GB,同样需要切块。
- SoL-Refiner:权重常驻约 71 GB;输出 1280×768 时峰值就有 75.8 GB;在这么小的 token 规模下 SoL-Engine 没有加速。
方法
口径说明
指标
- PSNR / SSIM:BT.601 Y 通道(16–235),不裁边,99 dB 封顶,和 BasicSR 实现一致。
- LPIPS:AlexNet v0.1;DISTS、MUSIQ(KonIQ)、CLIP-IQA(基础版)、MANIQA(KonIQ)都用 pyiqa,无参考指标取 32 帧平均。
- DOVER:完整 DOVER.pth,官方 [0,1] 归一化;technical 分支的采样位置用 seed 0 固定,所有方法相同。
- E*warp (GT flow):光流和遮挡 mask 都用 GT 计算(RAFT-things,迭代 20 次),所有方法在同一批像素上比较,×1e-3。
- tLPIPS:TecoGAN 定义,mean |LPIPS(Ot,Ot+1) − LPIPS(Gt,Gt+1)| ×100。它衡量的是帧间变化幅度和 GT 是否一致,不是稳定性本身。
运行
- LQ 不满足模型的尺寸或帧数要求时,先在右下 reflect pad,时间上复制末帧,跑完再裁回;不做中心裁剪,不丢帧。
- 各方法都用官方默认参数(color-fix、稀疏比例、窗口大小等),seed 0,bf16。ReCaVSR (wavelet) 是额外加的变体。
- SwiftVR 本身是同尺寸复原模型,按上游做法先 bilinear ×4。SoL-Refiner 的路径是:LQ pad 到 320×192 → Lanczos 2× → 2× latent upsampler → 1 步 DiT。
- 测试数据是 UDM10(SparkVSR 版本),LQ 带真实退化。