哔哩哔哩点播码率优化实践

LiveVideoStack

大家好,我是来自哔哩哔哩的何钧,很荣幸能有机会与大家分享一些我们的工作,去年底新冠疫情爆发以来,为了控制疫情传播,人们的外出社交活动大幅减少,因此有更多的时间宅在家上网,这对我们音视频行业来说是一个机遇,同时也是一个挑战。

疫情带来大规模超预期的业务增长的同时,我们也面临着带宽成本的急剧增加,如何保证用户体验、节省码率控制带宽成本,是摆在视频网站面前一个永恒的话题,我今天带来的分享是关于我们哔哩哔哩这两年在点播视频码率优化方面的一些实践经验,希望能给大家带来一些小小的启发。

1. 业务介绍

首先介绍一下哔哩哔哩,哔哩哔哩大家习惯叫做b站,或者有些人也亲切的叫我们小破站。

哔哩哔哩2009年在杭州成立,后来搬到上海,2018年的时候我们在纳斯达克上市。

伴随着十一年的发展,哔哩哔哩从一个主打ACG内容的小众网站,逐渐发展成为涵盖各种类型在线娱乐内容的年轻人文化社区,我们提供多种多样的产品和服务,除了大家熟知的视频点播、直播,我们还有漫画、电商、游戏、音频、广告,甚至还有影业以及我们自己的电竞战队,到今年的一季度,我们的日活跃用户达到了5100万,月活跃用户超过1.72亿,其中移动端的活跃用户有1.56亿,虽然从相对数据上,我们与爱奇艺、优酷、腾讯这几个长视频的行业巨头还有比较明显的差距,但从绝对用户数上来看,这个数字已经非常可观了,我们在技术上的一点革新,都可以极大的提升我们用户的使用体验。

上面提到的这些产品与服务中,视频点播无疑是我们最重要的基本盘。

在哔哩哔哩,每月有超过180万的活跃的内容创作者,我们称之为up主,这些up主每月创作超过了490万的视频,丰富的视频内容每天会被播放超过11亿次,而视频处理就是内容创作与内容消费最重要的纽带。

如此多的用户视频,其内容千差万别,规格也是千奇百怪,它们有不同的格式、码率、帧率和分辨率,为了这些视频能被大家观看到,并且保证统一的体验,我们会对视频做统一的处理,按照一定的标准输出成统一规格的视频,以适应不同播放场景(网页端、APP、大屏电视的客户端)的需求。

近年来随着移动互联网的普及,4G资费降低,越来越多的用户选择在移动网络下观看视频,移动网络并不像家用宽带那样稳定,也没有家用宽带那么高的带宽,观看高码率视频势必会增加卡顿,再加上用户规模扩大,播放带宽成本也越来越高,所以在做到投稿低延时和视频高画质的基础上,点播码率的优化就成了我们降低用户卡顿、节省带宽成本的一剂良方。

大家都知道在做编码的时候,码率、画质、编码复杂度三者是不能兼顾的,三个要素当中画质是我们不能妥协的,我们在不同阶段探索码率优化方案的时候,其实是在降低码率和控制转码复杂度之间做一个权衡。

2. 码率优化方法论

2.1 画质评价

如何评价画质呢?和很多的同行一样,我们也用了一些业内公认的基于信号学的指标,包括PSNR、SSIM,这些信号学的指标是很客观的,但是有时候与人的感官体验不一致,所以在客观的信号学指标的基础上,我们也自研了一套主观的盲测评价系统,这套系统可以用同屏来播放两个不同处理的相同内容的视频,让用户选择哪个视频更好,通过对不同的视频编码方式,收集大量的主观判断的数据,我们来选出一套合适的编码方案。另外,在NETFIX提出VMAF的评价指标后,我们也引入了VMAF作为评价画质的参考,通过计算视频的VMAF分数来判断画质的损失。

接下来我会介绍一下哔哩哔哩在点播码率上的一些优化方向,之后会解释我们是如何将这些优化应用到业务实践的。

常规的我们会把码率优化分为两大类:编码器的优化和基于视频内容的感知编码的优化(也可以叫做编码器外的优化)。

2.2 编码器优化

编码器的优化很好理解,众所周知每一代编码标准都会在上一代的基础上带来同质量下50%的码率节省,其代价肯定是更高的编码复杂度。

示意图是2015年的一个测试数据,那时的H.265和VP9编码器处于比较初期的阶段,没有经过很好的优化,即使这样,在相同的SSIM分数下,H.264的x264编码器比VP9的libvpx和H.265的x265在相同之下都要多出49%的码率。那我们哔哩哔哩自己的视频处理服务是在2015年上线的,当时我们选择的却是H.264,这是因为受限于当时的解码兼容性,当时手机端的解码性能,还不能跟上这个新一代标准的解码需求,另外由于专利的问题,浏览器又缺乏对H.265的解码支持。

但是随着4G的普及和手机性能的提升,目前移动端的观看视频占比越来越大,使用H.265编码也就重新进入我们的考量范围内,2019年,我们上线了自研的H.265/YHEVC编码器,与开源编码器相比,相同画质下H.265/YHEVC编码器能达到三倍编码速度的提升。我们通过升级编码器,在相同的编码质量下获得了30%的码率节省,而复杂度只增加了20%,美中不足就是受限于解码的兼容性,目前YHEVC的编码只能应用于我们的APP端。

2.3 内容优化

第二个方向是对于视频内容的优化,对于视频网站来说,通常输入一个视频需要转出多个不同分辨率的视频。针对不同的分辨率,常规的做法是设定一个码率阶梯,为每一组分辨率选择一个合适的输出码率,比如图中表格是一个常规的H.264的码率阶梯,这个阶梯是从360P 30帧一直到1080P 60帧,码率分配从400k分配涨到了6m,这样的码率分布在大多数的场景下是合理的。不同的码率输入的视频会按照码率阶梯的码率上限来进行压制。

但是也有一些例外,例如英雄联盟这个游戏视频的画面,原始视频的分辨率是1080P 30帧,码率是6兆,按照常规码率阶梯方案压制后,输出的码率达到1080P 30帧的上限,码率为3兆,但是分析画面可以看出,这个2D游戏的边缘过度平滑,场景也不是很复杂,编码复杂度其实不高,完全可以将码率压的更低。

再看基于内容优化的编码输出结果,在相同质量下使用内容感知编码方式压制,码率不到2兆。这个基于内容感知编码,思想就是给不同的复杂度的视频挑选最合适的编码方式,达到在相同画质下降低码率的效果。

将内容感知编码按照编码处理的细粒度分为两类:第一类是以视频内容的类型为维度,比如动画、游戏、舞蹈等常见的视频形式作为分类方式。我们给不同类型的视频挑选出适合该场景类型的编码参数,在实际的操作中,针对每一类的内容做了大量的离线编码测试和主客观的质量评定,从离线实验中制定出各类合适的内容编码参数。第二类,是根据内容的优化更细致的分类,为每个视频的每个不同场景挑选出一组最合适的编码参数,需要在处理每一个视频中先按视频场景进行视频内容切分,对场景逐个分析,挑选出最合适的参数,从而达到整个视频的码率最优解。

2.3.1 CAE Per Category

对于内容分类的码率优化其实是一个离线参数的调优过程,我们在实践中会预先挑选各个类型的线上视频样本。如示意图,以舞蹈视频为例,内容是哔哩哔哩比较火的一个up主叫“一只小仙若”,这是一个古风的舞蹈视频,这类的视频场景通常是非常固定的,在一个开阔的室外环境跳舞,那画面中唯一运动的就是跳舞的主体,针对这样的舞蹈内容,我们会给出几套不同的转码参数方案进行转码,转完之后我们会再计算出转出各个视频的VMAF分数和我们常规的转码方式做对比,结果发现第3套参数的VMAF分数值是明显偏低的,这时我们就把第3套的这个转码参数放弃掉。经过VMAF分数的筛选,还会再经历一轮内部主观盲测,挑选出一套最合适的参数,在这个案例中我们挑选出的是参数1,可以看到挑选出来的这套参数,其实在码率上并不是最优的,而是经过主观评定后,我们认为他最终在感官体验上和原来的转码方式是最接近的。

每一个分类的参数适配其实是非常耗费资源的,选择参数需要经过非常多的离线实验,我们要挑出参数1、参数2、参数3这三套参数,可能在线下会经过大量的参数筛选,离线的去计算SSIM、PSMI,从而得出相对合理的几套参数值。

有了参数之后,转码完成后的VMAF计算也需要大量的算力,如果不考虑离线实验时的计算消耗,我们目前应用于线上的根据内容分类的转码,平均会有30%以上的码率节省,但是实时转码复杂度也会增加1.5~2倍。这个方案,既可以用H.264的编码,也可以用H.265的编码,所以它在各端其实都有适用场景。

2.3.2 CAE Per Title

另一种内容感知编码的优化是按照场景分得更细,需要为每一个场景挑选一套合适的编码参数,如果按照内容分类的做法就需要做场景切分。以上图中的例子为例,这是一个4k的测试视频,做完场景切分后大致分为三个主要的场景,第1个是室外自然风光的场景,第2个是室外城市风景的场景,第3个是室内的场景,做完场景切分后,需要为每一个场景选一套合适的编码参数,最后对所有的场景做合并,这个方式离线应用于单个视频看起来是可行的,但是如果要为线上千千万万的视频量身定制转码参数,显然是不可操作的。

基于上述遇到的问题,我们在方案中引入了机器学习,利用之前在分类离线优化时的经验和数据,结合编码器编码时提取的编码器特征训练模型,帮助在线为每个场景决策出合适的转码参数,当完成场景的切分后,我们会对单个的场景进行一次常规的转码,提取出此次转码的编码器特征送入到机器学习的模型中,模型会预测出一套参数,再使用这套参数完成优化转码,对未优化的视频和优化的视频做VMAF计算和码率比较,验证这套参数是否可行、是否合适。当完成所有的场景的优化转码之后,有些场景可以被优化,有些场景可能机器学习模型预测出的参数并没有做到优化,那我们就会保留原始的常规转化的场景,再把各个切分场景做合并,得到最终的视频。

可以看到在整个过程当中,每个场景其实进行了两次转码以及两次VMAF计算,所以复杂度方面相较于常规流程会有三倍以上的提升,如果要应用于线上实时的话,那这个复杂度换来的将是单个视频40%的码率节省。

从码率和复杂度上两个维度上,不同的码率优化方式可以得出一个简单的分布,横轴表示复杂度,越靠近原点复杂度越低,纵轴代表码率,越接近原点表示码率越低。可以看到,H.264的复杂度是最低的,但同时其码率是最高的,而基于视频场景的内容优化结合H.265编码可以做到50%码率节省,但是消耗的算力也是惊人的。另外我们自研的YHEVC的265的编码器,效率是非常好的,它可以有效地降低码率,复杂度却增加的不多,但是由于H.265不是全平台的支持,它并不能适用于所有的场景。所以码率优化其实并没有一个非常完美的方案,要综合考虑业务场景、算力储备以及播放兼容性等各个因素来综合权衡。

3. 码率优化结合业务的实践

3.1 第一阶段

我们的码率优化实践就是遵循着上述的条件来一步一步实施的,在2017年和2018年,我们的投保量没有达到现在这个规模,还有一些富裕的算力,所以就选择了挑选一些热门的内容分区来进行离线试验,把试验的结果用H.264编码应用到线上,虽然增加了一些复杂度,但是可以换来全平台的码率节省。到了2018年底,YHEVC编码器已经研发完成准备上线,但此时有两个问题:

1. 我们有相当一部分的流量在网页端,虽然YHEVC的编码效率非常好,但是不能直接全量替换当前的H.264的编码方案。

2. 由于不是全量替换,H.264编码是必须进行的,加上H.265的转码,视频从投稿到能被用户看到的时间就会增加,这对于业务方是不能接受的,他们希望up主投稿的视频能够越快被看到越好。

此外我们的算力储备也不能支撑所有视频都做H.264和H.265的两次转码,算力增加不多的YHEVC都不可能全面应用,更不用说实时应用需要大量算力的内容感知编码优化。

3.2 第二阶段

为了解决上述提到的问题,我们提出了多版本的概念,并开发了一套转码优化的框架,加入了视频处理策略中心,采用触发式的方式优化。可以看到图中用户投稿的流程不变,还是按照H.264的编码方式进行快速处理,快速生产出第1个版本的视频,让用户能先观看到,而与此同时又会有另一条基于数据驱动的视频处理流在同步执行,实时的收集用户和视频相关信息,在第一个版本开放后,开始收集用户观看行为的数据,结合我们当时自身算力空闲情况,下发优化转码任务,生产出另外一个经过码率优化的视频版本,来替换掉线上快速处理的H.264版本,之后的用户就会看到一个画质相同、码率更低更流畅的视频。

这套框架的核心其实是个策略中心,它可以融入我之前提到的多种的优化方案,通过策略中心的不同配置并结合实时数据为不同的视频产生多个转码方案。例如检测到投稿用户的属性,如果是粉丝数非常多,非常知名的内容创作up主,在用户投稿的时候,就会同时产生H.264和H.265的双重编码任务,以保证第一时间能够做到手机端的用户用H.265低码率来播放。再例如通过实时播放量的统计,针对热度很高的视频触发基于内容感知编码的优化,我们甚至可以去区分这些访问流量的来源,是来源于网页端多还是手机端多,如果来源于手机端多,那就可以直接触发基于内容感知编码的H.265优化;如果是浏览器端多,那就触发H.264的优化。

这个触发式优化的核心是用合理的算力消耗换取观看码率的降低,所以在充分利用公司的平台算力之外,我们会用一些日常的监控指标去检测我们的策略是否有效。

4. 实际效果

检测策略是否有效主要关注三个指标:

1. 第一是用户观看经过优化的视频播放覆盖率,覆盖率越高,就说明我们的策略是越高效,我们目前做到了80%的播放覆盖率,即有80%的视频播放都是经过优化处理的版本。哔哩哔哩鼓励创作,所以内容非常的丰富,观看者的选择也就非常的多,相对观看内容的长尾效应非常明显,受限于算力,要做到100%的覆盖率是比较困难的,80%是一个还不错的数字。

2. 第二是码率,我们会统计每天所有视频观看的平均码率,从上图左边的示意图可以看到,从2019年初到现在,b站的平均观看码率是呈下降趋势的,已经做到累计38%的码率下降。事实上随着up主拍摄设备的升级,上传速度的增加,我们接收到上传的原始的内容的平均码率其实增加了50%,在用户创作的内容质量越来越好的情况下,我们的视频转码在保持高画质的同时还做到了码率下降,这直接提升了用户的播放体验,同时也做到带宽的节省。

3. 第三是卡顿率,我们总体的卡顿率从2019年初到现在下降超过50%,需要说明的是卡顿率的下降不完全是码率优化的结果,还有其他因素,一方面随着基建的升级,用户网络环境越来越好;另一方面我们在客户端也做了大量的播放体验的优化,所以综合起来使得卡顿率下降了50%以上。

5. 未来展望

我们还有很多工作在做或者将要做:

1. 首先会继续优化YHEVC编码器,在编码器内加入一些AI算法,同时我们也在预研下一代AV1、VVC的编码方案。

2. 其次针对内容感知优化,我们考虑加入一些视频的前处理,把场景切分的更细,能够提取更多的特征以达到更好的码率优化效果。为了加速感知编码的整个流程,VMAF计算我们考虑使用GPU,经过调研, VMAF在GPU上运行,处理吞吐率可以比CPU快3~4倍。

3. 最后我们也在和客户端团队配合,希望能将实时超分技术运用到客户端,做到最大程度的带宽节省。

阅读 2.9k
144 声望
38 粉丝
0 条评论
你知道吗?

144 声望
38 粉丝
文章目录
宣传栏