一段视频的处理耗时，通常由“逐帧识别”和“编码导出”两段组成，打码鸭这类工具把它们放在同一条进度条里，所以只看进度条走得慢，判断不出卡在哪一步。可行的做法是分开计时：先记录整段总耗时，算出总耗时与视频时长的比值当基准，再只跑识别不导出，看时间停在哪一段。视频分辨率、帧率、编码格式、机器 CPU 与是否用到 GPU 都会影响结果，下面的命令和记录格式需要用你自己的素材复测，不要直接沿用别人的倍速。

处理耗时该往哪优化，取决于识别与导出哪段占大头。先测总耗时÷视频时长得到倍速基准，再用预览或仅识别模式单独测识别段；把同一素材缩到更低分辨率重跑，若识别段明显变短，瓶颈就在逐帧识别，优先考虑降分辨率；若时间主要花在写出文件，切段更值得试。降分辨率可能让画面里的小目标识别变弱，切段会带来衔接问题，两种做法都要先确认输出质量可以接受，再批量套用。

先记录整段视频的总耗时和视频时长

先拿到视频时长，再记录完整走一遍的耗时，两者相除得到“倍速”，后面所有对比都以这个倍速为基准。

ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 input.mp4

输出是秒数，除以 60 换算成分钟即可；也可以用 mediainfo 这类工具看时长。计时建议在命令行里包住整个启动过程：

start=$(date +%s)
# 在这里启动打码鸭处理 input.mp4，等它完全退出
end=$(date +%s)
echo "总耗时: $((end - start)) 秒"

Windows 下可以用 Measure-Command 包住启动命令。记录表建议固定三列，同一份素材、同一台机器、同一套参数下填写：

视频文件      视频时长   总耗时    倍速(总耗时/视频时长)
clip_a.mp4   12:30      25:40     约 2.05
clip_b.mp4   03:00      05:20     约 1.78

表里的数字只是格式演示，务必替换成你自己的实测值。倍速小于 1 说明处理比视频本身回放还快，大于 1 说明要花更长时间。

只跑识别不做导出，看进度停在哪个阶段

打码鸭的进度条一般不会告诉你现在跑的是识别还是编码，所以要在进程外面记录时间点。如果界面里有“预览”“试看”或只处理前若干秒的选项，就用预览来测识别段；如果设置里有“仅识别/仅检测”或导出时复制原始视频流、不重新编码的选项，用它能把导出段压到最省。

两个阶段各记两个时间点：

• 识别开始：点击开始处理的那一刻
• 识别结束：进度文案跳到“编码/导出/合成”，或日志出现对应关键字
• 导出开始：同上，与识别结束基本重合
• 导出结束：输出文件不再增长、进程退出

没有分段提示时，可以盯输出目录里新文件的大小变化来判断导出是否开始：识别阶段通常不写视频文件，导出阶段文件体积会持续增长。记录成下面的形式，识别耗时就是“识别结束－识别开始”，导出耗时就是“导出结束－导出开始”。

阶段      开始时间   结束时间   耗时
识别     00:00      08:10      8分10秒
导出     08:10      25:40      17分30秒

如果打码鸭提供日志文件，优先用日志里的时间戳，比人工卡表更稳。这一步只用来定位瓶颈，不要同时改参数，否则下一组对比就失去参照。

把同一段素材缩到更低分辨率再跑一次

把原片缩放一份，再喂给打码鸭，参数和第一次保持一致，只改分辨率。缩放用 ffmpeg 即可：

ffmpeg -i input.mp4 -vf "scale=1280:-2" -c:v libx264 -preset veryfast -crf 20 -c:a copy input_720p.mp4
ffmpeg -i input.mp4 -vf "scale=640:-2"  -c:v libx264 -preset veryfast -crf 20 -c:a copy input_360p.mp4

scale=宽:-2 表示高度按比例自动取偶数，避免编码器报错。缩放本身也耗时，只用来准备素材，不计入打码鸭的耗时。对照表按“分辨率 / 估算像素量 / 识别耗时 / 导出耗时 / 总耗时”记录：

分辨率     像素量(约)   识别耗时   导出耗时   总耗时
1920x1080  207万        8:10       17:30      25:40
1280x720   92万         (填)       (填)       (填)
640x360    23万         (填)       (填)       (填)

看的是趋势：像素量降下来之后，哪一列明显缩短。若只有识别列缩短、导出列变化不大，说明瓶颈在识别；若两列同步下降，说明当前参数下两段都对分辨率敏感。低分辨率下画面里的小字、小目标可能识别不准，测完要回看输出，确认没有漏打码。

把长视频按固定长度切段分别处理

切段用 ffmpeg 的 segment 参数，不重编码只复制流，切得很快，但切点会落在关键帧上，所以每段实际长度会有几秒偏差：

ffmpeg -i input.mp4 -c copy -map 0 -f segment -segment_time 300 -reset_timestamps 1 seg_%03d.mp4

-segment_time 300 表示每段约 5 分钟，可以按内容改成 60 或 600。切好后逐段跑打码鸭，逐段记录耗时：

片段        时长    识别耗时   导出耗时   总耗时
seg_000.mp4 5:02    (填)       (填)       (填)
seg_001.mp4 4:58    (填)       (填)       (填)
seg_002.mp4 5:01    (填)       (填)       (填)

重点看两件事：单段耗时是否大致随段数线性增长；有没有某一段明显比别人慢。明显偏慢的段通常对应画面更复杂、运动更多或关键帧更密的片段，单独重跑一次确认是否稳定复现。如果切段后的总耗时反而比整段跑更长，多半是每段启动识别与编码器的固定开销被重复计入了，这时候段数就不宜再增加。

根据上面几组数据决定降分辨率还是切段处理

把上面的记录放在一起看，判断依据可以落到三条：

• 识别耗时占总耗时比例高，且降分辨率后识别耗时明显下降——优先降分辨率，只缩小送进识别的输入，导出分辨率可以另做决定。
• 导出耗时占大头，且逐段耗时近似线性、没有异常慢的段落——优先切段并行处理，让多段同时导出，通常比整体等待更省时间。
• 只有个别段落异常慢，其余正常——不要整体降分辨率，先单独重跑那几段，再决定要不要单独处理。

如果两段都占得多，可以先切段、再对每段降一档分辨率，但这样会同时引入画质下降和拼接误差，需要逐段确认打码是否完整。判断的边界也在这里：降分辨率会牺牲画面中原有的小目标识别效果，切段可能让跨段的动作或人脸追踪在边界处出现跳变，两种做法都建议先用一段短视频试，确认输出可用再批量处理。最终以你自己那份对照表的数字为准，别人的倍速只能当参考。