基于人眼感知质量的端云结合画质及带宽优化实践

  //  

编者按：随着小红书视频业务和短视频播放的规模化增长，如何有效地提升用户体验质量同时降低视频带宽成本成为一个重要的技术优化目标。LiveVideoStackCon 2023 上海站邀请到小红书的剑寒为大家分享小红书音视频架构算法团队开发的基于人眼感知质量的端云结合超分框架和画质及带宽优化相关实践。

文/剑寒

编辑/LiveVideoStack

大家好，我是剑寒，目前在小红书音视频架构负责视频图像算法研发和落地。今天我分享的主题是《基于人眼感知质量的端云结合画质及带宽优化实践》，核心是画质与带宽优化，有两个关键词分别是端云结合以及人眼感知质量。

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

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

2. 接下来介绍小红书自研的一个基于 AI 的无参考视频质量评估算法 RedVQA，它提供与人眼视觉感知一致的质量评估。

3. 我们结合 RedVQA 设计了一个端云结合超分，在带宽节省以及多项播放技术指标上具有显著收益，契合当下降本增效的需求。端侧超分的部署在画质提升以及带宽节省上都有帮助。

4. 最后是总结和展望。

-01-

视频处理架构与画质带宽优化

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

小红书最初主要面向消费场景，比如美妆产品的分享和购买攻略。经过近几年的发展，小红书已经变成了一个综合的 UGC 分享社区，在“衣食住行玩”各方面都有大量的用户真实分享，提供很多有价值的信息。同时用户群体也发生了较大的变化，性别以及各年龄段的用户比例变得更加均衡。

另一个显著的变化是：小红书以前主要是图文笔记分享，随着视频成为用户分享生活的重要载体，小红书也响应趋势提出视频战略，目前用户刷小红书可以发现视频笔记占了很大的比例。当前每日新增视频达到了百万级别，直播消费侧业务也在稳步提升。

那么，PUGC 点播及直播业务背后涉及的关键技术有哪些？

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

回归本次分享的主题：如何对画质与带宽进行优化？

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

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

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

1、模块级优化

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

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

2、跨技术方向融合

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

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

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

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

3、全局系统优化

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

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

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

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

从模块优化到全局优化的演进过程中，我认为最重要且最基础的能力升级是质量评估。如果只是优化编码，可以用 PSNR/SSIM/VMAF 等有参考指标。而当构建智能转码时，这些有参考质量评估方法不再适用，比如经过画质增强的视频比原视频看着更好。此外，站在全局视角来看，很多处理节点也没有参考视频可用，相对质量评估方法也无法使用。因此质量评估需要升级为以人眼感知质量为基础，并且评估视频的绝对质量。

-02-

基于人眼感知的质量评估指标 RedVQA

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

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

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

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

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

基于上面的分析，我总结下 RedVQA 的研发目标与挑战。

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

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

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

在自研数据集前，我们收集了质量评估领域的几个主要数据集，通过分析和总结得出一些结论：a. 相比 CV 任务，开源质量评估数据集规模很小；b. 数据来源可能和我们线上不太一致，包括用户设备和拍摄专业程度等；c. 开源数据集缺少经过业务视频链路处理的数据，如小红书特有的编码/画质处理、特效模板处理；d. 我们也测试了使用开源数据集训练的算法在业务测试集上的准确率，结果比开源数据集低很多。

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

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

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

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

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

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

接下来是算法验证。首先介绍下质量评估领域的几个评价指标，PLCC 表示相关性，SRCC/KRCC 反映保序性，RMSE 反映绝对误差。RedVQA 的相关性在 0.9 左右，达到了可用的状态。此外，我们也验证了算法对质量劣化的敏感程度，首先需要构造一批质量保序的样本。我们通过编码参数的配置得到一系列不同分辨率和码率的样本，实际线上转码服务也是基于不同分辨率以及不同的编码参数来设计转码档位，这也贴合了线上的视频处理方式。上图可以看到，随着质量控制参数 CRF 的增大，质量分逐渐减小，符合预期，说明算法可以在一定程度上捕捉一些细微的质量损失。其次，我们也看到，同一个视频的不同分辨率版本，高分辨率质量整体优于低分辨率，这也符合预期。

基于 RedVQA，我们实现了一个大盘质量监控看板，按照不同的维度统计视频的质量分。通过这些数据，有助于了解大盘整体的视频质量以及各拆分维度的质量。在有了数据后，后续的优化动作变得有据可依。图中展示了不同垂类的视频质量分，不同分位数的质量统计使得我们对生产侧视频的质量分布有了全局的掌握。右边上图是按照分辨率拆分的生产侧视频质量统计，右边下图是不同编辑方式的统计。

除了生产侧质量监控，消费侧视频质量监控更加重要，这决定了小红书对用户呈现的整体质量。消费侧比生产侧更复杂，一方面为了应对网速变化、成本控制以及端设备计算能力不同，每个上传视频都需要转码成不同的档位，通过播放控制来决策下发档位；另一方面，推荐系统会极大影响用户看到的视频内容，因此消费侧质量监控除了有助于了解实际用户看到的视频质量，也有助于我们对转码档位、播放以及推荐策略的优化。

-03-

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

下面介绍端云结合超分，也是今年我们降本增效的重点项目。

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

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

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

对于视频 APP 来说，一个算法能不能落地，除了离线评测外，AB 实验数据是最终量化指标。我们希望获得 QoS 技术指标和 QoE 业务指标的正向收益，对于降本增效任务来说，带宽节省也是最重要的一个指标。而播放端视频算法落地，算法性能有极大的影响，算法耗时长可能引起卡顿、集成方式不对可能导致播放失败率和首帧时长增加。此外，用户设备机型及性能多种多样，通常在高端机上部署算法比较容易，如果想进一步覆盖到中低端机会非常困难。

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

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

为了获取最大的收益，我们设计了一个基于人眼感知质量的端云结合超分方案来解决上述挑战，主要分为云端媒体处理和端侧播放两部分。用户在看视频时，对应的云端视频是有多个档位的，而不同的档位对应不同的决策。对超分来说，端侧超分算法部署在播放端解码之后，同时我们在云端为端侧超分定制化了的一个超分档位，定制化的目的是为了精细化控制超分开启策略且补偿最终端侧超分的效果。首先，我们通过带宽高峰期预测来控制超分档位下发的时间段；其次，我们通过质量&码率收益评估来更好地平衡用户体验与带宽收益，动态精细地量化出每个视频的质量问题及收益，避免超分效果不佳的视频产生超分档位，这里用到的质量评估即是前文提到的 RedVQA。

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

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

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

虽然可以进一步对上述算法进行模型压缩，不过我们总体判断在极轻量算法设计中，有图像理论指导的 low level 图像算法会比深度学习更高效，因此我们把目光投向超分领域更早的文献。这里列出一篇 Google 发表的很有启发意义的文献，被用于节省图片下发带宽。总体来说，这是一个 two-stage 算法，推理时先对图片 patch 进行模式分类，选出滤波 kernel，然后用这个 kernel 进行滤波，可以认为是一个内容自适应的滤波算法。在训练阶段，通过将相同分类的输入 patch 及对应的 ground truth pixel 集合在一起形成训练集，求解出 kernel。需要说明的是，这个算法的 kernel 求解不是通过梯度后向传播训练出来的，而是直接求的解析解。从左下图可以看到，这个算法在当时还是非常高效的，可以达到实时。

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

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

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

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

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

尽管在端侧超分算法上做了精心设计，但受限于其本身的计算量，能实现的效果还是有限。如果是一款终端产品研发，似乎也没有更好的办法。而在我们的视频处理架构中，端侧超分的输入视频或者下发的超分档位是由云端转码而来。通过定制化超分档位，可以有效提升和补偿端侧超分效果。实践中，我们基于 RedVQA 把原视频分成高质和低质。对于高质视频，可以通过云端增强算法有效提升超分后的纹理细节；对于低质视频，重点在于去除一些压缩损失，避免 artifact 放大。

下面是整套方案的离线评测。上图是性能数据，对于一个 60fps 540P 的视频，开关超分帧率降得不多，GPU 占用增加 20%，内存增加 8M 左右（在撰写本文时，GPU 及内存占用经算法及性能优化后进一步降低），基本没有发热问题。下表是超分档位的码率和 RedVQA 质量分数据，其中超分档位是一个 540P 档位，我们用了自适应锐化以及深度学习增强来生成超分档位，对比的档位是一个 720P 档位，考虑计算时效以及计算成本，这个档位只带了自适应锐化。可以看到超分档位相比 720P 档位有 40% 的码率节省，平均质量分会小一点，而经过端侧超分后，平均质量分也超过了 720P 档位。进一步看下超分结果和 720P 视频的质量分差值分布，会发现并不是每个超分后视频质量分都高于 720P 视频。总的来说，RedVQA 提供了一种规模量化视频质量的方式，目前在画质优化方向上的准召率上还没有非常精细，不过实践中我们可以做一些权衡和策略来弥补。

以上是两个画质优化的例子。上图超分档位码率节省 45%，RedVQA 提升 0.529；下图码率节省 32%，RedVQA 提升 0.275。从这两个例子可以看到，超分视频同时兼具了画质收益和带宽收益。

再看两个劣化 case。上图超分档位码率节省 45%，RedVQA 降低 0.09；下图码率节省 46%，RedVQA 降低 0.13。我们也发现，并不是所有 RedVQA 降低都是画质劣化，但当码率节省过大时，比如这两个 case 都超过了 40% 的平均码率节省，判定为画质劣化的准确率就会提升。如前面所述，我们通过质量&码率收益评估可以更好的平衡用户体验与带宽成本，避免一些极端的劣化 case 影响用户体验。

我们也做了 AB 实验佐证大盘上的表现。实验条件是基于 iPhone XR/XS 及以上开启超分，在带宽高峰 3 小时下发超分档位。实验结果还比较正向，QoE 数据整体波动，说明超分整体效果基本没大的问题，QoS 数据在卡顿率、启播失败率等技术指标上有显著优化，下发码率及带宽节省也比较显著。

-04-

总结与展望

最后做下总结。在降本增效的大背景下，如何兼顾体验和成本是大家都很关注的问题。但对于音视频处理来说，体验和成本一直都是音视频处理的“一体两面”，而算法研发以及技术的迭代就是为了实现“既要又要”。从技术角度来说，我更关注如何提升音视频系统智能化这个话题，智能化的目标之一就是实现“既要又要”，另一个目标是实现更高的系统自动化程度及效率。另外，更好的跨方向技术融合以及全局系统优化能力可能是构建更智能音视频系统的有效途径，而基于人眼感知的质量评估是支撑音视频系统智能化的关键技术。最后，端侧超分部署面临性能要求苛刻、部署覆盖率低、难规模量化等挑战，我们设计了一个基于人眼感知质量的端云结合超分来解决这些挑战。

对于未来的展望，我们希望达到更智能的质量评估，在细粒度质量评估上有所提升，期待在画质优化方面发挥更好的作用。另外，未来我们会持续优化云端“窄带高清”视频转码，“窄带高清”的效果和收益会随着转码智能化程度的提升而持续扩大，但同时我们判断，整体收益提升的同时可能会伴随着画质分布方差也变大，融合了多种技术的“窄带高清”码流也对质量评估的准确性和泛化能力提出了更高的要求。

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

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

---

LiveVideoStackCon是每个多媒体技术人的舞台，如果您在团队、公司中独当一面，在某一领域或技术拥有多年实践，并热衷于技术交流，欢迎申请成为LiveVideoStackCon的出品人/讲师。