本文来自复旦大学微电子学院教授范益波在LiveVideoStackCon 2021上海站的演讲内容，分享从硬件和软件的区别切入，详细介绍了硬件编码器的硬件微架构，面向与芯片实现的X1编码器和面向与FPGA实现的K1编码器，以及开源版本的视频编码器。
文 / 范益波
整理 / LiveVideoStack
大家好，我是范益波，来自复旦大学微电子学院。本次分享的主题是视频编解码IP硬件开源。首先我会介绍硬件和软件编码器的差别；接下来重点介绍硬件编解码的硬件微架构，包括开源版本、高性能版本都基于统一架构；随后将分享面向芯片实现的高性能X1编码器和面向FPGA实现的低硬件成本的K1编码器，以及开源的版本。X1主要优化目标在于逻辑面积较小、RD性能突出，根据实测结果可以比X265 median好10%左右，与主流IP vendor的压缩率性能相当，而芯片面积仅仅是主流IP vendor的1/3左右。K1主要面向FPGA，目标器件是K7这类最常见的FPGA，目前K1是唯一支持FPGA的4K软核编解码器。
01
—
Introduction
首先做个简单的介绍。
1.1 关于我和我的实验室
我本人在复旦大学微电子学院工作，我的实验室叫VIP实验室，定位为视频、图像的专用处理器IP和芯片设计研究。主要是以硬件芯片设计研究为主，包括视频压缩，从H.264到H.265、下一代的H.266、AVS3，对SVAC2也做过研究。我们同时也做图像处理方面研究，包括图像的ISP处理，图像的压缩，比如JPEG、Lepton、WebP、面向显示端的DSC和VDCM。另外还有关于Learning based 的ISP和Video Codec研究，利用深度学习的方法实现将传统的ISP处理和视频编解码转为端到端的神经网络处理。另外，我们的实验室还从事面向数据中心、云计算的异构计算系统建模研究。
1.2 关于XKSilicon
开源主要是用XKSilicon作为开源基金会组织。我们有开源网站，开源代码会放在Http：//www.openasic.org上，可以直接登录到网站，下载开源代码。除了H.265之外，还有H.264开源，在2018年，2019年分别做了两个更新，今年会做H.264/H.265 3.0版本更新。在芯片领域，国内外的硬件IP开源非常少，硬件开源项目没有软件开源项目多，相关开发人员也比较少，需要更多的硬件开发者为开源社区做贡献。为了支撑开源的这部分工作，我们也为合作伙伴定制了闭源版本，为其专业的应用领域定制领域专用的编解码器IP核商业版本，这部分工作也体现了我们团队的工程落地能力以及我们硬件IP核架构的敏捷开发优势。
02
—
硬件与软件编码器
这一部分想和大家解释硬件编码器和软件编码器的一些差别。
2.1 软件编码器发展迅速，开源编码器丰富
我们国家软件编码器方面做得非常好。如果大家看MSU视频编码大赛，基本上是华人战场，前十都是国内公司和各大互联网巨头。软件编码器方面的发展非常好，国内公司在此领域有强核心竞争力，推出领先世界的编码器版本。开源软件也比较丰富，如果初创公司一开始想使用编码器，则无需开发，直接使用X264、X265就可以立马支持主流标准，AOM也有开源的AV1编码器。
2.2 硬件编码器受限芯片，无开源编码器IP
相较于软件的热闹，硬件冷清些。目前来讲，云端的编码器会借助Intel或Nvida的平台，其中有转码针对视频编解码的IC芯片。手机端可以借助高通、海思等，其都有成熟的硬编方案。公司想开发支持视频应用的芯片，就需要在芯片中集成视频编解码IP核；一般而言，初创公司不会自研视频编解码IP核，通常会寻求第三方的IP Vendor。能够提供编码器的IP Vendor不多，以国外为主，国内的芯原可以提供IP。当然我们也可以用FPGA，例如XILINX有FPGA产品内置了编码器硬核。对于小批量的、定制化较高的硬件产品，可以用这种带硬核CODEC的FPGA，其主要缺点是价格昂贵、平台依赖性很强，一旦设计定型就意味着产品依赖上某种特殊型号的FPGA，平台切换很难。而视频编码器软核IP就不存在平台依赖问题，目前来讲，开源的软核硬件IP很少，开源的视频编解码IP核全世界也就我们团队在做。
2.3 软件和硬件的区别
接下来我想与大家解释软件与硬件编码器有何差别。无论是H.264或H.265都是混合编码框架，将里面的模块抽象出，对软件来讲CPU分成时间片，在不同时间执行不同算法。在算法中可以无序地执行。例如这次执行IME模块，下次执行FME，将CPU把相应的指令调进来，下次可以执行下面的，CPU对于软件来讲，核心是不断提高CPU主频就行，无论是8K还是16K，如果有能力将CPU做到10GHz频率基本上软件可以包打天下。但现在面对的问题是CPU主频提不上去，对于嵌入式CPU频率提升面临更大瓶颈，CPU不可能有很强的算力。对于软件人员来讲，开发编码器相对来说比较简单，CPU会搞定所有外存带宽，开发人员不需要解决这些底层的数据调度问题。
而对于硬件设计来说，情况完全不同。
一方面，同样的算法模块，硬件上是流水线的形式，流水线一旦排起来，前后级模块就有数据依赖，后级数据只能拿前级的结果，不能乱序执行，只能沿着流水线一个方向执行。且硬件是所有模块是并行的，同一时刻，例如在上图所示的clock-cycle中，实际上所有模块都在工作，与CPU任一时刻只有一个模块执行不同，对于硬件流水线，同一时刻所有模块都在执行并且其执行的数据块都不相同。
第二个方面是流水线前后级模块强关联，只有前级模块执行的结果，后级模块才用得上，所以数据上有很强的依赖，不能随机执行。
第三个方面是硬件IP的内存读取操作需要手动控制。软件开发者可以完全不关注CPU的内存读写操作，因为CPU会自动通过D Cache和I cache帮组开发者完成指令和数据的存取。开发者仅需关注核心的算法逻辑即可。而硬件IP核开发则完全不同，开发者需要手动处理与总线以及外存的数据交互，什么时候写数据，什么时候读数据，读写数据的长度是否符合DDR Burst的长度要求，是否能让DDR带宽得到充分的利用，这些都需要硬件开发者手动来实现。
因此，开发一个硬件编码器的工作量是软件编码器的好几倍。一般来讲，在写一个硬件编码器IP核之前，我们也会先写一个软件编码器，将其叫做C model，这个C model编码器模拟硬件的流水线划分，将其所有模块与硬件模块一一对应，其中各种数据依赖都考虑到模型中去，C model本身也是可执行的功能齐全的视频编码器。当在C model模型中确认架构没有问题，并且编码压缩性能达到设计要求后，便可以开始写硬件，完成RTL级别的硬件编码器设计。可见，开发一个硬件编码器通常需要写两个编码器，既要写软件编码器，又要写硬件编码器，并且其中所有算法都要优化一遍，去除数据依赖，优化不适合硬件执行的算法，其开发工作量比软件大很多，并且算法优化要求更高。
2.4 硬件编辑码器的实现方式
一般来讲，硬件编码器实现有多种方式，其中最通用的实现方式是通过主处理加协处理器，像Intel CPU就是通过增加多媒体指令集扩展（CPU Co-Processer）实现，GPU可以集成专用算法模块硬件，同时利用GPU的多核算力可以实现高性能可编程的硬件编码。另一方面，对于专用的处理器ASIC或SOC，需要将编码器IP核集成到总线上，做SoC整合有硬核和软核两种方式，硬核是用芯片方式实现，固话为芯片内部电路；软核是用FPGA方式实现，下载到FPGA芯片中就会形成编码器电路作为加速。硬核与软核的差别是一个偏向于芯片实现，一个偏向于FPGA实现。
2.5 使用硬件编码器的原因
使用硬件编码器的原因首先是性能和成本，比如要做一个8K编码器，用软件方式需要很多台服务器，对于硬件编码器只需要一颗芯片就够了，硬件编码器会比软件编码器性能好几个数量级。另外是压缩率的性能，软件编码器会比硬件编码器做的更好，因为软件编码器可以串行执行，只要CPU能力足够高就可以调动非常复杂的算法，不用考虑数据依赖关联，可以追求极致的RDO优化算法，所以在压缩率方面，软件编码器会比硬件编码器做的更好。硬件编码器需要消除流水线数据依赖，一定会做算法优化，会造成RD表现下降。第二个原因是实时性和低延时，CPU做编码，一条条指令去做，运算速度远远比不上专用芯片，并且一般会引入帧级缓存，而硬件编码可以消除掉其中大部分缓存处理，还可以按行处理，外部数据来几行就可以开始做编码了，可以实现极低的延迟。第三个原因是超高清与高IO带宽。超高清时会带来高IO带宽，这边的带宽是DDR和CPU之间的带宽。硬件编码可以做带宽的压缩优化，带宽可以降低且对DDR访问可以做得更好，软件编码器很难做到8K或16K的编码，用硬件还是比较容易的。
03
—
XK265编码器结构
接下分享一下XK265编码器的架构。
3.1 XK265的设计目标与特性
首先讲的是架构设计目标，一是做成算法、标准可扩展架构，所以说我们的架构只体现算法流程模块而与具体的编码标准不相关。可扩展的硬件架构能够做成不同标准算法集合，在统一架构下支持不同编码标准。二是性能、面积、特性可定制的灵活硬件架构。不同应用领域对视频编码的要求是不同的，比如针对手机和针对安防就很大不同。手机编码器要求低功耗，压缩率可以不一定很低，针对安防则压缩率一定要很高，高清要压到1Mbps以下，可以用非常复杂的RDO的策略，去保证压缩的清晰度。因此，不同的应用场景，对视频编码器的要求是不一样的，需要在一些基本的核心PE单元做一些可配置，在一些重要流水线单元做一些可配置，包括搜索预测的模式也是可配置，包括里面一些块大小也是可配置，可以实现性能、成本、画质跟压缩率的动态可调配。三是一些多路流的支持和低延迟方面的支持和一些编解码的硬件复用，编码器和解码器里面70%左右的逻辑都是可以复用的，只要加少量逻辑就可以既能做编码又能做解码。另外，一些多流零延时的切换，我们希望能够做到不同的流进来之后，可以非常快速的编出多路流来，并且多路流可以并行做实时性很高的编码。第四是要有丰富的用户配置参数空间，包括用户的编码控制和一些参数的配置，包括一些RDO策略的配置，包括搜索的方式配置，包括对码控方面的控制，ROI的配置等。我们需要有一个非常强的用户可配置的空间，方便他们实现对不同场景的适配。
3.2 XK265:X001 CDC架构
这是我们一个五级流水线的CDC（Encoder Decoder）架构，这个架构是面对芯片实现的，目标频率要跑到800Mbps频率下去支持4k30到4k60这样一个性能。如图所示，模块的主要功能，比如FTH是用来预取一些数据的，RMD是做增内的预判决，ME（motion estimation）engine 包括两个——整数和分数的都做在一起。RDO、REC、DBF、SAO都放到同样的流水级。DMP是一个最终重建图像输出的通路，E_C/E_D支持熵编码和熵解码，走编码路线从EXT_RD进到BS_O出，走解码路线则从BS_I进到EXT_WR出。基于这样的敏捷芯片架构，我们很容易定制出单一Encoder、单一Decoder、复合模式的Codec，以及支持单一I帧版本或支持I P的版本的不同IP核。同时，也非常容易定制生成出不同性能指标、面积指标、压缩率指标的专用编码器IP核。
3.3 XK265:X001 ENC架构
作为敏捷架构的一个IP定制例子，这是我们面向FPGA软核的K系列IP架构。因为FPGA的主频一般难以跑的很高，我们的K系列目标频率在150MHz左右，和面向芯片的X系列800MHz主频相差非常大。而K系列IP的性能与X系列一样，同样需要支持4K30的高性能，因此K系列我们采用七级流水线架构。如图所示，我们将IME、FME剥离出来作为单独的流水级，同时将RDO、REC和DBF、SAO剥离出来作为单独的流水线级，最终实现低主频下的高性能编码。
3.4 XK265:X001 DEC架构
作为敏捷架构的另一个IP定制例子，我们针对FPGA完成了单一解码功能的K系列视频解码器IP核。解码器同样采用七级流水线架构，只是把编码的数据通路剔除掉了，去掉之后就只剩解码，可以实现一个非常精简的解码器流水线。
3.5 XK265:可配置RMD
接下来看一下我们硬件架构中的底层模块设计。我们提供了丰富的可配置选项，这对于敏捷架构设计非常重要。对于硬件来讲，电路固化了就很大程度上失去了可修改特性。对于IP来讲，在固化硬件之前，我们还可以进行一些面积上的调优，我们在IP核的模块级别提供两种可配置的参数——静态可配置参数和动态可配置参数。
所谓静态可配置是指把IP做成真正的芯片电路之前，可以去配置的一些参量，而这些参量将会影响到最后的电路规模和逻辑面积。比如对于RMD，我们可以去配置它的引擎数量，去平衡它的面积和吞吐率。我们也可以对DC和Palanar模式是否支持进行配置，因为这两个模式的支持占用面积较多，去除这个模式支持可以节省很多面积，当然RD也会受到影响。
动态可配置是指电路已经被固化了，这时可以通过一些配置寄存器把模块的一些功能打开或关闭来调节编码性能和压缩性能。比如搜索的PU大小，所有的PU大小都可配，从最小的4x4 PU到8x8、16x16、32x32、64x64，可以动态关闭或打开某类PU的预测，以平衡视频的压缩质量和吞吐率性能。动态可配置的一个重要配置指标是RDO level，通过RDO level来指导各个模块的动态配置参数，RDO level高则可以取得更高的压缩性能，付出的代价是所有的PU都要被搜索，这样将得到更好的压缩率，但是帧率就下来了，比如只能到4k30了。如果希望同样的电路做到4k60，可能需要舍弃掉部分PU，将RDO的level下调，这样就可以做到4k60。
3.6 XK265:可配置IME
这是整数的运动估计，其静态可配置选项可以配置阵列的大小、更新方向、被搜索的PU大小等。其动态可配置选项主要是被搜索的图案，search pattern 和search window都是可配的。
这是我们做的可编程的运动估计引擎，可以把search window设置成不同的样子大小，search pattern可以做全搜和快搜，通过微代码的更新，算法的更新，去做到不同的搜索方式。
3.7 XK265:可配置FME
在这个分数像素运动的估计上也是一样的，静态可配置项上面，可以对不同的引擎数量配置，想要裁剪的话，就把引擎数量设小，同时性能就下来了，面积就省下来了。所有的引擎数量都是可以在面积和吞吐量方面做平衡。引擎的大小，到底是用16×2还是8×1，无非就是多像素处理的不同并行度差别。引擎的寄存周期可以平衡面积和时序，希望频率更高还是更低，也可以通过寄存周期去配置。动态可配置也一样，所有的PU大小都可以配置，被搜索的邻域都可以去配置。
3.8 XK265:可配置RDO
这是RDO部分，也是编码器非常重要的平衡压缩率和性能的关键引擎，影响编码器视频质量的最重要的点就是RDO。如图所示，在我们设计的RDO引擎中，环路里各种引擎的大小和搜索PU的大小都可以进行可重配。静态只影响面积，动态影响图像质量和吞吐量，包括所有的帧内预测模式数量可以进行重配，DC和Plannar模式，色度预测到底是开启独立色度预测还是采用亮度方式去做色度预测，Merge，Skip的开关都可以去打开和关闭。还有一些场景自适应的判决系数，一些简单场景的检测，方便大家对不同的场景去做不同RDO配置的策略。
3.9 XK265:高并行度CABAC
在最后的熵编码环节，我们做了一个高度并行的CABAC流水线设计，我们采用了四个Bin并行的方式，在前面Bypass也有一些并行的优化策略，最终我们可以做到4.37的BPCC的并行度，可以支持8K大码率，高画质的熵编码。
04
—
X1 for Silicon
接下来我们看一下两款商用定制的编码器性能评估
4.1 X1:面向芯片实现的IP核
第一个是面向芯片实现的IP，我们叫做X1，面向芯片的五级流水的架构，大部分的feature都支持，其中的重要特性包括：
1. CDC架构，支持编码和解码。它支持两路流，主流和辅流，可以通过影子寄存器去扩展做到更多路流的并行。它支持多种图像输入通道，可以通过外存DDR的输入，原始图像放在DDR中，编码器从DDR中读取输入；也可以做成Line Buffer输入，做超低延迟的编码应用，只要来32行图像就可以开始编码。
2. 支持LCU level的多路流切换。可以在一路流里面编码它的CTU，然后实时切换到另一路流去编码它的CTU，做到来回切实现多路流的高实时编码。
3. 采用了32×32的低成本硬件设计，这里我们没有去做64×64，是为了平衡它的面积，做64x64的话所有Buffer的缓存都要增加到4倍，32x32就可以节省很多面积。同时所有的CU，TU，PU的规格我们都支持。
4. 支持CBR，VBR等码控方法，在Frame level 是通过软件来做，CTU level是通过内置硬件来做。我们也支持参考帧的无损压缩，在压缩4k30、4k60的情况下，外存带宽可以做到比较低。
5. 支持所有的IME模式，search window全部都是可调的，按照目前的配置是±32和±64，但如果需要更大的search window也是可以做到的。
6. 支持1/2、1/4的FME，和上面的IME特性类似。
7. 支持ROI，针对某些区域去做ROI也是可行的。
目前我们在22nm工艺可以实现800MHz，针对RDO Level High，我们可以做到4k30的编码性能，针对RDO Level medium，我们可以做到4k60的编码性能，比其他IP Vendor的面积做的更小。
这里大家看一下X1的码率表现，Anchor是x265-medium，上方是带码控的测试结果，下方是固定QP的测试结果，这里我们用于衡量的指标是BD-Rate，BD-Rate越小（越负）则表示压缩效率越好，码率节省的越多。如图所示，带码控的测试下， C厂比x265低9.6%，V厂比x265低9.7%，我们的F265 Cmodel比x265低10.1%，可见在开启码率控制的情况下，我们和友商的码率水平是差不多的。另一方面，在码控下的Rate Mismatch大家都表现得不错，这里我们的数据更好一些，可以控制在0.2%-0.3%以内。
表2是做固定QP的测试，Anchor也是x265-medium。I frame我们的结果是最好的，远远优于其他两家商业编码器。P frame 方面，v厂做的非常不错，比x265好13%，我们只做到了好6.4%，我们在P Frame和v厂的差距在7%左右。另一家c厂和我们差不多。但这里我需要强调的一点是，我们采用的是32x32 LCU，取消了对64x64的PU支持，并且取消了Nx2N的划分，这几个feature一般会带来8%-10%的压缩性能损失，而v厂这些feature都开启了，因此如果算上这些feature我们P帧的压缩率跟v厂是差不多的。另外由于我们采用了32x32 LCU以及内部优秀的敏捷架构设计，我们的硬件面积仅仅是v厂的1/3。
05
—
K1 for FPGA
K1面向于FPGA，是一个低时钟频率高编码性能的版本，因此它的压缩效率表现肯定要差一点。由于FPGA的各方面资源都受限，我们的目标是在K7-325T这样一个非常小的K7系列下的FPGA去实现4K编解码。为此我们做了非常大的裁剪，这个编码器主要还是面向嵌入式端，而不是加速卡。在一些对码率要求不高，但是性能要求很高的场景下可以满足应用需求。
5.1 K1:面向FPGA实现的IP核
在K1的流水线设计中，我们把CTU的SIZE直接设定到了16×16，跟H.264的MB SIZE是一样的，接下来我们会跟X264-medium相比较压缩率，而非跟X265比。K1目标是在小规模的FPGA上提供高性能的4K编解码，同时其压缩率比X264-medium更佳。如图所示，K1也是支持编码和解码，支持External memory和Line Buffer输入，但这里没有支持多路流并行编码。
其他方面就和X1相似，我们在RDO中做了一些简化，实现在140MHz上去支持4K编码性能。FPGA实现方面，以K7-325T的芯片为最终的目标应用器件，整个性能方面最高可以做到4k30的分辨率。我们也提供了两档的RDO Level配置，RDO Level median 支持4K30；RDO Level high，可以支持1080p60，可以提供更好的压缩效率。K1的总体面积是170k LUT左右。
这是K1跟X264-median的比较，因为目前没有支持4k的、面向FPGA的软核，所以只能跟X264软件比。如图所示，我们也列出了X264-veryslow和X264-veryfast的压缩性能指标，所有性能比较都以X264-median为anchor。Baseline是最精简的一版，我们把DB、SAO全部去掉，search window也非常小，可以做到150k LUT以内。压缩率方面，Baseline的I帧比X264-median好13%左右， P frame方面会差16%左右。
但是在Baseline 基础上面积稍微放大一点，加入DB，I frame会好15.8%，P frame从差15.9%降到差3.8%。如果加了SAO之后，P frame的表现将会表现得更好。因为FPGA比较灵活，我们可以根据不同的器件大小，去配置到底要加哪些模块去实现码率和面积的最佳平衡。这也是我们敏捷架构设计的优势，可以在Baseline的基础上灵活添加工具实现性能、压缩率、面积的可配置性。
5.2 K1:Demo
演讲厅外有我们的demo版本，欢迎大家去看实物演示。
这里显示的是Demo系统的原理框图，通过最右边PC的HDMI输入图像到FPGA编码板，FPGA编码卡做编码并通过以太网输出码流，另一块FPGA作为解码卡收取视频码流做解码，同时解码FPGA输出图像到显示器。
上图我们编解码实物的演示。
06
—
开源路线图
K1和X1都是面向产业的高性能版本，目前阶段还不开源。此外，我们还有一个开源的版本，开源和闭源版本的硬件架构是一样的，区别在于面积、算法复杂度和支持的分辨率性能方面。
我们在2017年就对XK265进行了开源，分别发布了1.0和2.0版本，大家可以去官网就能下载到。V1.0版本侧重在参考硬件设计，针对视频编解码的各个算法模块做了硬件设计；V2.0版本是对1.0版本的架构升级和测试升级。在V2.0版本上，我们做了更多的测试，比起V1.0版本更加稳定，并且我们还提供了C model作为对比测试。在V1.0和V2.0上，我们都仅采用了极为精简的RDO算法，这部分我们鼓励其他团队去探索实现自己的RDO算法，在目前的开源版本上，我们更多关注硬件面积的减小、算法流水线的精简。目标是实现在极低硬件代价下的高性能视频编解码。
今年我们计划将发布V3.0版本，等我们K1项目结束后，将会推出这个开源版本。
V3.0版本的特点：主要面向嵌入式FPGA，针对k7 、Pynq这类非常小的FPGA的软核编码器。比如面向Pynq将只有I帧的编码，因为Pynq的逻辑非常小，售价大概在7、8百人民币，而k1的开发板要一万多元，估计只有大学实验室才能买得起。另外，我们会针对低时延做优化，实现超低时延的端到端编解码。在极低面积代价方面，我们争取把硬件的开销做的非常小，甚至可以做到只有Y通道，尽可能把一些冗余逻辑去掉，实现极低成本；另外，我们会提供完整的总线接口和FPGA demo开源代码；在其他功能方面，我们还会增加低成本高效率的RDO算法和码率控制算法。
最后，我再分享一下我们未来的开源路线图。今天的演讲主题是XK265编码器，我们还有一个XK264，今年也会放出一个V3.0版本的更新，它的硬件成本比XK265更低一些，它的适用范围更广。XK264在一些板级的应用里和嵌入式的应用里还是比较普遍的，因为这类应用复杂度比较低。我们实验室里还在做AI-CODEC，算法已经研究的差不多，接下来要做一些面向硬件的实现工作。所以在明年的时候我们会计划公布一个基于AI的面向图像的开源编码器。另外，我们还在研发AI-ISP，我们后续也会做一个AI-ISP的开源版本。
在应用领域方面，我们主要面向领域是终端芯片和嵌入式。同时，最近我们也在考虑面向云端的IP核设计，以及在云端FPGA加速卡（比如Xilinx的U250等）上的IP核应用。特别是针对一些要求压缩效率比较高，面向8k、16k、VR等云端编码应用，目前来讲没有芯片方案，但又需要在云端做编码加速，因此可以在数据中心实现基于异构的编解码器设计。
以上就是我分享的全部内容，谢谢大家！
