点了 Sonilo 的分析按钮之后长时间没有结果，最难判断的是两件事：它到底还在算，还是已经停住了；以及该先降分辨率还是先缩短区间。这两项都会拉长等待，但成因不同——区间拉长是增加要处理的帧数，分辨率变高是增加每一帧的像素量。用控制变量法各跑一次，就能看出等待时间主要来自哪一项。
等待时间通常由「分析区间长度 × 分辨率」共同决定，但两者可以分开验证：先固定素材和分辨率，只把区间从整段改成前 10 秒，看结束时间是否随之提前；再固定区间，把素材降到较低分辨率重跑。缩短区间减少的是总帧数，降分辨率减少的是单帧计算量，一般优先做前者。只有当进度与日志都不再变化时，才按卡住处理，此时再考虑拆段或重启。
在同一素材上分别测试只分析前 10 秒与整段
这一步只动区间，其他全部不动。素材固定条件：同一个文件、同一条路径、同一帧率、同一种分析类型或模型、同一台机器；测试期间把后台占资源的任务尽量停掉，两次测试不要同时跑，否则会互相抢资源，时间没有可比性。
两次测试的区间设置：第一次用默认的整段或「全片分析」，第二次手动把起止点设成 0 到 10 秒，只分析前 10 秒。如果界面只支持拖动进度条选段，就把起点拖到最前、终点拖到大约 10 秒处，并把选区截图或记下具体秒数。
记录开始与结束的方式：点下开始的同时记一个时刻，看到结果出现时再记一个时刻，两者相减就是本次等待时间。可以用系统时间、手机秒表，或直接记下界面显示的时间。除总时长外，建议顺手记下结果面板里显示的处理时长或帧数，用来判断等待是否随区间长度大致成比例变化。
测试记录模板（区间对比）
素材 : clip_a.mp4（固定）
分辨率 : 原始（固定）
区间 : 整段 开始 __:__:__ 结束 __:__:__ 等待 ____
区间 : 0-10 秒 开始 __:__:__ 结束 __:__:__ 等待 ____
结果是否可用: 整段 ______ 前 10 秒 ______如果整段要等很久、前 10 秒很快出结果，说明等待时间主要跟着区间长度走，缩短区间是更有效的第一步。如果两者差得不多，区间不是主因，接着做分辨率对照。
把素材降到较低分辨率再跑同样的区间
这一步只动分辨率。做法是用同一个源文件导出一个低分辨率副本，例如把长边压到 720 或 480，具体数值按素材内容和可接受的结果精度来定；导出时保持帧率、时长、音轨和编码格式不变，只改分辨率。如果 Sonilo 自身提供「分析前缩放」或类似的快速模式，也可以在原文件上直接勾选，但要记下勾了哪几项。用 ffmpeg 生成副本的通用骨架如下，参数按实际环境替换：
ffmpeg -i clip_a.mp4 -vf scale=-2:480 -c:a copy clip_a_480.mp4两次测试必须一致的设置项：分析区间（都用同一个区间）、分析类型或模型、语言与其它参数、输出格式、同一台机器，以及测试时的后台负载。只允许分辨率不同，否则结论不成立。
结果对比的记录方式：在上一张记录表后面再加两行，分别写原始分辨率和低分辨率副本的等待时间，并单独标注结果精度是否可以接受。等待明显变短但结果仍够用，说明分辨率是主要负担；等待变化不大，说明瓶颈更可能在区间、模型加载或磁盘与解码环节。
用界面进度或日志判断是在处理还是已停住
界面进度是最先看的信号：进度条是否持续前进、百分比或已处理时长是否增长、当前处理到素材的第几秒是否在变、状态文字有没有从「排队/加载中」进入「分析中」。只要其中一项还在稳定变化，通常说明任务仍在处理，只是比预期慢。反过来，如果进度与状态文字长时间停在同一个数值，就需要去看日志。
日志输出位置常见于：界面内的日志或输出面板、工作目录或用户数据目录下的 .log 文件（常见命名如 app.log、sonilo.log，或按日期命名的日志文件）；如果是命令行启动的，终端里的标准输出也算日志。重点看最后几行的落点——停在模型加载、解码、抽帧还是后处理，位置不同，下一步的处理方向也不同。
典型停滞表现可以分两类：一类是还在算但界面没刷新，日志仍在追加、CPU 或内存占用持续波动，进度条却不动或更新很慢；另一类是真的停住或已退出，日志不再新增，CPU 掉到接近空闲，界面状态文字也不再变化。两类都不建议用固定秒数判定，而是拿同一素材的前后两次运行对比，看是否停在同一位置、有没有报错行。
按区间优先、分辨率其次的顺序调整单次负担
调整顺序建议是：先缩短区间，再降分辨率，最后才拆成多段。缩短区间减少的是要处理的帧数，通常比降分辨率更容易回退，也不会直接损失画面细节。
- 缩短区间：把本次分析改成只跑最需要的那一段，先跑一次，确认能在可接受的时间内出结果。验证观察点：等待是否明显提前结束、结果内容是否确实对应你选的区间。
- 降低分辨率：在同样的区间下换成低分辨率副本或开启分析前缩放。验证观察点：等待是否进一步变短，以及结果精度是否还能支撑你的用途；如果关键细节丢失，这一步就该退回。
- 拆成多段处理：把长素材按时间切成若干段分别分析，再在结果侧合并。验证观察点：每段是否都能独立出结果、相邻段之间是否留了重叠以防切掉边界内容、合并后是否出现重复条目。
如果走完这三步等待仍然很长，需要结合环境确认别的因素，比如模型首次加载、素材存放在慢速磁盘或网络位置、后台同时跑了其他分析任务。这时先把并发降到一次只跑一个任务，再重复上面的对照测试，判断是否只是资源被分摊导致的等待。