我有一个网络应用程序，允许用户在较长的主视频(通常为 45 分钟，但文件大小可能差异很大)中插入短广告视频(30 到 60 秒)。
整个过程涉及：
- 从 s3 导入所有选定的文件
- 将每个编码为通用方案，
ipad-high. - 从主视频中提取剪辑。
- 将主视频中的所有片段与广告视频连接起来。
对于要插入主视频的n个视频，将提取n + 1个剪辑。
由于 Transloadit 不提供任何关于程序集可能运行多长时间的估计，因此我希望找到一种方法来自己估计这一点，以便我可以显示进度条或仅显示 ETA，让用户了解他们的工作需要多长时间。
我的第一个想法是确定程序集中所有文件的总大小，并将其保存到某个 redis 数据库中，以及完成时间。
后续运行将以此作为基准，即如果 60GB 需要 50 分钟，则 25GB 需要多长时间。
redis上的数据将不断更新(我想我可以使这些值成为各种运行平均值)，以使估计值尽可能可靠。
欢迎任何想法，谢谢:)
我将解释Transloadit关于这个问题的一些对话：
- 估计程序集的持续时间是一个复杂的问题，因为计算中需要考虑多少因素，例如：正在上传的 zip 中有多少个文件？将导入目录中有多少个文件？ 有多少文件将通过
colorspace: rgb过滤器？这些东西只有在大会运行时才会发现 - 但它们可以疯狂地改变ETA - 有一个仪表板的计划，该仪表板将展示包含程序集信息的图形 - 例如以 Mbit/s 为单位的吞吐量，结合模板和文件大小的历史数据，可用于粗略估计。
- 一个建议是，与ETA相比，实现进度条来显示每个步骤或作业何时完成可能更容易。这样做的缺点当然是准确性，但这可能是您前置解决方案所需要的全部
- 您可能还有兴趣研究涡轮增压模式。如果您使用的是
/video/encode或/video/concat机器人，它可能有助于显着降低编码速度