哔哩哔哩视频云画质与窄带高清AI落地实践

视频赛道卷到下半场，一定会面临体验与成本的对抗，尤其是在行业大环境“过冬”的背景下，想要在有限带宽下获得最佳的画质观感变得异常具备挑战性。从视频云业务场景的视角来看，如何有效解决cross-domain问题、如何突破低业务延迟下的算力瓶颈、如何提升单位码字承载的有效信息量，成为我们在实践过程中的应用范式。LiveVideoStackCon 2022 北京站邀请了Bilibili云端多媒体平台的成超老师，为我们分享Bilibili在急速发展过程中基于视频业务上总结的一些先进的经验和想法 。

文/成超

编辑/LiveVideoStack

大家好，我叫成超，来自Bilibili云端多媒体。我们云端多媒体主要负责Bilibili点直播技术业务，而我所在的算法组则是基于AI算法为Bilibili点直播降本增效相关工作赋能。

尽管过去行业在过冬，但是Bilibili仍然是一家保持着非常高增长的公司，我们的用户规模以及播放量一直在持续增长，相关的总带宽成本也在节节攀升。大家参加LiveVideoStackCon2022北京站可能最高频听到的一个词就是降本增效，它对成本增长提出了非常高的要求，我们需要把成本增长控制在一个非常合理并且高效的规模上。但与此同时，我认为B站的初心仍是没有变的，我们始终秉持着“用户是B站最核心的价值”这一信条，也始终期望着用户能够在B站得到最好的音画体验。

围绕着这个目标，我们做了非常多的工作，自下而上我们在预处理层面做了今天要讲的画质矩阵、AI前处理，并且我们有一个很强大的团队自研编码器，再上一层，研究使用编码器开展窄带高清工作，最底层也会设立一道CDN来进行网络、调度和节点优化等等工作。

如果说降本增效是目前行业对于所有公司提出来的命题作文，那么我们的答卷就是：低码高画。

今天我的分享主要分为四部分，第一部分讲视频云AI画质提升链路；第二部分将结合一个非常具体的实时游戏直播来分享我们所做的4K游戏实时超分；第三部分则转到低码部分，讲一下基于低秩重构所做的AI窄带高清前处理算法；第四部分是一个简单的总结及展望，介绍我们在做和未来可能会做的一些工作。

-01-

视频云AI画质提升链路

首先简单谈谈我们对于画质业务的思考和理解，即为什么要在成本受限的情况下仍然坚持做高画质服务，我认为原因可能出于以下四个方面：

第一方面是对于用户，我们认为高画质是科技发展的必然趋势，并不受行业的升降趋势所左右。我们在企业内部提出了一个“全时高清”的概念，即用户在任何时间、任何地点都无需受到任何约束来享受高品质的音画服务；

第二方面是希望对UP主进行赋能，我们希望UP主们能够将百分百的身心投入到idea创作和内容的生产中去，无需受到专业的拍摄器材设备和拍摄条件限制；

第三方面是针对产品和运营，我们希望画质能力能够成为他们执行一些策划或者活动的有效抓手，配合扩大B站的影响力；

第四方面则是针对商业合作伙伴，我们希望能以画质做为切入点，配合他们做好商业宣发和推广活动。

在这里谈谈B站以前旧的画质生产链路，在过往长期的业务需求里我们积累了大量的画质原子能力，形成了画质矩阵，但实际上应用模式并没有实时更新到原子能力的增长上。

举一个简单的例子：以前想要对视频做超分大概要按照这样一个流程，如果上传了一部动漫，在其转码完成后，运营首先要浏览视频内容并判断它适合进行什么样的画质增强处理，如果认为适合做超分，那就将它送到对应的超分服务里去。

这个流程存在的问题就是所有内容都是预先定义好的，如果一个视频需要同时进行多种画质增强处理（如先去噪、再增强、再超分）但目前没有对应服务，那便必须先上线相应的服务才能支持该视频所需的处理流程。这导致旧链路的时效性很差，在业务规模较小的时候尚可，一旦处理需求增长，它势必将受到运营人员的经验主义制约，并且无法实时去响应业务需求。

新链路与旧链路最大的区别在于两点：一个是QoE的接入，我们把QoE接入到画质决策体系中，形成了一个以QoE为主，人工运营策略为辅的决策模式。QoE将会提取视频的约40多个特征，包括视频的信息密度、噪声强度，动态分析结果，一些业务上的指标（如上传的视频是否会成为一个高热度视频），另外还涉及一个内部的无参画质评价。

总之QoE策略加上运营策略最后得到的特征向量，将被送至一个决策器来决策当前投稿究竟适合什么样的画质处理，如果信息密度不够则需要做超分，如果时域性不够强并且有提升空间的话则可以做超帧，如果要进行完美的画质修复，则可能需要进行超分加超帧，甚至还需要进行修复，后续的处理流程可能是非常多样并复杂的。基于此，为了满足视频复杂的画质处理需要，我们要完成可用于自定义画质处理链路的工程支持。

最终我们对画质矩阵重新设计了一套底层的AI处理框架，这也是新旧链路的第二个主要区别。它的思想是把所有的画质原子能力尽量节点化，然后我们将处理流程搭成计算图，以计算图的形式来支持任意的画质处理流程，可以说它在使用上就像搭积