人工智能AI 应用计算机视觉视频处理图像处理深度学习【免费下载链接】jasnaVideo restoration tool项目地址https://gitcode.com/GitHub_Trending/ja/jasna点击查看免费下载本篇技术指南以 docs/en/development.md 为核心系统讲解视频修复工具Jasna从源码运行的全部开发环节NVIDIA 与 AMDROCm 10.0双平台环境搭建、GUI/CLI 启动与解码后端切换、pytest测试规范、jasna/media/*.cuCUDA 内核的 fatbin 预编译流程、发布级基准测试方法以及 LTX 原生 Transformer Block 的构建与发布检查清单。阅读本文后你将掌握如何搭建一个可运行 GUI、CLI 与免费 BasicVSR 修复流程的公开源码环境并理解其底层内核加载、原生扩展与版本发布机制。一、源码运行与发布包的分工Jasna 的公开源码仓库即当前仓库面向开发者。普通用户应直接下载发布包发布包自带完整的 Python/Tk 运行时、ffmpeg与ffprobe无需任何手工配置。从源码public checkout运行可以使用的功能包括GUIpython -m jasna与CLIpython -m jasna --input ...免费的BasicVSR视频修复模型。而以下能力依赖官方发布包中的私有 protection 模块公开源码环境不可用软件激活activation加密的unet-4x、SD 1.5与LTX模型LTX trial 模式仅使用随机权重用于测速不会真正修复视频。值得注意的是缺失私有模块时激活被禁用静默降级但若已安装的模块内部报错仍会如实报告失败不会因为缺失而掩盖错误。这一定义可在 jasna/protection/ 目录结构与 RELEASE_SOURCES.md 的可复现性边界章节中相互印证——最终整包构建驱动与 protection 实现保留在私有 protection 项目中公开 checkout 只能复现免费工作流。二、环境要求依赖版本/说明Python3.12发布版在 NVIDIA 上捆绑 3.13在 AMD 上捆绑 3.12ffmpeg/ffprobe8系列且必须在PATH中libVLC 3GUI 播放器音频用Ubuntu 包名libvlc5、vlc-plugin-baseCUDA 13 工具链可选NVIDIAnvcc、nvcc可用的 C 编译器、ninja来自devextra用于首次使用时构建原生 LTX block否则 LTX 走torch.compile路径python_valiwheel可选NVIDIA由 https://codeberg.org/Kruk2/vali fork 构建需 CUDA 13、cmake、ninjaWindows 还需带 C 的 VS Build Tools 2022。缺少该 fork 时解码器对所有视频回退到 PyAV其中python_vali的腐坏容错要求可在源码中直接看到jasna/media/video_decoder.py 中的_ValiFrameSource在构造时会检查python_vali.PyDecoder是否带有DecodeSingleSurfaceAsyncDetailed方法缺失即抛出VideoDecodeError因为公开 PyPI 的原版 wheel 在打开时就会回退到 PyAV。Windows 特别说明NVIDIA从VS 2022 的 x64 Developer prompt启动 Jasna确保 MSVC 的cl在PATH上——CUDA 13.0 不接受 VS 2026 的 MSVC。这是构建原生 LTX 扩展的前提。三、NVIDIA 环境搭建官方推荐用发行版自带的 Python 创建虚拟环境因为其 Tk 使用 Xft 渲染独立分发的 Python 若带no-xft的 TkGUI 所有字体都会变成位图fixed。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--no-managed-python --no-python-downloads强制使用系统 Python避免 uv 下载自带 Python 造成 Tk/Xft 问题--extra-index-url https://download.pytorch.org/whl/cu130让依赖解析器从 PyTorch 的 cu130 索引拉取 CUDA 版 torchWindowsNVIDIA在 Python 3.13 venv 中执行同一条uv pip install行即可。Ubuntu 22.04 没有 Python 3.13 软件包需要针对tk-dev和libxft-dev自行构建一个 Python。[nvidia,dev]两个 extra 的具体内容定义在 pyproject.tomlnvidiatorch2.12.1cu130、torchvision0.27.1cu130、tensorrt10.16.1.11、torch-tensorrt2.12.0、nvidia-vfx、comfy-kitchen0.2.38LTX INT8 自注意力内核、scipy、triton-windows仅 Windows与python_vali4.8.8devnuitka2.4冻结/打包、pytest、pytest-cov、scikit-build、cmake、ninja。发布构建者的额外要求冻结freeze前必须先安装项目要求的ultralytics8.4.96,8.5。旧版本在发布版受限加载策略下无法加载 YOLO 检查点即使同一 checkpoint 在开发环境中可以正常加载pyproject.toml 注释也说明了这一点。YOLO 的 ONNX 导出既不需要 onnxruntime 也不需要 onnxslim发布版两者都不捆绑但ultralytics导出 TensorRT 模型需要onnxpyproject 中Not imported directly的依赖。NVIDIA extras 会为 LTX worker 直接安装 SciPy发布打包器会拷贝其 Python 模块、原生扩展与捆绑的 BLAS 库。四、AMDROCm 10.0环境搭建Linux在rocm/pytorch的 ROCm 10.0 镜像内工作torch 来自镜像本身然后uv pip install -e .[amd,dev]WindowsPython 3.12Adrenalin 26.8.1 或更新必须先从 AMD 的索引安装 torch否则后续某个依赖会从 PyPI 拉下 CPU 版 torch$I https://stable.repo.amd.com/rocm/whl-next/ $D device-gfx1100,device-gfx1101,device-gfx1102,device-gfx1103,device-gfx1150,device-gfx1151,device-gfx1200,device-gfx1201 pip install --index-url $I torch[$D]2.12.0rocm10.0.0 torchvision[$D]0.27.0rocm10.0.0 uv pip install -e .[amd,dev]$D中的device-gfx*extra 按显卡架构选择[amd,dev]在 pyproject.toml 中固定了torch2.12.0、torchvision0.27.0、rfdetr1.8.3、transformers5.1.0与numpy1.26.4transformers5.1.0的固定是因为新版 transformers 解析 AutoBackbone 时会导入 FSDP而 Windows ROCm torch wheel 刻意不包含distributed_c10d扩展。安装后校验python -c import torch, torchvision; assert torch.version.hip and rocm in torchvision.__version__; print(ROCm OK)这一步非常关键若 torch 版本 pin 不可满足uv 会静默安装 CUDA 构建版进而破坏 RF-DETR。因此必须显式断言torch.version.hip存在且torchvision.__version__含rocm。新增 GPU 目标时除了在上面的device-gfx*extra 中追加还要同步加入Dockerfile.amd的 keep-list位于私有 protection 子模块内。AMD 运行时行为差异AMD 将RF-DETR 作为rfdetrtorch 模型运行ROCm 路径不再走 ONNX/MIGraphX——这绕开了 Windows 专属的 MIGraphX wheel 问题解码/编码使用AMFAMF 不可用时回退软件解码二次修复secondary restoration为 NVIDIA 专属--device cuda:N可以指定 GPU但FFmpeg 8 的 Linux AMF 会忽略 adapter 参数多 GPU 机器需要在容器或主机层面隔离 GPU。五、运行与解码后端选择python -m jasna # GUI python -m jasna --input in.mp4 --output out.mp4 # CLI详见 docs/en/cli.md从 jasna/main.py 可以看到入口逻辑无参数时进入 GUIrun_gui带参数时进入 CLIjasna.main.mainWindows 下jasna-cli.exe/jasna-gui.exe的命名也会影响路由。Linux 上入口会先于 tkinter 预加载 PyAV_preload_native_libs避免 Tcl/Tk 共享库与 PyAV 捆绑的 libav 冲突。解码后端由环境变量控制JASNA_DECODE_BACKENDvali|pyav-hw|pyav-swauto默认NVIDIA 优先尝试 VALI失败后回退 PyAV 硬件加速、再回退 PyAV 软件解码AMD 走 AMF → 软件解码的升级链vali只用 VALI任何失败直接抛错仅 NVIDIApyav-hw跳过 VALI用 PyAV hwaccel 路径含软件回退pyav-sw强制 FFmpeg 软件解码并在所有厂商上 GPU 上传。实现细节见 jasna/media/video_decoder.py非法取值会抛出ValueErrorauto模式下 VALI 的可用性判断即构造_ValiFrameSource并解码首帧构造失败发生在调用方提交到该后端之前损坏包则在 VALI fork 内部跳过最多连续容忍 10 个超出后与 PyAV 路径一样抛VideoDecodeError。测试 tests/test_video_decoder_backends.py 专门验证了auto在 VALI 失败时回退 PyAV 的行为。六、测试python -m pytestGUI 测试需要屏幕在无头或锁屏桌面下用xvfb-run -a -s -screen 0 1920x1080x24运行——默认的 640x480 屏幕会裁掉底部 widgetGPU 测试需要匹配的 GPU如test_ltx_native_gpu.py、test_ltx_kernels_gpu.py、test_video_decoder_backends.py中的真实解码用例。[tool.pytest.ini_options]位于 pyproject.tomltestpaths [tests]并屏蔽了 mmengine 与torch.jit.script的弃用告警。七、CUDA 内核与 fatbin 预编译jasna/media/*.cu如cas.cu、denoise.cu、lut.cu、resize_normalize.cu、rgb_to_yuv.cu、yuv_to_rgb.cu已预编译为同目录下提交的.fatbin文件因此运行 Jasna 不需要 CUDA 工具包。运行时的加载路径见 jasna/media/cuda_kernel.py通过 CUDA Driver API 的cuModuleLoadData把 fatbin 载入当前 CUDA context并按(context, fatbin_name)缓存内核经cuModuleGetFunction解析后由Kernel.launch复用参数缓冲区发射。这也解释了为何加载失败会报Missing precompiled CUDA kernel——说明对应 fatbin 未随包分发。编辑.cu源码后需要用 CUDA 13 与g-15重建可用CCBIN覆盖scripts/build_fatbins.sh # 重建全部内核 scripts/build_fatbins.sh cas # 只重建 jasna/media/cas.cu从 scripts/build_fatbins.sh 可以看到构建细节CCBIN${CCBIN:-g-15}——CUDA 13 拒绝比 GCC 15 更新的宿主编译器目标架构覆盖 compute_75code[compute_75,sm_75]内嵌 PTX驱动可对更新的架构 JIT与 SM 80/86/87/88/89/90/100/103/110/120/121构建后会用cuobjdump打印每个 fatbin 实际包含的sm_*集合便于核对。新增 fatbin 需要登记到私有 protection 子模块jasna/protection/keytool/build_nuitka.py的CUDA_KERNEL_FATBINS列表。每个内核都必须有 Torch 等价实现ROCm 使用它测试也以它作为参考基准例如tests/test_cas.py、tests/test_lut.py、tests/test_yuv_to_rgb.py等 kernel 测试。八、基准测试基准测试仅由维护者在空闲 GPU 上运行——卡上任何其他负载都会让数字失去可比性。输入视频位于 gitignored 的assets/benchmark/结果写入benchmarks/日期_主题.{csv,md}且绝不修改旧 CSV仓库中benchmarks/下按日期命名的历史数据即遵循该约定。发布套件组成每个分辨率一条 H.264 输入外加 8K VR 片段三次运行取中位数固定参数--max-clip-size 180 --temporal-overlap 15 --secondary-restoration none当改动涉及解码、编码或像素格式时追加--codecsHEVC 10-bit 与 AV1——H.264 会掩盖解码差异源码注释指出这两种格式跨解码后端约有 19% 的差异。常用命令scripts/run_benchmarks.sh benchmarks/scratch [--codecs] [--scan] # 约 8 分钟 P~/.virtualenvs/jasna-linux/bin/python $P scripts/benchmark_decode_backends.py --backends vali pyav-hw pyav-sw # 各解码器 e2e $P scripts/benchmark_scan_backends.py --backends vali # GUI 马赛克扫描 $P scripts/benchmark_releases.py --release v0.9.0/path/to/jasna --source HEAD. --workdir WORKDIR/releases --csv out.csv $P scripts/benchmark_lada_flatpak.py --workdir WORKDIR/lada --csv out.csv # Lada 基线 $P scripts/benchmark_ltx_denoise.py --model undistilled --csv out.csv # LTX 去噪trial 权重 $P scripts/benchmark_ltx_decode.py --variants shipped,kitchen,eager # LTX VAE 解码 $P scripts/benchmark_na3d.py # Triton NA 内核其中scripts/bench_memory.py是其他脚本共享的 RAM/VRAM 采样器。查看 scripts/run_benchmarks.sh 可确认发布套件的输入清单SONE-610_bench_720p/1080p/2160p_h264_8bit.mp4与vr1_8k_vr_hevc_8bit_60fps.mp4而 scripts/benchmark_decode_backends.py 展示了它在子进程中注入JASNA_DECODE_BACKEND并逐后端调用 CLI 的机制还会通过日志中的falling back/software decoding标记识别非预期的后端回退FALLBACK标记。九、LTX 原生 Block工作原理源码模式source mode下LTX 运行公开的原生 blockjasna/ltx/native/每个 transformer block 对应一次 C/CUDA 调用首次使用时在编译缓存中构建约 1–2 分钟。从 jasna/ltx/native/init.py 的模块 docstring 可知其构成block.cpp在一个 block 内串联ltx/kernels.py中为此 GPU 预编译AOT的 Triton 内核、与 torch 路径相同的 cuBLAS NVFP4 GEMM 与 prompt SDPA、随附的 INT8 自注意力sage_attention/、以及glue.cu的逐元素粘合Python 侧持有全部模型常量与 launch 策略通过Config传入。触发条件与回退原生 block 在以下任一情况不会使用采样器退回torch.compile/Triton 路径缺少工具链无nvcc/C 编译器/ninjaGPU 不在内核表中kernels.supports(device)为假JASNA_LTX_NATIVE0显式关闭——用于在同一棵树里做 A/B 对比。unavailable_reason()jasna/ltx/native/init.py会精确报告为何不能用包括it needs an NVIDIA GPU、there are no tuned kernels for SM x.y、NVFP4 blocks need SM 12.0 / 12.1等而load()在任何构建/加载异常时记录 warning 并返回None调用方继续走编译路径——这与 development.md 描述的行为完全一致。INT8 自注意力的来源INT8 自注意力是comfy-kitchen 0.2.38 的 SageAttentionvendored 在 jasna/ltx/native/sage_attention/bf16、unmasked 子集来源与改动记录在其NOTICE中。它必须与comfy_kitchen.int8_attention保持逐位一致——由 tests/test_ltx_native_gpu.py 验证该测试用 trial-shaped 权重与输入对比原生 block 与transformer.block_forward的相对误差INT8 容差(5e-3, 3.5e-2)NVFP4 为(2.5e-2, 0.15)因为一次舍入会翻转多个 FP4 码字。当 torch 路径的 comfy-kitchen pin 变动时需要重新 vendor 它。注意编译隔离它用 comfy-kitchen 的 nvcc 标志--use_fast_math等见_ATTENTION_NVCC_FLAGS且--use_fast_math不能波及glue.cu因此两者分开编译jasna/ltx/native/init.py。发布构建与预编译jasna.ltx.native.prebuild(dir)为发布构建扩展及内核表中每个架构的 cubin把dir拷贝到jasna/ltx/native/prebuilt/。实现见prebuild()jasna/ltx/native/init.py先prebuild_kernels全架构内核再设置TORCH_CUDA_ARCH_LIST构建扩展并拷贝产物prebuild_profiles()枚举了公开的 (架构, BlockDims, 量化) 组合相关测试在 tests/test_ltx_prebuild_kernels.py。发布版使用从同一份block.cpp编译的私有扩展发布打包保留NOTICE到licenses/。发行版的 fatbin/Triton 模块加载逻辑见 jasna/ltx/native/init.py_extension()优先加载prebuilt下的扩展冻结版绝不现场编译。任何路径改动都必须用相同的权重、输入、随机种子与已预热缓存做对比A/B。GPU 适配矩阵官方在SM 12.0RTX 5090、SM 8.9RTX 4090、SM 8.6RTX 3090、SM 7.5RTX 2080 Ti上完成了 GPU 认证SM 12.0 以下仅 INT8SM 8.x 用纯 Triton GEMMSM 7.5 用 cuBLAS INT8 GEMM Triton epilogue仅为某个 SM 编译出 cubin并不代表该架构得到支持——支持需按上述矩阵认证。十、发布检查清单版本一致性pyproject.toml、jasna/__init__.py、git tag 与 RELEASE_SOURCES.md 中的版本必须一致该文件必须匹配构建所用的 PyAV、VALI、FFmpeg、Python 与 protection 修订当前仓库对应 v0.11.x 的完整来源对照包括 PyAV 18.1.0、VALI fork commit、RF-DETR 1.8.3、FFmpeg 8.1.2 与 mmengine 权重加载补丁 patches/fix_loading_mmengine_weights_on_torch26_and_higher.diff。解包内容完整包含LICENSE、LICENSING.md、NOTICE、RELEASE_SOURCES.md、assets/THIRD_PARTY_*.md与licenses/见 assets/THIRD_PARTY_LICENSES.md、assets/THIRD_PARTY_MODELS.md 与 assets/licenses/。模型哈希校验每个捆绑模型的哈希与 assets/THIRD_PARTY_MODELS.md 一致。上传完整性把每个归档分片及其.sha256一起上传到同一个 GitHub release。发布构建NVIDIA 与 AMD位于私有 protection 子模块jasna/protection/keytool/中不随公开源码发布。十一、常见问题速查现象原因与对策安装后 torch 是 CUDA 版而非 ROCm 版AMD 上未先装 torch 或 pin 不可满足uv 静默回退 PyPI用第四节校验命令确认GUI 字体全是位图fixed使用了no-xftTk 的独立 Python改用发行版 Python 建 venvLTX 没有走原生 block缺nvcc/编译器/ninja、GPU 不在内核表、或JASNA_LTX_NATIVE0看日志中的unavailable_reason与 fallback warning新增.cu内核不生效需重建 fatbinscripts/build_fatbins.sh、登记到CUDA_KERNEL_FATBINS并提供 Torch 等价实现无头环境跑 GUI 测试失败用xvfb-run -a -s -screen 0 1920x1080x24提供大屏幕总结Jasna 的源码开发体系围绕发布包开箱即用、源码环境面向开发者分层设计CUDA 内核以 fatbin 预编译免除运行期工具链依赖LTX 原生 block 以首次构建 全架构预编译兼顾开发灵活性与发布性能AMD 通过 ROCm wheel 与 AMF 路径实现跨厂商支持而严格版本的发布清单则保证二进制与源码、第三方组件的可追溯性。开发者若需深入可继续阅读 docs/en/cli.mdCLI 全参数、docs/en/tuning.md性能调优与 docs/en/gui.mdGUI 功能。赞分享人工智能AI 应用计算机视觉视频处理图像处理深度学习【免费下载链接】jasnaVideo restoration tool项目地址https://gitcode.com/GitHub_Trending/ja/jasna点击查看免费下载相关推荐Apache CouchDB 开发者指南源码环境搭建、测试流水线与发布构建实战Apache CouchDB 开发者指南源码环境搭建、测试流水线与发布构建实战 本文以仓库根目录下的 README DEV.rst https://link.数据库文档数据库分布式数据库后端数据同步Kode CLI 贡献指南环境搭建、源码构建、测试与发布全流程Kode CLI 贡献指南环境搭建、源码构建、测试与发布全流程 Kode CLInpm 包名 shareai lab/kode 是一个运行在终端中的 AAI 应用开发工具AI AgentCLIReScript 编译器开发贡献指南从环境搭建、源码构建到测试与发布的全流程实战ReScript 编译器开发贡献指南从环境搭建、源码构建到测试与发布的全流程实战 导读 本指南面向想要参与 ReScript https://link.git编译器编程语言开发工具上一篇ExplorerPatcher 崩溃Windows 资源管理器崩溃排查与修复完整指南下一篇10分钟掌握pyvideotrans批量处理自动生成处理报告终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考