作为一个视频网站，随着B站的视频种类的增多，网站的成本压力增加，考虑到降低成本，就要选择一个超低码率的编码器。本文来自B站视频云技术部的技术专家叶天晓在LiveVideoStackCon2019北京站上的精彩分享，文章中详细介绍了B站自研的H.265软件编码器(yhevc)研发历程, 以及针对实际的点播和直播业务做的一些优化与实践。
文 / 叶天晓
整理 / LiveVideoStack
大家好，我是来自B站视频云技术部的技术专家叶天晓，今天和大家分享的主题是B站H.265编码器在直播和点播中的实践和应用。
先自我介绍一下，我初次接触视频编解码是在2004年，当时H.264协议刚刚制定完成，我的主要研究方向是H.263、264的转码以及H.264的编码。回国后我加入了国内的多家公司从事视频算法相关的工作。2018年加入B站，现任视频云技术专家，负责视频编解码团队. 目前在B站研发并上线了自研的H.265编码器(yhevc)，应用于点播和直播业务。
1. 自研H.265的编码器研发的背景
这次演讲的内容分为五部分，第一部分介绍B站做自研编码器的原因，第二部分介绍做视频编码器的方法论, 从工程角度分享一些我做编码器的心得体会, 第三部分介绍一下自研编码器的现状以及应用场景。最后介绍一下编码器对直播和点播的一些特殊优化。
早期的B站不做视频转码, 即将UP主上传的视频直接分发给用户，但这种操作流程会带来很多弊端。首先, UP主的视频有很多编码标准，比如realmedia, H.263，H.264。而且相同编码标准也有各种profile(例如baseline，main, high)以及不同的level。其次, UP主的视频有各种封装格式, 例如mp4, flv, mov, mkv等等. 当用户观看不同封装, 不同编码格式的视频时，可能会出现各种播放问题，例如手机不支持某个profile或level，或者播放器对某种封装兼容不佳, 都就会导致播放卡顿、黑屏等问题。现在的B站会对绝大部分的UP主视频做转码转封装, 来规避上面所述的播放兼容问题。
1.1 B站点播业务
这两年来，B站单日用户上传量在翻倍增长，公司做了很多策略去激励UP主上传视频。2018年1月，B站推出UP主激励计划，培训UP主做出更好的视频去吸引用户。2月, B站支持60fps和6兆码率视频观看，提高了付费大会员的视频观看质量。8月, B站支持DASH技术, 做到多分辨率之间无缝切换。2018年底, B站将UP主单个视频的上传文件体积限制由4GB提高到8GB，这样可以让UP主上传更好画质的源视频, 让我们转码出来的视频质量也变得更好。2019年6月，B站在PGC支持了4K分辨率。
1.2 B站直播业务
在B站直播方面，上图这种一个1080p60fps的6兆码率的吃鸡视频会给弱网用户带来严重的卡顿，所以B站采用实时转码的方案, 将码率降低至2.5兆或以下, 提供低码率视频流, 满足各类用户的需求。
1.3 B站成本压力
B站已经从以动漫为主的小众网站，渐渐变成了视频种类包罗万象的中国版YouTube。随着B站视频的数量变多，画幅变大，时长变长，B站的成本压力也一直在快速增长, 这其中主要包括带宽成本, 存储成本，和转码算力成本.
1.4 自研H.265视频编码器的原因
H.265协议是2013年制定的, 相比H.264可以节省50%的码率，2019年市面上90%的手机都已支持H.265硬件解码。为了节省成本, B站要上H.265有三种选择：一是使用开源x265编码器，但是它的算力要求高, 转码效率低；二是云厂商转码服务，但这会导致转码方面的成本很高；三是自研编码器，也是我们最终选择的方案. 自研软件编码器需要很强的开发能力, 但它的可控性, 与业务结合的可定制性对B站业务是极为有利的, 从长远来看也是成本最低的方案. 此外,软件编码器除了编码以外，还是一个天然的数据生成器. 它能输出各种可定制的信息, 与AI技术结合做出更多的优化方案。
2. 如何做视频编码器
2.1 怎样做视频编码器
研发视频编码器可以认为是在一个三维空间做优化. 这三个维度分别是：画质、复杂度、码率。在这个优化的区域内有两个极限点: 1. 如不考虑复杂度，做一个画质最好的编码器，就可以选用H.265的参考编码软件HM. 2. 如果想做一个速度最快的编码器，则可以直接将一个解码器进行改造，可以跳过所有的高复杂度编码流程. 这两个极限点可以认为是触手可得, 并且有现成代码可用. 而一般视频编码器开发的难点则是在这两个极限点中间做优化, 这需要很大的研发投入.
2.2 怎样做视频编码器
视频编码器的研发环境主要由三个部分组成的: 视频解码器、测试架构、数据分析工具。在研发yhevc期间, 我们用HM解码器做修改，将它作为质量评析以及编码器验证的工具, 来快速定位到某个编码模块的问题。我们的测试架构是由python脚本以及数据库组成. 在测试的时候, 脚本调用编码器, 解码器, 以及数据分析工具，将各种各样的测试场景的结果固化地输出到数据库，验证新的idea是否有效. 我们的数据分析工具是由python脚本及Matlab组成，主要做数据可视化分析.
2.3 视频编码器的研发过程
视频编码器的研发过程可以大致分为三步: 首先是正确编码, 即编码器和解码器做到完全匹配；其次是高效编码，即研发优秀高效的算法来加速编码器并保证编码画质；最后是业务结合编码, 即根据业务场景及编码pipeline对编码器做优化适配。
2.4 yhevc正确编码测试方法
根据我们的经验, 正确编码可以通过两类测试来验证：一, 编码器和解码器之间的比对测试, 二,编码器和编码器自身的比对测试。在第一类测试中, 熵编码层的测试主要是验证nal层代码的正确性. 重建层的测试是验证例如IDCT及Inverse quantization代码的正确性. 预测层的测试是为了验证例如inter-prediction 及motion composition代码的正确性。在第二类测试中, debug和release、x86和Linux的测试可以验证出数据alignment的问题; 多线程和单线程、first time和second time的测试是为了验证编码deterministic的问题。
2.5.1 yhevc正确编码测试举例一
下面举三个yhevc正确编码测试的例子。
第一个例子是CUSize与TUSize相关的测试. 表格中的每一行表示一种CuTu的配置方式, 其中表格的第一行是大部分编码器使用H.265协议推荐的默认配置。我们在研发yhevc的时候不仅仅测试了这个默认配置, 还对H.265协议所允许的所有CuTu设定都做了验证测试，来提高yhevc编码器的强壮度.
2.5.2 yhevc正确编码测试举例二
第二个例子与FrameSize相关. yhevc的编码测试可使用的最小的framesize是8×8, 相比较x265所能允许的最小64x64,我们的yhevc编码器可以更早的发现bug。例子二里所列的frameSize和例子一所列出的CuTu配置可以进行交错测试，来提高yhevc编码器的强壮度。
2.5.3 yhevc正确编码测试举例三
例子三是编码器随机测试. 左图是正常编码的一个视频分析图，右图是随机模式下的视频分析图. 测试的时候, 打开yhevc编码器的debug开关, 可以将CU中的QP、模式的选择、CU Size、TU Depth、motionvector(MV) 等等都设定为随机值, 来验证编码器的强壮度。这里重点说下MV，右图中随机模式下的很多MV指向frame边界之外，这样可以验证多帧并行编码的时的同步机制是否正确。
2.6 yhevc编码器算法分类
基于复杂度和画质的变化, 编码器的算法大致可以分为四类: 一,复杂度不变画质提高的算法. 这类算法一般是预分析和码控相关算法，他们的复杂度不高，但可以大幅提高画质。二, 复杂度及画质都提高的算法. 这类算法又分两种：增加编码工具 ，例如weighted motion estimation；增加复杂度，例如 RDOQ. 三, 复杂度和画质都降低的算法. 这类就是俗称的快速算法, 可以参考很多paper，例如TU、PU、CU的快速分割策略. 四, 复杂度降低画质不变的算法. 这类算法偏工程, 例如C语言, 汇编语言优化、多线程的优化。
在不同的算力预算下, 可以从这四类的算法中抽取算法组合达到最优画质效果, 所以在这四类算法中选择最优算法集也是一个研发难点.
3. 自有编码器现状
3.1 自有编码器现状
关于自有编码器的现状，yhevc编码器是从0编写，包含40多个快速算法，80多个配置参数。我们的编码器支持主流的编码工具集以及多个preset档位, 现在已用于B站的点播及直播业务。相比x265，yhevc在相同画质下能达到3~10倍的编码速度。
3.2 yhevc编码器的点播业务性能
点播业务的测试结果: 左图PSNR体现出yhevc比x265在同码率下高0.3~0.4的PSNR；右图Speed体现出yhevc可以达到x265三倍左右的编码速度。
3.3 yhevc编码器的直播业务性能
直播业务的测试结果，可以看到，yhevc的ultrafast可以达到x265的veryfast编码质量, 并达到2倍编码速度。
3.4 yhevc编码器上线B站历程
B站在2018年底开始在点播和直播转码系统中试上线yhevc，并于2019年1月开始全量上线。B站手机用户现在看到的视频大多已采用H.265格式，现今H.265的流量占比已超过50%. 预计2019年末, B站单日H.265流量占比会达到80%左右.
4. 视频编码器针对B站直播业务的优化
4.1 视频编码器在直播中的痛点
这章介绍一下yhevc针对直播转码这个业务场景下的优化. 软件编码器在直播中有的一个很大的痛点, 即编码速度不恒定, 这主要是由于软件编码器内部的快速算法导致的。例如上图这个例子, 复杂场景下软件编码速度就会下降到60fps以下, 造成观众播放卡顿.
4.2 视频编码器在直播中痛点的因素及解决方案
这个痛点是由多因素造成: 首先, 待转码视频的复杂度差异很大,比如足球比赛和视频会议的复杂度天差地别；其次, 转码目标分辨率、码率、帧率的多种组合, 会导致对转码算力有不同的需求; 再次,转码期间CPU算力变化，比如在一个服务器上做三路直播转码时，加入第四路时，CPU之间会有一个资源的抢占问题。
这个痛点的传统解决方式有两种: 一, 针对某个码率、帧率、分区，设定一个能够保证实时编码的编码档位，但这样会引起码率的上升从而导致成本上升。二,针对每个视频都调试设定一个能够保证实时的编码档位，但这需要大量人力成本，而且有时也不一定有效。
4.3 复杂度自适应视频编码器解决直播中的痛点的方案
针对前面所述痛点，我们研发了一个复杂度自适应的视频编码器, 在编码器内部根据编码的状态以及输出fps做一个闭环控制，来控制预分析码模块和编码模块中档位的设定。
4.4 复杂度自适应的视频编码器效果
图1是复杂度自适应的视频编码器的一个效果展示, 横轴是时间轴，纵轴是编码fps。采用了自适应编码之后可以在复杂场景下降低编码复杂度档位来避免编码卡顿问题。
图2, 图3是编码质量和编码复杂度切换图. 当复杂度很高时，自适应编码器会把preset 降到ultrafast和veryfast之间；当复杂度降低时，自适应编码器会将preset切回到slow。
4.5 复杂度自适应的视频编码器效果
我们对复杂度自适应的视频编码器也进行状态监控，可以对每一路视频获取五个信息：平均preset、实际帧率低于目标帧率70%的次数、实际帧率低于目标帧率50%的次数、平均psnr、平均ssim。
5. 视频编码器针对B站直播业务的优化
5.1 多分辨率转码流程
5.2 共享1pass算法的多分辨率转码流程
5.3 共享1pass的视频编码器设计思路
最后介绍一下视频编码器针对B站点播业务的优化. 由于我们的点播使用多分辨率的2pass编码. 我们经过研发, 发觉首先对720p做一个1pass的中间文件，然后使用这个文件做2pass的多分辨率转码可以降低整个编码流程36%的复杂度.
6. 未来计划
我们下一步的计划有: 机器学习和编码器结合, Content based video encoder, 新编码格式AV1、VVC, 视频前后处理技术, 等.
我们准备继续加大研发投入, 用更好的编解码技术给B站用户提供更佳的观看体验。
