企业官网建设流程全解析

RELEASE_SOURCES.md 深度解读：Jasna 发布包从 Git 提交到二进制的完整可核验链路

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

Jasna 是视频修复（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.0，pyproject.toml 第 7 行同步version = "0.12.0"；
• jasna/ltx/model_files.py 第 33 行_MODEL_BRANCHES = ("0.12.0",)，而 docs/en/development.md 说明 0.11.3 及更早发布沿用各自main分支 URL——版本推进与模型分支注册是发布流程的一部分；
• pyproject.toml 第 39 行 NVIDIA pin 已是torch==2.12.1+cu130，AMD extras 指向torch==2.14.0+rocm10.1.0（第 57 行），与 v0.11.1 发布时点未必相同。

这意味着清单是随发布快照冻结的：它锁定"那次构建用了什么"，而不是描述仓库主干现状。验证方法只有两步：对照 git tagv0.11.1与文档记录的输入逐一取差集；再检查pyproject.toml、jasna/__init__.py、git tag、RELEASE_SOURCES.md四处是否同版本，任何一处不一致即说明清单落后于构建。

维度二：第三方依赖的来源分类

分类的关键不是版本号，而是依赖相对上游被修改了多少——未修改的才能直接对标上游 tag，fork 与补丁必须给出各自的精确锚点：

VALI 一行最值得展开：pyproject.toml 第 49-52 行注释写明"VALI 解码后端需要容错 fork（codeberg.org/Kruk2/vali，DecodeSingleSurfaceAsyncDetailed）；使用官方 PyPI wheel 时读取器在打开时回退到 PyAV；发布构建在keytool/wheels/的 fork wheel 之上安装此 pin"。所以发布版实际链接的是 fork wheel，4.8.8只是 PyPI 基线占位。

mmengine 补丁（patches/fix_loading_mmengine_weights_on_torch26_and_higher.diff）改四处：torch.load加weights_only=True（第 8 行）；mmengine/dist/dist.py加from __future__ import annotations；model/__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_location='cpu', logger=logger)。链路是 mmengine 0.10.7 + 补丁 + 发布版受限加载策略 → BasicVSR++ 权重安全加载；pyproject.toml 第 27-28 行对ultralytics>=8.4.96,<8.5的注释（"旧版本无法在发布版受限加载策略下重建 YOLO 检查点"）说明同一条策略还管着 YOLO 检查点。

维度三：原生库与工具链的双构建源，及 GPL 许可证推论链

核心事实：Linux 发布包里有两套 FFmpeg，构建来源完全不同，不能默认同源：

GPLv3 推论的链条是：

1. pyav-ffmpeg 构建脚本请求 x264/x265 与--enable-version3；
2. wheel 内置并链接了 GPL 许可的 x264 库；
3. 因此 Jasna 将 PyAV/VALI 的组合 wheel 负载（combined wheel payload）按 GPLv3 分发；
4. 而 FFmpeg 自身运行时元数据把库标识为LGPLv3-or-later——同一 wheel 内存在两套许可证层级，assets/THIRD_PARTY_LICENSES.md 的 Bundled native components 表把这个推论固化为"GPLv3 for the combined payload; FFmpeg reports LGPLv3-or-later"，assets/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-debug；Windows 包用发布构建者选定的 GPLv3 FFmpeg 8 安装，若与 Linux 构建不同，发布前必须把ffmpeg -version输出、源码修订、configure 行与归档哈希补进发布说明。

维度四：构建环境与输入哈希的可核验锚点

核心事实：Linux 发布版从官方源码归档构建 CPython 3.13.14，归档Python-3.13.14.tar.xz的 SHA-256 为639e43243c620a308f968213df9e00f2f8f62332f7adbaa7a7eeb9783057c690；assets/licenses/README.md 中Python-3.13.txt即 CPython 3.13 许可证文本，构成"解释器级"追溯闭环。

文档同时给出两份 FFmpeg 归档哈希，构成发布审计的完整输入集：

应用依赖与全部精确直接版本约束在 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源码，包装器吞掉OSError；torch.compile在二进制中改为进程内编译（worker 池会重新拉起 jasna 二进制），强制compile_threads = 1并基于 torch 版本重写codecache.torch_key；Triton 从triton_prebuilt/加载预编译 C 辅助模块。这解释了为什么对应表要区分"Windows 冻结收据"与"Linux 构建要求全新应用冻结"。

tests/test_public_source.py模拟"没有私有子模块的公开检出"，验证五类可观测行为：

1. protection_available()返回 False，jasna.protection.license_store不进入sys.modules，公开启动可正常导入；
2. CLI 的--help/--version正常输出；
3. --machine-key、--activation-key fake、--license-code fake以退出码 1 结束，stderr 含 "official Jasna release" 且断言不含Traceback；
4. open_tensors、LtxModelFiles.from_dir、SD 1.5 检查点读取、unet-4x 引擎编译全部抛ProtectionUnavailableError，在打开数据之前失败；
5. 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 试用模式用随机权重，不真正恢复视频。

NVIDIA（Linux）构建验证：

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.mp4

AMD（Windows，ROCm 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.0+rocm10.1.0" "torchvision[$D]==0.29.0a0+rocm10.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 四条：

1. pyproject.toml、jasna/__init__.py、git tag 与RELEASE_SOURCES.md同版本，且该文件必须与构建实际使用的 PyAV、VALI、FFmpeg、Python 及其他依赖修订一致；
2. 解包后的包必须含LICENSE、LICENSING.md、NOTICE、RELEASE_SOURCES.md、assets/THIRD_PARTY_*.md与licenses/；
3. 每个捆绑模型哈希匹配 assets/THIRD_PARTY_MODELS.md；
4. 每个分卷归档与其.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 独立下载归档重算哈希，按"自由工作流可复现、支持者二进制不可逐位复现"划定审计范围。

版本号只告诉你"这是什么时刻的 Jasna"，RELEASE_SOURCES.md才告诉你"这个 Jasna 由哪些可核验的输入拼装而成"。

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