Jasna 视频马赛克修复3:22 的 1080p 视频 34 秒修完的 GPU 加速实战指南【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是免费开源的 GPU 加速视频马赛克修复工具把解码、检测、修复、编码全放到 GPU 上适合想给视频去马赛克的 NVIDIA/AMD 独显用户。读完能过环境检查、跑通第一个任务并按自己的显卡调好显存与速度。 启动前的 4 项硬性门槛第一次运行前花一分钟核对下面四项任何一条不达标启动检查jasna/gui/system_checks.py都会直接拦下来。项目可接受范围不达标怎么办显卡NVIDIA GTX 16 系 / RTX 20 系起计算能力 ≥ 7.5AMD RX 7000/9000、Radeon 780M/760M/740M、Ryzen AI实验性GTX 10 系及更早无法使用只能换机器驱动NVIDIAWindows 610 / Linux 580AMDAdrenalin 26.8.1Linux 另装 AMF 视频运行库升级后从头部菜单重跑系统检查Linux AMD 先装 AMF 再执行run_jasna_amd.sh存储本地 SSD文件系统为 NTFS / ext4 / Btrfs / XFS / ZFS网络盘不支持挪到本地 SSD机械硬盘能跑但启动与加载明显变慢程序会给出警告路径纯 ASCII 字符不含中文、日文、带重音符号的字母整个文件夹挪到D:\Tools\jasna这类路径校验由 jasna/os_utils.py 的check_ascii_install_path在每次启动执行注意路径这条最容易被忽略。C:\Users\张三\Downloads\jasna这种中文用户名下的路径会直接报错退出必须整体搬到英文路径。 三条命令跑通GUI 与 CLI 并列图形界面最短路径解压版本包到纯英文路径 → 启动Windows 双击jasna.exeLinux NVIDIA 执行jasna文件Linux AMD 先装好 AMF 运行库再执行run_jasna_amd.sh→ 把视频拖进队列并保持默认设置 → 点界面底部的▶等它跑完。命令行最短路径就是这一条对单个视频执行默认的 BasicVSR 流程jasna --input input.mp4 --output output.mkv图片输入自动走 SD 1.5 模型文件夹输入批量处理先图片后视频jasna --input photo.png --output restored.png jasna --input input_folder --output output_folder首次任务要等 15–60 分钟仅此一次。NVIDIA 上 Jasna 会把检测模型和修复模型编译成专属于这块 GPU 的 TensorRT 引擎期间关闭其他应用、别碰电脑判断正常的标志是机器负载拉满、model_weights目录持续增长。编译产物存放在model_weights目录缓存位置由 jasna/engine_paths.py 的configure_torch_compile_cache配置以后升级 Jasna 时把这个文件夹复制到新版本目录即可跳过等待。跑完发现显存吃紧时把最大剪辑大小从90降到60是最直接的手段调法见后文。 三种引擎怎么选BasicVSR、LTX、SD 1.5先说结论绝大多数视频用免费的BasicVSR就够只有当你对个别关键场景的质感有更高要求、且显卡是 RTX 30/40/50 系8 GB 显存起时才值得上LTX静态图片自动走SD 1.5。选型细节见 docs/zh/models.md。引擎速度画质GPU 要求费用模型体积BasicVSR默认快良好全部受支持显卡免费随包附带随包LTX很慢耗时表见下纹理更细腻自然RTX 30/40/502080 Ti 仅验证过Linux 兼容 Radeon RX 7000/9000 与 R9700Windows AMD 为测试版支援者专属25 USD 档含 UNet 4x 与 SD 1.5不附带需下载标准约 15 GB、高速约 9 GB、更高画质每档再加约 13 GBSD 1.5仅图片单张数十秒级实验性单张差异大约 7 GB 显存支援者专属15 USD 档起约 6.9 GB首次使用会询问后下载LTX 耗时参考1 分钟 1080p、马赛克持续出现的素材标准画质档显卡标准画质高速模式--ltx-fast仅 RTX 50 系RTX 5090约 1 分钟不到 1 分钟RTX 4090约 1.5 分钟不可用RTX 5080约 2 分钟约 1.5 分钟RTX 3090约 3 分钟不可用RTX 2080 Ti约 10 分钟不可用LTX 常用开关--restoration-model-name可选ltx标准/ltx-4step良好慢约 1.5 倍/ltx-8step高画质慢约 2.5 倍/ltx-undistilled顶级慢约 5 倍--ltx-large-canvas让大马赛克按 768px 修复该部分慢约 3 倍需约 12 GB 空闲显存不足自动回退--experimental-ltx-less-overlap默认开启马赛克持续超 4 秒的场景约快 13%--ltx-seed默认20260923控制可复现性。决定上 LTX 前先跑一次--ltx-trial速度实测无需模型和许可证不产出修复视频jasna --input input.mp4 --output output.mkv --restoration-model-name ltx --ltx-trial注意 LTX 的硬限制不支持 VR180 左右并排、不支持流媒体且启用后二次修复与降噪自动关闭。Jasna 0.12 起从 0.11.3 复制过来的 LTX 模型文件需要重新下载原来的许可证码和共享 VAE 文件仍可复用。检测模型管的是找马赛克这一步全部选项如下阈值取自 jasna/mosaic/detection_registry.py模型权重状态输入分辨率默认阈值适合什么rfdetr-v6默认随包5760.35绝大多数视频拿不准就用它rfdetr-v6-large另下载NVIDIA 用.onnx、AMD 用.pt7680.404K 素材、要更高检测精度rfdetr-vr-v1随包7680.40VR180 视频zelefans-vr-yolo-v2另下载—0.25VR180 的另一选项lada-yolo-v2/lada-yolo-v4随包—0.252D 动画素材或 AMD 上求快rfdetr-v5随包7680.25旧版仍可用批大小固定为 4权重放进model_weights/后自动发现。阈值用--detection-score-threshold调0–1调低检得更多、调高检得更少。AMD 上 RF-DETR 明显慢于 NVIDIA检测是瓶颈时换成lada-yolo-v4换回速度。二次修复只在修复块看起来软大马赛克、特写、4K 素材时才有必要且仅限 NVIDIA。1080p 实测耗时 / 显存修复组合CAWD 1080pKV-109 1080p不启用22 秒 / 10.0 GB11 秒 / 10.7 GBUNet 4x支援者专属质量接近 TVAIiris-2且更快29 秒 / 12.5 GB14 秒 / 12.6 GBRTX Super Res免费、极快个别视频会闪先在短片段验证25 秒 / 11.7 GB13 秒 / 11.4 GBTVAI2 workersiris-2需付费 Topaz Video仅 Windows很慢52 秒 / 12.1 GB24 秒 / 12.4 GBjasna --input input.mp4 --output output.mkv --secondary-restoration unet-4xTVAI 需额外设置环境变量TVAI_MODEL_DATA_DIR与TVAI_MODEL_DIR指向 Topaz Video 的模型目录相关参数--tvai-model默认iris-2、--tvai-scale默认 4输出为 256×scale、--tvai-workers默认 2、--tvai-ffmpeg-path见 docs/zh/cli.md。三档场景推荐日常够用全部默认值--max-clip-size 90 --temporal-overlap 8交叉淡化默认开在 10 GB 级显存的卡上非常宽裕。追求质量--max-clip-size 180收益拐点1080p 实测 35 秒 / 5.0 GB再往上时间不再变好只吃显存 二次修复 低 CQjasna --input input.mp4 --output output.mkv --max-clip-size 180 --temporal-overlap 8 --secondary-restoration unet-4x --cq 22资源受限4–6 GB 显存--max-clip-size 30起步1080p 实测 51 秒 / 3.4 GB关二次修复关闭一切占 GPU 的其他程序。4K 素材同剪辑大小下显存约 ×1.5再往下压。 帧的旅程七段 GPU 流水线源码把整条流水线拆成四个并行线程循环decode_detect_loop→primary_restore_loop→secondary_restore_loop→blend_encode_loop定义在 jasna/pipeline_threads.py。七个环节各自吃进什么、做什么、吐出什么GPU 解码输入源文件H.264 / HEVC / AV1含 10-bit处理NVIDIA 走 NVDEC、AMD 走 AMF另有软件解码兜底jasna/media/video_decoder.py 的_setup_nvdec_decoder/_setup_amf_decoder输出连续帧流进入检测队列逐帧马赛克检测输入刚解码出的每一帧处理默认rfdetr-v6按推荐阈值打分并框出马赛克区域输出该帧的马赛克框列表与置信度时间维跟踪分组输入连续帧的检测框处理同一块马赛克沿时间轴被跟踪帧归组为剪辑长度上限即最大剪辑大小硬切镜头处强制收尾保证一个剪辑不混入两个镜头jasna/tracking/clip_tracker.py输出一批互不混镜头的剪辑主修复BasicVSR输入每个剪辑的 256×256 图像序列处理按序列做时间维超分重建相邻剪辑刻意保留少量重叠来隐藏接缝输出补出纹理的马赛克图块二次修复可选NVIDIA 独占输入256×256 修复图块处理UNet 4x / RTX Super Res / Topaz TVAI 先把图块放大到 512×512 或 1024×1024再走一遍锐化输出更清晰的图块用 LTX 时此环节整体关闭合成回原帧输入修复图块 原始帧处理只替换马赛克区域其余像素原样保留混合掩码与缓冲在jasna/blend_buffer.py与jasna/tracking/blending.py显存告急时排队中的帧自动挪到系统内存、需要时再搬回jasna/vram_offloader.py全程无需手动干预输出完成混合的完整帧GPU 编码输入完整帧 原音轨处理NVENC 或 AMF 编码音频默认直接复制仅当输出容器装不下原音轨才重新编码判断逻辑在jasna/media/audio_utils.py的needs_audio_reencode输出最终文件默认 HEVCLTX 不走这条流水线它要把视频完整过四遍——找马赛克、准备、用扩散模型修复、保存——所以慢得多但能补出更真实的纹理。⚡ 速度与显存调优把显存从 10 GB 压到 3.4 GB 的三档配置调参对象主要是 BasicVSRLTX 自管内存核心变量就三个最大剪辑大小、时间重叠、交叉淡化参数合法性由 jasna/session_config.py 统一校验。剪辑大小扫描数据1080p 单视频、重叠 8、RTX 5090趋势普适、绝对值因环境而异剪辑长度帧1080p 耗时典型显存3051 秒3.4 GB6040 秒3.7 GB9034 秒4.1 GB18035 秒5.0 GB36032 秒6.3 GB72033 秒8.0 GB小剪辑只会更慢重叠帧在每个剪辑里都要重复处理剪辑越多重复劳动越多超过 180 之后时间不再变好、只有显存上升。交叉淡化复用的正是已处理好的帧零额外开销保持默认开启即可。模型编译同理——关掉编译开关--no-compile-basicvsrpp只省不到 0.5 GB 显存却让处理慢约 3 倍同素材对比编译 33 秒 / 5.0 GB不编译 107 秒 / 4.6 GB几乎没有正当理由。注意时间重叠必须满足2 × temporal_overlap max_clip_size否则启动即报错8–20 是推荐区间超过 20 通常无收益。按需求查表编码与画质你的需求推荐设置兼容性最好、8-bit 到处能放--codec h264质量体积平衡默认--codec hevc默认 CQNVIDIA 28 / AMD 25文件体积最小--codec av1需 RTX 40 系 / RX 7000 及以上默认 CQNVIDIA 35 / AMD 16质量更高、文件更大调低--cq默认值NVIDIA H.264 25 / HEVC 28 / AV1 35AMD H.264 24 / HEVC 25 / AV1 16画面更锐--sharpen 0.2–0.50 关闭1 最强CQ 合法范围NVIDIA H.264/HEVC 为 1–51、AV1 为 1–63AMD H.264/HEVC 为 0–51、AV1 为 1–51。Jasna 还会按源码率自动给输出设maxratebufsize为其 2 倍防止低码率源被过度放大NVIDIA H.264 输出为源码率 2.0 倍、HEVC 源 1.25 倍、其余组合 1.0 倍自行指定maxrate可覆盖。常用默认值速查以jasna --help为准参数默认值--devicecuda:0AMD 经 ROCm 也用cuda:N命名--batch-sizeNVIDIA 4 / AMD 8rfdetr-v5恒为 4--fp16/--no-fp16开半精度省显存且通常更快--max-clip-size90--temporal-overlap8--enable-crossfade开--detection-modelrfdetr-v6--max-detection-gap2同位置马赛克漏检最多补 N 帧0 关闭--min-detection-duration2短于 N 帧的检出按误检丢弃0 关闭--scene-detection开硬切处结束所有剪辑--denoisenone可选low/medium/high只清理修复区域--denoise-stepafter_primary或after_secondary移到最后--codechevc--sharpen0--ltx-seed20260923--sd15-steps/--sd15-strength/--sd15-seed/--sd15-variants25 / 0.6上限 0.7/ 0 / 1variants 产出name_v1…vN供挑选--stream-port/--stream-segment-duration8765 / 4.0--log-levelerror可选debug/info/warning 四个进阶方向区间、流媒体、VR180、云 GPU区间处理segments—— 马赛克只出现在部分场景或想只对关键片段花 LTX 的慢钱未选中的区间原样复制快且无损输出仍是全片长视频。jasna --input input.mp4 --output output.mp4 --segments 10-25,01:10-01:30.5一次只能处理单个视频不支持文件夹/图片/流媒体输入须为恒定帧率的 H.264/HEVC/AV1输出 MP4/MOV/MKV且输出编解码器恒等于输入不能与--stream、--retarget-high-fps、--fmp4、--ltx-auto-split组合区间之间的少量帧会被重新编码视频只能在特定帧处切开GUI 里点队列条目的剪刀按钮打开区间编辑器按帧选区间、逐区间指定 BasicVSR 或 LTXLTX 区间可先渲染指定种子、比较多个种子、用内置马赛克扫描RTX 5090 上约 2000 FPS自动定位含马赛克的场景还能开仅大马赛克用 LTX把慢速 LTX 集中在收益最大的大马赛克上建议从 12% 起步。想让文件夹里每个视频大马赛克走 LTX、其余走 BasicVSR用自动分配jasna --input videos/ --output restored/ --restoration-model-name ltx --ltx-auto-split 12临时文件默认放输出旁的隐藏文件夹磁盘紧张时用--working-directory指到更快的盘。流媒体Stash / 浏览器—— 边修边看不落盘先确认效果或挂在 Stash 里按需修复。jasna --stream恒用 BasicVSR 与 H.264LTX 不可用首次必须先用 Stash 里实际会用的相同设置流式跑通一个短视频——第一次要为 GPU 准备文件、耗时很长跳过这步 Stash 会超时放弃日志出现timeout waiting for jasna-cli to become healthy就是这个原因Stash 需下载专用的 v0.30.1-jasna 版本并设置JASNA_CLI_PATHjasna 可执行文件完整路径与JASNA_WORKING_DIR其所在文件夹两个环境变量启动后 Jasna 会开 HLS 服务并自动打开浏览器播放器可拖动进度--stream-port默认 8765、--stream-segment-duration默认 4.0 秒、--no-browser可调。VR180—— VR180 文件通常把左右眼并排放进一个宽帧Jasna 会拆开分别修复再拼回。保持VR180 模式 自动高度 1080px 的 2:1 视频如 3840×1920、8192×4096或文件内 VR 元数据、已知片商名都会自动识别为并排 VR检测模型换用内置的rfdetr-vr-v1认不出来时手动指定jasna --input input.mp4 --output output.mp4 --vr-mode sbs-fisheyeLTX 不支持 VR180 并排视频只能用 BasicVSR--vr-mode取值auto默认/off/sbs/sbs-fisheye投影方式原样/鱼眼/球心投影按片商自动选择也可在区间编辑器的修复预览旁手动切换云端 GPURunPod / Vast / Docker—— 本地显卡太慢或没有显卡租一张云 GPU 跑批量任务。向许可证码来源申请开通云权限后用 Linux NVIDIA 官方版 CLI 在容器内以root登录运行安装到/root不要用/workspace权限不可靠apt-get update apt-get install -y zstd wget libgl1 libglib2.0-0 # 从官方发布页下载 v0.11.1 的四个分卷包part000–part003拼合解压 cat jasna-linux-nvidia-0.11.1.tar.zst.part* | zstd -dc | tar -xpf - --same-owner cd jasna-linux-nvidia-0.11.1 export XDG_CONFIG_HOME/root/jasna-config ./jasna --license-code YOUR-LICENSE-CODE --cloud-workspace激活前可花一秒验证硬件编码器是否可用没打出OK就换机器./tools/ffmpeg -loglevel error -f lavfi -i testsrc2duration1:size1280x720 -c:v hevc_nvenc -f null - echo OK硬性要求驱动 ≥ 580、磁盘 ≥ 80 GB、设置NVIDIA_DRIVER_CAPABILITIESall不加则读不了也存不了视频、固定的/etc/machine-id--pidhost的 Docker 容器不可用RunPod 上 LTX 暂不可用会替换 root 用户导致 LTX 校验失败BasicVSR 可用每次启动前先重新export XDG_CONFIG_HOME删 Pod 前把jasna-config私有备份否则激活名额就浪费了 官方基准3.4–4.7 倍提速显存从 9.3 GB 降到 4.8 GB测试条件RTX 5090、Linux、BasicVSR、同一段 3:22 全长视频。输入Jasna v0.9.1 耗时Lada 0.11.0 耗时提速720p H.26400:3201:473.4 倍1080p H.26400:3402:023.6 倍2160p H.26401:0304:564.7 倍显存占用演变典型 / 峰值GBH.264 8-bit 输入版本720p1080p2160pLada1.8 / 3.12.0 / 3.32.6 / 4.1v0.4.117.6 / 19.918.9 / 21.426.0 / 30.5v0.5.08.6 / 9.09.5 / 10.212.9 / 15.0v0.9.08.6 / 9.19.3 / 10.111.4 / 15.4v0.9.14.2 / 4.64.8 / 5.67.2 / 10.9横向看v0.9.1 相对 Lada 在同硬件上把 1080p 整片修复压到约 1/3.6 的时间纵向看v0.9.1 相比自家旧版本把 1080p 典型显存从 9.3 GB 降到了 4.8 GB。完整测试设置、内存占用与全编解码器明细见 benchmarks/2026-07-26_release_matrix.md逐项提交的性能演进数据保留在benchmarks/目录的 CSV 中可用 scripts/benchmark_releases.py 复现。 踩坑速查看到什么、为什么、做什么症状根因动作首次任务卡在开头不动15–60 分钟的一次性 TensorRT 编译正常等待期间负载拉满且model_weights目录在增长升级时复制该目录到新版本即可免等启动即报路径错误安装路径混入非 ASCII 字符中文/日文/重音字母check_ascii_install_path拦截整个文件夹挪到纯英文路径顺带确认是本地盘、文件系统为 NTFS / ext4 / Btrfs / XFS / ZFS显存不足out of memory 或明显卡死剪辑太大、显存超了按顺序①--max-clip-size90→60→30 对照扫描表看每档代价② 关二次修复或换 RTX Super Res③ 关闭浏览器、游戏等其他占 GPU 程序。4–6 GB 显存的卡固定从 1080p 剪辑 30 起步驱动检查不通过 / 提示版本过低NVIDIA 需 Windows 610 / Linux 580AMD 需 Adrenalin 26.8.1Linux 另装 AMF升级后从头部菜单重新执行系统检查无需重装 JasnaAMD 上检测速度很慢RF-DETR 在 AMD 跑 torch 模型比 NVIDIA 的 TensorRT 引擎慢--detection-model lada-yolo-v4换速度默认批大小在 AMD 上自动取 8LTX 模型下载一直失败连不上 Hugging FaceJasna 会自动切 hf-mirror.com仍失败需手动手动下载 3 个文件所选模型 1 个 vae.safetensors.enc与vae-decoder.safetensors.enc文件名保留.enc后缀全部放入model_weights/ltx-restore/目录不存在就新建60 fps 素材处理时间翻倍帧数翻倍工作量自然翻倍用 --【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
