RELEASE_SOURCES.md 深度解读Jasna 发布包从 Git 提交到二进制的完整可核验链路【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是视频修复video restoration工具官方发布包内置自带 Python/Tk 运行时、FFmpeg 与 FFprobe 及多套第三方原生组件。RELEASE_SOURCES.md是 v0.11.1 发布包的源码对应表source correspondence记录每个输入组件的精确修订、归档哈希与许可证边界。读完后你会拿到一套从 Git 提交追踪到二进制产物的核验方法能判断这个可执行文件到底由哪些源码拼装而成。一、为什么单靠版本号不够一个二进制只印着v0.11.1无法表达它内部由五类输入混合而成Jasna 公共应用源码基础版本 native-LTX 延续改动私有保护组件源码不发布被修改或打补丁的第三方依赖PyAV、VALI fork、mmengine 补丁两套互不相同的 FFmpeg 构建wheel 内嵌库 vs 内置命令行工具构建环境CPython 源码归档与工具链。文档开篇就声明不要仅凭版本号推断二进制对应关系Do not infer binary correspondence from the version number alone。构建收据build receipts标识精确的原生源码与工具链冻结收据freeze receipts标识冻结应用输入资质报告qualification reports把打包的可执行文件与原生库绑定到各自源码修订版。本文按核验维度逐项拆解这份清单的证据链。二、证据链拆解按核验维度组织维度一应用本体与基础 tag 的偏移量核心事实发布包 v0.11.1基础版本加 native-LTX 延续改动文档第一页明确Linux 与 Windows 的 native-LTX 延续包含超出v0.11.1tag 的改动精确打包输入记录在构建收据中。源码交叉印证jasna/init.py 第 3 行当前版本是0.12.0pyproject.toml 第 7 行同步version 0.12.0jasna/ltx/model_files.py 第 33 行_MODEL_BRANCHES (0.12.0,)而 docs/en/development.md 说明 0.11.3 及更早发布沿用各自main分支 URL——版本推进与模型分支注册是发布流程的一部分pyproject.toml 第 39 行 NVIDIA pin 已是torch2.12.1cu130AMD extras 指向torch2.14.0rocm10.1.0第 57 行与 v0.11.1 发布时点未必相同。这意味着清单是随发布快照冻结的它锁定那次构建用了什么而不是描述仓库主干现状。验证方法只有两步对照 git tagv0.11.1与文档记录的输入逐一取差集再检查pyproject.toml、jasna/__init__.py、git tag、RELEASE_SOURCES.md四处是否同版本任何一处不一致即说明清单落后于构建。维度二第三方依赖的来源分类分类的关键不是版本号而是依赖相对上游被修改了多少——未修改的才能直接对标上游 tagfork 与补丁必须给出各自的精确锚点依赖修改状态文档记录的锚点pyproject.toml 中的 pinPyAV未修改tagv18.1.0commit7e3d950a8b72062502c1a60d672f8ca565313af5av18.1.0第 13 行VALIKruk2 公共 fork含 Jasna 解码定制commit0e5c01ee57222a8ef4f9c7591284c4324bb3fba5Apache-2.0python_vali4.8.8第 53 行仅基线RF-DETR未修改1.8.3/3bd6bffbcb13cac3a5b1c37da5a0fd5453b50c86rfdetr1.8.3第 61 行amd extrasmmengine仓库内补丁patches/fix_loading_mmengine_weights_on_torch26_and_higher.diffmmengine0.10.7第 20 行VALI 一行最值得展开pyproject.toml 第 49-52 行注释写明VALI 解码后端需要容错 forkcodeberg.org/Kruk2/valiDecodeSingleSurfaceAsyncDetailed使用官方 PyPI wheel 时读取器在打开时回退到 PyAV发布构建在keytool/wheels/的 fork wheel 之上安装此 pin。所以发布版实际链接的是 fork wheel4.8.8只是 PyPI 基线占位。mmengine 补丁patches/fix_loading_mmengine_weights_on_torch26_and_higher.diff改四处torch.load加weights_onlyTrue第 8 行mmengine/dist/dist.py加from __future__ import annotationsmodel/__init__.py与model/wrappers/__init__.py把MMFullyShardedDataParallel导出条件从torch ≥ 2.0改为≥ 2.0 且torch.distributed.is_available()第 33-34、50-51 行。消费点在 jasna/models/basicvsrpp/inference.py 第 59 行load_checkpoint(model, checkpoint_path, map_locationcpu, loggerlogger)。链路是 mmengine 0.10.7 补丁 发布版受限加载策略 → BasicVSR 权重安全加载pyproject.toml 第 27-28 行对ultralytics8.4.96,8.5的注释旧版本无法在发布版受限加载策略下重建 YOLO 检查点说明同一条策略还管着 YOLO 检查点。维度三原生库与工具链的双构建源及 GPL 许可证推论链核心事实Linux 发布包里有两套 FFmpeg构建来源完全不同不能默认同源位置构建来源FFmpeg 源码修订许可证推论PyAV / VALI wheel 内嵌库pyav-ffmpeg8.1.2-1tagn8.1.2commit38b88335f99e76ed89ff3c93f877fdefce736c13GPLv3组合负载内置ffmpeg/ffprobe工具BtbNlinux64-gpl-8.1构建ffmpeg-n8.1.2-34-g9b6c8969e0commit9b6c8969e05b4f0b29f0f85cd501be6b3e582e6btag 后 34 个提交构建显式启用 GPLGPLv3 推论的链条是pyav-ffmpeg 构建脚本请求 x264/x265 与--enable-version3wheel 内置并链接了 GPL 许可的 x264 库因此 Jasna 将 PyAV/VALI 的组合 wheel 负载combined wheel payload按 GPLv3 分发而 FFmpeg 自身运行时元数据把库标识为LGPLv3-or-later——同一 wheel 内存在两套许可证层级assets/THIRD_PARTY_LICENSES.md 的 Bundled native components 表把这个推论固化为GPLv3 for the combined payload; FFmpeg reports LGPLv3-or-laterassets/licenses/README.md 则列出对应文本GPL-3.0.txt覆盖 GPLv3 的 FFmpeg 库与命令行工具LGPL-3.0.txt覆盖 LGPL-3.0-or-later 的库代码BSD-3-Clause.txt覆盖 PyAV。注意n8.1.2-34-g9b6c8969e0的命名那是 8.1.2 tag之后34 个提交、HEAD 为9b6c8969e0的构建不是纯 n8.1.2 快照——这正是文档必须把精确 commit 写出来的原因。BtbN GPL 变体使用--enable-gpl --enable-version3 --disable-debugWindows 包用发布构建者选定的 GPLv3 FFmpeg 8 安装若与 Linux 构建不同发布前必须把ffmpeg -version输出、源码修订、configure 行与归档哈希补进发布说明。维度四构建环境与输入哈希的可核验锚点核心事实Linux 发布版从官方源码归档构建 CPython 3.13.14归档Python-3.13.14.tar.xz的 SHA-256 为639e43243c620a308f968213df9e00f2f8f62332f7adbaa7a7eeb9783057c690assets/licenses/README.md 中Python-3.13.txt即 CPython 3.13 许可证文本构成解释器级追溯闭环。文档同时给出两份 FFmpeg 归档哈希构成发布审计的完整输入集归档SHA-256ffmpeg-manylinux-x86_64.tar.gzpyav-ffmpeg 8.1.2-1665b4903251dc753725e9cf64615c1af7708b932fb26bf16356acc77d76e95f8ffmpeg-n8.1.2-34-g9b6c8969e0-linux64-gpl-8.1.tar.xzBtbN09fc77be269c7053e438b7e96548e4af97604faf96a42c4a3c56a1ad74c22c0a应用依赖与全部精确直接版本约束在 pyproject.toml二进制包还会把每个已安装 Python 发行版的许可证文件复制到licenses/python-packages/——这是完整许可证集的落地方式。验证方法独立下载三份归档重算 SHA-256 并与文档比对再核对ffmpeg -version输出哈希或版本行任一不符即构建输入发生过漂移。三、源码活证据文档声明 vs 实现行为jasna/media/video_decoder.py 的_ValiFrameSource构造时先检查vali.PyDecoder是否有DecodeSingleSurfaceAsyncDetailed方法缺失即抛VideoDecodeError并提示需要容错 fork——这是文档该 fork 包含 Jasna 解码定制声明的直接消费点。构造函数创建PyDecoder后立即解码第一帧整个构造就是 VALI 可用性检查VALI 无法处理的容器/编码在此抛出调用方不会提交到该后端此后的损坏包在 fork 内部跳过受连续包容差限制超限才抛错与 PyAV 路径行为一致。第 161-162 行把 I/O 超时设为_VALI_IO_TIMEOUT_MS 60000传给PyDecoder注释说明原因VALI 默认 3 秒中止 open/read对需要更长时间唤醒的休眠 HDD 不够。jasna/license_api.py 的protection_available()用find_spec检测jasna.protection并要求spec.origin非空——未初始化的 git 子模块只是空命名空间不算实现require_protection()缺失时抛ProtectionUnavailableError。pyproject.toml 的包发现规则exclude [jasna.protection.keytool*, jasna.protection.tests*]说明私有构建驱动不会进入公开 wheel。jasna/_frozen.py 处理冻结构建的真实工程问题torch import 时做源码内省inspect.getsource编译产物没有.py源码包装器吞掉OSErrortorch.compile在二进制中改为进程内编译worker 池会重新拉起 jasna 二进制强制compile_threads 1并基于 torch 版本重写codecache.torch_keyTriton 从triton_prebuilt/加载预编译 C 辅助模块。这解释了为什么对应表要区分Windows 冻结收据与Linux 构建要求全新应用冻结。tests/test_public_source.py模拟没有私有子模块的公开检出验证五类可观测行为protection_available()返回 Falsejasna.protection.license_store不进入sys.modules公开启动可正常导入CLI 的--help/--version正常输出--machine-key、--activation-key fake、--license-code fake以退出码 1 结束stderr 含 official Jasna release 且断言不含Tracebackopen_tensors、LtxModelFiles.from_dir、SD 1.5 检查点读取、unet-4x 引擎编译全部抛ProtectionUnavailableError在打开数据之前失败GUI 激活对话框保持禁用test_public_activation_dialog_stays_disabled。另有两个边界用例test_frozen_missing_protection_cannot_use_public_fallback确认sys.frozen环境下缺失私有模块如实报告不走公开回退tests/test_pyproject.py 参数化断言每个.fatbin/.hipfb都作为包数据发布与运行无需 GPU 编译器的声明一致。四、可复现性边界边界声明很直白公开 tag 含 Jasna 公共应用源码、公共补丁与上述对应关系但整应用构建驱动whole-application build driver与保护实现留在私有保护项目中。因此公开检出能复现自由工作流不能逐位复现启用支持者功能的官方可执行文件——这不是口头承诺tests/test_public_source.py的五个用例就是它的自动化证明。docs/en/development.md 划定了免费范围公开检出可运行 GUI、CLI 与免费 BasicVSR激活与加密的 unet-4x、SD 1.5、LTX 模型需要官方发布版LTX 试用模式用随机权重不真正恢复视频。NVIDIALinux构建验证uv venv --python /usr/bin/python3.13 --no-managed-python --no-python-downloads .venv source .venv/bin/activate uv pip install -e .[nvidia,dev] --extra-index-url https://download.pytorch.org/whl/cu130 python -m jasna --input in.mp4 --output out.mp4AMDWindowsROCm 10.1$I https://stable.repo.amd.com/rocm/whl-next/ $D device-gfx1100,...,device-gfx1201 pip install --index-url $I torch[$D]2.14.0rocm10.1.0 torchvision[$D]0.29.0a0rocm10.1.0 uv pip install -e .[amd,dev]装完用python -c import torch, torchvision; assert torch.version.hip; print(ROCm OK)确认 ROCm 生效保持完整版本后缀development.md第 88 行防止其他厂商的 wheel 满足 pin。jasna/media/*.cu已预编译进同目录.fatbin/.hipfb日常运行无需 CUDA 工具链改过.cu后用scripts/build_fatbins.sh重建。五、该文档在发布流程中的位置它是强制产物而非事后记录。docs/en/development.md 的 Release checklist 四条pyproject.toml、jasna/__init__.py、git tag 与RELEASE_SOURCES.md同版本且该文件必须与构建实际使用的 PyAV、VALI、FFmpeg、Python 及其他依赖修订一致解包后的包必须含LICENSE、LICENSING.md、NOTICE、RELEASE_SOURCES.md、assets/THIRD_PARTY_*.md与licenses/每个捆绑模型哈希匹配 assets/THIRD_PARTY_MODELS.md每个分卷归档与其.sha256文件一起上传。LICENSING.md 把精确的自定义依赖修订、FFmpeg 构建、补丁、模型哈希与源码链接全部指到RELEASE_SOURCES.md与两份第三方通知文件README.md 的 Licensing 一节同样以它作为发布源码对应的权威入口。六、分角色收束普通用户 把RELEASE_SOURCES.md与 assets/THIRD_PARTY_LICENSES.md、assets/THIRD_PARTY_MODELS.md 一起读即可确认每个原生组件与模型的精确来源、许可证与哈希。开发者/打包者 发布前逐项核对两个 FFmpeg 构建、VALI fork wheel 对 PyPI 基线的覆盖、Windowsffmpeg -version记录义务——清单第一检查项是四处版本号一致。审计者 用665b4903…、09fc77be…、639e4324…三个 SHA-256 独立下载归档重算哈希按自由工作流可复现、支持者二进制不可逐位复现划定审计范围。版本号只告诉你这是什么时刻的 JasnaRELEASE_SOURCES.md才告诉你这个 Jasna 由哪些可核验的输入拼装而成。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
RELEASE_SOURCES.md 深度解读Jasna 发布包从 Git 提交到二进制的完整可核验链路【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasnaJasna 是视频修复video restoration工具官方发布包内置自带 Python/Tk 运行时、FFmpeg 与 FFprobe 及多套第三方原生组件。RELEASE_SOURCES.md是 v0.11.1 发布包的源码对应表source correspondence记录每个输入组件的精确修订、归档哈希与许可证边界。读完后你会拿到一套从 Git 提交追踪到二进制产物的核验方法能判断这个可执行文件到底由哪些源码拼装而成。一、为什么单靠版本号不够一个二进制只印着v0.11.1无法表达它内部由五类输入混合而成Jasna 公共应用源码基础版本 native-LTX 延续改动私有保护组件源码不发布被修改或打补丁的第三方依赖PyAV、VALI fork、mmengine 补丁两套互不相同的 FFmpeg 构建wheel 内嵌库 vs 内置命令行工具构建环境CPython 源码归档与工具链。文档开篇就声明不要仅凭版本号推断二进制对应关系Do not infer binary correspondence from the version number alone。构建收据build receipts标识精确的原生源码与工具链冻结收据freeze receipts标识冻结应用输入资质报告qualification reports把打包的可执行文件与原生库绑定到各自源码修订版。本文按核验维度逐项拆解这份清单的证据链。二、证据链拆解按核验维度组织维度一应用本体与基础 tag 的偏移量核心事实发布包 v0.11.1基础版本加 native-LTX 延续改动文档第一页明确Linux 与 Windows 的 native-LTX 延续包含超出v0.11.1tag 的改动精确打包输入记录在构建收据中。源码交叉印证jasna/init.py 第 3 行当前版本是0.12.0pyproject.toml 第 7 行同步version 0.12.0jasna/ltx/model_files.py 第 33 行_MODEL_BRANCHES (0.12.0,)而 docs/en/development.md 说明 0.11.3 及更早发布沿用各自main分支 URL——版本推进与模型分支注册是发布流程的一部分pyproject.toml 第 39 行 NVIDIA pin 已是torch2.12.1cu130AMD extras 指向torch2.14.0rocm10.1.0第 57 行与 v0.11.1 发布时点未必相同。这意味着清单是随发布快照冻结的它锁定那次构建用了什么而不是描述仓库主干现状。验证方法只有两步对照 git tagv0.11.1与文档记录的输入逐一取差集再检查pyproject.toml、jasna/__init__.py、git tag、RELEASE_SOURCES.md四处是否同版本任何一处不一致即说明清单落后于构建。维度二第三方依赖的来源分类分类的关键不是版本号而是依赖相对上游被修改了多少——未修改的才能直接对标上游 tagfork 与补丁必须给出各自的精确锚点依赖修改状态文档记录的锚点pyproject.toml 中的 pinPyAV未修改tagv18.1.0commit7e3d950a8b72062502c1a60d672f8ca565313af5av18.1.0第 13 行VALIKruk2 公共 fork含 Jasna 解码定制commit0e5c01ee57222a8ef4f9c7591284c4324bb3fba5Apache-2.0python_vali4.8.8第 53 行仅基线RF-DETR未修改1.8.3/3bd6bffbcb13cac3a5b1c37da5a0fd5453b50c86rfdetr1.8.3第 61 行amd extrasmmengine仓库内补丁patches/fix_loading_mmengine_weights_on_torch26_and_higher.diffmmengine0.10.7第 20 行VALI 一行最值得展开pyproject.toml 第 49-52 行注释写明VALI 解码后端需要容错 forkcodeberg.org/Kruk2/valiDecodeSingleSurfaceAsyncDetailed使用官方 PyPI wheel 时读取器在打开时回退到 PyAV发布构建在keytool/wheels/的 fork wheel 之上安装此 pin。所以发布版实际链接的是 fork wheel4.8.8只是 PyPI 基线占位。mmengine 补丁patches/fix_loading_mmengine_weights_on_torch26_and_higher.diff改四处torch.load加weights_onlyTrue第 8 行mmengine/dist/dist.py加from __future__ import annotationsmodel/__init__.py与model/wrappers/__init__.py把MMFullyShardedDataParallel导出条件从torch ≥ 2.0改为≥ 2.0 且torch.distributed.is_available()第 33-34、50-51 行。消费点在 jasna/models/basicvsrpp/inference.py 第 59 行load_checkpoint(model, checkpoint_path, map_locationcpu, loggerlogger)。链路是 mmengine 0.10.7 补丁 发布版受限加载策略 → BasicVSR 权重安全加载pyproject.toml 第 27-28 行对ultralytics8.4.96,8.5的注释旧版本无法在发布版受限加载策略下重建 YOLO 检查点说明同一条策略还管着 YOLO 检查点。维度三原生库与工具链的双构建源及 GPL 许可证推论链核心事实Linux 发布包里有两套 FFmpeg构建来源完全不同不能默认同源位置构建来源FFmpeg 源码修订许可证推论PyAV / VALI wheel 内嵌库pyav-ffmpeg8.1.2-1tagn8.1.2commit38b88335f99e76ed89ff3c93f877fdefce736c13GPLv3组合负载内置ffmpeg/ffprobe工具BtbNlinux64-gpl-8.1构建ffmpeg-n8.1.2-34-g9b6c8969e0commit9b6c8969e05b4f0b29f0f85cd501be6b3e582e6btag 后 34 个提交构建显式启用 GPLGPLv3 推论的链条是pyav-ffmpeg 构建脚本请求 x264/x265 与--enable-version3wheel 内置并链接了 GPL 许可的 x264 库因此 Jasna 将 PyAV/VALI 的组合 wheel 负载combined wheel payload按 GPLv3 分发而 FFmpeg 自身运行时元数据把库标识为LGPLv3-or-later——同一 wheel 内存在两套许可证层级assets/THIRD_PARTY_LICENSES.md 的 Bundled native components 表把这个推论固化为GPLv3 for the combined payload; FFmpeg reports LGPLv3-or-laterassets/licenses/README.md 则列出对应文本GPL-3.0.txt覆盖 GPLv3 的 FFmpeg 库与命令行工具LGPL-3.0.txt覆盖 LGPL-3.0-or-later 的库代码BSD-3-Clause.txt覆盖 PyAV。注意n8.1.2-34-g9b6c8969e0的命名那是 8.1.2 tag之后34 个提交、HEAD 为9b6c8969e0的构建不是纯 n8.1.2 快照——这正是文档必须把精确 commit 写出来的原因。BtbN GPL 变体使用--enable-gpl --enable-version3 --disable-debugWindows 包用发布构建者选定的 GPLv3 FFmpeg 8 安装若与 Linux 构建不同发布前必须把ffmpeg -version输出、源码修订、configure 行与归档哈希补进发布说明。维度四构建环境与输入哈希的可核验锚点核心事实Linux 发布版从官方源码归档构建 CPython 3.13.14归档Python-3.13.14.tar.xz的 SHA-256 为639e43243c620a308f968213df9e00f2f8f62332f7adbaa7a7eeb9783057c690assets/licenses/README.md 中Python-3.13.txt即 CPython 3.13 许可证文本构成解释器级追溯闭环。文档同时给出两份 FFmpeg 归档哈希构成发布审计的完整输入集归档SHA-256ffmpeg-manylinux-x86_64.tar.gzpyav-ffmpeg 8.1.2-1665b4903251dc753725e9cf64615c1af7708b932fb26bf16356acc77d76e95f8ffmpeg-n8.1.2-34-g9b6c8969e0-linux64-gpl-8.1.tar.xzBtbN09fc77be269c7053e438b7e96548e4af97604faf96a42c4a3c56a1ad74c22c0a应用依赖与全部精确直接版本约束在 pyproject.toml二进制包还会把每个已安装 Python 发行版的许可证文件复制到licenses/python-packages/——这是完整许可证集的落地方式。验证方法独立下载三份归档重算 SHA-256 并与文档比对再核对ffmpeg -version输出哈希或版本行任一不符即构建输入发生过漂移。三、源码活证据文档声明 vs 实现行为jasna/media/video_decoder.py 的_ValiFrameSource构造时先检查vali.PyDecoder是否有DecodeSingleSurfaceAsyncDetailed方法缺失即抛VideoDecodeError并提示需要容错 fork——这是文档该 fork 包含 Jasna 解码定制声明的直接消费点。构造函数创建PyDecoder后立即解码第一帧整个构造就是 VALI 可用性检查VALI 无法处理的容器/编码在此抛出调用方不会提交到该后端此后的损坏包在 fork 内部跳过受连续包容差限制超限才抛错与 PyAV 路径行为一致。第 161-162 行把 I/O 超时设为_VALI_IO_TIMEOUT_MS 60000传给PyDecoder注释说明原因VALI 默认 3 秒中止 open/read对需要更长时间唤醒的休眠 HDD 不够。jasna/license_api.py 的protection_available()用find_spec检测jasna.protection并要求spec.origin非空——未初始化的 git 子模块只是空命名空间不算实现require_protection()缺失时抛ProtectionUnavailableError。pyproject.toml 的包发现规则exclude [jasna.protection.keytool*, jasna.protection.tests*]说明私有构建驱动不会进入公开 wheel。jasna/_frozen.py 处理冻结构建的真实工程问题torch import 时做源码内省inspect.getsource编译产物没有.py源码包装器吞掉OSErrortorch.compile在二进制中改为进程内编译worker 池会重新拉起 jasna 二进制强制compile_threads 1并基于 torch 版本重写codecache.torch_keyTriton 从triton_prebuilt/加载预编译 C 辅助模块。这解释了为什么对应表要区分Windows 冻结收据与Linux 构建要求全新应用冻结。tests/test_public_source.py模拟没有私有子模块的公开检出验证五类可观测行为protection_available()返回 Falsejasna.protection.license_store不进入sys.modules公开启动可正常导入CLI 的--help/--version正常输出--machine-key、--activation-key fake、--license-code fake以退出码 1 结束stderr 含 official Jasna release 且断言不含Tracebackopen_tensors、LtxModelFiles.from_dir、SD 1.5 检查点读取、unet-4x 引擎编译全部抛ProtectionUnavailableError在打开数据之前失败GUI 激活对话框保持禁用test_public_activation_dialog_stays_disabled。另有两个边界用例test_frozen_missing_protection_cannot_use_public_fallback确认sys.frozen环境下缺失私有模块如实报告不走公开回退tests/test_pyproject.py 参数化断言每个.fatbin/.hipfb都作为包数据发布与运行无需 GPU 编译器的声明一致。四、可复现性边界边界声明很直白公开 tag 含 Jasna 公共应用源码、公共补丁与上述对应关系但整应用构建驱动whole-application build driver与保护实现留在私有保护项目中。因此公开检出能复现自由工作流不能逐位复现启用支持者功能的官方可执行文件——这不是口头承诺tests/test_public_source.py的五个用例就是它的自动化证明。docs/en/development.md 划定了免费范围公开检出可运行 GUI、CLI 与免费 BasicVSR激活与加密的 unet-4x、SD 1.5、LTX 模型需要官方发布版LTX 试用模式用随机权重不真正恢复视频。NVIDIALinux构建验证uv venv --python /usr/bin/python3.13 --no-managed-python --no-python-downloads .venv source .venv/bin/activate uv pip install -e .[nvidia,dev] --extra-index-url https://download.pytorch.org/whl/cu130 python -m jasna --input in.mp4 --output out.mp4AMDWindowsROCm 10.1$I https://stable.repo.amd.com/rocm/whl-next/ $D device-gfx1100,...,device-gfx1201 pip install --index-url $I torch[$D]2.14.0rocm10.1.0 torchvision[$D]0.29.0a0rocm10.1.0 uv pip install -e .[amd,dev]装完用python -c import torch, torchvision; assert torch.version.hip; print(ROCm OK)确认 ROCm 生效保持完整版本后缀development.md第 88 行防止其他厂商的 wheel 满足 pin。jasna/media/*.cu已预编译进同目录.fatbin/.hipfb日常运行无需 CUDA 工具链改过.cu后用scripts/build_fatbins.sh重建。五、该文档在发布流程中的位置它是强制产物而非事后记录。docs/en/development.md 的 Release checklist 四条pyproject.toml、jasna/__init__.py、git tag 与RELEASE_SOURCES.md同版本且该文件必须与构建实际使用的 PyAV、VALI、FFmpeg、Python 及其他依赖修订一致解包后的包必须含LICENSE、LICENSING.md、NOTICE、RELEASE_SOURCES.md、assets/THIRD_PARTY_*.md与licenses/每个捆绑模型哈希匹配 assets/THIRD_PARTY_MODELS.md每个分卷归档与其.sha256文件一起上传。LICENSING.md 把精确的自定义依赖修订、FFmpeg 构建、补丁、模型哈希与源码链接全部指到RELEASE_SOURCES.md与两份第三方通知文件README.md 的 Licensing 一节同样以它作为发布源码对应的权威入口。六、分角色收束普通用户 把RELEASE_SOURCES.md与 assets/THIRD_PARTY_LICENSES.md、assets/THIRD_PARTY_MODELS.md 一起读即可确认每个原生组件与模型的精确来源、许可证与哈希。开发者/打包者 发布前逐项核对两个 FFmpeg 构建、VALI fork wheel 对 PyPI 基线的覆盖、Windowsffmpeg -version记录义务——清单第一检查项是四处版本号一致。审计者 用665b4903…、09fc77be…、639e4324…三个 SHA-256 独立下载归档重算哈希按自由工作流可复现、支持者二进制不可逐位复现划定审计范围。版本号只告诉你这是什么时刻的 JasnaRELEASE_SOURCES.md才告诉你这个 Jasna 由哪些可核验的输入拼装而成。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
