Jasna 视频修复快 3~5 倍是真的吗：官方基准、原始 CSV 与源码核查实录

【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna

"比上一代修复工具快 3~5 倍"——这句写进 Jasna 官方 README 的话，值得逐帧核对。Jasna 是一款 AI 视频马赛克修复工具，把整片视频交给 BasicVSR++ 做时序超分重建。本文核查它的性能数字怎么测的、在哪些条件下成立、代价是什么，证据全部来自仓库内的基准报告、原始 CSV 与核心源码。

先说结论

• 数字可复现：3.4x~4.7x 的对照建立在同一台 RTX 5090、同一段 6056 帧源视频、两端都显式指定 clip/overlap/编码参数的同口径测试上，原始数据在 benchmarks/2026-07-26_release_matrix.csv，脚本 scripts/benchmark_releases.py 可重跑。
• 提速不是单一技术：硬件解码（NVDEC）、检测后只修马赛克小块、BasicVSR++ 拆成独立 TensorRT 子引擎加 CUDA Graphs，三层叠加。
• 代价真实存在：显存是上一代的 2~4 倍，首次编译 15–60 分钟不计入成绩，Windows 绝对时间多 55%~18%，量化反而更慢。
• 适用边界：结论绑定 Linux + NVIDIA + BasicVSR++ 链路；AMD 不做编译、LTX 模型家族是另一套数据，不能直接外推。

测试现场是怎么配的：硬件、样本与统计口径

测量协议写在 benchmarks/2026-07-26_release_matrix.md 开头，逐条看：

• 硬件与系统：RTX 5090 32 GB、驱动 595.84、i9-13900K，跑在带桌面的"live desktop"上。报告明确标注：个位数差异视为噪声，除非配对重跑能复现。
• 样本：单一源视频 SONE-610，6056 帧 / 202.07 秒，编成 720p / 1080p / 2160p × H.264 8-bit / HEVC 10-bit / AV1 10-bit 共六份，外加一段 8K VR（900 帧）。
• 链路参数：--max-clip-size 180 --temporal-overlap 15 --secondary-restoration none，HEVC 输出，各版本用自己的默认模型，先丢弃一轮 warmup。Lada 一侧同样显式对齐：Flatpak 0.11.0、Accuratev2检测器、CUDA FP16、--max-clip-length 180、hevc-nvidia-gpu-hq。
• 统计口径：release 与 Lada 单次运行，v0.9.0 取三轮交错运行的中位数；RAM / VRAM 每 0.5 秒采样一次，报中位数与峰值。

一个关键口径：首任务的模型编译时间不计入基准。NVIDIA 上首次运行要为具体显卡编译 TensorRT 引擎，耗时 15–60 分钟（docs/en/tuning.md），之后复用model_weights下的缓存。这条口径对"公平性"影响很大，复测时若没有编译缓存，首跑时间会完全不同。

速度差从哪来：按数据链路逐环节拆

解码：NVDEC 对软件解码，差距随位深放大

扫描基准（decode + detection 吞吐）实测，同一张 RTX 5090：

来源 benchmarks/2026-07-21_v0.8.2_scan_decode_backends.md。值得注意的是 720p 上两者只差 1.2 倍，到 4K 高位深拉开 5 倍——分辨率和位深是软件解码的死穴。Jasna 在 jasna/media/video_decoder.py 里还为 AV1 单独覆盖了 PyAV 默认解码器，因为 libdav1d 不带 NVDEC，否则会悄悄退回软件解码。

检测与追踪：先砍掉 90% 的工作量

修复成本不取决于全帧面积，而取决于马赛克面积。整批帧先过process_frame_batch里的detections_fn（jasna/pipeline_processing.py），再由ClipTracker按 IoU 把框追踪成 track，只把马赛克附近裁出的 crop 统一 resize 到 256×256（INPUT_SIZE = 256，jasna/restorer/basicvsrpp_sub_engines.py）送进 BasicVSR++，修完按 blend mask 回填，其余像素不动。场景检测还会在切镜头处强制断 clip，两个镜头永不混进同一次修复。

检测端吞吐实测：720p 860.6 fps、1080p 828.3 fps、2160p H.264 716.5 fps、8K VR 168.7 fps，4K 以上自动拆到双 NVDEC 并行，8K 提到 217.5 fps（同一报告）。社区文章里常见的"GPU 扫描约 2000 FPS"，仓库中未找到依据——实测上限就是 860 fps 一档，仍以远超实时（720p 实时仅需 24~30 fps）著称。

修复：子引擎化 + CUDA Graphs + 定长批

v0.9.1 对 BasicVSR++ 做了"外科手术"：SPyNet 预处理（preprocess）、循环体（loop_body ×4 方向）、重建上采样（upsample）拆成独立 TensorRT 引擎。

批常量BASICVSRPP_PREPROCESS_BATCH = 60、BASICVSRPP_UPSAMPLE_BATCH = 30定义在 jasna/engine_paths.py。最后一行是全文最硬的一组数字："比上一代快 3~5 倍"里相当一部分，就是"编译引擎 vs 不编译引擎"的差距。

编码：NVENC 收尾，音频直接复制

编码端走 NVENC（AMD 为 AMF），音频尽量 copy 不重编码。对比 Lada 的资源画像最说明问题：Lada 全程 VRAM 中位数只有 1.9–4.2 GB，系统 RAM 却要 5.1–15.0 GB（benchmarks/2026-07-26_lada_flatpak.csv）；Jasna 恰好相反，显存吃紧、内存轻盈。上一代的主要计算压力留在 CPU / 系统内存侧，这正是端到端差距的另一半来源。

端到端成绩对齐后（Lada 0.11.0 vs Jasna v0.9.1）：720p 01:47→00:32（3.4x）、1080p 02:02→00:34（3.6x）、2160p 04:56→01:03（4.7x），见 README.md Benchmarks 一节与两份 CSV。长片上差距反而扩大：4K、2 小时 25 分的 ABF-017 从 2:56:26 压到 42:17（4.2x），1080p、3 小时 10 分的 HUBLK-063 从 1:34:51 压到 18:01（5.3x），因为固定启动开销被摊薄（benchmarks/2026-07-26_legacy_videos.md）。

⚡ 反直觉与代价：量化更慢、clip 更小更慢、Windows 更慢

• 量化全线劣化。直觉上 int8/fp8 应该更快，实测 loop_body 引擎 fp16 218.5 ms（graphs 开），fp8 414.4 ms、int8 420.0 ms——约 1.9 倍更慢，因为该阶段约 90% 时间是顺序循环调用，量化后每次调用反而从地板抬升。FP8 upsample 曾随 v0.9.1 发布，真机上引入 +1.8 GB 显存回归，最终被移除（benchmarks/2026-07-28_engine_batch_vram.md）。
• clip 调小不省时间，只省显存。clip-size 扫描（1080p，overlap 8）：30→720 帧，耗时 51.4→33.0 s，显存中位数 3.4→8.2 GB；超过 180 帧后时间不再降，只有显存涨。原因：重叠帧每段都要重算，clip 越小重复工作越多（benchmarks/2026-07-28_clip_size_sweep.csv）。
• Windows 绝对时间更慢。同一 v0.9.0：1080p 61.3 s vs Linux 38.6 s（+59%），2160p 88.3 s vs 75.4 s（+17%），benchmarks/windows-v0.9.0.csv。
• 显存代价随分辨率陡增。1080p 下 Lada 典型/峰值 2.0/3.3 GB，Jasna v0.9.1 是 4.8/5.6；2160p 要 7.2/10.9。Jasna 自己的历史更能说明"GPU 化"的收敛成本：v0.4.1 在 1080p 吃 18.9/21.4 GB，v0.5.0 降到 9.5/10.2，直到 v0.9.1 定长批才到 4.8/5.6——同一工具不同版本差近 4 倍（README.md）。4K 在同 clip 下还要再多约 1.5 倍显存（docs/en/tuning.md）。

怎么选、怎么调：给普通用户的清单

• Max Clip Size 能塞多大开多大：官方建议"装得下的最大 clip + Temporal Overlap 8~20"，Crossfade 常开（复用已完成帧，几乎零成本）。GUI 滑杆上限已放开到 720。
• 显存不够会自动兜底：jasna/vram_offloader.py 在显存超阈值时把等待处理的帧调度到系统内存再取回，无需手动干预；4–6 GB 卡跑 1080p 建议 clip 从 30 起步。
• 别关编译：--no-compile-basicvsrpp只省不到 0.5 GB，却要付出约 3 倍的时间代价，官方文档明确"几乎没有理由"。
• 首次任务预留 15–60 分钟：编译缓存放model_weights，可手动拷到新版本复用，跳过等待。
• 预期差异：官方基准是 Linux + RTX 5090；Windows 用户按上文比例放大，其他显卡型号按算力缩放，但"GPU 化 + 检测前置 + 引擎化"的相对结构不变。AMD 显卡不做 TensorRT 编译，这一层收益不适用。

结论

"3~5 倍"在限定条件下成立：Linux + NVIDIA、同口径 clip/overlap/编码参数、BasicVSR++ 链路、编译缓存已就绪、不含首次编译时间——此时它是三层工程叠加的可复现结果，且长片上还会进一步扩大。它不成立的条件同样明确：Windows 绝对时间要多出 17%~59%，4K/8K 对显存的要求陡增（峰值可到 10+ GB），量化等"理论上更快"的手段实测反而更慢，AMD 与 LTX 模型家族需另看数据。对这套工具，看基准时要盯住"测在哪张卡、什么系统、什么编译状态下"，这三个变量决定了你能不能复现宣传数字。

【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna