视频通信中的一种视频压缩传输方案

0

 一种在可移植H.323的视频会议系统内,基于H.263的纯软件的视频压缩、RTP封装方案,经测试可在较低的运算量下实现实时、稳定的视频通信。

　　关键词: H.263协议  视频编码  运动估计  RTP封装

　　国际电信联盟(ITU)制定的H.323协议提供了一种在分组网上进行音视频通信的系统框架,具有良好的应用前景。在H.323框架中,H.225协议负责呼叫接续控制,H.245负责媒体信道的控制管理,视频编码使用H.261和H.263协议,RTP协议对媒体数据流进行封装。其中,视频压缩将占用大量计算时间和系统功耗。小型设备中的嵌入式应用对运算量和功耗都有严格限定,因此需要降低视频编码过程的计算量和实现复杂度,并保证一定的主观视觉效果。此外,嵌入式应用应具有良好的可移植性。本文描述了一个基于H.263协议的视频压缩传输方案,其目标是可移植性、低运算量和良好容错性。

1 问题的提出

　　基于H.263的视频压缩中,运动估计与搜索利用相邻二帧图像之间的时间冗余,在前一帧图像中搜索当前帧的最佳匹配位置,然后进行预测编码,通过压缩帧间冗余达到对视频数据的压缩。为此,需要确定搜索路径和匹配准则。前者通过使用快速搜索算法降低运算复杂度,后者通过快速匹配算法保证一定的误差精度。运动估计与搜索过程占用大部分的编码时间,因此需要一种快速搜索的运动估计算法,同时要保证一定的信噪比和主观视觉效果。

　　在H.323系统中,视频数据流使用实时传输协议RTP进行封装,然后利用UDP通道传输。丢包和错序不可避免。因此,RTP封装必须提供相应的冗余信息,在接收端采取相应的措施进行出错处理,以保证通信的实时性和可靠性。

2 视频压缩和传输的实现

2.1 运动估计与搜索算法

　　视频压缩的流程主要包括离散余弦变换、运动估计与搜索、编码控制、量化编码和码流复用。其中运动估计与搜索算法决定了压缩的复杂性和质量。3种运动估计搜索算法:螺旋算法(Spiral Algorithm)、4步搜索算法(4SS Algorithm)和预测搜索算法(PSA Algorithm)。对这3种算法进行比较,匹配准则均采用绝对误差和(MAE)。

　　(1)螺旋算法

　　螺旋算法的搜索路径如图1所示。以黑点为中心起始点,进行环形搜索。每条新路径起始点位于前一路径起始点的左上角。当进行某个路径的搜索时,如果当前搜索点到达搜索区域边界,则本次搜索结束。图中,第1条搜索路径为虚线路径,第2条路径为实线路径。

　　(2)4步搜索算法

　　4步搜索算法的搜索路径如图2所示。黑点为中心起始点,点内数字代表所在搜索路径序号,搜索的步骤和过程如下。

　　①以中心起始点为中心,以步长为2的8个点为搜索窗(5×5),找出9个点中绝对误差和最小的点。如果这个最小误差点是搜索窗的中心点或者到达搜索区域边界,则转到第③步。

　　②以①中找到的最小误差点为中心点,步长为2的8个点为搜索窗(5×5),找出9个点中绝对误差和最小的点(如果当前中心点为前一窗的四顶点之一,则当前窗与前一窗中有4个点重合,只需再计算5次绝对误差和;同理,如果中心点是前一窗边界中点,则只需再计算3次绝对误差和)。如果该最小误差点是搜索窗中心点或者到达搜索区域边界,则转到第③步;否则,重复本步骤。

　　③以②中找到的最小误差点为中心,步长为1的8个点为搜索窗(3×3),找出9个点中绝对误差和最小的点。以该点为基础进行一次半象素精度的运动估计,得到最终的运动矢量,结束搜索过程。

　　(3)预测搜索算法

　　预测搜索算法中参考矢量的相对位置如图3所示,其搜索窗中心点的一种可能路径如图4所示。预测搜索算法主要包括2个步骤,即确定搜索起始点和按路径进行搜索。确定搜索起始点的方法是:假设当前宏块在当前帧内的坐标值为(x,y),找出在前一帧内位于(x,y)处的宏块(假设为图3中序号为0的点),然后将位于该宏块左方、上方和右上方的3个宏块(图3中序号为1、2、3的点)所对应的运动矢量求和并乘以1/3(按运动矢量的垂直分量和水平分量分别进行加权),获得一个加权运动矢量v;在当前帧内,以(x,y)为基础,偏移该加权运动矢量v,获得一个新的位置,即为对应当前宏块的运动估计搜索起始点的位置。确定搜索路径的过程如下(假设图4中序号为0的点为前一步骤中确定的搜索起始点)。

　　①以中心起始点为中心,步长为1的搜索窗(3×3)计算9个点对应的绝对误差和,找出误差最小的点,如果该最小误差点为搜索窗的中心点,则转到第③步。

　　②取以第①步中获得的最小误差点为中心,搜索步长为1的搜索窗,计算9个点对应的绝对误差和,找出误差最小的点,如果当前最小误差点为搜索窗的中心点或者达到了搜索区域的边界,则转到第③步;否则,重复本步骤。

　　③以第②步中获得的最小误差点为基础,进行半象素精度的全搜索,得到最终的运动矢量,结束搜索过程。

2.2 H.263码流的RTP封装

　　RFC2190描述了关于H.263视频流的RTP封装规范,它规定了H.263视频流在进行网络传输前RTP封装的3种模式:A模式、B模式和C模式。

　　(1)A模式

　　在A模式中,视频流以块组(GOB)为单位进行封装,总是以帧开始码或者块组(无论该块组是否有块组头部)开始的,但是并不需要包含整数个块组。模式A的载荷头共4个字节。封装格式如图5所示(图中数字表示比特位序号)。

　　其中,F字段和P字段的不同组合表示不同的封装模式;SBIT、EBIT分别表示视频数据首部和尾部的填充位数;I、U、S和A分别表示H.263的4种可选增强模式。这些载荷头字段与H.263视频流中的相应字段是冗余的。

　　(2)B模式

　　在B模式中,视频流在宏块(MB)边界进行分段封装,该模式只在未选PB帧模式时使用。使用B模式,主要是考虑在块组数据较大的情况下,为避免底层网络分片,以及配合完成A模式封装的需要。模式B的载荷头共8个字节。具体封装格式如图6所示。

　　其中,QUANT为本RTP包中第1个宏块所用的量化参数;GOBN和MBA分别为第1个宏块所在的块组号和宏块地址;HMV1和VMV1字段分别表示第1个宏块的运动矢量的水平和垂直分量的预测值(在高级预测模式下,为该宏块中第1个块的运动矢量的水平和垂直分量的预测值);HMV2和VMV2字段仅在高级预测模式中出现,表示宏块中第3个块的运动矢量的水平和垂直分量的预测值;其余字段与A模式的同名字段意义相同。

　　(3)C模式

　　C模式与B模式类似,C模式只在选用PB帧模式时使用,载荷头共12个字节。具体封装格式如图7所示。

　　C模式中的各个字段的意义与A模式和B模式中的同名字段相同。

3  实现方案选择及结果

3.1 运动估计与搜索算法的实现及选择

　　本系统在编码器中实现了螺旋搜索算法、4步搜索算法和预测搜索算法,采用QCIF格式测试序列“Mother and Daughter”、“Grandma”、“Salesman”和自行录制的“Sample”,记录了平均每宏块搜索次数,以及亮度Y分量平均压缩信噪比,分别如表1和表2所示。

3.2 RTP封装模式的使用

　　进行RTP封装的目的是提供一定的冗余信息,在发生传输错误(丢包、数据出错)时,能够限制错误蔓延、提高视频通信的容错性和健壮性。

　　为了减小运算复杂度,不选用PB帧模式,因而不用模式C。H.263协议中规定块组头是可选的,而视频流中的最小同步单位是块组。为了能在丢包的情况下快速重同步,选择为每个块组均加上块组头。

    按照RFC2190的规定:如果当前宏块所在的块组存在块组头,则其运动矢量的预测编码可参考前一块组的运动矢量;否则只参考本块组的运动矢量。因此,同一块组的宏块应尽量在同一个RTP包内,否则在丢包的情况下可能无法正确恢复已接收的宏块的运动矢量。一种简单的方案是:假定当前块组无块组头,对当前宏块进行编码时,如果该宏块不能放入当前RTP包(可能RTP包已满),且该宏块为某块组的第1个宏块,则对该宏块重新编码,并且加上块组头。实验证明,该方案没有明显增强传输的健壮性,但却增加了实现复杂度。

　　综上所述,选择模式A进行RTP封装。在编码端,开辟1KB的RTP缓冲区。在每个块组编码完毕之后,如果有足够的剩余空间,则将该块组放入当前RTP包内;否则,立即发送当前RTP包,重新申请一个RTP缓冲区,将当前块组放入新的RTP包。如果当前块组是某帧的最后一个块组,则放入RTP缓冲区之后立即发送(RFC2190中规定一个RTP包内不能包含不同帧的数据)。在解码端,根据RTP头部的序号进行排序和解封装过程,然后搜索帧/块组开始码进行同步,并解压缩。在解码过程中出错时,丢弃收到的数据,用前一帧相应的数据填充出错的部分进行差错掩盖,并重新搜索帧/块组开始码进行重同步。

3.3 实验环境及测试结果

　　整个H.323协议栈测试运行的平台是PⅢ800MHz PC机和Windows2000操作系统,以及一套公共服务函数。这套公共服务函数提供一个抽象操作系统所必需的功能,并具有可移植性,相当于协议栈与具体操作系统之间的适配层。协议栈运行在这套公共服务函数模拟的多线程实时操作系统之上,并调用其API函数(这些API函数独立于特定的软/硬件环境)。因此协议栈也是可移植的,以便将来移植到小型终端的嵌入式系统中。视频压缩和解压缩作为2个独立线程属于协议栈的一部分,并与其他相关线程(如采集)通信,整个协议栈的可用内存空间为1MB。

　　在测试中,采用QCIF格式的视频源,输出速率为64Kbps。采用螺旋算法的压缩过程P帧平均编码时间在600ms以上,协议栈CPU占用率约为60%。由于运算量大而明显地影响了协议栈内其他线程的运行和通信,不符合系统对视频压缩的低运算量和实时性的要求。采用4步搜索算法的压缩过程P帧平均编码时间约为39ms,CPU占用率约为20%。通过对I帧和P帧的合理选择,能有效缩减整个视频压缩的平均时间,并达到稳定的运行效果。采用预测搜索算法的压缩过程P帧平均编码时间约为42ms,CPU占用率约为25%,但在测试过程中其峰值大约为70ms,稳定性不如4步搜索算法。综上所述,协议栈的视频压缩中的运动估计过程最终采用4步搜索算法。

　　为了测试容错性能,在编码端每20个RTP包主动丢弃1个,虽然解码的图像出现短暂的画面模糊和图像错位,但在2～3秒内基本恢复正常。在编码端主动使部分RTP包序号乱序,解压缩端也同样出现图像错位,但是经过差错掩盖,可在2～3秒内恢复正常的解码过程。由此证明在解码部分采用的丢包处理和差错掩盖等措施是有效的。

4  结  论

　　本文针对小型设备的嵌入式系统中基于H.323视频通信的应用,提出并实现了一种基于H.263纯软件实现的、可移植的、基于IP网络的视频压缩、解压缩和传输方案,在低运算量和传输不可靠的环境下实现了实时、稳定的视频通信。经过实验测试,该方案适用于具有较强处理能力的小型嵌入式系统。

0