本系列主要介绍视频编解码芯片的设计,以HEVC视频编码标准为基础,简要介绍编解码芯片的整体硬件架构设计以及各核心模块的算法优化与硬件流水线设计。
H.265/HEVC标准相较于前代H.264/AVC视频编码标准,可以在同等视频感知质量下节省约50%的码流。但是,随着码流的减少,单位比特携带的信息量就大幅增加,使得码流对传输差错更为敏感。因此,必须采取高效的传输差错控制,使丢失图像恢复到人眼可接受的程度。本章将主要对差错控制中的差错掩盖技术进行介绍,并分别探究空域和时域差错掩盖上的技术优化方向和VLSI实现。
1
概述
编码器用极高的计算复杂度换来了优异的压缩比,在如何提高编码质量和编解码速度的研究上已经取得显著的成果。高压缩率方便了视频信息的存储和传输,但同时也增加了视频码流对信道传输中错误的敏感度。因此,保证传输过程中视频流的鲁棒性成为解决压缩视频流在低带宽信道中传输的关键问题。数据丢包或传输误码在信道传输过程中由于多种干扰因素时有发生,对于HEVC,极少量的传输误码或数据丢包会带来整个块的解码错误。如下图所示,第一帧丢失块的解码错误经过帧间预测扩散至后续帧,同时关键信息的错误甚至会导致解码过程中断。
原始捕捉的视频通过编码端编码以后首先经过分包,然后通过网络传输到解码端,解码端接收到数据包以后进行拆包解码。但是网络传输往往是不可靠的,会出现随机的比特错误或者在较差的网络环境下直接发生丢包现象,而HEVC对于码流的差错十分敏感,为了提高视频码流的鲁棒性,有很多方法被提出来进行差错控制,进而降低码流对传输中错误的敏感度。差错控制技术包括编码端的冗余编码、传输过程中的交织传输、数据重传和解码端的差错掩盖等,其中差错掩盖(Error Concealment, EC)算法不需要编码端的额外信息,独立于编解码器。

01

编码端控制
HEVC标准在提出的时候本身就考虑到了需要对传输差错进行控制。为了应对不同的网络传输,视频数据应该被分为不同大小的分组,高效的分组策略必须考虑到数据的内容,并根据其重要性进行分组。HEVC采用了视频编码层和网络适配层的双层架构,编码层就是裸码流,承载的是视频压缩后的数据,网络适配层是对裸码流的封装,根据数据的性质封装为不同的NALU(Network Abstract Layer Unit)。HEVC中共定义了0-63这样的64种NALU的类型,这样当网络严重拥塞时,设备将根据NALU头表征的数据重要性进行分组丢弃。
此外,可以通过冗余编码例如前向纠错码和循环冗余码等来控制错误的传输。冗余编码在码流中添加冗余信息,接收端通过对冗余部分进行校验来纠正错误数据,确保送到解码器的数据是正确的,但是该方法增加了码流的长度,反而加重了网络的负担。

02

传输信道控制

通过数据重传实现编码端和解码端的交互。解码器在顺序解码的过程中,如果通过错误检测机制或者包计数器发现了错误或丢包,就向编码器反馈错误信息,请求数据重传。该方法增加了传输的次数,使传输效率大幅下降,不适合于实时性较强的应用,同时,因为需要交互,也不适用于单工信道传输的应用,例如广播电视等。

03

解码端控制
上述的方法都可以一定程度上减少错误的传输或者降低错误在视频帧间扩散的几率,但是对于网络极端恶劣的情况,上述方法的使用会受到限制,此时只能在解码器端独立地进行差错控制。差错掩盖技术在解码端利用邻近的正确解码块的数据来预测当前丢失块,而不是通过冗余码流恢复传输包的信息来正确解码,所以不会带来码流长度的增加;也不需要反馈信道,不会像数据重传那样带来时延,具有更高的实际应用价值。
差错掩盖技术的目标是尽可能地修复受损区域,使错误解码的视频恢复到满足人的主观视觉体验的程度,同时也提供给后续解码帧作为参考像素。差错掩盖算法分为如下两个步骤:1)确定码流丢包或误码所在编码块的位置;2)利用邻近正确解码块的数据来重建当前块,从而在主观体验上提高当前视频的质量。因此,差错掩盖不能完全重建原始视频,只是完成了对差错部分的最优预测。如下图所示即为差错掩盖的效果图。
2

空域差错掩盖算法

01

Criminisi算法
Criminisi算法[1]是一种经典基于块匹配的修复算法,由Criminisi在2004年提出,是一种针对受损区域较大的纹理修复算法,修复的效果如下图所示。
其基本思想是以受损边界上的点为中心作为待修复块,对每个待修复块根据像素和结构信息,确定修复的优先级;对于某个待修复块,在未受损区域中寻找最佳匹配块,然后将整个匹配块的像素拿来填补丢失像素。该算法的核心是修复优先级的计算,通过沿着结构走向逐步确定修复顺序,完成了从边缘到中心的修复,具体的修复过程如下:
下图中,Ω表示受损区域,φ表示未受损区域,δΩ表示受损块的边界。
p为边界上的一个修复优先级最高的待修复点,以p为中心选取的修复块记作ψp,在φ区域内搜索ψp的最佳匹配块,最佳匹配块的判定根据差值平方和(Sum of Squared Difference,SSD)决定,如图中的ψq即为搜索得到的最佳匹配块,将整个匹配块复制到待修复块上。修复的优先级计算方式如下。
首先对边界δΩ上的所有点计算优先权值P(p),其中置信度C(p)表示待修复块中可靠像素的比重,置信度越高,表示区域内可靠像素信息越多,能为待修复块提供更多的修补信息,就越早被修复,一般来说在受损区域的边界处,置信度高,而越是靠近受损区域中心,置信度就越低,因此置信度能基本保证修复顺序是由边缘向内部逐渐扩散;数据项D(p)表示等照度线在法向量方向上的投影,反映了该像素点处的线性结构强度,因此数据项保证优先填充结构强度大的位置,使图像的结构信息从边缘向内部延伸到受损区域内。
其中,|ψp|表示待修复块中的总像素数,q∈Ω时,H(q)=0,q∈φ时,H(q)=1。∇Ip是点P的等照度线,np是单位法向量。α是归一化因子,在8bit深度的图片中,为255。
完成一次填充后,更新置信度C(p),对修复后新出现s的边界点计算优先权值P(p),排序后重复进行填充直到所有受损块都被修复完毕。总结整个算法流程如下,流程图如下图所示,过程如下
(1) 根据输入的待修复图像和mask,手动指定损失区域;
(2) 确定边界像素点δΩ,如果没有边界点表示修复完成,退出;
(3) 计算边缘像素点的优先权值;
(4) 根据权值选择待修复块;
(5) 遍历未受损区域寻找SSD最小的匹配块;
(6) 复制匹配块的像素信息到待修复块,同时更新置信度和δΩ。
可以看到,Criminisi算法的修复顺序是由外而内的,从数据项选取的结构信息显著的区域开始延伸纹理至受损区域中心,符合人眼的视觉连通性,图像的纹理基本得到了保留,并没有普通插值修复的模糊的情况出现,在主观质量上符合人眼的视觉感受。尤其是当受损块面积较大时,Criminisi算法的修复结果会更出色。但它同时还存在了几个缺点:
(1) 权值计算中数据项的计算需要计算等照度线和边界法向量,计算复杂,且不一定适用于差错掩盖算法。
(2) 搜索最佳匹配块时,采用的方式为在未受损(包括已修复)区域进行全搜索,这样搜索的计算量非常大,耗时很长,不利于解码系统中的同步;同时由于图像固有的邻域像素相关性,在远离修复块位置的地方找到匹配块并不是实际最优解。
(3) 权值的大小决定了丢失块的修复顺序,而修复顺序很大程度上影响着最后的修复效果。算法中的权值计算方式采用的是乘法,在极端情况下会出现修复顺序错乱,导致修复偏差的累计,影响修复效果。
(4) 修复块的大小是固定尺寸,不能根据图像信息动态调整,由此会导致修复次数增多和修复效果的下降。

02

算法设计优化

如前所述,Criminisi算法在恢复图像丢失块的纹理和结构上表现很好,算法也较为直观,在对其进行以下几个方面的改进后,可以在较低的计算代价的前提下高效地完成HEVC的空域差错掩盖。

01
快速搜索法
对于Criminisi原始算法,在全图进行待修复块的最佳匹配块,一方面计算复杂度过高,搜索耗时大,对实时性的影响大;另一方面,在距离丢失位置较远的地方,即使搜索到的匹配块在SSD的表现上是最优的,但从SSD的定义出发,仅考虑了像素间的灰度值差异,而没有考虑像素间的离散程度或纹理结构,再结合空间相关性,这个匹配块很可能不是实际的最佳匹配块。
对此,我们引入了HEVC中CU的概念,最佳匹配块的搜索只在周围8个LCU中进行。首先定位丢失块,然后检测周围8个LCU的有效性,最后只在有效块中进行搜索。对同样分辨率的图像进行丢失LCU为64x64大小的修复,修复耗时有数十倍的减少,而且由于全搜索的耗时与分辨率大小成线性关系,分辨率越高,快搜带来的搜索速度提升越明显。
同时,对于全搜和快搜,分别比较其对修复效果的影响。可以看到无论是从PSNR还是从SSIM的评价标准上快搜都与全搜基本相同,在较为平滑的图像上甚至比全搜的效果更好。
上表中SSIM为基于人类视觉系统的客观质量评估指标,其值越接近1,表征图像质量越好。有关SSIM的介绍将在质量评估章节中详细展开,在此不做赘述。
02
自适应修复块尺寸
Criminisi算法中,待修复块的大小固定选择为9x9,这是经过大量实验得出的最通用的修复大小,但并不是对于所有视频都是最佳的选择。对于平坦区域,待修复块与周围块的变化十分平缓,此时9x9的小块虽然在修复效果上更优,但耗时较长;对于纹理丰富的块,此时纹理的变化过多,9x9的块在修复上会造成块与块间的边缘不平滑,会出现明显的块效应。因此,需要找到一种自适应调节修复尺寸的方法更好地平衡修复效果与修复耗时。考虑到HEVC帧内预测的过程本身就是根据纹理结构来做四叉树划分的过程,对于丢失块我们可以借用周围的正确解码块的划分深度信息来决定修复块的尺寸。
具体地,我们将匹配块的尺寸划分与HEVC的划分一一对应,以距离待修复点P最近的原始未受损区域中的点Q所处的CU大小作为依据,动态地调整修复块的大小,计算公式如下式:

03
优先权值改进
对于丢失区域的填充顺序是Criminisi算法的核心技术点之一,原算法中提出的优先权重计算方式同时考虑了可靠点数量和结构信息,由置信度C(p)和数据项D(p)的乘积决定,但是乘法对于极小的值十分敏感,对于等照度线方向与法向量垂直的情况,数据项D(p)等于0,此时,无论置信度的大小如何,权值P(p)都为0,即在修复顺序中排在了最后,显然这会导致修复顺序的不理想,引入修复的偏差,而这个偏差会随着修复的进行而累积,最后导致填补完的图像不满足视觉的连通性;同样,实验结果表明随着修复的进行,置信度C(p)存在迅速降低至0附近的现象,此时,数据项D(p)的重要性被忽视了,也会导致修复顺序的错乱。
为了修复乘法带来的极端情况下权值大幅度跳跃的情况,最简单的做法是把乘法改为加法,即下式:
此时,置信度和数据项在权值的计算中呈同样地位,显然也是不合理,因此可以进一步改进为下式:
3
时域差错掩盖算法

01

解码端运动估计算法
同样采用块匹配方式来修复丢失块的还有解码端运动估计算法(Decoder Motion-Vector Estimation, DMVE)[2],该算法在解码端采取类似于编码端帧间预测的方式,在参考帧内进行最佳MV的搜索,其算法流程图如下图所示。
(1) 获取当前丢失块的外边界像素;
(2) 确定搜索区域;
(3) 以左上角为搜索起点开始进行全搜索,每次计算匹配块与丢失块的外边界像素的SAD值;
(4) 在上述最佳搜索点附近进行半像素精度的搜索,确定最佳的运动矢量,并基于此做运动补偿修复丢失块。
不同于BMA算法是利用空间相关性进行块匹配来预测最佳的运动矢量,DMVE根据时域上的相关性进行匹配,它将匹配的方式改为了计算参考块的外边界像素与当前丢失块的外边界像素的SAD,即计算公式为:

其中,Y(mvj)iOUT采用的是参考块的外边界。此举不再过分依赖于当前块的运动矢量与周围块的运动矢量间的相似度,具有更广泛的应用范围。DMVE对于运动估计都很准确,恢复效果较好,但是计算过程与帧间预测过程相似,计算复杂度比较高,需要硬件加速。

02

算法优化与硬件设计
我们希望提出一种可配置的搜索方法,根据已正确解码块的先验信息,如果当前视频的分辨率较低或者运动范围较小,此时可以采用比较快的搜索配置,以加快差错掩盖的效率,减少计算功耗;反之当视频分辨率高或运动剧烈的情况下,可以配置更精细的搜索策略,避免出现太差的掩盖效果。
01
微代码控制结构
DMVE与整像素搜索过程类似,充分利用先验信息,能同时获得更低搜索耗时和更精确的搜索结果,我们提出了一种微代码控制结构,通过APB总线来配置差错掩盖模块的寄存器,通过寄存器来控制搜索的行为,而不是固化在硬件中。寄存器有三个:搜索起始点,搜索窗大小,搜索形状。总的来说,通过配置这三个寄存器,可以将实际的搜索窗限制在一个较小的范围,从而减少了搜索的次数。可配的搜索窗可以参考下图。当搜索起始点加上配置的搜索范围超出实际搜索窗时,菱形会畸变为六边形。
02
参考像素管理
DMVE中对参考像素的管理可以参考编码器中整像素预测的参考像素管理,因此我们提出的参考像素管理方法对整像素预测也具有指导意义。上文提到通过微代码控制搜索窗的形状和起始点,具体搜索时通过移动搜索候选点不断更新参考外边界像素和丢失块外边界像素的SAD。如下图所示候选点往各个方向移动时需要更新的参考块的外边界像素,其中灰色的部分表示是不在之前的参考块外边界像素存储器中,需要更新的像素,白色的部分表示可以复用的像素。
可以看到无论是垂直方向的移动还是水平方向的移动,需要更新的像素数都为64+1=65个,且单独的那个点与完整的64个像素并不处于相同行列,因此每次更新需要分别读入一行一列数据。
搜索窗中的参考像素是从外存搬运至片上的,存储方式为光栅存储方式,存储器按行进行存储,这样无法在一个周期内获取一列的像素值。为了减小读取参考像素的延迟,需要对其光栅存储的搜索窗整体进行转置处理,用额外的存储空间换取读列像素的效率。作为对比,将新的参考像素管理方式与光栅存储的更新周期数进行对比:对于光栅存储,每次读入一行需要1个cycle,读入1列需要64个cycle,一共65个cycle;而基于转置的行列存储方式,每次更新可以在1个cycle内同时读入一行与一列数据,即对于每次搜索点的参考像素更新可以节省64个周期,对于一个20x20的小搜索窗全搜索就能减少25600个周期,可以在满足实时性的同时支持更大的搜索范围。我们对水平存储器进行转置,转置结果存储于垂直存储器。
这里以8x8的块的转置为例说明本节提出的转置方法,如下图是转置模块需要实现的功能,红色序号是原始像素进来的顺序,每个周期进来一行8个像素,一共8个周期全部读完,黑色序号是转置后的输出顺序。

对此,最简单的实现方式,是例化8个深度为8,位宽是1个像素的存储器,对于每次进来的行像素,依次写到8个ram中,这样每一块存储器中,都存放了8个转置完的像素,这样会导致写出转置像素时,由于在存储器的不同地址,需要8次才能输出一列像素,对于整个8x8块则需要64个周期,造成极大的写出延时。对此将每行进来的像素在存储时进行一个相对于行地址的偏移,如下图所示,其中绿色数字表示当前存储像素在一行中的位置。
通过这样的存储方式,当要送出第一列数据也就是绿色标号为0的8个数据时,通过同时访问存储器0的地址0,存储器1的地址1…存储器7的地址7,即可在一拍内把所有数据取出,对于第二列也就是绿色标号为1的8个数据也可以以此类推,都分布在不同存储器的不同地址,支持一个周期内读出。
对于连续的转置操作,有两种乒乓操作,一种是通过两份相同的8x8的存储空间来实现乒乓操作,在从第一块读出列像素时,紧跟着的行像素写入第二份块存储空间,实现流水处理。第二种方式是通过地址控制逻辑的乒乓切换实现,用索引号0,1表示当前乒乓操作的序号,根据索引号改变写入读出的控制逻辑。假设上图所示是索引为0时的处理逻辑,每行的像素都存在对应行数的地址中,如第一行的0-7分别存在存储器0-7的0地址;那么对于索引为1的转置块,每进来一行,则插空存在前一块被读出去的地址中,即每一行的数据是存在对应列数的地址中,如下图所示,加粗且有下划线的0-7表示流水处理的第二个8x8块的第一行数据,被存放在了刚被读出去的标号为0的8个地址上。

综上所述,我们提出的DMVE的顶层架构如下图所示。

03

实验结果分析
本节提出DMVE算法的硬件实现的最终目的是要满足实时解码的需求,对此,我们对差错掩盖的耗时进行分析。对引入的微代码架构,我们设计了一套通用性较强的配置:搜索起始点为(0,0),搜索窗大小为±30,搜索斜率为1。假设实际搜索窗大小为±64,那么对于此配置方案,所需的时钟周期约为:
256+2+60
2
/2=2058

其中,“256”是转置整个192x192的实际搜索窗需要的时间,具体计算方式为:根据水平方向的参考窗复用,相邻LCU只需更新64x192的参考像素,由于吞吐率为64,写入转置模块需要192个周期,从中取出需要64个周期,一共256个周期;“2”是从行列存储器中读入待匹配的外边界像素的时间,“602/2”是宽高各为60的菱形的总搜索点数。
对于实验室现有的HEVC解码器,其在ZCU102的开发板上时钟为125M,则此方案最高可以支持的帧率约为4Kx2K@30fps[1],基本满足大多数应用下的实时解码需求。
此外,还可以通过灵活配置适应不同的需求,当需要最好的匹配性能时,可以配置为:搜索起始点为(0,0),搜索窗大小为±64,搜索斜率为∞,此时相当于在实际搜索窗内进行完整的全搜索,根据同样的计算方式,一共需要16642个周期,此时,还以30fps为目标,只能支持720p视频的实时解码;当需要较快的处理速度时,可以配置为:搜索起始点为周围块MV,搜索窗大小为±10,搜索斜率为1/2,此时能支持4kx2k@135fps。
对于本节提出的DMVE硬件实现,在ZCU102上进行综合实现,得到的资源利用率与实验室编码器的IME模块进行对比。如下表所示,可以看到对于比较紧张的LUT资源,DMVE仅用了IME的三分之一,片上的存储也只占了IME的一半。对于ZCU102,共有274080个LUT,DMVE仅占用了4.3%,而其他资源并不是视频编解码器的瓶颈,因此,DMVE的资源开支处于可接受的范围,可以插入到硬件解码器中。

[1](3840x2160)/(64x64)X2058x30125MHz
参考文献:
[1] Criminisi A, PPérez, Toyama K. Object Removal by Exemplar-Based Inpainting[A]. 2003 IEEEComputer Society Conference on Computer Vision and Pattern Recognition (CVPR2003)[C].Madison, WI, USA: IEEE, 2003:2-2.
[2] Jian Z, ArnoldJ F, Frater M R. A cell-loss concealment technique for MPEG-2 coded video[J].IEEE Transactions on Circuits and Systems for Video Technology, 2000,10(4):659-665.

关 注 我 们 
实验室网站:http://viplab.fudan.edu.cn/
OpenASIC官方网站:www.openasic.org
知乎专栏:http://zhuanlan.zhihu.com/viplab
微信公众号:OpenASIC
继续阅读
阅读原文