Jasna：把"马赛克找出来再重建"这件事做成一条 GPU 全流程流水线

如果你手头有一段打了码的视频，想把码去掉——注意，是"去掉"而不是"猜出来它原本是什么"。这两件事有本质区别：前者是把马赛克区域当作噪声，用时序冗余重建出合理的纹理；后者是凭空捏造一个从未存在的画面。Jasna 属于前者，它有明确的边界意识：画面里除了马赛克区域，其他部分一个像素都不动。

这个边界在 2026 年的开源去马赛克工具里并不常见。多数同类项目要么只给一张命令行脚本，要么直接对整帧做生成式处理，结果是脸变形、衣服纹理漂移。Jasna 走了工程化路线——检测、跟踪、切片、修复、融合、编码六步分离，每一步都可调、可测、可加速。

项目背景：一个从 Lada 血统长出来的工具

Jasna 由 Kruk2 独立开发，代码托管在 GitHub（AGPL-3.0），模型和部分依赖来自 Codeberg 上的 Lada——Jasna 使用的 mosaic_restoration_1.2 模型正是 Lada 作者 ladaapp 训练的。项目在 2026 年 1 月 18 日创建，到 10 月已经积累 3330 星、249 个 fork、61 个 open issue，最新版本 v0.11.3（2026-10-20）。发版节奏非常密：v0.11.1 引入 LTX 扩散模型，v0.11.3 就把它提速了 2.7 倍。

社区里流传的中文评测不少，"一键整合包"版本在掘金、CSDN、DeepFace 等站点都有转载。值得留意的是这些转载几乎都强调同一件事：首次运行要等 15–60 分钟。这不是 bug，而是 Jasna 要为你的具体显卡编译 TensorRT 引擎。

类比理解：它像一个给视频做"局部重绘"的流水线

如果把整段视频想成一张会动的画布，Jasna 的工作方式更像专业修图师而不是整图重生成：

• 检测相当于用放大镜找出画面里所有"打了格子"的区域。默认模型是 rfdetr-v6（RF-DETR 目标检测系列），也提供 YOLO 系列的多个变体可选。
• 跟踪是把这块"格子"在时间轴上锁定，避免检测框在帧间乱跳导致修复区域闪烁。
• 切片把连续的帧聚成 clip（默认上限 90 帧），clip 边界落在镜头切换处，所以两个不同场景的帧永远不会被混在一起修复。
• 修复把每个 clip 当成一张 256×256 的静态图，用 BasicVSR++ 这类视频超分模型重建细节；clip 之间有少量重叠，视觉上不会断。
• 融合只把修复后的像素贴回马赛克区域，其余保持原样。
• 编码走 GPU 硬编（NVIDIA NVDEC/NVENC，AMD AMF），音频直接 copy。

整条链路几乎全部在 GPU 上跑，从解码到编码都不落地到 CPU。这让它在 4K 素材上依然可用——RTX 5090 上修复 3 分 22 秒的 2160p 视频只需 1 分 03 秒，比同类的 Lada 0.11.0 快 4.7 倍。

核心功能：两个模型、两种取舍

BasicVSR++（免费）：快，走传统视频超分路线，显存友好。官方基准里 1080p 典型显存 4.8GB / 峰值 5.6GB。

LTX（赞助者专享，仅 NVIDIA）：慢但细节多得多。走的是四遍流程——找马赛克、准备、扩散模型修复、保存。支持 Standard/Good/High/Top 四档质量（分别约慢 1.5×/2.5×/5×）。v0.11.3 的加速主要来自新的默认模型，Sage Attention 的 INT8 自注意力算子、CUDA 内核、torch.compile 缓存、VAE 优化都做了专门调优。仓库里能看到完整的 jasna/ltx/native/ 目录，包含手写的 .cu/.cuh kernel（cp_async 异步拷贝、MMA 张量核、INT8 量化注意力），这部分已经从 Lightricks LTX-2.5 移植过来。

二次修复是可选项：UNet 4x、RTX Super Res、Topaz TVAI，用来做锐化和放大。

其他实用功能：

• Segment Editor：只修复你手动选中的片段，带预览，大码块可以只交给 LTX 处理。
• Video Player：边修复边看，不用等文件生成完。
• Streaming：jasna --stream 在浏览器里播放已修复视频（默认 8765 端口），还能和 Stash 媒体库联动（作者 fork 了 Stash v0.30.1-jasna）。
• VR180 支持：识别 VR 视频的左右眼并正确投影。
• 静态图片：走 SD 1.5 inpaint（赞助者模型）。
• CLI：jasna --input input.mp4 --output output.mkv，支持单文件、文件夹、图片，参数覆盖了 App 大部分能力。

上手门槛：门槛在硬件，不在代码

NVIDIA 路线：GTX 16 系列 / RTX 20 系列及以上，计算能力需 ≥ 7.5（GTX 10 系直接不支持），驱动 Linux 580+ / Windows 610+。LTX 需要至少 8GB 显存、16GB 内存。

AMD 路线：Radeon RX 7000/9000，ROCm 10.0，实验性。文档里明确写了 AMD 环境下 secondary restoration 和 LTX 不可用。

文件系统坑：路径里不能有中文、日文、带重音的字符。这条看起来奇怪，但 PyAV/ffmpeg 在这类路径下的老问题大家都懂。磁盘格式要求 NTFS（Windows）或 ext4/Btrfs/XFS/ZFS（Linux），网络盘不支持。

首次运行 15–60 分钟：TensorRT 引擎要针对你的具体显卡编译。编译结果缓存在 model_weights 目录，升级版本时把旧目录拷过去就不用重来。

显存不够怎么办：调低 Max Clip Size（比如 90 → 60），这是官方给的第一建议。仓库里有 benchmarks/2026-07-28_clip_size_sweep.csv 这样的调参数据表。

从源码跑：Python 3.12+、ffmpeg/ffprobe 8、libVLC 3；NVIDIA 路线建议 uv pip install -e ".[nvidia,dev]" 配 cu130 索引。源码版能跑 GUI、CLI 和免费的 BasicVSR++，但激活与赞助者模型需要官方发行版——保护模块是闭源的。

争议与局限

商业化与开源的边界：这是 Jasna 最需要正视的问题。应用主体是 AGPL-3.0 开源，但 LTX、UNet 4x、SD 1.5 三个模型需要付费许可证码（$15/$25 档），且许可证码的验证组件是闭源的（jasna.protection.keytool 在打包时被排除）。官方文档写得很直白：官方发行包里包含"一个单独维护的、源码不可用的保护组件"，在内存中解密订阅者模型。换句话说：你想用最强的那档模型，就得接受里面有一段你读不到的代码。 这在纯本地运行的工具里是一个真实的信任边界——你的素材不上传，但加密密钥分发逻辑不受审计。

这个项目在做什么，本身是灰色地带。Jasna 的 README 自我定位是 "JAV videos"，GitHub 仓库描述也从 "Video restoration tool" 变过几次。国内评测里也频繁出现"法律红线紧急预警"这类标题，讨论《个保法》第 24 条和 GDPR 第 22 条。技术上它是正当的视频修复工具，但用途高度依赖使用者的意图。 任何面向企业内部落地评估的场景，都应该把这个伦理与合规维度纳入考量，而不是只看技术指标。

修复不等于还原：这点在社区讨论里被反复强调。模型在码块区域补出的纹理是"合理推测"，不是原片。人脸和字幕这两个高频区域最容易补出原片里根本不存在的东西——修完更清晰，但更假。这是时序超分模型的物理上限，不是 Jasna 的实现缺陷。

硬件锁定：GTX 10 系及更老完全不支持，计算能力 7.5 是个硬门槛；AMD 路线功能残缺。这让很多还在用老卡的用户被直接排除在外。

没有容器化：仓库里只有 .dockerignore，没有 Dockerfile、没有 compose、没有 k8s 清单。考虑到项目深度绑定 CUDA 12/13、TensorRT、NVDEC、ROCm，容器化收益有限，但代价是团队部署时无法享受标准化交付。

代码质量：一份被测试撑起来的工程

387 个 Python 文件，测试目录里有超过 180 个测试文件，覆盖面细致到有点强迫症的程度：test_gui_scrollbar_stability.py、test_windows_dll_path_sanitization.py、test_bootstrap_sys_path_sanitization.py、test_no_cpu_tensor_ops.py、test_ltx_int8_attention_gpu.py、test_yuv_to_rgb.py、test_rfdetr_preprocess.py……

这个清单本身说明了很多问题：作者真的在关注那些"平时不出问题、出问题就毁一天"的地方——GUI 滚动条抖动、Windows DLL 路径污染、GPU 管线里偷偷溜进 CPU 张量运算、色彩空间 YUV↔RGB 的精度。

其他工程信号：

• 强类型依赖锁：torch==2.12.1+cu130、av==18.1.0、mmengine==0.10.7 全是精确 pin，注释里写明"release 的 VALI wheel 是针对同一份 pyav-ffmpeg 库构建的，两者必须同步升级"——这是被真实的坑教育过的痕迹。
• 性能基准体系化：benchmarks/ 目录有 30 多份 CSV/MD 报告，覆盖解码后端、VR 投影、量化、注意力实现、GPU 型号对比，每次发版都有 before/after 数据。
• 代码质量评分：85/100。扣分主要在闭源保护模块带来的不可审计性，以及单文件体量偏大。

行业意义

2026 年开源去马赛克赛道出现了一轮明显的分化：早期是 PULSE、Depix、TecoGAN 这类学术向、单图向的项目；中期 Lada 完成了工程化；现在 Jasna 把这件事推到了"全 GPU 流水线 + 消费级图形界面 + 发行版打包 + 浏览器流式播放"的完整产品形态。

它的技术路线选择值得注意。走生成式模型（LTX 扩散）意味着更强的细节重建能力，但也更慢、更吃显存，且需要 GPU 硬件；走传统超分（BasicVSR++）则更快、更通用。作者两条线都留着，让用户按硬件和需求自己选——这比"只有一种方案"务实得多。

从社区反馈看，让 Jasna 真正出圈的是它踩过了别人没踩的坑：路径字符限制、驱动版本坑、首次编译等待、显存调参——每一个都有对应的文档章节和 UI 提示。对一个面向普通用户的开源 AI 工具来说，这种"把摩擦写进文档"的取向，比模型本身多几个点更值钱。

落地建议

适合的场景：影视修复、素材整理、隐私打码内容的回溯、VR180 内容处理。技术团队也可以直接拿它当 CUDA 视频处理流水线的参考实现——jasna/media/ 和 jasna/ltx/native/ 里的解码、色彩空间、注意力 kernel 都值得读。

不适合的场景：老显卡（< 7.5 计算能力）、无 NVIDIA 卡的纯 CPU 环境、要求全流程可审计可自建的合规敏感场景。

如果要用它，先确认三件事：你的显卡过 7.5 门槛吗？你能接受首次 15–60 分钟的引擎编译吗？你能接受模型许可证的闭源验证组件吗？

三个都是"是"，那就是个好工具。