视频马赛克修复实测拆解：Jasna 如何把一段 3 分 22 秒视频的修复时间压到 34 秒，显存与首次运行等待全指南

视频马赛克修复实测拆解Jasna 如何把一段 3 分 22 秒视频的修复时间压到 34 秒显存与首次运行等待全指南【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是一款在本地 GPU 上自动找出并修复视频马赛克区域的开源工具。过去 24 小时它新增 502 个 Star总量逼近 2.9k登上 GitHub Trending 前列当前版本已到 v0.11.2见 pyproject.toml主分支同时维护英、日、中三语文档和一套持续积累的基准测试资产。谁在看它三类观众与各自留下的痕迹拆开关注构成大致能分出三类人本地修复的实用派。冲着免费、不上云、马赛克以外的画面不动这三个诉求来的社区里对应的痕迹是一键包、整合包和部署教程问题集中在第一次跑为什么这么慢。工程细节党。被全 GPU 流水线、TensorRT 引擎编译、自研 CUDA kernel 吸引痕迹是逐模块的拆解文章讨论点集中在 INT8 量化、CUDA Graph 和显存轨迹。潜在支持者。项目采用免费核心 支持者专享模型的双层结构$15 档与 $25 档一个许可证码可用 3 台设备痕迹集中在 Discord 里的样例图对比与激活码购买渠道讨论。值得注意的是这波热度的驱动来自产品本身而非营销事件。仓库里找不到任何推广投放痕迹取而代之的是工程痕迹benchmarks/ 下有 30 余份带硬件型号、驱动版本、参数与采样周期的基准报告pyproject.toml 对 torch、TensorRT 做了逐版本锁定版本号已从 0.4.x 一路推进到 0.11.x。判断热度由产品价值驱动。⚙️ 工程成色按快不快、稳不稳、好不好用反推快不快一条几乎不落地 CPU 的七步链路官方流程README.md How Jasna works 一节GPU 解码NVIDIA 走 NVDECAMD 走 AMF→ 逐帧检测 → 跨帧追踪并聚成片段 → 以 256×256 裁剪喂给 BasicVSR 修复 → 可选二级修复 → 只把马赛克区域混回原帧 → GPU 编码NVENC/AMF音频默认直接复制。追踪层里 ClipTracker 用 IoU 矩阵做跨帧匹配、用coast_count容忍短暂漏检GPU 场景切分器 把画面缩到 192px 宽后用相邻帧亮度差检测硬切保证一个修复片段永不横跨两个镜头。官方基准给的速度数据RTX 5090同一段 3:22 视频BasicVSR720p H.264 下 Lada 0.11.0 需要 01:47Jasna v0.9.1 为 00:321080p 02:02 → 00:342160p 04:56 → 01:03。显存侧同样有轨迹1080p 典型占用从 v0.4.1 的 18.9GB 降到 v0.9.1 的 4.8GB。另有 VRAM offloader 在显存吃紧时自动把等待帧挪到系统内存属于免配置的安全网。稳不稳可溯源的结论与一次公开的回退真正有意思的是 benchmarks/ 的记录方式。以 发布矩阵报告 为例RTX 5090、驱动 595.84、i9-13900K、--max-clip-size 180 --temporal-overlap 15RAM RSS 与进程 VRAM 每 0.5 秒采样一次取中位数/峰值——每个数字都能复现。逐 commit 的性能系列则把一次优化拆成 8 个提交1080p HEVC 从 43.7s 降到 38.4s−11.7%每一步对应哪个 kernel 一目了然。更少见的是失败记录CUDA Graphs 端到端基准 显示 CUDA Graph 带来 2–10% 提速但随后随版本发布的 FP8 upsample 引擎实测显存反而上涨约 1.8GB被整体移除完整过程写在 引擎批处理与显存报告 里。依赖侧同样是锁死思路NVIDIA 固定torch2.12.1cu130、tensorrt10.16.1.11、torch-tensorrt2.12.0连 Triton 都区分了 Linux 与 Windows 的 wheelpyproject.toml 里逐条有注释解释原因。好不好用三个关键设计决策双修复模型。BasicVSR 免费且全平台默认LTX 是面向支持者的扩散模型细节更多但每修复一分钟视频需数分钟且限 NVIDIA RTX模型选择文档。这等于把能用开源、把上限体验留给付费——而 CLI 提供了--ltx-trial试运行模式不下载模型、不激活码就能先测出自己显卡的速度cli_help.py降低的是决策成本。检测模型注册表。detection_registry.py 维护一张规格表默认rfdetr-v6在 576 分辨率、阈值 0.35 下运行rfdetr-v6-large升到 768、阈值 0.40适合 4K另有rfdetr-vr-v1、zelefans-vr-yolo-v2两个 VR180 专用模型以及 Lada YOLO 系列作为 2D 动画场景的兜底。后端策略按平台分流AMD 走 PyTorch 原生推理NVIDIA 走 ONNX 导出后编译 TensorRT engine。可插拔二级修复。unet-4x4 倍超分需激活码、RTX Super Res基于 NVIDIA Maxine源码 里专门处理了 nvvfx 自带 TensorRT 与 pip 版 TensorRT 的符号冲突、Topaz TVAI以 ffmpeg 子进程接入商用模型三条路径互不干扰。另外 流式模块 提供jasna --stream把修复中的画面以 HLS 推给浏览器或 Stash边修边看不落地成文件——这是离线导出之外第三种消费方式。 上手与排障首次运行要等多久显存溢出怎么调最简用法两条git clone https://gitcode.com/GitHub_Trending/ja/jasna jasna --input input.mp4 --output output.mkv第一次运行的三个关键问题1. 首个任务为什么要等 15–60 分钟。NVIDIA 平台上首次任务会在子进程里把检测与修复模型编译成针对你显卡的 TensorRT engineengine_compiler.py子进程超时上限 30 分钟放在子进程是为了保证显存被完整释放。产物缓存在model_weights目录升级版本时把这个文件夹拷过去即可免等。2. 显存溢出的三个旋钮。按 显存调优文档 的实测RTX 5090、1080p--max-clip-size从 30 提到 720显存从 3.4GB 涨到 8.0GB而耗时反而从 51s 降到 33s——小片段更慢而不是更快因为重叠帧会被重复处理超过约 180 帧后只有显存增长没有提速。其次是--temporal-overlap推荐 8–20再不行就开--fp16。4K 视频在同 clip size 下显存约为 1080p 的 1.5 倍。3. 硬件与平台门槛诚实说。要求 NVIDIA compute capability 7.5 以上GTX 16 系 / RTX 20 系起GTX 10 系不可用AMD RX 7000/9000 仅实验性支持且二级修复与 LTX 均为 NVIDIA 专属。LTX 单独要求 RTX 显卡、8GB 显存、16GB 内存。两个容易踩的坑解压路径不能含中文、日文等非英文字符只支持 NTFS / ext4 / Btrfs / XFS 本地盘不支持网络磁盘README.md What you need 一节。 冷思考热度之后看什么文档自洽docs/ 下 en / ja / zh 三语各 9 篇覆盖 GUI、CLI、模型选择、区间编辑、VR180、显存调优、流媒体、云 GPU 与开发模式LICENSING.md 与 第三方模型声明 把 AGPL-3.0 主许可证和模型、依赖各自的条款分开列明。文档体系对得起 0.11.x 的复杂度。维护可持续发布矩阵里逐版本记录了显存优化轨迹单个 FP8 引擎因显存表现异常被完整记录并回退说明基准不是发版前的公关素材而是日常迭代的一部分。社区正反馈Discord 里持续有样例对比与排障讨论衍生出了 Stash 深度集成的定制版本中文 README 还为国内用户单开了许可证购买渠道并明确警告第三方倒卖。克制的结论Jasna 已经把结论可溯源做成了仓库文化这是它区别于昙花一现项目的地方。真正的悬念只有一个工程问题——它深度绑定了 NVIDIA 生态AMD 仍标注 experimentalLTX 与二级修复均 NVIDIA only首次编译 15–60 分钟的门槛也注定了目标用户是愿意折腾的人。AMD 路径能否从实验性转正、首次编译体验能否进一步磨平将决定这 500 日增 Star 里有多少最终沉淀为长期用户。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考