H.265硬编码器的高效数据存取系统设计

陈业旺，吴林煌，杨俊伟

（1.福州大学 先进制造学院，福建 晋江 362200；2.福州大学 物理与信息工程学院，福建 福州 350108）

0 引 言

高效视频编码标准H.265/HEVC（High Efficiency Video Coding，HEVC）[1-2]提供了超高清视频的压缩编码方案[3-5]。在压缩相同质量视频时，它比上一代编码标准H.264提高了约50%的压缩性能[6]。但同时，H.265标准相对H.264标准也增加了算法复杂度[7]。本文所述的编码系统使用Zynq这种包 含 PL（Programmable Logic）与 PS（Processing System）的异构平台实现，利用PL硬件的高度并行运算加速编码过程，利用PS控制编码器的编码参数[8]。这使得编码器既能加速编码运算，又可向PS端CPU提供控制接口而不失灵活性。H.265硬编码器要压缩编码更高清视频，还需要解决一个重要的问题，即如何满足其成倍增加的数据吞吐量，同时尽可能降低存取延时、减少存储带宽压力。由于H.265标准中可在8×8至64×64范围内动态划分CTU，支持33种帧内预测模式[9-11]，因此更增加了对内存空间访问的需求。

文献[12]将新型的非易失性存储器如ReRAM、STT-RAM等与DRAM组成分层内存结构，有效地节约了总体存储器面积、降低了编码数据存取功耗。但该方案中，DRAM与非易失性存储器需要不同的存储控制器管理对内存的访问，这无疑增加了硬件成本。文献[13]采用现场可编程逻辑门阵列（Field Programmable Gate Array，FPGA）拓展的PCIE接口接收待编码的视频数据然后缓存至DDR中，再利用SRIO（Serial RapidIO）接口将FPGA预处理后的数据送至DSP芯片中，在DSP芯片上完成HEVC压缩编码。该方案硬件成本高，使用多个接口连接不同硬件电路，增加了系统的不稳定性，也增加了视频编码延时，传输带宽利用率不高。文献[14]设计了DDR-BRAM-LUT三级物理存储结构，使用DDR进行帧缓存、用BRAM行缓存、用LUT缓存参考像素，在一定程度上缓解了片外存储器的带宽压力，但没有考虑CTU在内存中的存储安排与DDR访问效率的关系，数据存取效率不高。

综合考虑上述问题，本文设计了一种可有效提升H.265编码器数据存取效率的硬件架构。首先分析了DDR4访问的特性、硬件结构特点以及H.265编码的特性，从而设计了以64×64的CTU为单位、以DDR4内存页对齐存储、视频帧乒乓结构读写，然后介绍了基于DDR-FIFO-BRAM结构的编码数据存取方案，主要包括：待编码图像数据的存储；重构图像的存储与滑动读取重构图像搜索框数据，并根据当前分辨率对重构图像做填充，整个过程硬件流水实现；码流缓存控制。最后介绍了系统整体设计流程，并对系统测试结果进行了分析。本文所述方案在Xilinx的Zynq UltraScale+ MPSOC 9EG平台上得以实现，并通过搭建基于H.265硬编码器的软硬件协同工程验证了本方案的可行性。

1 Zynq系统整体设计

本设计使用Xilinx的ZCU102套件完成方案的测试验证。ZCU102是面向视频等应用设计的套件。其具有Xilinx 16nm可编程逻辑架构的Zynq UltraScale+ MPSOC器件，具备四核ARM Cortex A53、双核Cortex R5F实时处理器、一个Mali -400 MP2 GPU以及HDMI等外设接口。其中，H.265编码器在FPGA端运行；视频数据从HDMI接口接收后输出Native Video格式数据，再经分辨率检测、色彩空间转换及下采样为YUV4∶2∶0格式后通过AXI_HP口存于PS端DDR4中；H.265编码器读写DDR4中的像素数据，完成视频编码并实时输出码流，码流经控制模块缓存输出至PS端DDR4中；Linux操作系统在PS端的ARM CortexA53核上运行，操作系统负责把码流封包后通过以太网发送至目的IP，在目标设备上接收码流并解码显示。系统整体框图如图1所示。

图1 系统整体框图

2 Zynq PS端DDR4存储设计

文献[15]采用NAND flash作为编码数据存储单元，可实现掉电不丢失数据，但在实时视频编码过程中需要频繁访问存储器。使用NAND flash会带来更高功耗，同时相较于DDR其工作频率也更低。本文所述方案中，编码数据与PS端CPU操作系统使用同一DDR4，在保证存取效率的同时，也使DDR4存储空间得到充分利用，降低了系统功耗。

2.1 存储器结构分析

Zynq芯片平台有4个AXI_HP（High Performance）接口用于提供PL与PS存储器之间的高吞吐量数据路径。AXI_HP接口与存储器之间的硬件结构如图2所示。PL端的IP可通过4个AXI_HP接口向PS端DDR或OCM（on-chip RAM）存储器快速传输数据。

图2 AXI_HP与存储器结构图

为了使数据访问更高效，本设计使用DMA传输的方法，无需CPU干预。在DDR4颗粒中，同一时间只能访问同一bank group的一个bank，而且在此bank中只能访问其中一行。DDR4内存页大小为内存整列中一行对应的列可寻址范围乘以DQ位数，内存页大小如式（1）所示。

式中：SP为DDR4内存页大小，C表示内存矩阵列地址的位数，O表示DDR4 DQ位数。如果要换行或bank访问意味着存储器需要额外的时钟去做片选、使能控制，这会进一步降低存储器的访问效率。但值得注意的是，不同bank group之间可以独立预取8位数据，同一时间不同bank group的数据预取互不影响。若将数据都存放在同一bank group中，DDR4的效率会严重降低。另外，DDRC总线的效率与突发读写长度相关，适当增加突发读写长度，可使存储器访问效率得以提升。

2.2 编码帧数据与CPU内存使用安排

基于以上分析，本文把DDR存储空间分为CPU操作系统核心使用部分和编码数据缓存部分，进一步把编码数据的两个主要部分即待编码图像数据和重构图像数据分别存放在两个bank group中，以减少存取延时。为了避免数据的存储与读取发生冲突，本文将待编码图像数据与重构图像数据都做了帧乒乓存取处理。DDR4内存空间划分示意如图3所示。

图3 DDR4内存空间划分

3 H.265硬编码器数据存取

H.265硬编码器在对高清视频编码时会产生大量的中间数据。这些数据需要暂存在DDR4中。如在帧内预测时，编码器需要参考已编码的块去预测当前待编码块消除图像空间冗余；同时把编码器输出的重构图像写入DDR4缓存，供帧间预测使用。本文针对待编码图像与重构图像数据的编码特性，设计了一套高效存取FPGA硬件框架。为了适应不同分辨率的编码需求，首先在视频输入端正确识别出当前输入的分辨率，然后将分辨率值输出给编码系统使用。在计算分辨率的同时，图像帧的起、止信息也包含在此模块中。为了节省资源，不再使用额外的逻辑资源去获取帧的同步信息，本文将模块的帧同步信息输出给编码器数据存取系统，用于控制存取帧地址的切换。

3.1 待编码图像数据的存取

本文中所述H.265编码器编码图像数据为YUV 4∶2∶0格式，而本设计的HDMI接口接收到的图像为RGB 8∶8∶8格式，故需要把接收到的视频图像做格式转换，并做下采样处理。本设计先把RGB 8∶8∶8图像格式转为YUV 4∶4∶4，色彩转换如式（2）所示；再把YUV 4∶4∶4下采样为YUV 4∶2∶2，最终把YUV 4∶2∶2下采样为YUV 4∶2∶0后存储到DDR4中。在编码器做率失真优化时，只需要用到Y亮度分量数据，故把Y分量与UV分量分开存储，这样更方便数据读取。

H.265编码器是以CTU为单位编码的，但HDMI接收到的图像是从左上顶点开始按行接收的。如果按行存储输入图像数据，那么意味着读出CTU数据的时候将需要做非常繁杂的地址映射，且需要频繁地做内存页、内存bank的跳转，这会严重降低DDR4的访问效率。另外，H.265编码器的编码单元（Coding Unit，CU）与预测单元（Prediction Unit，PU）原始数据分开读取，意味着在DDR4中相同地址的数据可能会被重复读取。这无疑增加了DDR4的带宽压力与数据读取延时。考虑到H.265最大支持64×64的CTU块划分，本设计以最大支持的CTU单位划分存储数据，这样可兼容编码器在不同CTU划分下的工作模式。按照CTU的划分，在YUV 4∶2∶0图像格式下亮度CTB以64×64为单位存储，将两个32×32色度CTB拼凑为32×64的数据块存储。为了隔离148.5 MHz的HDMI数据接收模块与200 MHz写DDR4内存模块的时钟域，以及控制AXI4总线读写突发长度，本文在这两模块之间插入了两个FIFO缓存Y、UV分量数据。从FIFO读出的数据经过写地址映射模块，把按行接收到的像素数据按照CTU划分把数据写入到DDR4对应的地址上。同时，写地址模块还会控制图像帧的起始地址，以此实现帧图像的乒乓缓存。在读取待编码图像时，使用PL端的资源例化两个64×64的乒乓RAM，用于存储从DDR4读取而来的同属于同一个CTU的CU、PU数据，以此实现使用少量逻辑资源换取降低片外存储器带宽压力与减少编码器编码延时的效果。待编码图像数据的存取如图4所示。

图4 待编码图像数据存取结构

把按行输入的图像数据转换成按CTU方式存储，同时还要控制图像帧的乒乓存储。此过程的地址控制若按照常规的方法采用状态机实现，将会非常烦琐，且消耗很多FPGA资源。本文设计了一个基于地址位操作的地址控制模块用于实现读写数据地址控制。此模块无需任何FIFO缓存，数据输入后仅需两级用于防止亚稳态传播的同步寄存器接收后，即可把数据给到对应的DDR4地址上。对于8 bit×64×64的Y分量数据，一共需要4 kB的存储空间；而由UV组成的数据包8 bit×2×32×32=2 kB。本文所使用的DDR4内存矩阵有效列地址位宽为10 bit，DQ位数为16，由式（1）可得一个内存页恰为2 kB，故可使用一片内存页存储一个UV数据包，将64×64的Y分量分为64×32×2存放在两片内存页中。此后在读取UV分量时无需做切换内存页操作，读取Y分量只需做一次页跳转，连续内存读取，提升了存储器的访问效率。比如Y分量的存储结构如图5所示。

图5 Y分量存储结构示意图

3.2 重构图像数据的存取

编码器对原始像素编码后，会输出重构图像供帧间编码使用。重构像素写入DDR4的过程与上述待编码图像的存储方法一致，而重构图像搜索框的读取则相对复杂。对于图像边缘，需要做填充处理，重构图像的填充如图6所示。对于图像边缘的黄色正方形区域参考相应的顶点填充，绿色区域参考相邻边缘像素填充。

图6 重构图像边缘填充

编码器在做预测时，相邻编码单元使用的搜索框数据有大量重叠部分，搜索框数据移动如图7所示。如果不做缓存处理，每个搜索框数据都读一遍，将会使存储带宽的需求成倍增加。以CU大小为16×16、Y分量读取为例，读取示意如图8所示。模块以每次突发读64×8像素点为单位将数据从DDR4中读出，数据存储在80行RAM中，然后对边缘做填充，填充完成后等待编码器读走64行数据。第64行数据读完后，立即开始从DDR4中继续读取。数据读出后将第1—16行RAM数据覆盖，与此同时，第65—80行数据继续输出给后续模块。因为读DDR并填充数据的速度大于编码器请求数据的速度，因此在编码器请求数据时，模块总能提前准备好所需数据。UV分量重构像素的读取与Y分量同理。

图7 搜索框数据移动示意图

图8 Y分量滑动读取示意图

3.3 码流输出

视频图像经编码器编码后生成8 bit位宽的码流。为了减少对DDR4的访问次数，本文先用FIFO缓存码流数据，综合考量FIFO资源，以1 kB大小把码流数据写入DDR4中。每次写完成后产生一个中断信号给CPU，CPU收到中断信号后读取码流并对其RTP封包。

4 系统测试结果分析

本设计从工作频率、AXI4突发长度、功耗、资源使用等多方面综合考虑，进一步分析、优化编码器存储系统的性能。AXI_HP口最大支持128 bit，系统以流水线方式工作。

表1为使用不同参数时，FPGA硬件在vivado 2020.2软件上采用ZCU102评估板工艺节点综合得到的数据。由表1可知，存储系统工作在器件端口最高频率333 MHz时，仅需增加小于0.1 W的功耗即可得到更高的存储效率。以单通道128 bit总线、333 MHz为例子估算带宽：相邻两次突发读写之间至少需要间隔两个clk，突发长度设置为最大256，因此其最大理论带宽约为4.92 GB·s-1，满足8K（7 680×4 320）30 f·s-1视频编码带宽需求；写码流模块时钟设为30 MHz、数据位宽32 bit时，允许的最大理论带宽为 120 MB·s-1，约为 0.12 GB·s-1；原始图像、重构图像读写共4个通道，总带宽约为14.76 GB·s-1。所使用的DDR4 2133理论最大带宽为17 GB·s-1，故PL端存储系统对DDR4内存使用的效率可达约87.52%。

表1 FPGA存储系统实现结果

为了验证本存储系统是否可在硬件上成功运行，使用实验室自研H.265内核搭建验证平台，其中各功能模块的工作时钟如表2所示。由于实验室自研H.265内核目前最高支持200 MHz，为了方便与H.265内核进行数据交互，存储系统工作时钟设置为200 MHz。抓取存储系统将数据读给编码器的时序波形，波形如图9所示。64×64的数据块仅需64个clk即可全部送给编码器。

表2 验证平台各功能模块的工作时钟

图9 编码器读取数据块时序图

使用高清摄像头拍摄笔记本电脑播放的测试视频，摄像头输出1 080P视频给编码器编码，码流由解码板解码播放，编解码效果如图10所示。

图10 编解码效果图

5 结 语

本文根据H.265标准对CTU划分、编码时对原始像素、重构像素和预测搜索框需求的特点以及DDR4的访问特性，设计了一种用于H.265硬编码的实时、高效视频数据存取方案。CPU与编码数据共用一套DDR4以节省硬件成本，通过降低H.265硬编码器在高清视频编码时对存储器的访问次数和带宽的需求，更合理安排编码数据在DDR中的存储，减少内存页跳转访问，提高存储器访问效率，减少数据存取延时，能够自适应输入视频分辨率与重构图像边缘填充。在实际测试中，内存使用效率可达 87.52%，且可满足 8K（7 680×4 320）30 f·s-1视频编码带宽需求。与文献[13]的FPGA视频缓存所需总功耗16.242 W相比，本文方案节省了近10 W。所提框架在ZCU102平台上完成验证，摄像头采集的1 080P视频经编解码后显示正常。