谈谈1080P@60 H.265实时编码器的架构设计。
首要考虑1080P@60的实时编码能力,
即设计的编码器需要具备不小于每秒60帧的编码能力,
不允许丢帧的前提下,每帧编码时间不能大于16.6ms,
按照编码主频可以推算出每帧的时钟周期数cycle,或反推,
一般情况下,可以先根据FPGA/ASIC器件平台的fmax确定主频,
此处的fmax并非器件理论上的最高主频,
而是设计RTL代码在器件上能运行的fmax,
不同设计风格或者不同开发者开发代码,fmax可能会有差别。
对于FPGA而言,如xilinx kintex7系列,
类似视频编码这种较大型工程,一般fmax可不低于200M,
速度更快的FPGA器件一般可达300M以上,
ASIC器件则根据工艺不同,差异较大,
同样工艺条件下比FPGA要高不少。
如zobovision开发的H.265 1080P@60实时编码器,
可在xilinx k7325t或ku3p这样的FPGA器件上运行,
fmax在ku3p器件的fmax约300M,
实时运行1080P60所需的主频为265M左右。
以主频250M为例,
每帧平均分配的时钟周期数为4166666,
按64x64的CTU基本编码单元,
平均每个CTU分配8170cycle,
CTU共有4096像素,每个像素2cycle;
对于编码,每个像素大致需要经历几个过程,
帧内或帧间模式粗选,
帧内预测或帧间预测数据计算,
残差数据DCTQ及IDCTQ重建,
RDO最优选择,
码流信息编码,
去块滤波Deblock等。
要完成这么多的功能及选择,
1pixel 2clk?
显然是不够的,
不同功能模块的流水级设计是必须的。
对于H.265/HEVC而言,
以CTU为流水级基本单元,
CTU大小可设定,最大64x64,最小16x16,
一帧编码中只会固定选择一种尺寸,
常见的有64x64和32x32,
理论上尺寸越大,计算复杂度会更高,编码效率会好些,
zobovision编码器固定选择CTU 64x64。
不同的编码功能模块,
有些是必须合并划分到同一级流水单元的,
主要看编码数据流的依赖性,
CTU编码单元又会进一步划分成尺寸更小的TU/PU单元,
以帧内预测为例,每个PU单元会参考相邻的重建像素,
即当前PU块的预测数据计算需要等待相邻块重构数据完成,
也就是说,帧内预测计算、DCTQ、IDCTQ、RDO选择,
这几个不同功能模块实现了从预测数据到重建数据完成的过程,
它们需要被设计到同一个级流水中;
至于帧内模式粗选,以及帧间运动估计功能,
数据的依赖性较少,取决于不同的硬件算法,
它们可以单独划分为一级流水,或多级流水,
如运动估计粗选,可以基于整像素,亚像素等进行多级流水设计,
多级流水可以提供压缩效率,但通常硬件资源也会有所增加。
码流编码和Deblock去块滤波,
是相对独立的功能模块,
它们可以单独划分为一级或多级流水。
不同的流水级,
所需cycle可能有所不同,
有些是可以通过增加并行处理降低cycle数目,
有些却很难通过并行加速,因处理数据存在反馈依赖关系,
如前面所述的帧内预测到DCTQ/IDCTQ重构的过程。
从绝对可控的角度,
一帧视频所需最小cycle数目,
或,一帧编码所需最长时间,
取决于最耗时的流水级处理单元;
当1080P@60的实时主频设定在250M时,
每级流水处理cycle要控制在8000左右,
基本1pixel分配2clock(clk),
对于特定功能模块,
不同的cycle要求将导致不同的硬件算法选择。
zobovision H.265视频编码器,
各流水级处理cycle保持一致,均为8400cycle,
每帧编码所需时钟周期数一致,
保证绝对可控的帧编码时间。
对于1pixel 2clk处理时间,
到底是个什么概念,
下面举例说明。
对于一个64x64的CTU单元,
共有4096pixel,一个流水级可分配8192clk,
假设CTU最终都划分为4x4的帧内预测PU单元,
每个i4x4块分配32clk,
因为帧内预测,需要参考相邻块重建后数据,
基本可认为,前面i4x4编完,后面i4x4才可启动,
即,每个i4x4需要在32clk内完成既定任务,
共有哪些任务呢,主要包括:
1)i4x4帧内预测数据计算;
2)4x4 2D-DCT运算;
3)Q4/IQ4运算
4)4x4 2D IDCT运算
5)RDO判决
6)i4x4重建数据生成;
上述只是i4x4帧内编码的基本任务,
要提高压缩效率,
还需要类似RDOQ和RDO递归操作,
计算复杂度更高,
如何在32clk内实现,
那只能是各显神通了,
不同硬件架构及实现方法,
结果差异化就容易显现。
待续...
(转载请勿更改文章标题和内容)