在媒体内容流传行业中，视频作为信息流传的载体，其重要性占比越来越高。通常，为了应答不同的播放场景，视频须要批改封装容器格局、编码格局以及分辨率、码率等媒体流属性，这些解决的过程咱们统称其为视频转码。

网易云信集网易 21 年 IM 以及音视频技术，对外提供行业一流的交融通信云服务。其中，云信的点播服务，基于分布式解决集群和大规模散发系统资源，可满足全终端设备的播放需要，为企业用户提供极速稳固的视频上传、存储、转码、播放和下载等云服务性能。云信的分布式工作解决零碎，则承载了其中的媒体解决这一能力，次要性能有音视频的转封装、转码、合并、截图、加密、加减水印等，以及图像伸缩、图像增强、音量归一化等一系列前解决性能。

视频转码作为媒体解决的外围性能，在对大视频文件转码时，通常须要破费较长时间，为了晋升服务质量，咱们将重点晋升视频转码的速率。本次文章将以分片转码为主，介绍网易云信在转码提速方面的致力与成果晋升。

转码性能的影响因子与优化

常见的视频转码流程，个别如下图所示：


在转码过程中，瓶颈次要在视频流，因而咱们对速度晋升的探讨次要针对视频流解决，音频流解决暂不在思考范畴内。针对视频流解决的环节，从以下几个方面展开讨论：

  • 源视频：个别源视频越长，那么编解码所需工夫则越长。
  • 封装与编解码：对于视频转封装、关键帧片段裁剪等不须要解码编码的解决，其所需计算量很小，个别耗时在1~2s。若须要从新编解码，则依据源视频、编码输入参数的不同，所耗时间也不同。常见的有编码格局以及码率、分辨率、帧率，比方不同编码算法的压缩率与计算复杂度不一样，导致所需耗时也有所不同，举例来说 AV1 编码工夫就大于 H.264 的编码工夫。指标码率、分辨率、帧率等参数越大，通常计算耗时更大。

<!---->

  • 计算资源的程度与垂直伸缩：通用处理器的单核计算能力越强，转码耗时必定越小。利用 GPU 这类更适宜图像计算解决的专用处理器，也有利于升高转码耗时。晋升转码执行流的并发计算度，也有利于升高转码耗时。这里的并发路数能够是多线程和多过程，多线程指单过程内以多线程的形式晋升，多过程则为通过对文件切片后，多过程对多个切片文件计算。
  • 集群任务调度：多租户的云服务零碎，通常都是基于租户间资源分配优先级和租户内转码工作优先级综合而设计的调度算法，调度效率次要在以下几个方面体现：如何用更少的工夫调度多的工作，如何用更少的集群资源实现高吞吐量，如何做好优先级和防饥饿的衡量设计。

针对上述的影响因素，咱们提出以下几个优化方向：晋升硬件能力、优化编码、分片转码以及晋升集群调度效率。

专用硬件加速

多媒体解决是典型的计算密集型场景，优化多媒体应用程序的整体计算性能至关重要。CPU 是一种通用计算资源，将视频图像类运算 offload 到专用硬件上是一种常见的计划。目前，业内诸如 Intel、NVIDIA、AMD、ARM、TI 等芯片厂商都有相应的多媒体硬件加速计划，晋升高码率、高分辨率等视频场景的编码效率。

咱们的转码零碎次要基于 FFmpeg 多媒体解决框架，在 Linux 平台上反对的厂商计划有诸如 Intel 的 VA-API （Video Acceleration API）和 Nvidia 的 VDPAU （Video Decode and Presentation API for Unix ），同时两家厂商也反对了绝对更公有的 Intel Quick Sync Video 和 NVENC/NVDEC 减速计划。目前咱们次要采纳了 Intel 核芯显卡的视频减速能力，联合 FFmpeg 社区的 QSV Plugin 和 VAPPI Plugin 两种形式，针对 AVDecoder、AVFilter、AVEncoder 三个模块做了硬件加速。硬件加速相干技术，相干厂商和社区都在继续优化，在咱们的后续系列文章中，咱们也会具体介绍这块的进一步实际。

AMD 大核服务器 

这里次要指搭载了 AMD EPYC 系列处理器的服务器，绝对于咱们此火线上的服务器，其单核计算力更强，并行计算能力更优异。单核计算力的晋升让咱们在解码、前解决、编码能有整体性的通用晋升，而搭载超大核则是让咱们的分片转码计划中的单机多过程场景更加锦上添花，大大防止了媒体数据的跨机器IO通信。

自研 Codec 

NE264/NE265 是网易云信自主研发的视频编码器，在云信的 NERTC、直播点播中都有所利用。除了编码性能的晋升之外，NE264 更重要的技术劣势是低带宽高画质，其实用于高码率高清晰度直播场景（如：游戏直播、线上演唱会、产品发布会等），能够确保人眼主观画面质量不变的状况下，均匀节俭 20%~30% 的码率。这里不再开展介绍，有趣味的能够关注网易智企技术+微信公众号。

分片转码 

如果说下面的几种性能优化伎俩是垂直的，那么本节所说的分片转码则是程度的。视频流实质就是一连串的图像组成，并以 IDR 帧为边界划分成一串 GOP，每个 GOP 就是独立的一组图像集。视频文件的这一内容特点，决定了咱们能够参考 MapReduce 的算法思路，将视频文件切割为多个分片，而后并行地对分片进行转码，最初再合并成一个残缺的文件。

任务调度 

除了对单个转码计算执行流优化之外，咱们也须要晋升集群资源的整体调度效率。在调度算法这块，调度节点既要接管工作提交，又要实现工作下发的要害流程，这个工作下发的算法设计须要做好多租户调配、工作优先级抢占和尽量晋升集群资源利用率的多方均衡。

咱们设计了两种工作下发的机制：

  1. Master 节点 push 工作到计算节点
  2. 计算节点被动来 Master 节点 pull 工作

前者的长处是实时性更高，毛病则是 Master 对计算节点的资源视角是一种 snapshot 快照，有些状况下该快照信息的滞后性会导致局部节点的过载景象。后者的长处则是节点按需取工作来执行，不会呈现局部节点过载的景象，同时在工作选择性这块的可编程性更加便当，而毛病则是 Master 对全局资源分配的实时力度掌控性有余。

分片转码计划实际

媒体流程

媒体解决的繁难流程如下图所示，次要分四个步骤：分片前转封装（按需）、视频分片、并行转码、视频合并。

分片流程

在集群资源短缺的状况下，即工作的调度与散发个别不会有积压和资源抢占景象，这种状况下视频流自身的解决计算，个别会耗费整个工作周期 80%-90% 的工夫，所以针对这一阶段进行优化，能够有更高性价比的收益。

晋升硬件能力、优化编码这两个维度是针对晋升单个转码过程的计算效率，然而单过程能调用的资源无限，对大视频文件的速率晋升也是很无限。因而，在这里咱们探讨如何采纳分布式 MapReduce 的思维，缩短一个转码工作所耗费的工夫。接下来的章节将具体讲述实现分片转码技术计划。


分片转码流程基础架构如上图，咱们首先介绍以下几个概念：

  • 父工作：相似于 Hadoop 中的 Job，客户端提交的转码 Job，需将其待转码的视频拆分成多个小分片；
  • 子工作：相似于 Hadoop 中的 Task，将多个小分片包装成能够独立调度和执行的 Task 子工作；
  • 父 Worker：执行父工作的计算节点；
  • 子 Worker：执行子工作的计算节点。

分片转码的次要流程：

  1. Dispatch center 给 worker0 派发一个转码 job，worker0 依据总开关、job 配置、视频文件大小等策略判断是否进行分片转码；
  2. 如果确定进行分片转码，则进行分成 n 片；
  3. 包装成 n 个转码Task提交给 Dispatch center；
  4. Dispatch center 将这 n 个转码子任务调度给符合要求的 n 个 worker；
  5. worker1~n 转码实现后，给 worker0 发送回调；
  6. worker0 别离从 n 个 worker 上下载转码后的分片视频，待所有分片转码实现，将转码后的分片合并在一起；

  7. 发送回调给 client。

    子任务调度 

在调度零碎中，每个用户的工作队列是独立的，并别离设置工作限额。当 Dispatch center接管到计算节点的 fetch job 申请时，调度线程先从多个用户队列中，选出已应用限额比例（比较简单的算法模型能够是，已调度工作数量/用户总限额）最小的用户队列，而后从队列头部取出一个合乎该计算节点条件的子工作返回。子任务调度和一般任务调度在调度优先级、节点抉择上有所不同，须要独自设计，这里咱们简略介绍一下。

  • 子工作优先级

    子工作不须要在各自用户队列里从新排队，子任务调度的指标是心愿能够第一工夫被调度到。该父工作其实曾经被调度到了，而零碎处于放慢该工作执行的目标，在零碎设计上将其再次派发，如果还要和其余未被调度的工作一起竞争，那对这个工作来说是不偏心的，也削弱了减速的作用。所以针对分片子工作，会将其搁置到一个全局高优先级队列，优先被抉择调度。

  • 子任务调度节点抉择
影响到子任务调度节点次要有以下因素：1. 机器类型机器类型分为硬件转码机器与一般转码机器，因为两个环境中应用的编码器不一样，所以可能导致合并分片后的视频会有瑕疵，因而咱们抉择将子任务调度到与父工作雷同的机器类型。2. 代码版本不同版本的代码可能导致转出的分片无奈很好的合并在一起，所以当呈现这样的版本迭代后，能够通过计算节点 worker 上的代码版本，来确定子工作能调度到哪些其余计算节点上。3. 数据存储当父 worker 上的工作并发大时，就会同时进行多个上传下载的网络传输，这样会导致分片文件 IO 阶段耗时减少，因而优先选择将子工作放在父 worker 上执行，就会节俭网络 IO 与上传下载耗时。

落伍者问题 

在分片转码场景中，落伍者问题（straggler problems） 是指在多个子工作中，如果大部分子工作已执行实现，但还剩多数子工作迟迟未实现，父 worker 久久无奈进入到下一个流程，从而导致该工作被阻塞住。这在分布式系统中是一种较为常见的景象，针对该问题的零碎畛域钻研论文也是不足为奇。

对这个问题的解决方案很大水平会影响零碎的效率。如果父 worker 抉择始终期待子工作，就可能呈现工作过长时间的期待，这违反了咱们提速的初衷。因而，基于保障该工作在无限工夫内能被实现的准则，有以下几个优化方向：

1.冗余调度

这个计划参考了 Hadoop 中 MapReduce 对落伍者问题的解决方案：当达到超时规范时，子工作还未实现，则父 worker 会针对同一个分片文件再次发送一个新 Tsak 子工作给 Dispatch center，让其从新调度，并从新执行。当有其中一个子工作实现则勾销另一个。

这种做法是用空间换工夫，不把心愿只放在一个节点上，而是采取赛马机制。然而，当这样的状况产生较多时，则会产生大量的工作冗余，而且也不能保障新起的子工作不阻塞。

2.父 worker 接替实现

为了解决冗余调度中的不足之处，咱们对其进行了优化。当达到超时规范，而子工作还未实现时，则父 worker 会筛选实现进度起码的分片进行转码。同样，其中一个工作实现则勾销另一个冗余的工作。若还有子工作未实现，则持续筛选，本人实现转码，直到所有子工作实现为止。

上述第二种计划较第一种计划的区别在于冗余工作不会从新调度到其余 worker 上执行，而是优先让父 worker 来冗余执行。这样，父 worker 上会继续对分片进行转码，直到整个 job 齐全实现。最大的长处是：在不会无限度的耗费资源下，保障父 worker 不会处于有限期待状态中，只有在多数状况下，当父 worker 负载较高时，会思考应用其余领有闲暇资源的 worker。

子工作进度跟踪 

在父 worker 筛选子工作执行时，须要收集子工作的进度后抉择进度最慢的子工作进行冗余执行。在计算工作进度时，咱们将一次转码分为这四个阶段：期待调度、下载与筹备、转码计算执行、上传与收尾。

不同阶段的开始，示意达到不同的进度：

期待调度0% → 下载与筹备20% → 转码计算执行30% → 上传与收尾90% → 完结100%

其中，转码计算执行占70%，也是执行速度无奈保障的一个阶段，所以须要具体计算进度，转码执行流会定期输入 metric 日志，并进行监控计算，以后转码进度 = 已转码时长（time 字段）/ 需转码时长 。

HLS/DASH 封装 

HLS 格局与其余封装格局不同之处在于其会有多个 ts 文件与 m3u8 文件，对转出 HLS 视频的工作进行分片转码，会减少分片视频传输与治理的复杂性。因而咱们对此问题的解决方案是先将源视频转成 mp4 视频，而后在父 Worker 上合并后，再对整个视频转换 HLS 封装。

测试数据

通过记录并比照同一个视频转为不同分辨率视频的速率，咱们能够发现各个单个的优化措施对转码速度都有不同水平的晋升。在理论线上场景，咱们通常会依据用户设定、视频属性决定综合应用某几项优化形式。



测试视频1属性：

Duration: 00:47:19.21, bitrate: 6087 kb/s

Stream #0:0: Video: h264 (High), yuv420p, 2160x1216, 5951 kb/s, 30 fps

Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, 127 kb/s

测试视频2属性：

Duration: 02:00:00.86,bitrate: 4388 kb/s

Stream #0:0: Video: h264 (High), yuvj420p, 1920x1080, 4257 kb/s, 25 fps

Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 125 kb/s

结语

以上就是本文的全部内容，网易云信转码团队次要通过调度优化、硬件能力、自研编码、分片转码等维度切入，晋升视频转码速度，测试结果显示转码提速效果显著。另外着重介绍了云信转码零碎中对分片转码模块的次要设计。咱们也会继续进行技术摸索，实现提速以及更多的场景笼罩。后续的系列文章中，咱们还会对集群资源调度算法、硬件转码实际等其余方面的内容进行分享，也欢送继续关注咱们。

作者介绍

罗微恒，网易云信高级服务端开发工程师，硕士毕业于武汉大学计算机学院，网易云信转码团队核心成员，目前负责云信媒体工作解决零碎设计与开发工作，致力于晋升云信视频转码服务质量。