酷应用

新浪微博杜东澄：微博视频转码系统架构演进 | 又拍云 Open Talk 2018 音视频技术沙龙·北京站

百家作者：又拍云 2018-08-24 10:20:22

7 月 28 日，又拍云 Open Talk | 2018 音视频技术沙龙·北京站顺利落幕，这是 2018 音视频技术沙龙的第三站。

活动现场，来自新浪微博的杜东澄做了《微博视频转码系统架构演进》的分享。

杜东澄是新浪微博视频转码系统研发负责人，2016 年加入微博，负责微博视频转码系统的架构设计及研发，专注于音视频处理及高并发的架构设计方向。擅长用各种工具脚本排查问题、流程自动化、提升研发效率。

△ 杜东澄

本次分享，杜东澄主要介绍了微博视频转码的特点和各种应用场景下微博系统架构的演进，基于演进的目标引入 DAG 框架，介绍在框架基础上的业务和系统的应用场景。

DAG 意为“有向无环图”，它原本是计算机领域一种常用数据结构，因为独特的拓扑结构所带来的速度快、吞吐量高等优异特性，经常被用于处理动态规划、导航中寻求最短路径、数据压缩等多种算法场景。

以下是分享实录：

微博转码系统的特点

微博视频转码，主要承载微博上的原生视频、微博故事和扩展视频等。目前每天有数百万转码任务处理。在视频处理的基础上，支持多格式、多编码和多分辨率下发。随着业务的发展，视频转码还会做多种业务类型，包括截图、抽帧、gif2video、全景截图等。

微博视频转码系统架构演进

1、旧的系统架构

△ 旧的转码系统

旧的转码系统分为两个模块：调度器和执行器。

调度器作为系统的基础服务，会收到很多任务处理请求，通过调度的队列，将任务派发给执行器进行处理。调度器在调度的单元里不涉及整个任务的处理逻辑，比如调度器拿到一个任务，它的任务是要做多个节点的事情，转码成多分辨率、截图等。在此过程中，整个任务会被下发到执行器，执行器会根据任务配置解除任务执行逻辑，所以逻辑都是在执行器里，其他任务也是一次下发。

这个框架暴露以下几个问题：

第一，不易扩展。由于逻辑都在执行器里，随着业务需求的不断增加，节点处理逻辑也越来越复杂，在实际的业务场景中，节点大概有 40-50 个，需要不断增加新的节点，比如有一个需求是要截视频阅览图，那么就需要在节点里加一个分支，这对开发来说是不容易扩展的。

第二，粗粒度调度不均匀。旧的系统模块中任务是整个一次下发的，不同的任务分支不一样。比如普通用户，可能最高的分辨率是转码到 720P，但对于 VIP 用户或者 PC 视频，会要转出 1080P。每个任务的处理复杂度是不均匀的，但是我们还是单个任务下发，这样做有的机器相对会比较空闲，而有的机器处理会很忙，这是由于调度不均匀引起的。

第三，缺少任务监控。转码任务是一个 CPU 密集型任务。比如 PC 视频，一个视频源文件可能是几个 G，分辨率是 1080P 或者 2K，它的转码时间会比较长，在这种情况下需要做任务监控，目的是当用户上传视频时，需要告知用户视频转码的进度，这个功能在旧的系统上是不好实现的，无法实时汇报给用户每个节点的任务状态。

2、新的系统架构

新的系统架构，首先在调度器层改进，可以感知到业务逻辑，清楚任务有多少个分支和节点；在任务下发时，按单个节点下发而非整个任务下发，这样可以更细粒度地管理每个节点的任务。如果是有依赖性逻辑的任务，可以把多个节点一起下发。

△ 设想的新转码系统

上图是我们设想的新转码系统，可以解决旧的转码系统的三个问题，从而引出我们此次架构演进的目标。

3、架构演进的目标

目标主要有三个维度：

灵活地应对需求：转码系统需要灵活应对业务需求，方便地支持我们的产品需求、内部的系统优化、业务迭代等。

快速的任务调度：降低任务延迟，提高吞吐量。

稳定的服务架构：容易监控任务，方便重做、降级等。

新的系统的目标就是要：灵活，快速，稳定！

DAG 架构

1、什么是 DAG 架构

综合上面这些问题，我们引入 DAG 框架。如下图，它是一个有向无环图，从任意节点出发无法经过若干条边回到原点，也就是有始有尾。

△ DAG 架构

2、转码的业务逻辑

△ 业务逻辑

上图就是目前的主要业务逻辑，首先下载视频，下载水印，然后对视频做预处理的逻辑，之后做各个业务需求，比如截图，抽帧，然后转出很多不同码率、播放分辨率的视频。

△ DAG 描述业务逻辑

上图是用 DAG 描述的业务逻辑，和上面不同的地方是把每一个节点的能力做了抽象，比如下载视频和下载水印都是下载操作，按时间截图、按帧截图、截预览图，都抽象成截图。

3、DAG 系统运行
△ DAG 系统运行
我们先抽象出一个系统的子单元的能力，系统的运行如上图。调度器关心任务的流程；执行器是实现每一个任务子节点要做的处理，它不管输入是下载视频还是下载图片，就做下载这个操作。任务派发只需要把“下载”给到执行器的下载单元，下载完成后，会通知调度器任务完成，要做后续的事情。调度器根据 DAG 描述可以知道下个节点执行什么任务，比下载水印，就调度到另外的执行器下水印，后面还有预处理、截图和转码等。

4、如何实现任务的 DAG 描述

△ 转码操作

举个简单的例子，对一个视频进行转码的操作，需要转码成一个 .mp4 的文件，指定宽高、crf、和封装格式，输入的是前面的 URL 转码配置，输出 .mp4 文件。

上图左边是执行下载的任务，包括下载节点的名称，下载类型以及作为输入视频传入的 URL。

接着是配置，第一个配置 URL 是在第一个节点使用，转码的配置 URL 是在第二个节点使用。当第一个节点执行 input 之后，会得到一个 URL，然后把视频分发给执行器，执行器拿到任务后会执行下载，下载完成后上报下载完成的结果，然后我们可以更新数据，下载的文件在哪个目录的哪个文件夹。

最后是转码，一个转码的任务需要有转码文件和转码配置，最终结果得到 context.file 的输出文件，如此用两个任务描述就可以实现一些简单的事情。

应用场景

1、分片转码

分片转码是将一个视频拆成多个 GOP 分片，对每个 GOP 分片进行转码，可以提高并发处理速度。如果为了转码系统更灵活，需要做音视频轨分离，分别对音频和视频进行处理，最后把音视频结合起来，得到最终文件。

△ 分片转码逻辑

上图是对整个文件进行分片转码的逻辑。在预处理之后，进行拆分视频 GOP 和拆分音频的操作，接着对每一个 GOP 分片转不同的分辨率，然后对每个 GOP 视频同一清晰度加上音频进行合并。整个分片转码在 DAG 框架下的架构图是如此，DAG 任务描述也是这样的架构图，按照这个图和节点之间的依赖关系，将任务派发下去。

2、DASH 转码

DASH 是一个自适应协议，做这个的目的是为了提升用户体验。在 DASH 基础上可以容易地支持多分辨率、多码率下发；能够无缝切换清晰度，用户只要点一下高清按钮，就可以切换高清片源，不会出现音视频卡顿的情况；支持播放码率自适应，用户的网络情况是经常变化的，从提升用户体验的角度考虑，是要优先保证视频的流畅播放，在此基础上可以做视频码率的自适应。

实现的方式是首先做音视轨分离，视轨我们做的是 fMP4。fMP4 和 MP4 的区别在于前者每一块都是独立的可播放的单元，还会用MPD文件去描述每一个分片是在哪个索引。MPD 有一个问题是文件比较大，在微博的场景下，刷 50 条微博可能 40 条是视频，这会导致服务器承载压力过大。然后我们用了 fMP4 的特点 SIDX，fMP4 支持在视频文件内部保存每一个分片的索引位置，只需通知客户端 MOV 和 SIDX 的是在多少字节区间，客户端下达这两个字节的数据，就可以很方便地支持视频的快进快退。

△ DASH 逻辑

那么 DASH 转码如何用 DAG 框架呢？在分片转码的基础上，拿到很多的分片后合上音轨，生成 MP4 文件。而如果使用 DASH，这个步骤是合视轨转成 fMP4，转封装一次，封装的 fMP4 就是我们用到的 DASH 文件，对每个分片都是这样操作一次。此外还要转成非 DASH 视频，即 MP4 文件，并且合上音轨。上图是支持 DASH 转码的 DAG 描述图，其实在原基础上，只需要增加转封装的逻辑，整个系统就可以支持 DASH 转码。

3、任务监控

对于任务监控，业务方和用户可能需要知道视频转码的时间和进度，比如下载视频，当把下载视频节点下发下去以后，回调显示成功，我们就可以更新进度，这样用户就能了解转码的时间和进度。在 DAG 基础上，因为是按节点下发，所以可以很清晰的知道任务进行的百分比进度。基于此，可以对每一个细的转码节点进行实时汇报进度，这样做会更加精确。