画质提升+带宽优化，小红书音视频团队端云结合超分落地实践

我的分享分为以下几个部分：

1. 首先介绍小红书的视频处理架构，以及我们如何思考音视频系统中视频处理最重要的两个目标，即提升观看画质体验和降低视频带宽成本。

首先，大家对小红书的印象是什么呢？

这里展示一张架构图，整个链路主要包含生产端、云端和消费端，用户在生产端进行内容创作、编辑和推流；然后将内容发布到后台云端进行处理，主要包括多档位视频转码、内容审核与理解、以及视频搜索与推荐；消费端则是用户实际体验的场景，用户体验来自两方面，一方面是视频推荐内容的体验，另一方面是视频画质及播放流畅度的体验，后者也是我们在音视频处理中需要关注和优化的目标。从这张图可以看到，音视频处理横跨三端，也是整个上层视频业务及应用的基础设施，我们需要保障整条视频链路的稳定和通畅、关注用户体验以及降低成本（带宽、计算、存储等）。

在论述这个话题前，先简单介绍一下背景。

小红书成立专业的音视频团队还不到 2 年，如果是正常的研发路径，应该是先提升体验，容许增加一些成本。但是在疫情之后，全行业进入降本增效主题，降成本也成为我们重要目标之一。而提升体验是建立这个专业团队的初衷，在不牺牲用户体验的前提下来换取技术成本的节省，唯一的手段就是提升技术和优化策略。

因此，我们算是跑步进入了“深水区”，比较幸运的是，一方面我们是站在行业经验的肩膀上；另一方面，我们也有后发优势，并结合自己的思考可以进一步改进和优化。所以如何兼顾体验和成本？下面分三个层面说说我的理解。

模块级优化

1、模块级优化

首先，大家熟知的是编码标准的迭代和升级，每一代标准相比前一代标准在画质基本不变前提下可以节省 30%~50% 的码率。当前小红书大规模部署的是 H.265 标准，目前达到比较高的覆盖率。在研主要标准是 AV1，H.266 未来也可能会跟进。

新一代标准大规模落地还需要一些时间，当前主要挑战是计算复杂度比较高。对于点播来说，云端可以用计算成本来换，而在播放端，当前硬解 AV1 和 H.266 的设备非常少，因此需要配套部署经过极致优化的软解。

2、跨技术方向融合

编码考虑的是用最少的码率最大程度地代表原视频，因此视频质量的上限就是原视频。而 UGC 创作的视频质量非常多样，如果能用画质增强及修复算法提升原视频的质量，那么对应消费侧的转码视频质量也能随之提升。比如一个带噪视频经过去噪算法后再编码，不仅画质有提升，还能进一步节省码率。当然并不是所有画质算法都能带来这种 double 的收益。比如在云端做超分，画质提升的同时码率也会增加。

其次，当前的编码框架还是比较传统，缺乏对视频内容的理解，固定的编码参数以及码控算法并不是最优的。因此，通过对视频场景的分类以及增加对内容和语义的理解，可以进一步提升编码效果和效率。另外从主观感受来讲，对于感兴趣区域提升编码质量可以更有效地提升实际观看体验，而对于非感兴趣区域降低编码质量，不太影响观看体验但有助于节省码率。

视频分析、处理以及内容自适应编码技术整体形成了智能转码方案，涉及到 high level 图像分析、low level 图像处理、编码技术的融合。据我了解，各家厂商在这部分都有自己的一些方案，但是智能程度（包括效果和自动化程度两个方面）还有待提升，随着智能化程度的提升，收益及效率也会越来越高。

此外，学术界也有一些颠覆性的前沿探索，比如端到端的深度学习视频编码，不过总的来说更偏中长期才有机会大规模落地。

3、全局系统优化

转码是音视频处理最重要的一个任务，而它也只是云端处理的重要一环。全局来看，音视频处理是一个从生产端到消费端的视频处理链路。局部优化往往带来局部最优，站在全局视角，可以发现很多技术优化不再矛盾，比如前文提到云端超分，提升画质但是会增加码率，理论上会增加带宽成本，但如果全局分析，我们可以发现 CDN 通常是根据高峰期来收费，在非高峰期下发超分后的高码率视频并不会增加带宽成本。

另外，如果能够在播放端做好画质增强，就可以下发更低码率和更低分辨率的视频，从而实现显著的带宽节省，后面要讲的端云结合超分就是一个典型例子。

站在更大的视角，用户体验包含画质体验和内容体验，音视频处理的结果是提升大盘视频整体质量，而视频推荐能结合视频质量评估，就可以给用户推荐感兴趣且高质的视频。

从编码标准迭代到全局优化，我认为在兼顾体验和成本的优化上还有不少可以挖掘的点，且在单一技术点上其实也还有很大空间，给出这样的判断基于两个主要原因：一是音视频系统的智能化程度还比较低，更高的智能化意味着能够更好地兼顾体验和成本；此外，我们发现在音视频系统里落地的算法效果离学术界上限还有一定距离，客观原因是学术 idea 通常在很小的数据集上验证，而在亿级视频消费和展现上会有很多问题，但好的一面是，未来如果我们能利用好这些最新 idea 且解决泛化及性能问题，就会产生可观的收益。

下面介绍小红书自研的质量评估指标 RedVQA，它是一个基于深度学习的无参考视频质量评估算法。

回到这张架构图，我们希望 RedVQA 能做什么？

首先，我们希望它能对整个视频链路任一节点的视频质量做评估，包括拍摄视频的原始质量、经过编辑和特效处理后的质量、经过转码下发到消费端的质量。

其次，我们希望它可以指导优化画质及编码算法。

最后，我们希望它能够辅助上层视频业务和应用。

RedVQA 研发目标与挑战

第一个目标是能够捕捉拍摄或上传视频的多种视频质量问题；挑战是如何尽量多地覆盖到各种 UGC 质量问题（比如模糊、过曝欠曝、噪声、颜色不自然、过锐等）。

第二个目标是能够捕捉视频处理链路中的降质和升质变化，要求我们能够识别和理解整个视频链路的升质和降质操作，并且把这些因素融入到算法和数据集设计中。举个例子，低码率编码会引入降质，画质问题表现为：细节丢失、清晰度下降、平坦区出现块效应、边缘和纹理区域出现振铃效应/蚊式噪声。另外值得注意的是，视频压缩相比图像压缩在码率分配上更加复杂，会使得视频质量在空域和时域上不是均匀分布，这也对算法的智能识别能力提出了更高的要求。画质增强算法通常可以提升画质，常见的超分、去模糊、去压缩损失、HDR 等算法有助于改善细节、清晰度、噪声、亮度/色彩等方面的画质体验。

第三个目标是与人眼主观感受质量一致，要求算法智能且泛化强。比如大光圈拍的照片会产生背景虚化效果，人眼觉得 ok、有美感，而算法有可能把虚化的背景误判为模糊问题。

因此，我们决定自研构建 RedVQA 数据集。数据集构建中非常关键的是视频收集，主要思考的问题是如何通过有限的数据集来代表相对无限的大数据，使得训练出来的算法具有很强的泛化能力。实践中，我们分为三个步骤：首先是视频初筛，这一步根据线上视频的标签、垂类和基础视频信息进行筛选，比如主要的分辨率要覆盖到，包含不同的码率、转码质量的视频。第二步，我们需要在候选数据集内采样一批尽可能场景丰富和质量多样的视频子集，我们利用了一些场景分类以及不同画质维度的检测指标作为判断标准。通过指标采样，希望采集到的数据集在各指标上更加均衡或者符合预期。经过前面两步，仍然会缺失一些低质视频，因为有些问题视频占比很少，很难从线上筛选出来。通过对整个视频链路的理解和分析，需要人工补充或构造一些低质视频。

在数据标注和清洗上主要参照 ITU-T P.910 标准，通过流程规范来保证数据标注质量。质量分的定义也比较重要，由于美学具有很强的个体主观性，我们主要考虑画质维度，而不同画质维度的优先级主要参考了小红书的用户调研。

算法设计上，重点是如何有效提取质量特征，这里需要对质量问题的产生过程有充分的认知，比如视频链路中编辑和转码会如何影响质量，我总结了 3 个关键点：

1、在时空采样中，全局构图和局部纹理信息都很重要。质量感知特征体现在局部纹理上，而劣化程度在于全局感知；

2、网络设计要能够捕捉大范围时空信息及依赖关系，人眼对质量的感知涉及到整体语义理解、关注区域、创作意图理解等，很多视频处理操作会在较大的时空范围内影响质量，比如码率分配、ROI 编码；

3、质量评估数据集的量级和完备程度远低于分类识别等 CV 任务，而质量特征又非常复杂，因此需要某种显式地辅助质量特征提取的手段。一种方法是通过添加有序的质量样本或者利用质量评估的代理任务，进行数据增强及质量特征自监督学习。

超分这个课题在学术界和工业界研究了很多年。但面向不同的业务场景和集成系统，端侧超分技术在业务目标和技术方向上存在很明显的区别。

比如面向一款新的硬件设备，只需要基于它的硬件加速器定制化地设计和优化算法即可。

对于视频业务和 APP，需要关注什么，如何获得显著收益，下面分享下我们的理解与实践。

最近两年业界在端侧超分大规模部署上有所突破，效果和覆盖率的进一步提升是大家都关注的问题。但我们也发现另一个问题待解决：通常算法效果验证是离线验证，而上线后很难再对画质算法效果进行量化，有没有 badcase 并不知道。而 QoE 指标是后验指标，而且从定义可以看到它不完全受到画质一个因素影响，因此 QoE 数据的好与坏，并不直接对应超分效果，也没法对算法后续迭代有指导作用。

还要说明的是，如果牺牲一部分收益，落地也会更简单，比如当我们针对一款高端机来设计端侧超分时，可以按照其计算性能打满算法复杂度从而提升效果，但在大盘上的收益就会非常有限。

基于人眼感知质量的端云结合超分框架

当我们设计超分算法时，首先要保证的是 QoS 数据无负向，要求开启超分后的各项技术指标不会显著劣化。而为了达到比较高的覆盖率，需要在中低端机上也能流畅的运行，这对于算法的性能提出了更高的要求。我们对算法的性能目标有个经验性的判断：计算复杂度应该在 GFLOPS 以内，耗时在 10ms 以内，功耗在 100mAh 以内，这样开启超分后的影响可能比较小。

在部署层面，因为 CPU 通常被多任务共享，如果算法过多占用 CPU 和内存也会引起 APP 崩溃，因此我们也要求算法尽量少占用 CPU 和内存。避免“碎片化”部署的意思是，我们不希望设计多个算法，以及针对多个处理器做优化，主要原因还是我们希望第一版算法能够快速验证和部署，尽快带来收益。当然我们后续也计划对部分机型设计更优的算法进行迭代。

下面的表格是一些算法调研总结，可以看到，公开文献中轻量深度学习超分算法 (SCSRN) 仍然有比较大的计算量，尽管网络模型看起来已经非常小了，而在VeriSilicon NPU 上的耗时是 19ms，如果在更通用的处理器上耗时会更大。给出一个计算量级的对比，5×5 高斯滤波的计算量大概在 100Mflops。

我们认识到这个算法的计算复杂度还是有点高，并且难以直接满足我们的性能目标，所以借鉴它的思路做了进一步的优化。下面几个点值得探究和改进：

1、模式分类还是有点复杂，为了降低复杂度，需要通过实验找到最有代表性的特征；

2、当前的 kernel 是解析解，效果上 与 L2 loss 相当，且是线性滤波，如果能引入可导梯度学习，就可以引入非线性滤波以及多种 loss；

3、当前算法是 Patch-to-pixel 映射，如果改成 Patch-to-patch 映射，可能计算会更高效；

4、最后推理结果可能出现一些画质问题，考虑加一些低计算复杂度后处理方法。

总结

端云结合超分是一个非常有价值和可探索的方向，总的目标我们希望端云能够深度协同提升端侧超分后效果，从而无论在画质提升或带宽节省目标上带来更大的收益，这里说的“深度协同”包括整体方案端云划分合理、超分与编解码技术配合、端侧计算与播放策略适配等多个层面。具体来说，可以迭代更优的超分转码档位，设计更具表征能力和利用 Metadata 的超分模型，以及探索超分与编码的融合方案。

以上就是我的全部分享，谢谢！

剑寒

小红书音视频架构视频图像处理算法负责人。模式识别与智能系统专业博士，研究方向包括视频图像算法、异构计算优化等，擅长算法工程联合设计及优化。曾参与或主导“数字电视SoC设计与产业化”(国家科技重大专项)、4K 120 FPS HEVC芯片算法设计、拍照/短视频/直播画质算法研发和落地。