尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Jasna 教程:本地 GPU 马赛克视频修复是怎么做到的(附实测数据)
Jasna 教程本地 GPU 马赛克视频修复是怎么做到的附实测数据【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna一段 3 分 22 秒的 1080p 视频Jasna 在 RTX 5090 上 39 秒修复完1080p 端到端约 156 fps10 GB 显存即可跑满8 GB 显卡降一档参数也能跑通 720p。Jasna 是一个本地 GPU 视频马赛克修复工具它只找出画面里的马赛克区域并重建这部分像素其余画面原样保留。本文基于仓库源码与 官方基准报告 里的实测数据讲清楚这条流水线内部如何运转、为什么这么设计。 架构总览四个线程串起整条 GPU 流水线修复主路径由四个并发循环组成用有界队列衔接代码集中在 jasna/pipeline_threads.py。先看这张地图后面逐站走组件职责输入输出所在文件decode_detect_loopNVDEC/AMF 硬件解码 逐帧检测输入视频文件检测到的 bbox mask 批次jasna/pipeline_threads.py、jasna/media/video_decoder.pyexpand_bbox/CropBuffer把检测框长到 256×256 并做预处理bbox 原始帧256×256 裁剪序列 坐标元数据jasna/crop_buffer.pyClipTracker BasicVSR跨帧聚合成 clip对 clip 做时序重建裁剪序列256×256 修复张量 回填坐标jasna/tracking/clip_tracker.py、jasna/restorer/restoration_pipeline.pyblend_encode_loop按 mask 把修复结果混回原帧并硬件编码原帧 修复张量 mask输出视频音频流拷贝jasna/blend_buffer.py、jasna/media/video_encoder.py官方 README 对这条链路只有一句话但它就是全项目最重要的不变量Finds mosaics in a video and restores them. The rest of the picture is not touched.README.md也就是说后面所有裁剪、重叠、混合的工程手段都是在守住只改马赛克、不碰背景这条线。主线走读一段视频从解码到回填的完整旅程以下按数据流动方向走五站。每一站都回答三件事输入输出是什么、内部关键逻辑是什么、为什么这么做。站点一硬件解码与逐帧检测——帧和检测结果都留在显存这一步接收输入视频文件产出带置信度的 bbox 与逐像素 mask解码代码在 jasna/media/video_decoder.py检测调度在 jasna/mosaic/detection_registry.py。VideoReader默认走vali后端NVDEC 直读帧直接以 GPU 张量形式产出不再回拷到内存。检测默认模型是rfdetr-v6576 分辨率、置信度阈值 0.35它和只给框的 YOLO 不同同时输出逐像素 maskjasna/mosaic/detections.py 里的Detections同时携带boxes_xyxy裁剪定位用和masks回填混合用。在 NVIDIA 上模型首次会被编译成 TensorRT 引擎compile_rfdetr_engineworkspace_gb20AMD 则回退 torch 推理。为什么值得为首次慢买单因为引擎编译是一次性的编译产物缓存在model_weights目录可跨 Jasna 版本复用被否掉的替代方案是每次现跑 torch 推理那意味着每个任务都付一遍推理开销。常见误解首任务慢是因为模型在跑推理可以这样纠正——慢在引擎编译不在推理README 明确给出 15–60 分钟的预期并建议这段时间别动电脑。解码批次送进检测后检测线程继续推进下一批帧裁剪与重建随即接棒。站点二bbox 向 256 生长——裁剪与预处理这一步接收检测 bbox 和原始帧产出 256×256 的裁剪序列代码在 jasna/crop_buffer.py。核心是expand_bboxRESTORATION_SIZE 256 BORDER_RATIO 0.06 MIN_BORDER 20 MAX_EXPANSION_FACTOR 1.0它决定了裁剪的两个阶段先按BORDER_RATIO至少MIN_BORDER像素向外扩一圈上下文边距再向 256 的目标比例生长——优先吃画面内的可用空间扩张预算不超过原框的一倍MAX_EXPANSION_FACTOR。随后整批等比缩放只降不升、反射填充补齐到 256×256同时记下pad_offsets与resize_shapes两组坐标元数据它们会一路带到回填阶段。为什么带边距而不是贴框裁因为时序模型只靠马赛克内部的像素补细节会糊边界上下文是重建质量的来源。为什么不用修复后再按原框中心对齐之类的事后反推因为缩放和填充会打乱坐标对应关系显式携带偏移是零歧义的做法被省掉的就是一张事后对齐表。裁剪序列按时间顺序攒好后交给下一站做跨帧关联。站点三跟踪分组与 clip 重叠——时序重建的边界问题这一步接收逐帧的裁剪序列产出若干 clip 及各自的修复结果跟踪代码在 jasna/tracking/clip_tracker.py。ClipTracker给每个马赛克发track_id把连续帧聚成TrackedClipbbox 序列 mask 序列长度受max_clip_size约束超过就带重叠拆分SceneCutDetector在镜头切换处强制断开 clip保证两个镜头的画面永不混进同一个时序窗口。重建前还有一段容易被忽略的账相邻 clip 必须重叠否则拼接处会跳变。jasna/pipeline_overlap.py 负责算重叠策略——discard_margin对应 GUI 的 temporal overlap决定片段首尾各丢多少帧这些帧本身已被相邻 clip 覆盖compute_crossfade_weights给重叠区生成线性渐变权重weights[local_idx] (j 0.5) / (2 * bf)它决定了重叠区两路修复结果按多少比例交叉淡化。也就是说同一个时间窗会被相邻 clip 各修一遍再按权重融合而不是一帧只修一次——这是时序模型在片段边界不产生闪烁的工程答案被否掉的是按切点硬拼接省不了多少算力换来的却是肉眼可见的跳变。每个 clip 送进 BasicVSRprepare_and_run_primary输出 256×256 的修复张量坐标随张量一起回到混合缓冲。站点四mask 混合与硬件编码——把补丁精确嵌回原帧这一步接收原帧、修复张量和检测 mask产出最终视频流代码在 jasna/blend_buffer.py 的blend_frame。算法是差分回填把修复结果按pad_offsets反算回原裁剪坐标双线性放大回裁剪尺寸再以检测 mask 上采样得到的blend_mask为权重做 lerp——用大白话说就是把马赛克那一小块像素换掉边缘渐变一下original_crop.lerp_(resized_back, blend_mask.unsqueeze(0)).round_().clamp_(0, 255)mask 内侧 100% 采用修复像素向外渐变到原像素clamp_兜住 uint8 溢出。BlendBuffer还维护一张pending_map记录每帧还欠哪些 track 的结果全部到齐该帧才允许混合从机制上杜绝修到一半就编码的竞态。最后帧交给 NVENC/AMF 硬件编码音频默认流拷贝。为什么用差分 lerp 而不是直接覆盖矩形区域因为重建模型对没修的像素并非输出逐位相同的原值直接贴矩形会在马赛克边缘留下一圈可感的色差mask 加权让马赛克外的像素数学上不动正好兑现 README 那句The rest of the picture is not touched。一帧的旅程到此结束下一个批次已在解码线程里排队。关键工程决策显存与速度的几笔账决策一把修复面钉死在 256×256而非对全帧跑超分。付出的是每个马赛克都要走检测、裁剪、跟踪、回填一套完整编排代码量明显大于整帧丢进网络换来的是修复模型只吃局部补丁显存占用从 v0.4.1 的 17.98 GB 典型20.4 GB 峰值1080p压到 v0.9.1 的 4.8 GB 典型 / 5.6 GB 峰值benchmarks/2026-07-26_release_matrix.md8 GB 显卡从跑不了变成跑得满。决策二编解码全程硬件化。付出的是对硬件编解码器的依赖——NVIDIA 需 GTX 16/RTX 20 起README.mdAMD 仅实验性支持AV1 还要在_NVDEC_DECODER_OVERRIDES里单独指定原生解码器绕开 PyAV 默认路径换来的是 benchmarks/2026-07-21_v0.8.2_e2e_decode_backends.md 里的数字软件解码比vali硬解多花 5–13% 的端到端时间帧数据自始至终不离开 GPU。决策三首次编译引擎之后吃缓存。付出的是首任务 15–60 分钟的编译等待README 建议期间关掉其他程序换来的是此后每个任务直接加载model_weights里的缓存引擎且升级 Jasna 版本时拷走该文件夹即可复用README.md。决策四检测与修复拆成两个可互换的模型族。付出的是两套模型各自的版本与维护成本换来的是检测侧可换 YOLO 系列兼容旧权重生态jasna/mosaic/detection_registry.py 维护整张模型清单修复侧可插 LTX 扩散模型NVIDIA 为主走独立多遍流程显存峰值由修复阶段单独决定而非两者叠加。数字说话官方基准里的速度、显存与对比以下数字全部来自仓库 benchmarks/ 与 README.md测试机为 RTX 5090。端到端速度修复一段 3:22 的视频BasicVSR输入耗时吞吐显存典型/峰值720p H.26434.4 s175.9 fps4.2 / 4.6 GB1080p H.26438.6 s156.8 fps4.8 / 5.6 GB2160p AV1 10-bit79.7 s76.0 fps—数据来源benchmarks/2026-07-26_release_matrix.mdv0.9.0与 README.mdv0.9.1 显存。与同类工具 Lada 0.11.0 同机对比输入Lada 0.11.0Jasna v0.9.0提速720p H.26401:4700:343.1×1080p H.26402:0200:393.2×2160p H.26404:5601:163.9×README.md 给出的对比口径为 3.4× / 3.6× / 4.7×Lada 侧配置略有差异两个口径都指向同一结论差距在 3 倍以上。版本演进同一段 1080p H.264版本耗时显存典型/峰值v0.4.101:4619.4 / 21.9 GBv0.5.000:479.8 / 10.4 GBv0.9.000:399.5 / 10.4 GBv0.9.1—4.8 / 5.6 GB速度翻了约 2.7 倍显存降了四分之三——版本间的性能不是玄学benchmarks/2026-07-26_release_matrix.md 把逐 commit 的消融数据都留了档如检测预处理 kernel 一项2160p 从 87.6 s 降到 78.1 s。使用建议什么硬件跑得动哪些坑最常见硬件门槛与场景适配NVIDIA GTX 16 / RTX 20 及以上计算能力 7.5是完整支持线8 GB 显存可跑默认 BasicVSR 路径1080p 典型 4.8 GBLTX 则要求 8 GB 显存加 16 GB 内存README.md。AMD RX 7000/9000 为实验性支持且没有二级修复。适合的场景素材含局部马赛克、批量大、隐私敏感马赛克占满全帧或追求极致细节时才考虑 LTX——官方标注它比 BasicVSR 慢得多Top 档约 5 倍耗时。最常见的三个坑 ⚠️首任务 15–60 分钟是引擎编译不是卡死升级 Jasna 版本时把model_weights文件夹拷过去可跳过这次等待。显存不够时把 Max Clip Size 从90降到60README.md 的官方建议见 docs/en/tuning.md。路径不能含中文、日文等非英文字符且官方不支持网络盘机械硬盘上启动和加载模型会明显变慢。收束回到开头那组数字3 分 22 秒的 1080p 素材39 秒出片显存典型 4.8 GB。Jasna 的做法是把整帧问题拆成一个个 256 像素的窗口——rfdetr 负责找位置BasicVSR 只在小窗口里重建最后按 mask 精确嵌回原帧全程帧数据不离开 GPU。当修复一段 1080p 视频只需半分钟、8 GB 显卡就能跑通时马赛克修复就不再是上传-等待-下载而是显卡上的本地实时操作。【免费下载链接】jasnaVideo restoration tool项目地址: https://gitcode.com/GitHub_Trending/ja/jasna创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED

相关推荐

基于Springboot敬老院管理系统【附源码+文档】

基于Springboot敬老院管理系统【附源码+文档】

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/10/27 9:43:12
基于Springboot高校创业竞赛路演系统【附源码+文档】

基于Springboot高校创业竞赛路演系统【附源码+文档】

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/10/27 9:43:12
基于Springboot高校服装租赁平台【附源码+文档】

基于Springboot高校服装租赁平台【附源码+文档】

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/10/27 9:43:12
MORE NEWS

更多资讯

📰

AI开发语言选型:从Python到TypeScript的工程实践

1. AI开发语言选择:工程视角下的核心考量第一次接触AI项目时,我犯了个典型错误——直接选用当时最热门的Python框架。结果在交付企业级推荐系统时,遭遇了性能瓶颈和团队协作噩梦。这个教训让我明白:AI开发语言的选择绝非跟风那么简…

📰

营销技能系统性框架:从用户理解到数据复盘的五步法

先说一个我观察了很久的现象:很多刚入行做营销的朋友,一听到"marketing skills"这个说法,第一反应就是去学怎么写文案、怎么投广告、怎么剪视频。这些的确是营销技能的一部分,但它们只是冰山一角。真正让我在这个行业里…

📰

SAP Data Services 连接 MySQL 的 ODBC 驱动与字符集配置指南

简介:本资源是一份面向SAP数据集成工程师与ETL开发人员的实操指南,聚焦SAP Data Services(BODS)连接MySQL数据库的核心配置流程,解决跨平台数据源接入、元数据导入与表级数据预览等典型集成难题。文档以Step-by-step方…

📰

前端能力图谱:Skill可执行化与MCP协议实战

1. 这不是“技能分享”,而是一份在职前端工程师的真实能力图谱“在职前端 Skill 和 MCP 分享”——看到这个标题,我第一反应不是点开,而是停下来想:谁在分享?在什么场景下分享?分享给谁看?这不是…

📰

Ubuntu终端样式实战:ANSI转义序列与SGR配色指南

1. 终端字体样式到底是怎么"变"出来的在 Ubuntu 上敲了几年命令,我越来越受不了那种纯白一片、信息全糊在一起的终端输出。编译报错和成功提示一个颜色,日志里的警告和普通信息长得一模一样,几十行刷过去,眼睛得来回扫三…

📰

Agent Skills架构解析与开发实战指南

1. Agent Skills技术变革的背景与现状 大模型技术正在经历从单纯对话到功能集成的关键转型期。去年Claude团队首次提出的Agent Skills架构,本质上是一套标准化的能力封装协议。它允许开发者将特定功能(如数据分析、代码生成、文档处理)以标准…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬