EdenLive 生成一段镜头的等待时间没有固定基准，同样一段时长设置，快的几分钟、慢的几十分钟都正常。真正需要判断的不是「多久算慢」，而是这段等待卡在哪：显存峰值是否贴着上限、场景复杂度是否越过了拐点、还是导出与准备阶段拖了时间。可行的做法是先用 nvidia-smi 采样显存曲线，再在生成流程外面挂计时把等待拆成三段，最后固定分辨率只加物体数量做一次复杂度对照，把两个因素分开。

EdenLive 类似工具的单镜头等待，通常由显存峰值和场景复杂度共同决定，但两者表现不同：显存不足会出现降级、报错或显存占用停滞；复杂度上升则表现为生成段耗时随物体数量稳定增加。建议先跑一次带时间戳的显存采样，并把准备、生成、导出三段分别计时；若显存峰值长期贴近总量上限，优先降分辨率或换卡；若显存有余量而生成段时间随物体数线性上涨，先减场景内容。单次采样波动大，至少重复几次再下判断。

用 nvidia-smi 周期性采样显存占用

先拿到生成过程中的显存曲线，判断是否接近上限。采样放在开始生成之前启动，任务结束之后再停，这样首尾会对齐。Linux 与 Windows 下命令基本一致：

nvidia-smi `--query-gpu`=timestamp,memory.used,memory.total,utilization.gpu \
  `--format`=csv -l 1 -f gpu_samples.csv

-l 1 表示每秒采样一次；镜头较长时可以改成 -l 2，文件不会太大。如果同一张卡上还跑着别的进程，再加一条按进程采样，确认显存是 EdenLive 占的还是被别的任务吃掉的：

nvidia-smi `--query-compute-apps`=pid,process_name,used_memory `--format`=csv -l 1 -f gpu_procs.csv

与时间轴对照的方法很简单：采样文件第一列本身就是本机时间戳，只要计时日志和采样脚本跑在同一台机器上，把生成开始与结束时间按这一列对齐即可。跑完后直接看峰值：

awk -F, 'NR>1 {gsub(/ MiB/,"",$2); v=$2+0; if (v>m) {m=v; line=$0}} END {print m" MiB  " line}' gpu_samples.csv

曲线的作用是判断「有没有余量」。持续接近 memory.total 说明显存是瓶颈候选；采集周期内 utilization.gpu 时高时低、显存平稳上涨，说明计算还在推进，只是慢。

在生成流程外挂计时，把等待拆成准备、生成、导出三段

不去猜 EdenLive 内部接口，只在外部记录时间。下面的脚本放在你平时启动任务的同一台机器上，在点击生成前后各打一个点：

#!/usr/bin/env bash
LOG=edenlive_timing.log
mark() { printf '%s\t%s\t%s\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" "$1" "$2" >> "$LOG"; }

mark MARK_START '准备：开始导入素材、加载模型'
# 此处替换成你实际点击生成或启动任务的时刻
mark MARK_PREP_DONE '参数已填好，即将开始生成'
read -r -p '画面出结果后按回车 ' _
mark MARK_GEN_DONE '生成结束'
read -r -p '导出文件落地后按回车 ' _
mark MARK_EXPORT_DONE '导出结束'

三段耗时为：准备段 = MARK_PREP_DONE − MARK_START，生成段 = MARK_GEN_DONE − MARK_PREP_DONE，导出段 = MARK_EXPORT_DONE − MARK_GEN_DONE。替换项只有中间的注释行和回车提示语；验证方式是同一参数重复跑几次看波动，如果准备段每次都占大头，后面减场景或换卡的收益都会被稀释，应该先看模型加载、素材读取和磁盘。

固定分辨率只增加场景里的物体数量，找出复杂度拐点

把分辨率、帧数、时长、采样步数全部锁死，只动物体数量，才能把复杂度的影响从显存不足里拆出来。实验设计建议：从 1 个主体开始，每次增加 2 个物体或直接翻倍，每组跑两次以上，记录准备段、生成段、导出段耗时与显存峰值，填进同一张表：

拐点判定看两件事：一是相邻两组之间生成段耗时的增量是否明显放大，原本加两个物体多等一点、到某一组突然多等一截，那里就是拐点；二是显存峰值在同一组上跳变并贴近总量上限。记录时把每组的采样文件按组号重命名保存，方便回看曲线形状，而不是只记一个峰值数字。

记录显存接近上限时的报错和降级表现

真正的卡死和显存不足导致的降级要分开。报错文本的获取位置：如果你从命令行或启动脚本调起 EdenLive，把标准输出和错误重定向到文件，例如 ... > run.log 2>&1；从桌面启动器启动的，去找启动器的日志目录或运行目录下新生成的日志文件。Linux 上还可看内核侧是否记录了显卡相关错误：

dmesg -T | grep -i -E 'nvrm|xid|out of memory'

降级不一定报错，但输出会变。对比方式是：用同一提示词和同一参数，分别生成低复杂度与高复杂度两个场景，用 ffprobe 核对实际输出的分辨率、帧率、帧数是否和设置一致：

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,r_frame_rate,nb_frames \
  -of default=nw=1 output.mp4

同时人工记录可观察差异：画面细节是否糊、运动是否断续、结尾几帧是否重复或停住。判断真卡死的经验标准是：显存占用和 GPU 利用率长时间完全不动，且日志文件也不再增长；如果两者仍在变化，多半只是慢，不要急着中断。

按实测结论给出先减少场景还是先换硬件的判断顺序

按下面顺序走，不要同时改两个变量：

1. 先看显存峰值。若峰值在多数组次中都贴近 memory.total，并伴随耗时跳变或输出降级，先降分辨率、帧数或单次批大小，再考虑换卡。
2. 若显存峰值离上限仍有明显余量，但生成段耗时随物体数量近似线性增长，问题在场景复杂度，先减场景：拆镜头、删非必要物体、简化材质与透明叠加。
3. 若降分辨率后显存峰值下降而生成段耗时几乎不变，说明瓶颈不在显存，减场景的优先级高于换硬件。
4. 若准备段或导出段占总等待的大头，换显卡帮助有限，先查模型加载、素材读取、磁盘与编码设置。

边界提醒：上述判断依赖采样周期和重复次数，单次结果不足以定论；不同项目、不同驱动与不同 EdenLive 版本的表现会有差异，结论需要结合当前环境复测确认。