快手智能视频图像编码处理服务架构

正文字数：9639  阅读时长：14分钟

本文来自于快手视频算法工程师团队负责人闻兴在LiveVideoStackCon2020北京站上的精彩分享。凭借本主题演讲，闻兴老师荣获此次大会评选的优秀讲师称号。

文 / 闻兴

文章整理 / LiveVideoStack

在视频服务飞速发展的今天，视频平台如何在兼顾机器带宽成本的同时，让用户获得更加极致的观看体验，是每一个视频技术团队都会面临的问题。

复杂的技术从计划、研发、调试直到最终全量上线需要大量的线上测试及用户反馈，这一过程耗时长久，甚至可以说永无止境。很多时候，一些技术开发出来后，因为复杂度过高或者与实际场景差别过大，最终无法上线为用户提供更好的体验。所以在技术的开发及落地中，唯一的衡量标准——是能否在真实场景中以更低的成本为用户带来更好的体验。

本文中所援引皆为已经在线上稳定运行的算法及服务，所有展示的数据均是线上实际业务中所产生的真实结果。希望本文分享的信息能够给更多开发者带来价值，也希望我们完成的这些工作能够对大家未来的技术研发工作有所启发。

本文将分为四个部分展开：首先，我们简单回顾短视频行业的发展历程并简要介绍快手；其次，重点介绍快手用于分析/处理/推理/转码的多媒体算法引擎——Atlas；再次，深入介绍Atlas的基础能力之一视频图像编解码能力，这也是快手首次对外公开介绍短视频转码系统和技术；最后，我们通过两个实际的应用项目，即基于视频内容的处理及分析(CAPE)以及视频的AI智能增强，来进一步介绍Atlas的落地和使用场景。

1

短视频行业及快手公司介绍

在过去几年中，随着移动互联网覆盖逐步饱和，我国互联网的用户整体规模增幅一直呈下降趋势，但毋庸置疑短视频行业已逐渐发展成为当下最火爆的市场之一。从2019年的数据可以看到，中国短视频用户月活达8.2亿，今年受疫情等因素影响，月活已接近9亿。另外，短视频应用使用时长的增长在行业内也占据首位。

快手作为一个国民短视频社区，拥有海量的用户和短视频内容，日活用户规模超过3亿，日播放量达到百亿级。每日产出UGC内容1500万，原创短视频库达到260亿。海量短视频下多媒体内容处理的成本与体验之间的平衡，不断为我们带来了新的挑战和新的惊喜。

2

多媒体算法服务架构平台：Atlas

以下将详细介绍快手的多媒体算法服务架构平台Atlas。

2.1 为什么要做Atlas？

在进行多媒体算法开发的时候，业务方的需求一般主要集中于三个方面：场景、体验和成本。

从场景需求角度来说，在实际应用中存在大量且需求迥异的业务场景，比如短视频场景对清晰度和流畅度都有很高的要求，长视频场景则更在乎内容的清晰度和沉浸感，而直播场景相对而言对流畅度的要求会更高一点，并且需要保证实时性，对延迟比较敏感。多样化的场景会提出多种截然不同的优化目标。

就体验需求而言，难点在于部分业务方对体验的要求及预期无法量化，主观、感性表述往往较多，不能直接指导算法优化方向，因此专业的算法方案，需要同时兼顾客户的理解力和使用门槛。另一部分业务方的需求则更加具体及专业，有的业务方既需要传统算法，又希望能够利用神经网络推理能力；有的业务方既要做到尽量可控，又希望能有部分傻瓜模式以降低使用难度。

成本需求主要包含两方面，一是机器成本，业务方永远希望用最少的成本达到最优的体验；二是部署及维护成本，希望算法和工程的迭代及优化效率足够高，既要满足层出不穷的新需求又要尽量不新增更多的人力投入。

如何能更高效地满足这些需求？我们开始思考这个问题的解法，这就是快手建立多媒体算法服务端引擎Atlas的初衷。

（Atlas --- 阿特拉斯本是希腊神话旧神系中代表耐力、力量和天文的泰坦神，他被宙斯降罪放逐在大地之西，用双肩擎起整个天空(Uranus或指宇宙)；而在欧洲古典主义的建筑风格中通常会用这类男性形象放在立柱的位置，这种结构也被称为Atlas。因此，我们为这个核心引擎取名Atlas，也寓意着快手希望在用户和开发者之间、需求和算法之间、算法和硬件结构之间能够搭起一座座桥梁，起到连接支撑的结构性作用。）

2.2 Atlas 能力简介

Atlas作为多媒体处理算法引擎，已经在快手的各种线上服务全面落地，包括快手主站及海外的视频/图像分析、视频/图像处理、视频转码等。与此同时，它也支撑了视频剪辑和视频制作工具“快影”和企业级视频智能生产云平台“OnVideo”，以及其它新业务的大量视频分析、处理和制作需求。

Atlas现有的能力主要包括如下四个方向：视频图像压缩，画质增强，音频处理，以及智能生产。

在快手每天会新增千万级的视频内容，这些视频的服务端转码任务都是通过Atlas来完成的。在视频图像压缩方面，我们一直在追求这一基本能力做到精益求精，从而达到为客户节约成本，为用户提供最优体验的目的。通过自研的K系列编码器 (K264/K265/KVC)，Atlas展现了对于视频及图像的极致压缩能力。我们会在本文中后面的部分详细介绍快手的短视频编解码架构，作为其中核心的K系列编码器，以及上线后的具体收益。除了基本的编解码处理能力，Atlas也提供基于内容的智能处理与编码 (CAPE，Content Aware Processing & Encoding)，在后面的部分我们也会给出一个视频CAPE的应用实例，来详细说明如何搭建对应服务并取得线上业务的收益。

音频处理方面，Atlas包含音频美学，响度均衡，智能降噪，智能音效等功能。快手平台通过应用响度均衡处理技术和标准，能够有效规范平台的音频响度和动态范围平衡，避免切换不同视频时，声音响度忽大忽小。而智能降噪技术已经应用在快手直播，视频会议及快手K歌等多个业务场景。Atlas除了提供上述对音频的处理能力，也支持智能化的音频压缩算法，例如内容自适应音频编码 (CAE)等 。

除此之外，Atlas也具备很多非常成熟的图像算法处理能力， 例如在画质增强方面的失真去除 (De-Art) 、超分辨率 (SR)、视频插帧(FRUC)、色彩一键增强以及暗光增强等。这些算法及功能已经长期稳定地服务于快手平台及海外各App，服务范围涵盖了移动端的编辑和上传流程，以及服务端转码相关的处理和增强等重要任务。

智能生产方面，Atlas中具有很多独特的功能，比如精彩片段挑选、智能封面挑选和裁剪等。快手智能影集就是基于Atlas这些独家能力进行开发并持续迭代的。智能影集功能是通过对用户作品集的内容进行理解及分析，精选出用户公开作品中的优质片段，并以一定的故事线(时间或地点)逻辑裁剪梳理出视频集锦片段，最终结合特效片段合成出影集作品。

通过上述Atlas独具特色的能力，不同的用户可以根据自身业务及产品的需求，快速提升用户体验或搭建有趣的功能或玩法。

2.3 Atlas 架构简介

作为视频行业最火爆的公司之一，快手的业务需求种类繁复，横跨各种应用场景，但万变不离其宗，绝大多数的的需求都可以拆解为内容分析识别、处理增强、编码压缩以及硬件加速四个阶段。通过Atlas完善的接口及架构设计，算法开发方能够高效的跨越四个阶段，从而对业务方的需求进行快速响应和迭代；而用户也可以基于Atlas的架构低成本的搭建自己的服务，或将Atlas中的算法能力应用于产品中。接下来我们将对Atlas的整体架构及设计逻辑进行详细介绍。

2.3.1 逻辑架构

Atlas的整体架构从逻辑上划分，可分为四层：

服务接口层：Atlas的接口层是直接暴露给用户的，用户通过接口层进行任务的详细配置，例如需要使用的分析及处理算法组合，编码器及参数设置，硬件（GPU）加速方式等。此外，Atlas也提供命令行驱动、API集成等多种调用方式，用户可以根据自身需求灵活地搭建服务。

分析及逻辑决策层：Capella是Atlas的分析及逻辑决策层。这一层主要有两个功能，一是进行内容的特征分析及质量评估；二是根据分析结果 ，配置后续操作的“菜谱”(Recipe)。这里的“菜谱”包括后续算法服务层会使用哪些算法，以及这些算法的顺序和配置：比如用H.264/AVC还是用H.265/HEVC编码，采用怎样的编码配置；如何做前处理，包括做哪些处理及处理的顺序和参数，是先做去噪还是先做色彩增强，强度如何？

算法服务层：这是最核心的一层，主要分为三大模块，其一是音频、视频及图像编解码器(Codec)模块；其二是图像算法引擎VisionEngine，是包含各种自研图像算法的工具集；其三是EVA(Elastic Video AI Inference)，它是一个AI网络推理库，主要包含一些针对视频和图像的自研深度学习网络。

硬件层：作为最底层，包含了CPU链路、GPU链路及混合链路。

2.3.2 视频处理编码链路

我们通过线上常见的一个转码任务流程为例，来进一步说明Atlas的架构。在一般转码任务中，我们会首先对视频进行前处理，然后再做编码。用户在搭建类似服务时，可以直接通过Atlas内的Codec管理器和Filter管理器选择希望使用什么类型的编码器和前处理算法。在配置前处理算法时，如果选择传统算法，就会调用图像引擎VisionEngine中的相应算法能力；如果需要深度学习算法，就会通过EVA引擎获得网络推理能力，为减少读取网络造成的延迟，EVA将作为一个Daemon启动，通过进程间通信传输推理数据。

在GPU硬件加速方面，Atlas全链路支持NVIDIA平台的编解码、处理、推理能力，包括NVENC/NVDEC、CUDA、TensorRT等原生API和框架，同时也会提供CUDA版本的PyTorch和Tensorflow给用户做验证和测试。在Intel平台上，也可以通过MediaSDK、OpenVINO等框架获得Intel GPU的计算能力。

Atlas支持全GPU链路，全CPU链路，及混合链路三种任务执行方式。全GPU链路，即从解码到转换、推理，再到前处理以及编码的全流程都部署在GPU上，会提供最高的吞吐率。这样的链路比较适合一些对压缩比追求没有那么高的工作，比如预览或存储。而混合链路则可以提供极致的压缩及处理效果。一方面，为追求极致的压缩率，Atlas会使用CPU运行软件编码器；另一方面，当需要网络推理的算法时，用户可以在GPU上进行推理的加速。这样做的优点在于既可以利用深度学习网络取得更好的视频处理结果，也可以得到极致的压缩比。而混合链路的缺点是其整体的I/O开销会比较高，需要把数据在GPU和CPU之间互传。简言之，无论是GPU链路、CPU链路还是混合链路，用户可以根据具体工作进行选取，选择需要使用到的具体链路。

2.3.3 交付、集成及部署

在最终交付时我们会将底层的算法库、第三方库，打包Atlas整体镜像。当业务方获得Atlas镜像后，就可以在上面直接构建自身服务的镜像。此方法的优点在于集中度高、性能可控性高，升级的耦合度比较低。同时我们的技术团队正在致力于把底层再拆解成单独的小镜像来做微服务，提高部署的灵活性。

3

Atlas核心能力——视频编解码

以上是Atlas的整体架构介绍，接下来将着重介绍Atlas的核心能力之一，视频图像压缩中的视频编解码能力。在进入正题前，希望先和读者分享一些我们从客户价值出发而产生的思考，比如在日常编解码开发过程中遇到的各种难点和问题，我们是如何解决这些困难的，如何更高效的将研究中的算法落地，如何更好的理解和服务用户，以及应当如何体现编解码开发者的价值。

3.1 编解码开发与用户体验之间的鸿沟

在编解码开发到最终全量上线改善用户体验的过程中，一般会经历如下三个阶段：离线开发阶段，实际测试阶段，真实上线阶段，而三个阶段之中又有着多个复杂的鸿沟。

离线开发阶段一般代表算法或工具的开发初期，或标准建立过程中的早期阶段，在这个阶段主要关注的是“信号保真度” (PSNR/MSE) 和“码率” (Bitrate) 之前的权衡，一般会通过少量测试序列，计算BD-Bitrate及BD-PSNR等客观指标。但这些指标是很难反映工具或算法在真实场景的有效性的。

而在实际测试阶段，主要关注的是视频“主观质量”与“真实文件大小”之前的平衡。而这一阶段与离线开发阶段之间，其实已经存在一个巨大的鸿沟 (GAP1)：

GAP1-1：信号保真度本身无法反映主观质量。为了能够评估算法或工具带来的主观质量的变化，业界一般是通过例如SSIM、VMAF等客观指标来尝试逼近主观质量，但这种方法得到的结果和真实主观质量的相关性有限；更极端的方案，就是对于每个工具及算法都进行主观质量评估，根据所得的MOS/DMOS评分获得真正的主观质量变化，但是这个方案对人力和时间的需求都很大。

GAP1-2：码率与真实文件大小的区别可能很大。真实的文件大小会受到音频编码、视频内容、目标质量的档位、文件格式的冗余等因素的影响，会和简单估计视频码率产生很大的差异。同时在一般离线测试的时候，为了保证算法迭代效率，测试集最多几十个，最多到百级，是无法代表千变万化的视频内容的，尤其是对于UGC短视频内容，场景更是纷繁复杂，大千世界无奇不有。在快手，我们的实际测试阶段一般每天要进行数万至十万级别视频的线上环境测试，测试一般进行一周左右才能看到线上真实文件大小的变化。而根据我们技术团队的实际经验，实际测试阶段的文件大小变化和离线测试的码率变化的差距甚至可能达到50%~100%。

是否跨越这个阶段就万事大吉了呢？当然不是。从第二阶段到第三阶段，即真实上线阶段之间，鸿沟依然巨大：

GAP2-1：主观质量和用户行为之间的关系依然是一个迷团。即使在测试阶段对主观质量有了一定的评估，主观质量的变化首先需要被用户感知或感受之后，才会对用户的行为产生影响，这种影响对单个用户或单次行为可能是非常微小的，比如多看了一个视频或者某个视频多看了几秒。但现阶段学术界对人类视觉系统(HVS)的运作规律依然知之甚少，所以我们目前只能通过平台的亿级用户的百亿级播放量，来进行大规模A/B实验和观察用户的QoE/QoS指标，从侧面反映及理解用户的真实行为。

GAP2-2：真实文件大小和最终线上带宽节省的差距不容忽视。很多人认为真实文件的大小的变化就是最后线上带宽成本的变化，这是一个常见的错误认知。问题在于每个作品有其不同的热度，播放量少则十几次，多则百万次甚至千万次。每个视频的码率的节省或者增加需要乘以每个作品的播放次数，才能计算出最终带宽的变化结果。同时还要考虑设备的限制，线上的下发逻辑等，而这些条件都会影响线上不同档位及不同标准的用户端覆盖率，全部考虑在内后才能推测出真实线上带宽的变化。

因此只有跨越了这些鸿沟，最终到达第三阶段即真实上线阶段，才能够体现算法、工具和标准是否对用户有影响，是否对用户体验有贡献，才能够体现编解码开发者的真正价值。借用某部电影中的一句台词来总结这三个阶段，就是九个字，第一个阶段“见自己”，第二个阶段“见天地”，第三个阶段“见众生”。

3.2 我们的做法

接下来将详细介绍我们团队日常是如何来进行开发，跨越多个鸿沟突破这三个阶段，提高用户最终体验的。

3.2.1主观质量盲测标注平台

我们依照VQEG标准规定的方式，构建了快手的主观质量盲测及标注平台以及一系列的测试标准，在内部已推广至多个部门及团队。同时我们联合QA团队，培养了一批“黄金眼”。通过组织“Gold Eye敏感性测试”，筛选出一批观察入微，对质量变化敏感度高的同学作为“黄金眼”的备选团队。

而对于我们开发的每一个算法及工具，在上线之前，我们都会联合QA团队和“黄金眼”团队的成员一起来进行主观评测，取得MOS/DMOS分数。同时仔细分析每个视频质量的优劣。经过多维度的对比评价，通过主观质量盲测的算法和工具才能进行到下一个A/B测试的阶段。

3.2.2 音视频相关主要指标-评估收益

A/B 测试是针对一个变量的两个版本，来观察用户的不同反应，从而测试哪个版本更有效的一种方法。例如：将视频按照不同的算法压缩两个版本，下发至千万级的实验用户组和对照用户组，然后观察这两个用户组的行为。通常来说，观察的指标为两大类：QoS和QoE。

QoS指标包括首屏时长、卡顿率、丢帧率等等，和用户体验息息相关。而且我们团队自三年前就持续关注用户播放时的CPU、Memory和功耗情况，而这些指标对用户体验也影响深远。

QoE指标包括播放量、人均播放时长、播放完成率等等，是用来衡量最终优化效果的指标，QoE才是反映用户在平台的停留时长、反映用户对平台是否喜爱的因素。一般对算法A/B实验的原则是必须要将QoE全部指标优化至正向或持平的状态才能上线，而QoE负向的话是不可能上线的。很多算法在离线测试阶段，甚至是实际测试阶段都有着不错表现，但往往上线A/B测试后才发现QoE指标不理想。所以只有通过在真实上线阶段，才能反映算法和工具对用户体验是否真的有正面影响。同时我们也会分多个维度来分析QoE和QoS的指标，包括客户端、手机系统、版本、机型、粉丝数、地域、同时在线人数等等。快手内部有一个完善的流媒体大数据平台，部门内也有专门的数据分析师和算法的开发同学一起结合自动化工具来分析这些指标。

3.3 快手短视频编码能力发展历程

这是我们首次对外披露快手的短视频转码能力，也是我们部门多个团队合作的一个阶段性总结。由于线上带宽数据涉及公司机密，所以这里只能以“实际文件大小”数据来间接描述整体的能力。

3.3.1 时间线

“K系列编码器”是快手自研的一系列视频及图像编码器的统称，包括K264，K265以及KVC。涵盖了四种不同的编解码标准，其中包括由ITU-T与ISO/IEC联合发布的国际标准H264/AVC和H.265/HEVC；由快手自研的视频编码标准KVC以及自研图像编解码标准KPG。

如图中所示，快手的线上短视频转码共经历了两次重大的技术迭代。自2018年7月起，我们开始进行自研编解码器的研发和上线。2018年底我们自研的K265全面上线，快手由H.264/AVC时代进入到H.265/HEVC的时代，而整个H.265/HEVC时代线上的文件大小下降了56%。

自2018年底开始，我们开始了自研编解码标准KVC项目以及对应编解码器的开发。在经历了艰苦卓绝的算法研发以及大量的A/B实验后，KVC于2020年初全量上线，这也标志着快手提前进入了编解码的“次时代”，进入了快手自研编解码标准--KVC的时代。对比H.265/HEVC当时压缩比最高的档位Unicorn，线上的文件大小下降了27%。

而上述这些数据，是快手线上每天千万级新增视频，每天百亿次用户播放的真实数据，是经过多次实际A/B实验后，分析优化跨越鸿沟后的成果，是两年来多个部门团队通力合作，持续迭代的心血。

能够在线上实际应用场景取得如此的收益，其实也得益于我们的技术团队深度参与多个国际视频标准的制定，在视频技术的最前沿有着深厚的积累和贡献。在新一代视频压缩国际标准H.266/VVC的制定中，快手提交了过百件技术提案，并有数十件技术提案获采纳进入H.266/VVC标准。而在AVS3标准的制定中，快手从2020年3月开始参与，已有12件技术提案获采纳进入AVS标准。

3.3.2 指标收益

这里我们给出K265以及KVC上线后，线上真实的指标收益。文件大小的收益其实与我们离线测试的结果有着很大的不同，这也是我们在之前文中提到的两个阶段的鸿沟之一。另一方面，QoE及QoS的结果在没有进行线上A/B实验，仅凭离线测试阶段的测试是完全无法预测和衡量的。

K265-Romeo上线后，除了明显的带宽成本收益外，QoE在人均观看时长和人均播放次数上也获得了一定增益。而QoE上的收益我们猜测是因为QoS的大幅提升，从而影响到了用户行为。

KVC-1.0上线时，成本收益显而易见，卡顿率也明显下降，但QoE收益基本保持不变。我们推断可能是因为之前下降的幅度也比较大，用户已进入QoS的舒适区，感受就没有那么明显。

3.4 编码端优化算法：CAQ + CARDO

在K系列编码器中，我们有着大量的自研工具及算法优化，而大部分的算法及工具都是经过了多次上线实验的反馈迭代而成。CAQ就是其中的一个很典型的例子。

CAQ这个工具比较有趣，因为其上线后的收益比实际测试阶段的收益要高出50%，在同等文件大小下主观质量提升明显，但同时部分客观指标会下降，所以并不适合离线测试评估或进行“打榜”，但对于真实用户体验有明显提升。下面简要介绍一下CAQ的算法。

其算法的主要思想如下：CAQ算法中的第一部分类似x265中AQ的操作，在获取视频帧后对其进行内容分析，获得JND Factor从而计算出QP偏移。JND Factor包含三个部分：一是图像块的平均亮度值；二是纹理强度（纹理强度指的是首先做一个边缘检测，得到块级边缘强度和梯度方向）；三是纹理特点，例如是平滑、边缘、规则纹理（例如网格）、不规则纹理（例如草地或噪声）等。根据这三个特征，再结合内容的运动特性，从而得到块级的QP偏移。但是，直接使用这些QP偏移可能会造成帧或序列级别的码率波动较大，为了控制这种波动，我们使用一个模型来预测CAQ可能产生的码率变化，从而再次修正QP偏移。同时结合视频内容特征，在CAQ和自适应CUtree这两个工具所产生的QP偏移值之间进行合理选择，让那些主观质量提升不明显的序列能够最大化客观性能收益。

CAQ算法中的第二个部分CARDO主要包括两个算法：第一，感知量化（perceptual quantization），即在量化过程中保留主观失真敏感度高的区域的部分量化系数；第二，融合边缘梯度失真（edge-based gradient difference）的率失真优化，即在率失真代价函数中的失真部分加入边缘梯度失真（edge-based gradient difference），同时对λ的选择进行调整。

下图是整体方案应用后的一个例子。我们将蓝色部分的码率重新分配给黄色和绿色的部分。如图可见，原来衣服上珠花的部分其实分配了大量的比特，但人眼对复杂的不规则纹理并不敏感。当我们将这部分码率拿出来重新分配给睫毛、人脸等一些细节部分时，整体主观质量的提升就会非常明显。

4

Atlas实际应用

下面将介绍两个Atlas实际应用的例子，分别是CAPE（基于内容的处理与编码）和视频AI智能增强。

4.1 Atlas-CAPE

Content Aware Processing & Encoding (CAPE) 指的是内容自适应的处理和编码，主要可以分为以下几个维度：Per-Category、Per-Title、Per-Segment，再细化的话还有Per-Frame和Per-Block等。这个概念早已存在，如Netflix和YouTube在线上也有很多这个方向的应用，其最大的难点就在于如何衡量质量，及如何寻找到一个质量“足够好”的工作区间。

目前快手线上CAPE的应用有多个种类，并大规模应用于短视频上传，转码以及直播等场景。

上图是一个Atlas常用的CAPE框架。Capella就是之前在Atlas架构中提到的决策和分析层。在决策和分析层中会主要分析如下几个方面：其一，视频源的Metadata，即视频的生产类型和上传途径等原始信息；其二，进行热度分析，掌握其当前的观看数、点赞数等；其三，视频的基础数据，比如宽、高、帧率和码率；其四，进行视频的时间和空间复杂度分析；其五，对内容进行基础特征分析，而基础特征中包含了模糊程度、噪声估计、压缩失真估计等等。其六，对视频进行内容理解，基于场景分类做针对性编码方案。通过算法决策模块可以得出是否要做视频增强，做哪些视频增强，做多强的视频增强，获得对应的参数，同时告诉编码器，应当使用哪些档位编码可能会比较好。

再举个例子——直播推流中的CAPE应用。为尽量避免算法变得很笨重，在直播应用中实际用到的分析步骤不多，同时我们会降低分析的频率，约一秒钟一次对视频源进行时间、空间的复杂度进行分析，同时再附以一些基础特征的获取。其中最大的难点是在做直播推流时，移动端有很大比例用的是硬件编码器(如iOS平台的VideoToolbox)，可配置参数都比较基础并且数量较少，此时我们会给出一个硬件建议编码参数，来保证在场景切换或是在一些座谈场景时，能够尽量不要多浪费码率。直播推流CAPE上线后，文件大小降低了约10%，QoE没有明显变化，QoS收益也接近10%。

4.2 Atlas-AI视频增强

下面介绍Atlas在实际应用中的另一个例子：AI视频增强。在Atlas-AI视频增强算法触发策略中，最重要的工作是在分析模块Capella中完成的。

首先，根据视频的分辨率以及导入逻辑，判断它是不是从别的平台导入，是否经历过多次的压缩，当前的视频质量到底如何，进而根据不同的质量选择不同的模型。另外根据分辨率，可能会用到不同种类的SR网络或算法，有的是固定上采样大小，有的是任意上采样大小。同时每个视频还会进行噪声和色彩及亮度评估，看是否需要进行降噪处理或HDR优化。

目前，经由De-Art/SR处理过的视频在线上播放端覆盖率约为10%，并未占用过多机器资源。因为我们技术团队对模型复杂度做了大量的简化，在算法精度显著提升的情况下，速度提升到了最初版本的7倍左右。SR优化后实现了720p/30fps，De-Art优化后效果更显著，从最早版本的7fps提升到50fps。

我们依然在持续观察用户对于具体效果的感知及行为变化。按照10%的覆盖率来评估的话，De-Art/SR上线后，在播放量和播放时长方面的收益非常明显的，整体的投入产出比（ROI）非常高。

小结和未来展望

在快手海量且场景丰富的视频业务背景下，Atlas经过了持续考验和打磨，已经成长为越来越标准化、通用化的技术架构，我们将继续丰富和沉淀算法和平台能力，把对客户和用户更具价值的技术方案和产品提供出来，以应对国内、海外，点播、直播、实时互动等多样化的场景考验。更长期来看，我们的团队希望能够面向5G+AI时代的要求，将云端音视频处理和生成能力向极致的高性能方向不断深入优化，并且保持好奇心，持续探索各种技术和业务创新的可能性。

LiveVideoStackCon 2021 ShangHai

我们准备好全新的内容

在上海欢迎您的到来

LiveVideoStackCon 2021 上海站

北京时间：2021年4月16日-4月17日

点击【阅读原文】了解大会详情