Jasna 视频马赛克修复完整指南GPU 加速流水线、模型选型与排障实战【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是一款免费开源AGPL-3.0的 GPU 加速视频马赛克修复工具支持 NVIDIAGTX 16 系起与 AMDRX 7000/9000实验性把解码 → 检测 → 修复 → 编码整条链路放在 GPU 上完成并提供图形界面与命令行两种用法。本文按先跑通、再选型、后调优的顺序组织读完你就能独立完成第一个修复任务并知道每种配置在显存和耗时上各值多少。启动前核对与四步跑通第一个任务跑之前花一分钟核对下面四项任何一条不满足程序都会直接停在启动检查里检查逻辑见 jasna/gui/system_checks.py。核对项不满足时怎么办显卡NVIDIA GTX 16 系 / RTX 20 系及以上计算能力 ≥ 7.5或 AMD RX 7000/9000实验性GTX 10 系及更早不支持只能换机器驱动NVIDIA 需 Windows 610 / Linux 580AMD 需 Adrenalin 26.8.1Linux 另装 AMF 运行库升级驱动后从头部菜单重新跑系统检查无需重装 Jasna磁盘本地 SSDNTFS / ext4 / Btrfs / XFS / ZFS移到本地 SSD机械硬盘能跑但启动与加载明显变慢安装路径纯 ASCII不能含中文、日文、重音字母整个文件夹挪到D:\Tools\jasna这类英文路径校验由 jasna/os_utils.py 的check_ascii_install_path在每次启动时执行⚠️ 中文用户名下的C:\Users\张三\Downloads\jasna会直接报错退出这条最容易被忽略。GUI 最短路径4 步下载与系统、显卡匹配的版本包解压到纯英文路径启动Windows 双击jasna.exeLinux NVIDIA 运行jasna文件Linux AMD 先装 AMF 运行库再运行run_jasna_amd.sh把视频拖进队列或点添加文件保持默认设置点界面底部的▶等待完成。CLI 最短路径1 条命令jasna --input input.mp4 --output output.mkv图片输入自动走 SD 1.5 模型文件夹输入批量处理先图片后视频。⚠️ 首次任务需额外等 15–60 分钟仅此一次。NVIDIA 上 Jasna 会把检测模型和修复模型编译成专属于你的 GPU 的 TensorRT 引擎缓存位置由 jasna/engine_paths.py 的configure_torch_compile_cache配置期间关闭其他应用。编译产物存放在model_weights目录升级 Jasna 时把这个文件夹复制到新版本目录即可跳过等待。原理速览四段并行的 GPU 流水线整条流水线由 4 个并行线程循环驱动定义在 jasna/pipeline_threads.py压缩成四个阶段GPU 解码NVIDIA 走 NVDEC、AMD 走 AMF、软件解码兜底实现在 jasna/media/video_decoder.py 的_setup_nvdec_decoder/_setup_amf_decoder检测与跟踪默认模型rfdetr-v6常量DEFAULT_DETECTION_MODEL_NAME注册表在 jasna/mosaic/detection_registry.py逐帧找马赛克跟踪器沿时间轴把同一块马赛克归组为剪辑遇硬切镜头强制收尾见 jasna/tracking/clip_tracker.pyBasicVSR 修复每个剪辑按 256×256 的图像序列修复相邻剪辑刻意保留少量重叠避免接缝跳变合成与编码只替换马赛克区域其余像素原样保留混合掩码与缓冲在 jasna/blend_buffer.py音频默认直接复制仅容器装不下原音轨时才重编码判断逻辑在jasna/media/audio_utils.py的needs_audio_reencode。两条补充显存告急时 Jasna 自动把排队中的帧挪到系统内存、需要时搬回jasna/vram_offloader.py无需手动干预LTX 不走这条流水线它要把视频完整过四遍找马赛克、准备、扩散修复、保存慢得多但纹理更真实。修复模型选型与三档预设绝大多数视频用免费的BasicVSR就够只有对个别关键场景质感要求高、且显卡是 RTX 30/40/50 系8 GB 显存起时才上LTX静态图片自动走SD 1.5。维度BasicVSR默认LTXSD 1.5仅图片速度快很慢1 分钟 1080p 素材RTX 5090 约 1 分钟、RTX 2080 Ti 约 10 分钟单张数十秒级画质良好纹理更细腻自然实验性单张差异大GPU全部受支持显卡RTX 30/40/502080 Ti 仅验证过Linux 支持 Radeon RX 7000/9000 与 R9700Windows AMD 为测试版约 7 GB 显存费用免费支援者专属25 USD 档含 UNet 4x 与 SD 1.5支援者专属15 USD 档起模型文件随包附带需下载标准约 15 GB、快速模式约 9 GB、更高画质档每档再加约 13 GB约 6.9 GB首次询问后下载LTX 常用开关--restoration-model-name可选ltx标准/ltx-4step良好慢约 1.5 倍/ltx-8step高画质慢约 2.5 倍/ltx-undistilled顶级慢约 5 倍--ltx-fast仅 RTX 50 系快约 1.4 倍--ltx-trial无需模型和许可证即可实测速度不产出修复视频——决定上 LTX 前先跑一次。检测模型决定第 2 阶段找马赛克的效果阈值取自 jasna/mosaic/detection_registry.py模型名分辨率推荐阈值适用场景rfdetr-v6默认5760.35绝大多数视频拿不准就用它rfdetr-v6-large另下载7680.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-threshold0–1调整调低检得更多、调高检得更少。AMD 上 RF-DETR 明显慢于 NVIDIA检测是瓶颈就换lada-yolo-v4。调参对象主要是 BasicVSRLTX 自管内存核心变量就三个最大剪辑大小、时间重叠、交叉淡化合法性由 jasna/session_config.py 统一校验。够用的默认值--max-clip-size 90 --temporal-overlap 8交叉淡化默认开。默认值在 10 GB 级显存的卡上很宽裕。jasna --input input.mp4 --output output.mkv追求质量的--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再往下压。剪辑大小扫描数据1080p、重叠 8、RTX 5090趋势普适、绝对值因环境而异最大剪辑大小耗时显存3051 秒3.4 GB6040 秒3.7 GB9034 秒4.1 GB18035 秒5.0 GB36032 秒6.3 GB72033 秒8.0 GB小剪辑只会更慢重叠帧在每个剪辑里都要重复处理。交叉淡化复用的是已处理好的帧零额外开销保持默认开启。模型编译同理——关掉只省不到 0.5 GB 显存却让处理慢约 3 倍同素材对比编译 33 秒 / 5.0 GB vs 不编译 107 秒 / 4.6 GB几乎没有正当理由。⚠️ 时间重叠必须满足2 × temporal_overlap max_clip_size否则启动即报错8–20 是推荐区间超过 20 通常无收益。核心参数速查以jasna --help为准选项默认值作用--devicecuda:0GPU 选择AMD 经 ROCm 也用cuda:N命名--batch-size4AMD 为 8检测批大小rfdetr-v5恒为 4--fp16/--no-fp16开半精度计算省显存且通常更快--max-clip-size90单次修复帧数上限--temporal-overlap8相邻剪辑共享帧数隐藏接缝--detection-score-threshold按模型自动检测阈值0–1--denoisenonelow/medium/high只清理修复区域--codec/--cqhevcNVIDIA HEVC 28 / AMD HEVC 25编解码器与质量CQ 越低质量越高文件越大--sharpen00 关闭 ~ 1 最强0.2–0.5温和--ltx-seed20260923LTX 随机种子同种子同结果--retarget-high-fps关60 → 30、59.94 → 29.97 隔帧处理CQ 合法范围NVIDIA H.264/HEVC 为 1–51、AV1 为 1–63AMD H.264/HEVC 为 0–51、AV1 为 1–51。Jasna 还会按源码率自动给输出设maxratebufsize为其 2 倍防止低码率源被过度放大自行指定maxrate可覆盖。二次修复只在修复块看起来软时大马赛克、特写、4K才有必要。三个选项UNet 4x支援者专属质量接近 TVAIiris-2且更快、RTX Super Res免费、极快个别视频会闪、Topaz TVAI需付费 Topaz Video仅 Windows。1080p 实测耗时 / 显存二次修复CAWD 1080pKV-109 1080p无22 秒 / 10.0 GB11 秒 / 10.7 GBUNet 4x29 秒 / 12.5 GB14 秒 / 12.6 GBRTX Super Res25 秒 / 11.7 GB13 秒 / 11.4 GBTVAI2 workersiris-252 秒 / 12.1 GB24 秒 / 12.4 GB进阶场景手册区间处理只修要修的地方适用边界马赛克只出现在部分场景时用或想用 LTX 但嫌慢只对关键片段用 LTX。未选中的区间原样复制速度快且画质无损输出仍是全片长视频。马赛克遍布全片时别用直接整片跑更快。最小操作GUI 里点队列条目的剪刀按钮打开区间编辑器按帧选区间、逐区间指定 BasicVSR 或 LTX能开修复预览、用内置马赛克扫描自动定位RTX 5090 上约 2000 FPS、用仅大马赛克用 LTX建议从 12% 起步把慢速 LTX 只集中在大马赛克上。CLI 直接给时间区间秒或HH:MM:SS.sjasna --input input.mp4 --output output.mp4 --segments 10-25,01:10-01:30.5文件夹批量自动分配用--ltx-auto-split 12大马赛克走 LTX、其余走 BasicVSR。已知代价与坑一次只能处理单个视频输入须为恒定帧率的 H.264/HEVC/AV1输出 MP4/MOV/MKV输出编解码器恒等于输入不能与--stream、--retarget-high-fps、--fmp4、--ltx-auto-split组合区间边界处的少量帧会被重新编码。磁盘紧张时用--working-directory把临时文件指到更快的盘。浏览器 / Stash 流媒体边修边看适用边界想先确认效果不落盘或挂在 Stash 里按需修复时用。正式交付文件别用流媒体它恒用 BasicVSR 与 H.264LTX 不可用。最小操作jasna --stream启动 HLS 服务并自动打开浏览器播放器可拖动进度--stream-port默认 8765、--stream-segment-duration默认 4.0 秒、--no-browser可调。Stash 需下载专用版本并设置JASNA_CLI_PATH与JASNA_WORKING_DIR两个环境变量。已知代价与坑⚠️ 首次必须先用 Stash 里实际会用的相同设置流式跑通一个短视频——第一次要为 GPU 准备文件、耗时很长跳过这步 Stash 会超时放弃日志出现timeout waiting for jasna-cli to become healthy就是这个原因。VR180 视频拆开修再拼回适用边界VR180 文件通常把左右眼并排放进一个宽帧Jasna 会拆开分别修复再拼回。注意 LTX 不支持 VR180 并排视频只能用 BasicVSR。最小操作保持VR180 模式 自动高度 1080px 的 2:1 视频如 3840×1920或文件内 VR 元数据都会自动识别为并排 VR检测模型换用内置的rfdetr-vr-v1。自动认不出来时手动指定jasna --input input.mp4 --output output.mp4 --vr-mode sbs-fisheye--vr-mode取值auto默认/off/sbs/sbs-fisheye投影方式原样/鱼眼/球心投影按片商自动选择。已知代价与坑8K VR 素材耗时约翻倍基准8K VR HEVC 60 fps 在 RTX 5090 上约 34.5 秒 / 1080p 3:22 素材 38.6 秒显存占用也升到约 17.5 GB8 GB 显存跑 8K VR 会紧张。排障速查表现象第一判断解决办法首次任务卡在开头不动一次性 TensorRT 编译15–60 分钟等待期间model_weights目录在增长即为正常升级时复制该目录免等启动就报路径错误安装路径混入非 ASCII 字符check_ascii_install_path拦截整个文件夹挪到纯英文路径顺带确认磁盘是本地盘显存不足OOM 或明显卡死最大剪辑大小超出显存按 90 → 60 → 30 降档对照上表看每档代价再关二次修复或换 RTX Super Res最后关浏览器、游戏等占 GPU 的程序驱动检查不通过驱动版本低于要求升到 Windows 610 / Linux 580NVIDIA或 Adrenalin 26.8.1AMDLinux 另装 AMF头部菜单重跑系统检查AMD 上检测速度慢RF-DETR 走 torch 后端慢于 NVIDIA 的 TensorRT 引擎--detection-model换lada-yolo-v4AMD 默认批大小自动取 8LTX 模型下载一直失败连不上 Hugging Face自动切 hf-mirror.com 后仍失败就手动下载 3 个文件所选模型 1 个 vae.safetensors.enc与vae-decoder.safetensors.enc保留.enc后缀放入model_weights/ltx-restore/60 fps 素材处理时间翻倍帧数翻倍工作量自然翻倍--retarget-high-fps隔帧处理60 → 30处理量减半且音画同步不变不能与--segments、--stream组合云端机器报Failed to open hevc encoder该机器硬件编码器损坏直接换机器unsigned or modified Jasna runtime则是非 root 解压导致换 root 重新解压到/root官方基准耗时与显存数据测试条件RTX 5090、Linux、BasicVSR、同一段 3:22 全长视频时间越短越好。输入Lada 0.11.0Jasna v0.9.1720p H.26401:4700:32快 3.4 倍1080p H.26402:0200:34快 3.6 倍2160p H.26404:5601:03快 4.7 倍GPU 显存典型 / 峰值GB输入Ladav0.4.1v0.5.0v0.9.0v0.9.1720p H.264 8-bit1.8 / 3.117.6 / 19.98.6 / 9.08.6 / 9.14.2 / 4.61080p H.264 8-bit2.0 / 3.318.9 / 21.49.5 / 10.29.3 / 10.14.8 / 5.62160p H.264 8-bit2.6 / 4.126.0 / 30.512.9 / 15.011.4 / 15.47.2 / 10.9一句话结论Jasna v0.9.1 在同硬件上把 1080p 整片修复压到 Lada 的约 1/3.6 时间同时把 1080p 显存从 9.3 GB 降到 4.8 GB典型值。完整测试设置与全编解码器明细见 benchmarks/2026-07-26_release_matrix.md可用 scripts/benchmark_releases.py 复现。许可与延伸阅读确认好显卡与路径、熬过一次 15–60 分钟的编译剩下的就是按本文三档配置对号入座的事。许可公开应用源码为 AGPL-3.0模型与随附依赖各自保留原许可证详见 LICENSING.md、assets/THIRD_PARTY_LICENSES.md 与 assets/THIRD_PARTY_MODELS.md从源码运行可使用免费 BasicVSRLTX 与支援者模型需官方发行版与许可证码。延伸阅读docs/zh/models.md模型选型与 LTX 手动下载、docs/zh/tuning.md显存调优、docs/zh/segments.md区间处理、docs/zh/cli.md全量 CLI 选项、docs/zh/streaming.md 与 docs/zh/cloud.md。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jasna 视频马赛克修复完整指南GPU 加速流水线、模型选型与排障实战【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是一款免费开源AGPL-3.0的 GPU 加速视频马赛克修复工具支持 NVIDIAGTX 16 系起与 AMDRX 7000/9000实验性把解码 → 检测 → 修复 → 编码整条链路放在 GPU 上完成并提供图形界面与命令行两种用法。本文按先跑通、再选型、后调优的顺序组织读完你就能独立完成第一个修复任务并知道每种配置在显存和耗时上各值多少。启动前核对与四步跑通第一个任务跑之前花一分钟核对下面四项任何一条不满足程序都会直接停在启动检查里检查逻辑见 jasna/gui/system_checks.py。核对项不满足时怎么办显卡NVIDIA GTX 16 系 / RTX 20 系及以上计算能力 ≥ 7.5或 AMD RX 7000/9000实验性GTX 10 系及更早不支持只能换机器驱动NVIDIA 需 Windows 610 / Linux 580AMD 需 Adrenalin 26.8.1Linux 另装 AMF 运行库升级驱动后从头部菜单重新跑系统检查无需重装 Jasna磁盘本地 SSDNTFS / ext4 / Btrfs / XFS / ZFS移到本地 SSD机械硬盘能跑但启动与加载明显变慢安装路径纯 ASCII不能含中文、日文、重音字母整个文件夹挪到D:\Tools\jasna这类英文路径校验由 jasna/os_utils.py 的check_ascii_install_path在每次启动时执行⚠️ 中文用户名下的C:\Users\张三\Downloads\jasna会直接报错退出这条最容易被忽略。GUI 最短路径4 步下载与系统、显卡匹配的版本包解压到纯英文路径启动Windows 双击jasna.exeLinux NVIDIA 运行jasna文件Linux AMD 先装 AMF 运行库再运行run_jasna_amd.sh把视频拖进队列或点添加文件保持默认设置点界面底部的▶等待完成。CLI 最短路径1 条命令jasna --input input.mp4 --output output.mkv图片输入自动走 SD 1.5 模型文件夹输入批量处理先图片后视频。⚠️ 首次任务需额外等 15–60 分钟仅此一次。NVIDIA 上 Jasna 会把检测模型和修复模型编译成专属于你的 GPU 的 TensorRT 引擎缓存位置由 jasna/engine_paths.py 的configure_torch_compile_cache配置期间关闭其他应用。编译产物存放在model_weights目录升级 Jasna 时把这个文件夹复制到新版本目录即可跳过等待。原理速览四段并行的 GPU 流水线整条流水线由 4 个并行线程循环驱动定义在 jasna/pipeline_threads.py压缩成四个阶段GPU 解码NVIDIA 走 NVDEC、AMD 走 AMF、软件解码兜底实现在 jasna/media/video_decoder.py 的_setup_nvdec_decoder/_setup_amf_decoder检测与跟踪默认模型rfdetr-v6常量DEFAULT_DETECTION_MODEL_NAME注册表在 jasna/mosaic/detection_registry.py逐帧找马赛克跟踪器沿时间轴把同一块马赛克归组为剪辑遇硬切镜头强制收尾见 jasna/tracking/clip_tracker.pyBasicVSR 修复每个剪辑按 256×256 的图像序列修复相邻剪辑刻意保留少量重叠避免接缝跳变合成与编码只替换马赛克区域其余像素原样保留混合掩码与缓冲在 jasna/blend_buffer.py音频默认直接复制仅容器装不下原音轨时才重编码判断逻辑在jasna/media/audio_utils.py的needs_audio_reencode。两条补充显存告急时 Jasna 自动把排队中的帧挪到系统内存、需要时搬回jasna/vram_offloader.py无需手动干预LTX 不走这条流水线它要把视频完整过四遍找马赛克、准备、扩散修复、保存慢得多但纹理更真实。修复模型选型与三档预设绝大多数视频用免费的BasicVSR就够只有对个别关键场景质感要求高、且显卡是 RTX 30/40/50 系8 GB 显存起时才上LTX静态图片自动走SD 1.5。维度BasicVSR默认LTXSD 1.5仅图片速度快很慢1 分钟 1080p 素材RTX 5090 约 1 分钟、RTX 2080 Ti 约 10 分钟单张数十秒级画质良好纹理更细腻自然实验性单张差异大GPU全部受支持显卡RTX 30/40/502080 Ti 仅验证过Linux 支持 Radeon RX 7000/9000 与 R9700Windows AMD 为测试版约 7 GB 显存费用免费支援者专属25 USD 档含 UNet 4x 与 SD 1.5支援者专属15 USD 档起模型文件随包附带需下载标准约 15 GB、快速模式约 9 GB、更高画质档每档再加约 13 GB约 6.9 GB首次询问后下载LTX 常用开关--restoration-model-name可选ltx标准/ltx-4step良好慢约 1.5 倍/ltx-8step高画质慢约 2.5 倍/ltx-undistilled顶级慢约 5 倍--ltx-fast仅 RTX 50 系快约 1.4 倍--ltx-trial无需模型和许可证即可实测速度不产出修复视频——决定上 LTX 前先跑一次。检测模型决定第 2 阶段找马赛克的效果阈值取自 jasna/mosaic/detection_registry.py模型名分辨率推荐阈值适用场景rfdetr-v6默认5760.35绝大多数视频拿不准就用它rfdetr-v6-large另下载7680.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-threshold0–1调整调低检得更多、调高检得更少。AMD 上 RF-DETR 明显慢于 NVIDIA检测是瓶颈就换lada-yolo-v4。调参对象主要是 BasicVSRLTX 自管内存核心变量就三个最大剪辑大小、时间重叠、交叉淡化合法性由 jasna/session_config.py 统一校验。够用的默认值--max-clip-size 90 --temporal-overlap 8交叉淡化默认开。默认值在 10 GB 级显存的卡上很宽裕。jasna --input input.mp4 --output output.mkv追求质量的--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再往下压。剪辑大小扫描数据1080p、重叠 8、RTX 5090趋势普适、绝对值因环境而异最大剪辑大小耗时显存3051 秒3.4 GB6040 秒3.7 GB9034 秒4.1 GB18035 秒5.0 GB36032 秒6.3 GB72033 秒8.0 GB小剪辑只会更慢重叠帧在每个剪辑里都要重复处理。交叉淡化复用的是已处理好的帧零额外开销保持默认开启。模型编译同理——关掉只省不到 0.5 GB 显存却让处理慢约 3 倍同素材对比编译 33 秒 / 5.0 GB vs 不编译 107 秒 / 4.6 GB几乎没有正当理由。⚠️ 时间重叠必须满足2 × temporal_overlap max_clip_size否则启动即报错8–20 是推荐区间超过 20 通常无收益。核心参数速查以jasna --help为准选项默认值作用--devicecuda:0GPU 选择AMD 经 ROCm 也用cuda:N命名--batch-size4AMD 为 8检测批大小rfdetr-v5恒为 4--fp16/--no-fp16开半精度计算省显存且通常更快--max-clip-size90单次修复帧数上限--temporal-overlap8相邻剪辑共享帧数隐藏接缝--detection-score-threshold按模型自动检测阈值0–1--denoisenonelow/medium/high只清理修复区域--codec/--cqhevcNVIDIA HEVC 28 / AMD HEVC 25编解码器与质量CQ 越低质量越高文件越大--sharpen00 关闭 ~ 1 最强0.2–0.5温和--ltx-seed20260923LTX 随机种子同种子同结果--retarget-high-fps关60 → 30、59.94 → 29.97 隔帧处理CQ 合法范围NVIDIA H.264/HEVC 为 1–51、AV1 为 1–63AMD H.264/HEVC 为 0–51、AV1 为 1–51。Jasna 还会按源码率自动给输出设maxratebufsize为其 2 倍防止低码率源被过度放大自行指定maxrate可覆盖。二次修复只在修复块看起来软时大马赛克、特写、4K才有必要。三个选项UNet 4x支援者专属质量接近 TVAIiris-2且更快、RTX Super Res免费、极快个别视频会闪、Topaz TVAI需付费 Topaz Video仅 Windows。1080p 实测耗时 / 显存二次修复CAWD 1080pKV-109 1080p无22 秒 / 10.0 GB11 秒 / 10.7 GBUNet 4x29 秒 / 12.5 GB14 秒 / 12.6 GBRTX Super Res25 秒 / 11.7 GB13 秒 / 11.4 GBTVAI2 workersiris-252 秒 / 12.1 GB24 秒 / 12.4 GB进阶场景手册区间处理只修要修的地方适用边界马赛克只出现在部分场景时用或想用 LTX 但嫌慢只对关键片段用 LTX。未选中的区间原样复制速度快且画质无损输出仍是全片长视频。马赛克遍布全片时别用直接整片跑更快。最小操作GUI 里点队列条目的剪刀按钮打开区间编辑器按帧选区间、逐区间指定 BasicVSR 或 LTX能开修复预览、用内置马赛克扫描自动定位RTX 5090 上约 2000 FPS、用仅大马赛克用 LTX建议从 12% 起步把慢速 LTX 只集中在大马赛克上。CLI 直接给时间区间秒或HH:MM:SS.sjasna --input input.mp4 --output output.mp4 --segments 10-25,01:10-01:30.5文件夹批量自动分配用--ltx-auto-split 12大马赛克走 LTX、其余走 BasicVSR。已知代价与坑一次只能处理单个视频输入须为恒定帧率的 H.264/HEVC/AV1输出 MP4/MOV/MKV输出编解码器恒等于输入不能与--stream、--retarget-high-fps、--fmp4、--ltx-auto-split组合区间边界处的少量帧会被重新编码。磁盘紧张时用--working-directory把临时文件指到更快的盘。浏览器 / Stash 流媒体边修边看适用边界想先确认效果不落盘或挂在 Stash 里按需修复时用。正式交付文件别用流媒体它恒用 BasicVSR 与 H.264LTX 不可用。最小操作jasna --stream启动 HLS 服务并自动打开浏览器播放器可拖动进度--stream-port默认 8765、--stream-segment-duration默认 4.0 秒、--no-browser可调。Stash 需下载专用版本并设置JASNA_CLI_PATH与JASNA_WORKING_DIR两个环境变量。已知代价与坑⚠️ 首次必须先用 Stash 里实际会用的相同设置流式跑通一个短视频——第一次要为 GPU 准备文件、耗时很长跳过这步 Stash 会超时放弃日志出现timeout waiting for jasna-cli to become healthy就是这个原因。VR180 视频拆开修再拼回适用边界VR180 文件通常把左右眼并排放进一个宽帧Jasna 会拆开分别修复再拼回。注意 LTX 不支持 VR180 并排视频只能用 BasicVSR。最小操作保持VR180 模式 自动高度 1080px 的 2:1 视频如 3840×1920或文件内 VR 元数据都会自动识别为并排 VR检测模型换用内置的rfdetr-vr-v1。自动认不出来时手动指定jasna --input input.mp4 --output output.mp4 --vr-mode sbs-fisheye--vr-mode取值auto默认/off/sbs/sbs-fisheye投影方式原样/鱼眼/球心投影按片商自动选择。已知代价与坑8K VR 素材耗时约翻倍基准8K VR HEVC 60 fps 在 RTX 5090 上约 34.5 秒 / 1080p 3:22 素材 38.6 秒显存占用也升到约 17.5 GB8 GB 显存跑 8K VR 会紧张。排障速查表现象第一判断解决办法首次任务卡在开头不动一次性 TensorRT 编译15–60 分钟等待期间model_weights目录在增长即为正常升级时复制该目录免等启动就报路径错误安装路径混入非 ASCII 字符check_ascii_install_path拦截整个文件夹挪到纯英文路径顺带确认磁盘是本地盘显存不足OOM 或明显卡死最大剪辑大小超出显存按 90 → 60 → 30 降档对照上表看每档代价再关二次修复或换 RTX Super Res最后关浏览器、游戏等占 GPU 的程序驱动检查不通过驱动版本低于要求升到 Windows 610 / Linux 580NVIDIA或 Adrenalin 26.8.1AMDLinux 另装 AMF头部菜单重跑系统检查AMD 上检测速度慢RF-DETR 走 torch 后端慢于 NVIDIA 的 TensorRT 引擎--detection-model换lada-yolo-v4AMD 默认批大小自动取 8LTX 模型下载一直失败连不上 Hugging Face自动切 hf-mirror.com 后仍失败就手动下载 3 个文件所选模型 1 个 vae.safetensors.enc与vae-decoder.safetensors.enc保留.enc后缀放入model_weights/ltx-restore/60 fps 素材处理时间翻倍帧数翻倍工作量自然翻倍--retarget-high-fps隔帧处理60 → 30处理量减半且音画同步不变不能与--segments、--stream组合云端机器报Failed to open hevc encoder该机器硬件编码器损坏直接换机器unsigned or modified Jasna runtime则是非 root 解压导致换 root 重新解压到/root官方基准耗时与显存数据测试条件RTX 5090、Linux、BasicVSR、同一段 3:22 全长视频时间越短越好。输入Lada 0.11.0Jasna v0.9.1720p H.26401:4700:32快 3.4 倍1080p H.26402:0200:34快 3.6 倍2160p H.26404:5601:03快 4.7 倍GPU 显存典型 / 峰值GB输入Ladav0.4.1v0.5.0v0.9.0v0.9.1720p H.264 8-bit1.8 / 3.117.6 / 19.98.6 / 9.08.6 / 9.14.2 / 4.61080p H.264 8-bit2.0 / 3.318.9 / 21.49.5 / 10.29.3 / 10.14.8 / 5.62160p H.264 8-bit2.6 / 4.126.0 / 30.512.9 / 15.011.4 / 15.47.2 / 10.9一句话结论Jasna v0.9.1 在同硬件上把 1080p 整片修复压到 Lada 的约 1/3.6 时间同时把 1080p 显存从 9.3 GB 降到 4.8 GB典型值。完整测试设置与全编解码器明细见 benchmarks/2026-07-26_release_matrix.md可用 scripts/benchmark_releases.py 复现。许可与延伸阅读确认好显卡与路径、熬过一次 15–60 分钟的编译剩下的就是按本文三档配置对号入座的事。许可公开应用源码为 AGPL-3.0模型与随附依赖各自保留原许可证详见 LICENSING.md、assets/THIRD_PARTY_LICENSES.md 与 assets/THIRD_PARTY_MODELS.md从源码运行可使用免费 BasicVSRLTX 与支援者模型需官方发行版与许可证码。延伸阅读docs/zh/models.md模型选型与 LTX 手动下载、docs/zh/tuning.md显存调优、docs/zh/segments.md区间处理、docs/zh/cli.md全量 CLI 选项、docs/zh/streaming.md 与 docs/zh/cloud.md。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
