Jasna 马赛克检测模型怎么选：rfdetr-v6、lada-yolo-v4 与 rfdetr-vr-v1 的取舍指南

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

本文要回答一个具体的决策问题：在 Jasna 这条"先定位马赛克、再局部修复"的视频修复流水线里，检测环节该选rfdetr-v6、lada-yolo-v4还是rfdetr-vr-v1。核心结论一句话：先按场景选检测路线，再按漏检/误检症状调阈值。

一、为什么检测这一步决定整条流水线

本节回答：检测模型在整个流程中卡在哪里、哪个指标最影响体验。

Jasna 的处理顺序是：逐帧找出马赛克遮挡区域（docs/en/models.md 原文："The detection model finds the mosaics in each frame"），把命中区域裁成小块交给修复模型重建。检测漏了，马赛克留在原处；检测框偏了，正常画面被误"修"。而速度上，检测与解码串联在同一条链路上，扫描能跑多快决定了区间编辑器能否秒级定位马赛克区间。

两组数字说明它卡全局的程度。其一，在 RTX 5090 上用默认模型rfdetr-v6做逐帧全扫（fp16、batch 4），1080p H.264 能到828.3 fps、720p 到 860.6 fps（benchmarks/2026-07-21_v0.8.2_scan_decode_backends.md），意味着一段 10 分钟 1080p 视频的全帧检测在秒级完成。其二，瓶颈不在检测本身：官方把 ≥4K 视频的解码拆到 RTX 5090 的两个 NVDEC 单元并行后，4K 扫描被抬到约730–770 fps 的检测上限，8K VR 从 168.7 fps 提到 217.5 fps——检测在 batch 4 下就是这条链路的天花板，解码才是主要拖累。

所以下文的选型逻辑围绕三件事：找得准（阈值与输出形态）、跑得快（平台差异）、配得对（片源形态）。先看两条路线各自怎么实现。

二、各选项的技术实现：RF-DETR、YOLO 与 VR180 专用

本节回答：三个可选路线各自定位在哪、以什么方式运行、配置差异是什么。

2.1 RF-DETR（rfdetr-v6系）：默认主线，框加像素掩码

在系统中的定位：模型注册表 jasna/mosaic/detection_registry.py 把DEFAULT_DETECTION_MODEL_NAME设为"rfdetr-v6"，并维护了rfdetr-v2到rfdetr-v6-large、rfdetr-vr-v1的完整版本族。运行方式：NVIDIA 上由compile_rfdetr_engine()把.onnx导出编译为 TensorRT engine；AMD 上经rfdetr_weights_suffix()直接以.pt训练检查点跑 torch 变体（medium/large）；YOLO 的.pt则永远不转 engine。

输出形态是它的核心差异：jasna/mosaic/rfdetr.py 的_postprocess组合三路结果——pred_boxes（归一化 cxcywh 框）、pred_logits（sigmoid 后 topk 打分）、pred_masks（低分辨率像素掩码）。也就是说它不只"画个框"，而是直接给出马赛克区域的像素级掩码，修复可以按掩码裁剪。另一个工程亮点是scan_scores_masks()的 GPU 快路径：全程无主机端同步，直接返回每帧最佳分数与合并后的低分辨率掩码，这是区间编辑器能高速扫描整片视频的底层原因。

（配置来源：jasna/mosaic/detection_registry.py 中RFDETR_MODEL_CONFIGS。）值得注意：rfdetr-v6相对v5把输入从 768 降到 576、batch 从固定 4 改动态，换来更快且对多数视频足够好；v6-large再把分辨率拉回 768 换 large 变体，精度优先、速度让位。

2.2 YOLO（lada-yolo-v2/v4）：Ultralytics 生态的"拿来主义"

在系统中的定位：注册表里三个 YOLO 模型的backend均为yolo，权重文件名直接对应model_weights/下的.pt文件；lada-yolo-v4是基准脚本钦定的"快速版"（jasna/benchmark/detection_speed.py 中LADA_YOLO_FAST_MODEL = "lada-yolo-v4"）。运行方式：jasna/mosaic/yolo.py 复用 Ultralytics 的AutoBackend加载，输入统一做 640×640 letterbox（填充值 114/255），后处理是标准 NMS（IOU 0.7、max_det 32），默认置信度阈值 0.25。

差异化价值点有两处。其一，2D 动画场景可能比 RF-DETR 更准——这是官方文档的明确提示（docs/en/models.md："Lada YOLO models: can be better for 2D animation"）。其二，AMD 平台上的速度优势：benchmarks/2026-10-22_amd_rx9060xt_validation.md 在 RX 9060 XT 上测得同一条 1080p 片源，rfdetr-v6端到端 54.30 fps，lada-yolo-v4达 59.51 fps——官方文档因此给出取舍建议"If speed is more important than detection quality, uselada-yolo-v4"。

2.3 VR180 专用：rfdetr-vr-v1与zelefans-vr-yolo-v2

VR180 是左右眼并排（SBS）的片源，马赛克经过球面/鱼眼投影后形变，通用模型容易漏检或误框。路线配置上，rfdetr-vr-v1直接复用 large 变体、768 分辨率、0.40 阈值（见 2.1 表格），内置可用；zelefans-vr-yolo-v2是 ZeLeFans 贡献的另一套 YOLO 系 VR 方案，需单独下载。两者都放进model_weights/后被discover_available_detection_models()自动发现，GUI 与 CLI 一键切换，无需改任何代码。

小结：RF-DETR 赢在默认、掩码精度与动态 batch；YOLO 赢在动画与 AMD 速度；VR 专款解决投影形变。接下来看实测数据怎么读。

三、实测数据怎么读：官方基准的扫描速度与平台差异

本节回答：官方基准数据说明什么、有哪些容易被忽略的工程细节、如何在本地复现。

表 1：RTX 5090 逐帧全扫速度（rfdetr-v6，fp16，batch 4，GUI 默认参数）

（来源：benchmarks/2026-07-21_v0.8.2_scan_decode_backends.md。）

两个结论。其一，扫描是解码瓶颈而非检测瓶颈：4K HEVC 从 532.6 提到 711.2 fps，逼近 batch 4 下约 730–770 fps 的检测上限；8K VR 提升到 217.5 fps。其二，低分辨率下检测近乎"免费"：720p/1080p 稳定在 800+ fps，配合默认每秒采一帧的隔帧扫描（jasna/mosaic_scan.py 的scan_sample_stride，默认seconds=1.0），区间编辑器的秒级自动定位才有物理基础。

表 2：AMD（RX 9060 XT）端到端对比，1080p 片源 5310 帧，BasicVSR++ 修复

（来源：benchmarks/2026-10-22_amd_rx9060xt_validation.md。）两条链路的 detect/track 阶段都超过 88 秒、占端到端主体，检测是 AMD 上这条流水线的限速环节，这也解释了 2.2 的取舍。

一个容易被忽略的细节：每个模型带自己的推荐阈值（RF-DETR 系 0.35/0.40，YOLO 系 0.25），这不是随意取值，而是recommended_score_threshold()（jasna/mosaic/detection_registry.py）按模型固化、CLI 与 GUI 自动套用的校准值——不同检测器的置信度量纲不同，跨模型沿用同一阈值会整体偏移。

本地复现：官方提供现成脚本 jasna/benchmark/detection_speed.py，benchmark_rfdetr_detection_speed与benchmark_lada_yolo_detection_speed分别对应两条路线，按各模型推荐阈值、3 次运行取中位数，输出 fps 与每帧检出数。数据读到这里，下面给出落地选型。

四、选型路径：决策表与调参步骤

本节回答：给定场景和硬件，具体选哪个、怎么调。

选型决策表

调参三步（CLI 出处：docs/en/cli.md Detection 一节）：

1. 先按推荐阈值跑通：--detection-model指定模型后，--detection-score-threshold不传即自动套用推荐值（rfdetr-v60.35，rfdetr-v6-large/rfdetr-vr-v10.40，YOLO 系 0.25）。
2. 按症状微调阈值：有马赛克没修好 → 调低（如 0.35 → 0.25）；正常画面被反复"修"（误检）→ 调高。阈值影响是非线性的，比盲目换模型更划算。
3. 用好三个配套参数：--max-detection-gap 2填补同一位置 ≤2 帧的短暂掉检；--min-detection-duration 2丢弃短于 2 帧的误检；--scene-detection（默认开）在硬切处切断马赛克片段，避免一个片段横跨两个镜头导致修复"串戏"。

小结：先按表选路线，再按症状动阈值，逐片微调交给区间编辑器（可为每个视频单独指定检测模型）。但有几个流传较广的说法需要先纠正。

五、常见误区与坑

本节回答：哪些直觉会把你带偏。

误区一：阈值越小找得越全。真相恰恰相反——阈值是按模型校准的，不是越小越好。RF-DETR 系从 0.35/0.40 起跳，是因为其 logits 经 sigmoid + topk 后置信度分布整体偏高；YOLO 系 0.25 起步则接近通用检测的常规设置。跨模型沿用旧阈值（比如从rfdetr-v6换到lada-yolo-v4还带着 0.35）会系统性漏检，正确做法是让--detection-score-threshold留空取推荐值。

误区二：大模型一定更准，应该默认用rfdetr-v6-large。真相是"够用就好"。rfdetr-v6的 576 输入 + 动态 batch 是速度优先的设计，官方定位"fast and good for most videos"（docs/en/models.md）；768 输入 + large 变体的v6-large只在 4K 或大马赛克特写才值得付出更慢的代价，且它是单独下载项，按显卡选.onnx（NVIDIA）或.pt（AMD）放入model_weights/。

误区三：扫描 fps 低，说明检测模型慢。不是——如表 1 所示，4K/8K 的低 fps 是解码在拖后腿，检测本身的天花板在 730–770 fps。遇到全扫偏慢，先看片源是否 ≥4K（Jasna 会自动对 ≥4K 且 ≥10 秒的 NVIDIA 视频启用双 NVDEC 并行解码），而不是急着换检测模型。

最后回到开头：检测模型不是越强越好，而是与硬件、片源和修复成本匹配——NVIDIA 上默认rfdetr-v6，4K 与 VR180 按场景换rfdetr-v6-large/rfdetr-vr-v1，AMD 求速换lada-yolo-v4，再用推荐阈值起步、按漏检/误检症状微调，这条链路就是全部选型逻辑。

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