H.264解码纠错在软硬件协同系统中的实现
并非所有的码流错误都能直接通过句法元素的值判断出来。一些句法元素的值会影响解码方法并且被重复使用，所以有些错误是可以在解码过程中发现的，例如：
（4）引用的参考不存在。H.264 实现压缩的途径之一就是采用帧内和帧间预测，如采用了4 种16×16帧内预测模式和9 种4×4 帧内预测模式。各种模式对周边宏块的要求都有所不同，16×16 块的水平帧内预测模式所需要的相邻宏块信息如图2 所示。若当前宏块X 采用水平帧内预测，那么宏块A 必须可用。如果当前宏块位于一行的第一个，则说明这种预测方式是错误的。而在帧间预测时，要指定参考块所在参考图像的编号和位置，如果不存在当前编号所指向的参考帧或参考块的位置超出了图像范围，就说明当前的引用有误。由于宏块信息采用变长编码且没有特定符号分割，一旦发现错误，其后的数据直到下一个NAL 开始都应被丢弃。
图2 亮度分量Intra 16×16 水平预测模式
（5）查表无对应值。CAVLC 和CABAC 编码的数据由于其码长不定很难分隔出有错的数据，但是解码这些数据中包含大量的查表操作，非常有利于及早检出错误。
（6）其它异常情况。如参考队列中出现空缺，这时候只能判断前面某一帧或几帧出现了内存管理错误，管理使能句法元素daptive＿ref＿pic＿marking＿mode＿flag被错误地置1，或是具体的操作类型错误等。这种情况无法在解码句法元素的时候立即判断出错误（值在正常范围内且队列没有出现异常）， 虽然在人工调试的时候可以根据后面往队列中插入参考帧的情况检查出来， 但是对于实时解码器来说这样是没有意义的。这时候不需要放弃当前NAL 中的数据，只要将临近参考帧的信息复制到参考队列里即可。
以上是检错方法的大致概括。由于噪声是随机的，错误可能出现在解码过程的任何一个地方，所以只有通过调试大量码流才能达到一定的错误覆盖率，使解码器具有更好的适应能力。
3 软硬件协同系统中的纠错实现
尽管在H.264 的官方参考软件JM 中给出了较为完善的错误修补办法，但是考虑到尽量减少纠错部分对原有硬件的影响，我们采用基于帧内16×16 预测的修补办法， 其原理与解码帧内16×16 预测的方法相似。如果发现从某一宏块开始出现错误，解码器将判断周边宏块的存在和预测情况，为当前的宏块选择一个最佳的预测模式，通过周边宏块边界上的像素值修补当前宏块及其后的宏块直到当前Slice 结束。
本解码器采用软硬件协同的SoC 实现方案。在功能划分上，SPS ／ PPS ／ Slice 头的解析等分支较多的工作由灵活度较高的软件部分实现，熵解码和宏块预测等需要大量复杂运算的工作由硬件模块实现。硬件部分被分成前端和后端两个部分，前端部分包括熵解码单元，IQ ／ IDCT，后端包括运动补偿（MC）和滤波模块。
CPU 与各个模块、模块之间采用wishbONe 总线通信，前后端处理单元之间还有另外一条数据通道，以分担wishbone 总线的开销，其结构如图3 所示。CPU 对输入的码流做初步处理，提取出诸如图像大小、帧类型等信息，然后将处理后的数据送入硬件的前端处理部分，前端处理的输出被送入运动补偿模块恢复出像素信息并去除块效应。
错误检测是由软硬件共同完成的。软件[5]在解析SPS、PPS、Slice head 的同时判断解出的各个句法元素值是否合理，如果存在错误则通过总线向硬件发送信号HasErr＿soft。例如，在解析PPS 的函数中，解码无符号指数哥伦布（ue） 得到用来表示当前PPS 所调用SPS ID 的句法元素seq＿parameter＿set＿id， 然后判断解码器是否收到过此ID 标号的SPS， 如果无此SPS，则中断当前PPS 的解码，返回上一级函数。当前PPS的参数内容由其它PPS 复制得到。即在软件部分做以下修改：
read＿new＿slice（） ／ ／ 读入一个NAL 单元
{
…
switch （nalu－＞nal＿unit＿type） ／ ／ 判断NAL 类型
{
…
case NALU＿TYPE＿PPS:
ProcessPPS（nalu）； ／ ／ PPS 解析
break;
…
}
}
ProcessPPS（NALU＿t }nalu）
{
…
pps－＞seq＿parameter＿set＿id ＝ue＿v（…）；
／ ／ 读入当前PPS 所对应的SPS＿id
if （pps－＞seq＿parameter＿set＿id invalid）
／ ／ 若读入的SPS＿id 不可用
… ／ ／ 复制前一个PPS 的内容
HasErr＝1; ／ ／ 错误标志位置1
／ ／ （将通过总线发送信号给硬件）
return;
}
加入微信
获取电子行业最新资讯
搜索微信公众号：EEPW
或用微信扫描左侧二维码
