视频工作流中的并行协调机制
来源：Global Video Tech Meetup: Denver 主讲人：Douglas Bay 内容整理：付一兵 本文讨论了视频工作流中的并行协调机制，即如何利用并行作业来确保我们需要运行的转码、打包或其他类型的服务，并以快速和可伸缩的方式完成。
目录
- 并行工作流
- 例子：如何在并行工作流中执行转码
- 并行平台
- 总结
并行工作流
一些可以利用并行服务的平台可能是转码、点播打包、即时打包、或者只是普通的视频，就像我们的视频管道中注入的普通元数据一样。下图是视频并行的一般工作流，
有一个服务器有 api，这个服务器很可能会调用另一个引擎，引擎要做的是根据 api 来决定哪个客户端要运行哪个作业。引擎能够分析每个客户端的内存和每个客户端的处理器速度，并且会根据处理和内存选择可用的最佳客户端。现在所有这些客户机都将同时运行作业。
在某些情况下 我们需要消息代理。例如，当我们在转码时，视频被分块，我们想把它们拼接在一起，我们需要引擎知道这个工作什么时候完成，哪些块完成了，所以我们会使用像 Kafka 的消息代理。
例子：如何在并行工作流中执行转码
在这个例子中我们有一个客户端，客户端会调用服务器上的 api，编码 h265QT 到 h264TS，服务器上的服务或应用会创建执行该工作的命令，在这个例子中我们使用简单的 ffmpeg 命令ffmpeg -i bickbuckbunny.mov -vcodec libx264 -acodec copy bickbuckbunny.ts
但我们不能把这个命令发送给所有的客户端，因为所有的客户端会同时对整个影片进行转码，这当然是没有价值的。我们的服务器将需要分解这些命令，并将这些命令发送给客户端。此外，引擎会根据我们提供的设置知道编码这个区块需要多少内存。
所以现在引擎将会有一个 ffmpeg 命令的列表，每一个 ffmpeg 命令实际上代表了整个电影的整个转码过程，引擎也会知道每个命令需要多少内存，此时引擎会分析每一个客户端的内存和处理可用性，然后它会把每一个单独的命令发送给这些客户端。现在 每个客户端都要挂载相同的服务器和完全相同的存储，它将访问源文件，从源文件读取并写入输出文件夹。由于是并行，所以需要把结果合并。一旦每个工作完成 我们将联系消息代理，它会跟踪这些作业什么时候完成并向引擎发送消息，或向引擎之前的服务器发送消息。
块转码完成后，我们将计算整个工作完成的时间，然后将它们连接在一起，这时就完成了转码工作。这样有很强的灵活性，可以在 Prem 或云上进行，通过集装箱化可以运行任何 ffmpeg 命令。
并行平台
- HashiCorp Nomad
- Kubernetes
- AWS ECS
这三个平台都有各自的优缺点。以 Nomad 为例，当通过 nomad 运行一个作业时 我们只是发送一个 Json 来执行我们的命令。
总结
- 我们的编码器 api 能够让终端用户指定需要完成转码或打包的日期和时间。
- 换句话说我们现在可以根据我们需要它的确切时间进行转码。如果一小时内需要，我们一小时就能完成。
- 在云上，我们可以在作业运行时动态启动客户端，以确保大型一次性作业的可伸缩性
- 我们可以动态运行 特别是当我们在云上运行时可以动态地伸缩客户端来减轻负载，或者为更大的一次性任务提供更多的负载
- 我们可以在并行平台执行转码或打包作业，平台与作业类型无关
- 像 Nomad 这样的平台的真正优点在于，它与你所做的工作类型是独立的。在这一点上我们可以通过相同的工作流运行运行一个打包工作或者几个视频块转码工作。
附上演讲视频：
http://mpvideo.qpic.cn/0bc3maabsaaaa4akwwrbfrrfaygddfqaagia.f10002.mp4?dis_k=f8ecc251c80f3e7434888d9167098df9&dis_t=1649675013&vid=wxv_2294842238243536898&format_id=10002&support_redirect=0&mmversion=false