先查看运行计划里的帧数、处理尺寸和主机内存预算,再按深度控制的实际需要选择 fast 或 full。本文解释主机内存与显存的区别、质量档与输出尺寸的作用,并给出超预算后的调整和指标回查方法。
ReShot 处理视频前,怎么估算内存并选质量档:先用 Python 的 plan(cfg) 看处理帧数、处理尺寸与主机内存预算,再选深度推理的 fast 或 full。默认从 fast 开始;主机内存超预算先切短片,显存不足先降低深度工作尺寸。--max-res 在深度模式只限制输出尺寸,不能代替降低推理尺寸。预算通过也不保证显存够用。
运行计划是处理开始前对输入规格、处理规模、输出规格和主机内存需求的估算。本篇按猫斯卡开源的 ReShot 本地源码快照讲解,版本文件为 0.5.0;以下是接口与代码核对,示例未执行模型,不作为新性能实测。
输入、处理和输出尺寸各管什么?
根据 pipeline.py 的 plan 与 config.py,同一段视频至少要分清以下三层,不能只问“输出多大”。
| 层次 | 从哪里看 | 决定什么 |
|---|---|---|
| 原始输入 | src_w、src_h、src_fps、src_frames |
视频原本的宽高、帧率与帧数 |
| 读入并处理的帧 | proc_w、proc_h、frames |
整段帧数组的规模;主机内存估算使用这组数 |
| 编码输出 | out_w、out_h、out_fps |
控制视频交给下一步时的规格 |
深度模式先按质量档计算处理尺寸,模型还会按自己的尺寸规则调整。proc_w × proc_h 因此不能一概当成模型最终输入尺寸;实际深度运行的日志会给出模型看到的宽高,指标文件也记录 model_input_resolution。
--max-res 默认限制输出长边为 1280;深度模式即使把它调小,计划中的处理尺寸仍按深度工作尺寸决定。骨架和边缘模式则按输出尺寸读帧,因此减小输出规模也会改变这两种模式的处理规模。这个区别来自源码分支,不是所有控制类型通用的降内存办法。
怎样只查看计划,再决定是否处理?
先准备已经可用的 ReShot Python 环境和本地视频。项目要求 Python 3.10 及以上;下面使用公开 Python API,不是 CLI 的 --plan 参数。将 reference.mp4 换成自己的输入路径,在已安装对应版本的环境中保存并运行:
from dataclasses import replace
from pathlib import Path
from reshot import RunConfig, plan
cfg = RunConfig(
input=Path("reference.mp4"),
output=Path("depth.mp4"),
control="depth",
quality="fast",
target="none",
metrics=Path("depth-metrics.json"),
)
for quality in ("fast", "full"):
candidate = replace(cfg, quality=quality)
p = plan(candidate)
print(quality)
print("source:", p.src_w, p.src_h, p.src_fps, p.src_frames)
print("process:", p.proc_w, p.proc_h, p.frames)
print("output:", p.out_w, p.out_h, p.out_fps)
print("estimated GiB:", p.ram_estimate / 2**30)
print("budget GiB:", p.ram_budget / 2**30)
print("within RAM budget:", p.ram_estimate <= p.ram_budget)
plan 接收一个 RunConfig,返回 Plan 数据对象。它探测视频规格,但不进行视频帧解码或模型推理;上面也没有调用 run。正确结果是打印两档的计划数据,不会生成 depth.mp4 或指标文件。输入路径错误或没有视频流时,先按错误信息修复输入,不能把“没有计划”解释成“内存不足”。
计划没有 ok 字段,判断预算要比较 ram_estimate 与 ram_budget。也不要把 metrics 写进配置就认为有了实测:只有实际运行完成后的指标,才能拿来检查这次处理的耗时和资源。
内存估算怎么算,为什么它不是显存预测?
planning.py 的深度模式使用以下公式,单位为字节:
主机内存估计 = 2 × 2^30 + 20 × 帧数 × 处理宽 × 处理高
主机内存预算 = 物理内存总量 × 0.5
式中的帧数用 plan.frames,尺寸用 plan.proc_w、plan.proc_h,不要填输出宽高。源码注释说明:深度估算来自 2026 年 9 月 12 日、ReShot 0.3.2、RTX 4090、CUDA 12.8、torch 2.8、Small 模型条件下的六次校准,现有常量加入了保守余量。它是该版本采用的估算模型,不是所有设备都测得同样峰值的承诺。
骨架和边缘模式采用另一组估计:固定基数 0.75 × 2^30,再加 4 × 帧数 × 处理宽 × 处理高。源码明确把这组数标为按内存结构构造的上界,不能写成同一组性能实测。
预算取物理内存总量的一半,给操作系统、浏览器和驱动留下空间;它没有按此刻空闲内存实时计算。因而预算内仍应检查本机是否已有其他高内存任务。Apple Silicon 使用统一内存,也不意味着这个主机估算已经覆盖模型的全部资源需求。
显存是模型在加速设备上的另一部分需求。plan 没有返回显存估计:主机内存充足的长片可以遇到显存不足,显存充足的设备也可以因整段帧驻留而超过主机内存预算。两种症状要分别处理。
fast、full 和 input-size 应该怎么选?
质量参数在本篇指深度模型的工作尺寸,不是视频编码压缩质量,也不是骨架检测器的精度档。
| 设置 | 当前代码含义 | 选择建议 |
|---|---|---|
--quality fast |
默认深度短边 364;常见 16:9 模型工作尺寸为 644×364 | 先用短片判断人物和场景的大体深度关系是否足够 |
--quality full |
深度短边 518;常见 16:9 模型工作尺寸为 924×518 | 细节确实影响控制用途、资源允许时再对照 |
--input-size N |
覆盖质量档;必须是正的 14 的倍数 | 需要自定深度工作尺寸时使用,改后重新查看计划 |
--max-res N |
控制输出长边上限 | 按后续输入要求选择,不能当成深度推理降档 |
以上尺寸来自 pipeline.py 的质量常量与模型尺寸说明。不同画幅有不同长边和对齐规则,不把表中 16:9 尺寸套到所有视频。
“先 fast,必要时 full”是本文操作建议。比较时保留同一小段输入、目标和输出设置,检查需要的前后层次、人物轮廓是否能用,再决定是否付出更高资源开销。更大的工作尺寸不自动保证后续生成更好;后续模型能否正确利用控制视频,还要单独验证。
该版本对部分 CUDA 设备上的高工作尺寸会发出显存风险告警,但告警仍允许继续运行,并不等于已经通过显存容量验收。本篇不把文档中的不同设备、不同版本耗时拼成统一速度,也不保证 full 在某个容量的设备上一定成功。
超预算、显存不足或输出过大,分别改哪里?
| 看到的现象 | 应先核查 | 建议动作 |
|---|---|---|
| 计划估计超过预算,运行报内存预算错误 | frames、proc_w、proc_h、ram_budget |
先把长片切成所需短段,再查看计划;或减少读入帧数 |
| 主机计划通过,模型阶段仍报 CUDA 内存不足 | 深度档位、自定义工作尺寸、设备上其他任务 | 先用 fast;已经设置 input-size 时核查它是否覆盖了质量档 |
| 深度输出尺寸超过后续输入需要 | out_w、out_h |
调整 max-res,同时确认目标对齐后的输出规格 |
| 骨架或边缘整段处理规模过大 | 这两类模式的读入尺寸和帧数 | 切短片,或在用途允许时降低输出长边 |
--max-frames N 限制的是源视频帧数,不是最终输出帧数。设置了较低目标帧率时,计划还会按比例估算处理帧数;因此不要直接把“输出帧率 × 想要的秒数”当成源帧数上限。建议优先切好需要的片段,以免截断动作。降低帧率会减少时间采样,是否影响动作表达也要检查。
内存预算超限对应 CLI 退出码 3。--force 只跳过预算拒绝,不会减少帧数组、增加内存或避免显存错误,不作为默认处理方法。源码中的 run 会先建立后端,再进入逐片计划和解码前预算检查;因此想在模型处理之前作决定,应单独调用上面的 plan,不能把普通运行的预检说成完全没有后端加载。
实际运行后怎样回查估算?
确认计划可接受且设备资源可用后,可以按以下命令执行;这是供读者使用的运行示例,本篇未执行:
reshot reference.mp4 -o depth-fast.mp4 --control depth --quality fast --metrics depth-fast.json
输入是本地视频;输出是深度控制视频和 JSON 指标。命令需要可用的深度模型权重及编码依赖,首次权重获取可能涉及下载,不能把它说成无条件离线。
成功后同时检查文件可播放、目标动作未被截断,以及指标中的 plan、output_size、peak_rss_bytes。深度模式还可对照 input_size_used 和 model_input_resolution,看是否用了预期档位。peak_rss_bytes 是进程驻留内存峰值,不是 CUDA 显存;ms_per_frame 是模型阶段每帧耗时,不是包含所有准备工作的平均时延。保存真实指标才能在自己的环境中比较两档;一份可播放文件也不等于每帧深度或后续生成已经验收。
资料定位:项目使用文档、计划与执行接口、内存估算代码。本文使用本地已保存的 0.5.0 快照,线上文件后续可能变化,复现时请先核对安装版本及相应源码。