768p → 2× 超分方法对比

横轴按帧数排序。片子越长四条线越收敛 —— 两边的固定 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 和编码量。

• 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，那样更慢）—— 这个选择对官方版有利。