本文主要聊一聊云原生时代分布式转码系统实施过程中碰到的一些问题。
聊问题之前简单介绍一下我们的分布式转码方案。
云原生分布式转码
在计算资源招之即来的云计算时代,正在重构着软件架构的方方面面。
对软件架构师或者运维管理者影响比较大的一个点便是不需要在做容量规划,不需要提前评估为了应对某个活动应该准备多少台机器,这个特点也深刻影响软件架构的设计。
分布式转码方案
在之前的文章中有说到视频转码主要分为3个步骤:
- 切片:将输入的视频进行切片,切分成一个个较小的视频片段
- 转码:将一个个小的视频片段下发到不同的机器上进行转码,并行执行,充分利用多个实例的计算能力
- 合并:将转码后的小视频片段合并成一个视频
切片 转码 合并
输入视频 ------> (n个)转码任务 ------> (n个)转码结果 -----> 输出视频
为什么要切片?
为了加快转码速度。
视频转码是一个非常耗时的操作,让不同的机器并行转码不同的视频片段,可以充分利用大规模计算资源来加快最耗时的转码流程。
举一个例子,假设1台4核8G的机器能够提供2倍速的转码速度,
- 转码1个小时的视频则需要30分钟;
- 如果将1个小时视频分成2个片段(每段30分钟),就能够并行在2台机器上执行,那么每个片段分别只需要15分钟就能够转码完成;
- 如果将1个小时视频分成4个片段(每段15分钟),就能够并在在4台机器上执行,那么每个片段分别只需要7.5分钟就转码完成;
理论上对视频进行合理的切片加上充足的计算资源,能够极大的提高转码的速度。
虽然这种分布式切片转码方案优势这么明显,但是在实践过程中也发现了不少问题。
想借此文跟大家探讨一下我们碰到的部分问题以及解决方案,看看大家有没有更好的方案。
要是能够给大家带来一些帮助、少踩两个坑,目的就达到了。
碰到的问题
- 不聊工程上的问题,工程上的问题都比较好解决
- 主要聊ffmpeg切片、转码、合并过程中所遇到的问题
- 知识储备的原因,有些ffmpeg底层的原理可能会一笔带过。。
m3u8转码后有杂音
对于m3u8转码,我们在切片环节直接用ts文件作为切片,转码后再合并为最终的视频文件。