实时转码系统（建议收藏7000字详解青云实时音转码系统架构）

李小文

青云科技顾问级研发工程师

主导青云音视频处理相关技术架构设计，长期从事分布式系统的设计开发，在音视频领域耕耘多年，致力于持续提升青云音视频相关的产品能力和服务质量。

前言

近年来，随着互联网内容的更新迭代，音视频的内容形式已经逐渐取代了传统的文字和图片，语聊、短视频、点播、直播等交互形式已经深深地“侵蚀”了各个年龄阶段的用户。Cisco Study 指出，截止 2019 年，音视频流量已经占据了整个互联网 80% 以上的流量。

本文将结合青云在音视频转码领域所做的探索和实践经验，详细介绍青云是如何使用 GPU 和 VPU 等多种异构硬件来加速视频转码的。

本文主要包括三个方面：

一、介绍音视频转码领域相关的现状，转码已经成为音视频行业的基础和刚需。

二、介绍主流的异构转码硬件的特性，以及青云转码集群的架构设计及其细节。

三、对青云的转码系统进行简单的性能测试。

01 转码已是音视频行业刚需

音视频的内容生产和消费其实是不对等的，用户在生产音视频内容时，通常只会产生一路或几路特定规格的音视频。

而当音视频在消费时，却需要应对复杂的网络环境（有线、WIFI、移动网络等）、解码能力不一的各式终端，以及灵活多变的用户需求（多画面展示、水印、超分、高质低码等）。

同时，由于音视频编码标准的快速演进，以及 H265/VP9/AV1 等编码格式的快速普及，使得对原始音视频进行编码格式、分辨率、带宽、帧率、封装格式、水印等诸如此类的转码处理，成为整个音视频行业不可或缺的一环，转码已然成为行业刚需。

目前，音视频转码主要运用在以下领域：

一、企业/个人转码软件，比如：

• 专业的音视频制作软件，如剪映、爱剪辑等。

• 音视频工具类 APP，如格式工厂等。

• 用户上传音视频后调用的云端 SaaS 服务。

二、嵌入到相关产品或单独推出转码服务的 PaaS 形态，比如：

• 云点播/云直播等音视频产品下的转码功能，目前青云的转码功能就运用在了云点播产品中。

• 单独推出的云转码服务。

02 主流的转码硬件

一、CPU：Central Processing Unit，中央处理器，架构特征如下：

• 逻辑控制单元多，适合不同类型的复杂任务。

• 计算单元少，一次只能执行几个任务，容易排队。

• 采用串行编程模型。

CPU 的架构特征决定了 CPU 用于音视频转码领域的优缺点：

• 优点：兼容性好，画质高。

由于采用软编软解，几乎兼容所有的视频编码格式，除最常见的 H.264/H.265 外，还支持 H.263( )/MPEG-1(2/4)/MJPEG/VP8/VP9/Quicktime/RealVideo/Windows Media Video 等（尤其是较老旧的编码格式只能用 CPU 解码）；音频编码格式如 AAC/MP3/VORBIS/RealAudio/Windows Media Audio 等。

• 缺点：转码效率低，并发少，还可能阻塞其他程序的运行。

二、GPU：Graphics Processing Unit，图形处理器，架构特征如下：

• 逻辑控制单元少，适合处理类型简单的、重复度高的任务。

• 计算单元多，可以大批量同时处理多个任务。

• 采用并行编程模型。

GPU 的架构特征决定了 GPU 用于音视频转码领域的优缺点：

• 优点：针对视频转码领域，GPU 在架构设计时，专门包含了一个或多个基于硬件的解码器和编码器，因此在调用 GPU 进行视频编解码时，完全不用 CPU 参与，并且单卡并发路数高。

• 缺点：满载功耗高，直接限制了单节点和单机架的插卡数量，相应的对机箱和机架的散热要求也高。

三、VPU：Video Processing Unit，视频处理器，是专门针对视频编解码领域推出的专用芯片，具有以下特征：

• 内置视频编解码加速芯片。

• 内置 AI 引擎，可实现画质增强、ROI 编程等。

• 通过 PCIe 四代标准高速接入，支持热插拔。

• 单块卡满载功耗低，满载并发路数多，占用极少的机架资源（功耗、散热、 PCIe 槽位等）。

VPU 兴起较晚，某些方面还有待发展，比如：

• 支持的编解码格式单一，通常只支持 H264 和 H265 的编解码；

• 支持的功能单一，仅支持视频编解码，是专用芯片；

• 在 AI 处理、深度学习相关领域无法与并行计算能力强大的 GPU 比拟，比如慢动作补帧、 AI 物体擦除、自动美颜等。

03 软件处理框架

软件层面底层调用的是 FFmpeg 多媒体处理框架，该框架概要图如下：

自上而下依次是：

一、工具集

• FFmpeg 是进行音视频转码的命令行程序。

• FFprobe 负责提取音视频文件的媒体信息，如封装、音视频流、帧信息等。

• FFplay 是自带的播放器程序。

二、FFmpeg 核心库

• libavcodec 是最重要的核心库，负责所有类型的音视频编解码操作；

• libavfilter 包含各种音视频滤波器的实现，可实现裁剪、缩放、水印、旋转等特效处理；

• 另外，libavformat 用于处理各种媒体容器格式（封装格式）的复用和解复用。

三、适配硬件加速的 SDK 或插件库

• 通过 SDK 或插件形式可以实现各种类型加速硬件的接入，如 Intel/NVIDIA/ 专用 VPU等。这层适配库是 FFmpeg 命令行能调用各种不同类型硬件的关键所在。

04 转码任务分类

目前，青云的转码运用在了云点播产品之中，云点播产品支持以下几种转码任务类型：视频转码、音频转码、自适应转码、抽帧截图、水印、裁剪，以及长视频拆分和视频合并等。

经过技术分析结合实际测试发现，这些任务大致可以分为两类：

一、视频类的任务：如视频转码、水印、自适应转码。

视频类的任务，通常包含了视频解码和编码两个比较消耗计算资源的过程，原则上也可以调用通用 CPU 进行，但是通用 CPU 执行视频编解码效率很低，即使指定 16 核执行，执行时长以及系统容量也令人失望。因此视频类型的任务通常优先选择视频编解码能力强大的 GPU 和专用 VPU 进行，从而提高视频转码的响应性，以及整体容量。

二、“非”视频类的任务：包括音频转码、裁剪、抽帧截图、以及视频拆分与合并。

“非”视频类的任务，通常不包含视频编解码操作。具体而言，裁剪运用了视频关键帧快速定位技术，直接采用 CPU 即可快速响应。视频拆分跟裁剪操作类似，根据关键帧以及分段时长，快速对长视频进行多段的裁剪拆分操作，使用 CPU 就可以高效完成。

同样的，相同编码参数的短视频合并操作，也不涉及视频的编解码，重新封装成一个完整的长视频即可。经过实际测试发现，抽帧截图采用 GPU 或 VPU 执行对性能提升不大，转为采用 CPU，后续存在优化空间。

需要特别注意的是，GPU 和 VPU 支持的视频编解码格式比较有限，特别是专用的 VPU，如果碰到不支持的视频编码格式，这样的任务通常需要 CPU 执行软解码，编码方向可以继续选择 CPU 软编，或转为采用 GPU 或 VPU 进行加速。

05 青云转码设计

一、整体设计

青云转码集群的总体架构：

云转码用户通过云点播网关接入系统，通过控制台界面可以进行转码模板和任务的增删改查，媒资上传、下载、播放等操作，以及向集群发起转码请求，所有用户上传和转码输出的媒体文件都保存在青云对象存储中。

转码集群中有一个转码控制器，控制器能够接收转码 Worker 的注册和心跳消息，定期更新转码 Worker 的状态信息，并且从消息队列接收来自网关的转码请求，根据任务配置以及 Worker 的负载信息，选择一个或多个 Worker（分片转码）执行转码任务。

转码 Worker 负责对接不同的转码硬件，在 Worker 上 CPU 总是必须的，通常 GPU 和 VPU 会分开部署，一是两者安装的 FFmpeg 不兼容，二是两者通常都是通过 PCIe 接口接入物理机，存在竞争 PCIe 插槽的问题。转码 Worker 负责从控制器接收转码任务，执行最终的转码工作。

在整个系统中，一些必要的公共组件，如云服务器、负载均衡器、消息队列、对象存储服务、数据库、ELK 日志搜索以及告警接入、可配置通知等服务由公有云提供，方便开发人员简化系统设计，更专注于转码领域本身的技术特性。

二、并发调度策略

转码集群主要是通过 Worker 的负载信息来进行转码任务的并发调度：

转码 Worker 启动时需要向控制器进行注册，并携带自身的硬件信息以及负载详情。在运行过程中，周期性地向控制器上报自己的负载信息，并且在负载迅速增减或者发生切变（变满载或变空闲）时，增量上报及时更新控制器一侧的负载数组。

控制器在收到网关的转码请求后，总是根据任务类型和最低负载原则，选择合适的目标硬件类型以及最为空闲的 Worker 进行转码操作。如果转码请求中同时含有视频类和非视频类的任务，那么仍然判断为视频类任务，在装配 GPU 或 VPU 的 Worker 上，非视频类的子任务会采用 CPU 执行方式，同时视频类的子任务会采用 GPU 或 VPU 的方式执行。

Worker 上报的负载信息主要有三类：

1、硬件负载数组 PlatForm Loads，一项数据包含：

• 硬件类型（XPU：CPU/GPU/VPU）。

• 总体解码空闲值，如 2 个 GPU 解码单元均空闲为 200%。

• 总体编码空闲值。

• 多解码器负载数组（各解码器的解码空闲值）。

• 多编码器负载数组（各编码器的编码空闲值）。

2、系统负载 System Load，包含：

• CPU 使用率。

• 内存使用率。

• 下行带宽空闲余量。

• 上行带宽空闲余量。

3、主要过程并发数 Multi Load，包含：

• 等待下载数量、总大小。

• 并发下载数量、总大小。

• 并发转码数量、总时长

• 并发上传数量、总大小。

三、分片转码

音视频转码耗时主要有 2 个影响因素：源文件时长（耗时与之成线性关系）和目标编码规格（目标规格越高越耗时，如 2K 60fps 耗时显著高于 1080P 30fps）。

如果用户要将一个长时间视频文件，如 3 小时时长，进行高规格的转码输出，那么通过常规的一次执行一个完整任务的形式，只能调用一次异构硬件，是无法缩短执行时长的。

青云的转码系统设计引入了分布式分片转码，将长时间文件切分为多个片段，多片段同时在多个 Worker 上分片转码，然后合并得到结果文件。通过分片转码，杜绝了长耗时任务只能通过系统的单节点垂直能力的提升才能得到优化的弊病，在垂直能力不强的集群中，可以利用多台机器协作完成转码。

四、技术原理

分片转码技术原理如下：

分片转码主要分为 3 个步骤：

1、对原始的长视频文件执行分片操作，根据关键帧快速定位，按照指定的时长对视频进行切分。

2、对所有分片好的视频片段，运用相同的编解码参数进行转码操作，得到对应数量的分片结果文件，并发的分片转码可以在多台 Worker 上执行，也可以在一台机器上执行多片的转码。

3、对分片转码得到的所有分片结果，执行合并操作，即可得到一个完整的长视频结果文件。

4、（可选）如果用户最终指定的输出格式为 HLS，那么还需要对结果文件执行一次 HLS 格式的分割，该过程不涉及视频的编解码，CPU 即可快速执行。同样的 MPEG-DASH 封装格式亦是如此。

五、执行流程

分片转码的执行流程如下：

1、用户通过云点播控制台，SDK 或 API 发起转码请求。

2、网关校验请求，如验证用户信息、账户信息、调用频率等，校验成功后通过消息队列发送到控制器。

3、控制器读取转码请求，分析转码任务类型，选定转码硬件类型，以及是否需要分片执行等。

4、如果不需要分片，则选择一台目标硬件类型最空闲的 Worker 执行任务即可。如果需要分片，则选择一台目标硬件类型最空闲的 Worker 执行分片任务，分片任务本身采用该 Worker 上的 CPU 执行。

5、分片的过程主要是从对象存储下载源文件，然后对长视频进行快速分片，分片结果本机暂存。

6、分片完成后，该 Worker 向一个高优先级队列发送原转码请求，并携带目标硬件类型，分片详细信息，如：分片 Worker 地址信息、分片文件所处目录、分片数量大小等。

7、控制器从高优先级队列读取带分片信息的转码请求，根据目标硬件类型选择不多于分片数的目标机器，并优先选择分片 Worker 作为 MainWorker，即执行第一个分片的转码工作。

8、各个 Worker 分别执行分片的转码工作，即从分片 Worker 处拷贝分片源文件，然后按照相同编解码参数执行转码；转码完成之后，将分片结果文件传回 MainWorker 的指定目录，并标记该路执行完毕。

9、各个分片 Worker 在执行分片转码的过程中，会定期将转码进度汇报给控制器，由控制器对个别进度特别缓慢，或者无响应的 Worker 进行替换，以避免子任务陷入无限期的等待。

10、MainWorker 在自己转码完成之后，会启动扫描过程，扫描所有分片结果文件是否已经正确得到了；如果所有分片工作都完成了，那么 MainWorker 会进行分片合并，该过程由 CPU 执行。

11、MainWorker 执行合并完成之后，会将结果文件上传到对象存储中，并且发送任务完成通知标记任务结束。

六、分布式协调

分布式分片转码任务启动后，控制器有必要对该分布式任务进行管控，以防止某些 Worker 因进程退出、网络中断、进度异常缓慢等不可预料的因素导致的分布式任务无法及时完成的问题。控制器对子任务的协调机制如下图所示：

转码 Worker 会定期向控制器上报自己的转码进度，控制器将根据整体进度，判断少数特定的 Worker 进度是否严重滞后，一旦判定滞后节点，控制器会重新选择一个对应硬件类型最空闲的冗余节点，启动该分片的转码工作，同时老的滞后节点会继续执行分片转码，直到有一个节点完成了工作，那么另外一个节点的工作将被立即取消。在选择新的冗余节点时，会优先考虑 MainWorker 节点，因为该节点没有下载分片文件以及上传结果文件的步骤，只需要进行分片转码工作。

如果判定 MainWorker 进度滞后，存在两种情况：

1、其他 Worker 下载分片完成或下载进度正常，那么控制器优先在组内选择最空闲的机器担任新的 MainWorker 角色，从原 MainWorker 下载分片继续执行，并且通知组内所有 Worker MainWorker 发生变更，后续新的 MainWorker 将负责合并结果分片，以及上传、通知等处理。

2、存在 Worker 无法下载分片的情形，那么控制器将直接取消整个分布式任务，重新启动一次完整的分布式转码流程。

七、并行流水线

在 Worker 具体的转码过程中，分为主要的 3 个过程：下载源文件、执行转码、上传结果文件。

下载和上传取决于整体的网络上下行带宽，特别是在多任务并发下载和上传时，单个任务的带宽会被平均而降低，从而增加文件下载和上传时间，因此这 3 个过程都是比较耗时的过程，特别是其中的转码部分。如果采用同步的方式，后面过程的开始总是需要等待前面过程的结束，容易造成各个环节的相互等待，出现某些资源空置的问题。

为充分提高整个系统的并发度，充分利用上下行带宽、各种转码资源，将这 3 个主要的耗时过程进行了流水线化的设计：

各个过程异步的并发执行，如同时启动多个任务的源文件下载，下载完成之后放到待转码队列中；并发转码模块也是类似，在硬件负载能承受的前提下，尽可能多的启动新的转码任务，提高转码容量。转码集群中的上传模块其实是一个独立的进程，专门维护待上传列表，以及上传完成之后发送通知等后续处理，上传模块在设计时，已经考虑了进程崩溃，掉电等异常后的重新上传逻辑，保证上传和通知的成功。

在流水线化的执行过程中，各个队列的容量信息（数量、大小、时长等）会反馈给控制器，从而调节 Worker 接受新任务的规模。

八、日志搜索与告警

在整个系统架构设计过程中，运用了大量的公有云组件，比如前面提到的消息队列、数据库、对象存储等，另外我们也引入了 ELK 日志搜索以及告警系统，并针对 ELK 系统进行了部分优化，主要体现在对 JSON 日志行的一级字段进行索引化以提升查询效率，比如根据转码请求 ID 跨模块查询详细的处理过程。

我们也利用 Kibana 的仪表盘功能，展示一些个性化的统计信息，如各个 TransWorker 的负载折线图、各个 TransWorker 的转码请求数、滞后数，各阶段的并发数等，其中滞后数反应了 Worker 的健康程度，存在滞后执行的 Worker 需要特别关注。

九、并发转码测试

测试系统配置如下：

OS：Ubuntu 20.04

Tool：FFmpeg 4.4

CPU：2*Intel Xeon 16C

GPU：知名厂商数据中心 GPU*1（使用一个完整的 PCIe x16 槽位）

VPU：知名厂商 VPU*4

Oth：内存 4*32G，硬盘 PCIe SSD 1T，网卡 10Gbps

原视频：

H264-720P-24fps-2.1Mbps，时长 60 分钟

输出视频：

H264-1080P-30fps-3Mbps，时长 60 分钟

H265-1080P-30fps-2.5Mbps，时长 60 分钟

我们对系统进行了以下 3 方面的测试：

单任务耗时：

并发路数：

说明：测试使用的 GPU 数据中心显卡占用一个完整的 PCI-E x16 槽位，而一个 VPU 芯片（小卡）仅占据一个 PCI-E x4 槽位，实际安装的是该 VPU 厂商提供的四联装的一块大卡，大卡相当于 4 块小卡，也占用一个完整的 PCI-E x16 槽位，因此采用一个 GPU 和 4VPU（占用等量槽位）的形式进行转码容量对比。

单路功耗比：

说明：在估算 CPU 功率时，直接采用了 90% 乘以 TDP 热功耗，辅以 PowerTOP 程序对 FFmpeg 进程的功耗进行简单佐证，是一种粗略的估算方法。

通过分析测试结果，得出了以下结论：

总结

以上就是本文的全部内容。

首先介绍了三种主流的转码硬件 CPU/GPU/VPU，及其运用在转码领域的优缺点；软件层面，采用了 FFmpeg 多媒体处理框架，通过厂家定义的硬件加速适配库屏蔽不同加速硬件的差异，实现统一调用。

然后介绍了青云云点播产品中转码任务的分类，大体分为视频类和“非”视频类，前者优先选择具有硬件加速的 GPU或专业 VPU，后者选择 CPU 执行。

然后详细介绍了青云转码集群的架构设计，以及基于任务类型和 Worker 集群负载实施的并发调度策略，其中转码 Worker 是可以水平扩展的。

对于长耗时转码任务，传统的单次执行只能通过提升单节点的能力（比如配置性能更强的 GPU）缩短转码耗时，这是典型的垂直扩展方式，对此我们引入了分片转码的机制，即使在普通的 CPU 上执行长耗时任务，也可以大大缩短总执行时间。最后为了充分利用相关系统资源，我们还设计了并行流水线，让各个主要的耗时过程可以异步的并行执行，从而提高系统容量。

最后，我们进行了简单的测试，不同的硬件其实是适用于不同的业务场景的：GPU 拥有绝对的性能优势，适合对于实时性要求高的云游戏、大规模并行计算和机器学习等场景；VPU 拥有最佳的性能功耗比和性能价格比，适合大规模部署的直播、点播、转码集群，降低整体采购和运营成本；CPU 拥有最佳的通用性，在云平台和容器环境中，适合各种混合应用的场景。

Q&A

Q1：什么是分片转码？

A：分片转码是专门针对长耗时的任务（源文件时长长，并且编码输出规格高）推出的缩短转码耗时的一项技术。通过将一个长时间的源文件按照关键帧进行多片切分，比如，将一个 3 小时的视频切分为 6 个片段，每个片段大致 30 分钟，然后选定最多 6 台转码机，异步地同时执行 30 分钟分片的转码操作。分片转码完成后合并成一个大的结果文件，这就是分片转码的全过程。分片转码可以大大缩短长耗时任务所需的时间，这是一种水平扩展能力。

Q2：系统架构中的高优先级队列有什么特殊作用？

A：高优先级队列目前用于反馈分片响应给控制器，控制器在读取到这类消息时，会立即启动后续处理：选取临时转码组，进行分片转码。最初的转码请求已经在普通队列中排过一次队了，这里再排队不公平，还会导致分布式任务等待。

Q3：为什么不在分片前就直接选好转码组？

A：执行分片操作本身需要耗费时间，特别是架构设计中引入了并行下载源文件的逻辑，下载长时间源文件的耗时不好控制，如果控制器采用分片前的负载快照选定转码组，那么真正开始分片转码时，这个转码组大概率就不是负载最轻的前几个了。控制器采用最新的负载快照进行决策有利于分布式任务快速准确的执行。

Q4：VPU 是什么？

A：VPU 是近年来逐渐兴起的视频编解码专用芯片，专门针对特定的视频编码格式（如 H264/H265）实现硬件级别的解码和编码加速。由于是专用芯片，因此具有满载功耗低、转码容量高的优点，适合大规模的转码部署。专用芯片也是未来的一个发展趋势。

Q5：分片转码有进度汇报，对于普通转码的进度有查询接口吗？

A：系统对所有类型的转码过程，都有进度汇报要求，目前内部通过 ELK 日志查询详细进度，后期考虑提供对外接口进行展示。

Q6：直播的编解码怎么解决?

A：直播场景要求的是端到端的低延迟，一般在客户端对直播流进行处理。VPU 与 GPU 支持部署在边端或中心服务器，针对视频流进行处理。

Q7：进行分片转码后，各个分片转码任务之间有相互通信么？还是独立执行，执行完后如何处理？

A：执行分片的各个子任务是相互独立的，各个分片 Worker 都只和控制器交互：向控制器汇报进度，控制器发送某些控制消息（如终止任务）。临时转码组中有一个 MainWorker 的角色，即执行第一个分片的 Worker，这个 Worker 有两种方式判断分片是否执行完毕：一是在分片转码完成后，自身会定期性地扫描其他分片是否也转码完成了，是否正确获取了其他分片的结果文件；二是由控制器发送分片合并命令，控制器会接收所有分片 Worker 的进度，一旦收集到所有分片转码都 OK 了，就会向 MainWorker 发送合并命令。

Q8：从成本看，VPU 比 GPU 更低吗？

A：是的，针对视频编解码，VPU 具有最高的性价比。

Q9：这个视频转码是在服务端还是在用户端进行解码？

A：是这样的。目前泛娱乐行业都是在客户端实现。我们这个讲的是在服务端，针对海量的音视频文件处理，主要集中在教育、广电、广告等 预制类视频的处理。

与技术专家更多互动交流

请加入青云云点播技术交流群

,