企业官网建设流程全解析

Jasna GUI 视频修复实战指南：从自检到激活的完整操作与避坑路线

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

Jasna 是一款开源的视频修复工具，GUI 版支持批量素材入队、实时修复预览、静态图片精修，并通过激活解锁 UNet 4x、SD 1.5、LTX 等支持者模型。这篇文章沿真实使用路线展开：先把安装位置装对让自检通过，再把素材喂进队列、定好输出命名，用播放器验证效果，静态图逐帧精修，出问题时按清单排查，最后激活支持者模型。每个约束都能在源码里定位到实现，出问题你知道往哪儿查。

🧩 安装位置与自检：Jasna 启动前要过的两道硬门槛

纯 ASCII 路径与本地磁盘两道闸门

启动向导之前，安装位置有两条硬性要求，装错自检直接判失败：

• 路径必须纯 ASCII：不允许中文、日文或带重音的字母。自检对安装目录做 ASCII 编码尝试，编码失败即判不合规（check_ascii_install_path，逻辑在 jasna/os_utils.py）。
• 只装本地磁盘：装在了机械盘上时，启动时install_on_hard_disk会判断磁盘类型（Windows 查驱动器寻道开销，Linux 读/sys的rotational标志），日志面板写一条hard_disk_warning警告——启动和加载模型都会明显变慢，建议迁到 SSD。

七项自检逐条过：查什么、失败会怎样

检查逻辑集中在 jasna/gui/system_checks.py，逐项结果：

注意sysmem是源码WARNING_ONLY_CHECKS中唯一的键：只有它失败时，底部按钮仍可点"开始使用"；其余任何一项失败，按钮就变成"退出"。

30 秒兜底超时：没跑完的项按失败算

检查在后台线程里跑，UI 每 100ms 轮询一次；驱动查询卡住或 torch 冷导入特别慢时，向导等 30 秒就放弃（_CHECKS_TIMEOUT_SECONDS = 30.0，见 jasna/gui/wizard.py），先展示已完成的项。

⚠️ 兜底超时后，未完成的检查项按失败处理而不是通过——这是evaluate_check_results的明确设计：宁可从未运行的检查读成失败，也不能显示红行却放行"开始使用"。看到红行别急着重试环境，先确认是不是检查卡住了。

自检结果按版本记录：每个版本首次启动才强制走一遍流程（get_system_check_passed_version对比__version__，见 jasna/gui/app.py），之后可随时手动重跑，见后文排错部分。装好跑通之后，素材怎么进队列？

📋 素材队列管理：三种添加方式、20 条分页与页内拖拽

添加文件、添加文件夹、拖文件三条入队路

把素材放进列表有三条路（实现在 jasna/gui/queue_panel.py）：点添加文件选视频或图片；点旁边的文件夹图标，整个文件夹一次丢进来（递归扫描，图片排前、视频排后）；直接把文件拖到列表上（基于 tkinterdnd2）。处理顺序就是从上到下：拖动每个条目的把手调整，但拖动只能在同一页内——列表超过 20 条时下方出现翻页箭头（分页常量_PAGE_SIZE = 20），跨页换顺序得先翻页再拖；正在处理中的条目禁止拖动。

队列条目的四个按钮各管什么

对单个条目（JobListItem，见 jasna/gui/job_list_item.py）：

• ✂️ 剪刀：打开区间编辑器，只修复视频里的一段（图片条目无此按钮）；
• ▶️ 播放：在内置播放器里打开该视频，快速瞄一眼原片；
• ⋮ 三点（或右键）：打开所在文件夹、复制路径、打开修复后的输出、重新加入队列（把已完成/失败/跳过的项目放回列表末尾）；
• ✕ 叉号：移除该项目。

开始按钮会处理列表中所有项目，包括已完成和失败的——改完设置后不用重新添加文件，直接再按 ▶ 即可。隐含限制：列表非空、没有模型在下载、修复预览没占用 GPU 时，开始按钮才可用。

停止之后，写到一半的输出文件去向

处理中每个条目实时刷出进度、FPS 和剩余时间。停止按钮结束本次处理后，当前条目回到等待中状态（_mark_stopped，逻辑在 jasna/gui/processor.py），已写入的半成品输出文件原样留在磁盘上。下次再跑时它按什么处理，取决于基本处理里的文件冲突策略——"跑一半就停"和"覆盖"同时开着时，注意别把上次的半成品当成品。

队列排好，下一步是定输出落盘的命名与冲突规则。

🎯 输出文件落地：命名模板、与输入相同联动与冲突三选一

{original}模板与保存位置联动

队列上方工具栏有两个联动控件：点与输入相同，每个结果保存在原文件旁边；手动输入文件夹路径或点文件夹按钮选别处，会自动关闭"与输入相同"，想回到原片旁再点一次即可。命名用模板，{original}代表输入文件名（不含扩展名），默认模板是{original}_restored.mp4（DEFAULT_OUTPUT_PATTERN，定义在 jasna/gui/models.py），所以my_video.mp4出片就是my_video_restored.mp4。替换逻辑很直白：folder_output_path里就是output_pattern.replace("{original}", 输入文件名)（逻辑在 jasna/media/media_files.py）。

关键体验：改保存位置或模板的瞬间，任何会覆盖其他文件的条目会立即被高亮标出，不用等跑完才发现重名。

文件冲突三种策略怎么选

文件冲突下拉框在基本处理部分（实现在 jasna/gui/settings_sections/basic.py）：

⚠️ 选"覆盖"前确认目标文件确实可以丢——这个选项没有撤销，界面给出的唯一防线就是那枚警告图标。

预设记住上次状态与"已修改"标记

不同画质的片子参数差很远，手动来回调很痛苦。设置面板上方的工具栏（见 jasna/gui/settings_panel.py）能把当前全部设置存成一个名字：建个"1080p 快速"，再建个"4K 最佳质量"，之后一键来回切。底层是PresetManager（jasna/gui/models.py）：get_last_selected()/set_last_selected()记录你最后一次用的预设，重启后自动恢复；手动改过设置后，面板会标记"已修改"，防止你以为还停在某个出厂预设上；出厂预设与用户预设分开管理，删出厂预设会被拒绝。

全局参数归预设管，但有一类例外只属于单个视频：在区间编辑器里设置的检测模型和检测阈值，只保存给当前这一个视频。队列条目通过JobItem.try_set_video_options单独记录这些按视频覆盖的值，且仅在状态为PENDING时生效。同一个列表里可以混放"高阈值粗检"和"低阈值精检"的视频，互不干扰。

不想产出文件、直接看效果时，走实时预览这条路。

🎞️ 实时预览：玩家器打开步骤与批量处理互斥的原因

打开玩家器的三步操作与硬互斥

点页眉里的视频播放器（_open_video_player，见 jasna/gui/app.py）：

1. 选检测模型、检测阈值，需要的话再选二次修复（RTX Super Res或UNet 4x；Topaz 在玩家器中不可用）；
2. 点选择视频挑片子；
3. 按播放。

⚠️ 玩家器和批量处理互斥：只要有项目在处理、或修复预览在跑，点"视频播放器"没反应，页眉按钮也会置灰。源码里就一句硬检查：self._preview_gpu_busy或处理器在跑时直接return。它是硬性约束，不是显示 bug。

快捷键：空格播放/暂停，左/右方向键前后跳转 30 秒（_SEEK_STEP_SECONDS = 30.0）；全屏时鼠标移到底部边缘，控制栏自动浮出。改了模型、阈值或二次修复后，会从当前位置重新播放（管线重建）。另外记住一条设计决定：播放器永远用 BasicVSR++，不走 LTX。

3 秒预缓冲，"秒数反复归零"意味着什么

状态栏显示已提前修复好的秒数：后台修复线程往带时间戳的帧缓冲里写帧，缓冲最多领先播放 3 秒（BUFFER_SECONDS = 3.0，上限BUFFER_FRAMES = 90），预滚 1.5 秒（PREROLL_SECONDS）后才真正开声，缓冲写满时后台修复暂停等待，实现见 jasna/gui/raw_player.py。

所以这个秒数反复掉到零，就是 GPU 在当前设置下追不上实时播放：画面卡等、音频暂停。

⚠️ 别怀疑软件坏了——此时换低一点的分辨率或模型档位再看，"秒数反复归零"就是界面给出的"当前设置跑不动实时"的最直接信号。

预览验证完参数，静态图就该逐张精修了。

🪄 静态图精修：单帧渲染为什么比整任务快一个数量级

左右对比视图：三种视图与换种子

在图像修复（静态图片）部分点交互式处理图片，打开一个左右对比视图（窗口实现在 jasna/gui/interactive_image_restore.py）：上一张 / 下一张逐张浏览；换种子立刻重新渲染出图；三种视图切换：原图、遮罩、结果；满意才点保存，只留你喜欢的。

同帧前向推理替代整条管线

为什么快？渲染在后台 worker 线程按单帧进行，帧已预先准备好，换种子只是同一帧上的一次前向推理——不像整任务那样把解码、修复、编码全走一遍。修图这种"多试几次参数"的场景，快一个数量级。

效果满意准备量产，或者中途出了问题，就按这份清单排查。

🛠️ 排错清单：从系统检查到日志导出按顺序过

第一步：重跑系统检查（按版本记录）

换了驱动、换了显卡、装了新 FFmpeg 之后，从页眉再次运行系统检查（_show_system_check）即可——检查按版本记录通过状态，决定某个版本要不要重新走流程。

⚠️ AMD 用户：系统检查还会查 AMF 视频运行库。Windows 上它随驱动自带，Linux 上需要手动安装一次（官方文档 docs/zh/gui.md 给出了安装命令），装完重启 Jasna 再查一次。

第二步：展开日志面板并导出

底部工具栏的日志按钮展开 LogPanel（jasna/gui/log_panel.py）：实时滚动，可按 debug / info / warning / error 过滤；导出保存最后5000 行（环形缓冲deque(maxlen=5000)，超出自动丢最旧的），写为.txt。反馈问题前先导出日志，基本能省掉一大轮"复现了吗"。

第三步：瞄一眼底部状态条

处理时底部状态条显示 GPU 利用率、显存、内存、CPU。数据来自read_system_stats（NVIDIA 解析nvidia-smi，AMD 读 sysfs），轮询线程每 1.5 秒采样一次。跑任务时瞄一眼这排数字，显存吃紧就该降档。

问题排完，最后一步是解锁支持者模型。

🔓 激活支持者模型：在线与手动两条路径及 3 台设备名额

在线激活与手动激活怎么操作

支持者模型（UNet 4x、SD 1.5、LTX）需要激活。页眉打开激活 Jasna（对话框在 jasna/gui/components.py），所有网络与验签操作都在后台线程执行（jasna/gui/activation_worker.py），不卡 UI。

• 在线激活（默认）：输入许可证码，点在线激活。上传的只有许可证码和机器密钥，之后 Jasna 完全离线工作；
• 手动激活（断网机器，或在线失败时）：
  1. 复制机器密钥（基于本机硬件生成）；
  2. 在任意联网设备打开激活页面（或点打开激活页面），填入机器密钥 + 许可证码；
  3. 拿到激活密钥粘贴回 Jasna，点激活。

3 台设备名额：哪些操作占名额

一个许可证码最多用于3 台电脑或云工作区（界面提示license_service_slots_full即"3 个名额全部占用"）。占名额：更换主板（Windows）、重新安装 Linux、个别没有真正主板 ID 的 Windows 机换系统盘。不占名额：重装 Windows、更换显卡 / 硬盘 / 内存、同一台机器重复激活——重新激活即可。已激活后打开该窗口会联网显示已用名额（如 2 / 3），查不到时重开窗口重试即可，修复功能不依赖这次查询。

密钥被拒：JW1-前缀与旧版密钥

按顺序过一遍：机器密钥是不是完整复制的？激活密钥有没有截断？密钥是不是为旧版 Jasna 生成的——旧版密钥不再通用，需回购买渠道换新密钥。

⚠️ 你手里的密钥是不是以JW1-开头？那是云端 CLI 专用身份密钥，GUI 直接粘贴会被明确拒绝（license_cloud_cli_only，见 jasna/gui/activation_worker.py)——请去正确的入口使用。

另外记住一条：激活密钥只包含你许可证码里购买的模型，不会顺带解锁其他支持者模型。

从安装位置到激活名额，这条路线可以收束成一句话：装对位置让自检一次通过，队列决定处理顺序，模板与冲突策略决定成片落点，预览和静态图窗口让效果在出文件前可见，日志、状态条与重跑自检是出问题时的三件工具，激活把支持者模型接进来。界面里的每个约束——分页、互斥、归零提示、名额校验——都能在源码里找到一一对应的实现。官方文档入口：docs/zh/gui.md。

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