1. H.263 简介
H.263 由 ITU 定义,为视频会议和视频电话应用程序提供图象压缩(译码)。H.263 基于 H.261,并且其带宽是由小于 20K 到 24K bit/sec 的视频流形成。作为一种一般规则,H.263 要求其半带宽要于 H.261 的对应带宽达到相同的视频质量,所以在很大程度上 H.263 取代了 H.261。H.263 使用传输视频流。
H.263 的译码算法和 H.261 中的类似,但它在 H.261 的基础上有了提高和改变,从而增强了性能和错误恢复能力。H.263 中运动补偿采用的是半象素精确度,而在 H.261 中采用的是全象素精确度和环路滤波器。数据流中分层结构的某些部分是可选的,如此可以通过一个较低的数据率或较好的错误恢复能力来配置视频编译码。目前有四种能够提高性能的可选协商选项:无限制运动向量、基于语法的算法译码、前向预测和前后帧预测,类似于 MPEG,叫做 P-B 帧。
2.视频压缩中的一些基本概念
1 有损和无损压缩
在视频压缩中有损(Lossy)和无损(Lossless)的概念与静态图像中基本类似。无损压缩也即压缩前和解压缩后的数据完全一致。有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程中要丢失一些人眼和人耳所不敏感的图像或音频信息,而且丢失的信息不可恢复。丢失的数据率与压缩比有关,压缩比越小,丢失的数据越多,解压缩后的效果一般越差。此外,某些有损压缩算法采用多次重复压缩的方式,这样还会引起额外的数据丢失。
2 帧内和帧间压缩
帧内(Intraframe)压缩也称为空间压缩(Spatial compression)。当压缩一帧图像时,仅考虑本帧的数据而不考虑相邻帧之间的冗余信息,这实际上与静态图像压缩类似。帧内压缩一般达不到很高的压缩。
采用帧间(Interframe)压缩是基于许多视频或动画的连续前后两帧具有很大的相关性,或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息,根据这一特性,压缩相邻帧之间的冗余量就可以进一步提高压缩量,减小压缩比。帧间压缩也称为时间压缩(Temporal compression),它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。
3 对称和不对称编码
对称性(symmetric)是压缩编码的一个关键特征。对称意味着压缩和解压缩占用相同的计算处理能力和时间,对称算法适合于实时压缩和传送视频,如视频会议应用就以采用对称的压缩编码算法为好。不对称或非对称意味着压缩时需要花费大量的处理能力和时间,而解压缩时则能较好地实时回放,也即以不同的速度进行压缩和解压缩。一般地说,压缩一段视频的时间比回放(解压缩)该视频的时间要多得多
4 H.263 帧类型
A 内码帧(I帧)不能由任何其它帧构造出来,包含所有可显示它的信息。
l 每个光亮度和色差平面被分成8*8的块
l 各块使用DCT转换成频率域
l 利用量化表进行量化。
l 对各块中最重要系数序列(DC系数)用DPCM技术进行编码,且仅编码两个相邻DC值的差
l 各块中的系数是按锯齿形次序进行行程编码
l 最后进行类哈夫曼编码
l 在基准帧中对每个宏块均查找其最佳匹配宏块
l 计算实际宏块和最佳匹配宏块的差,作为运动向量
l 误差项用DCT进行转换
l 接着进行量化步,形成“锯齿形次序”行程编码,最后进行类哈夫曼平均信息量编码。注意量化表与I帧所用的不同,DC系数的编码与其他系数的编码方式相同
3. H.263的内容和特点
图象格式 亮度取样的象素个数(dx) 亮度取样的行数 (dy) 色度取样的象素个数(dx/2) 色度取样的行数(dy/2)
对每种图象格式,色差取样被定位在和亮度块边界一致的块上。取样象素的纵横比和图象格式的纵横比一致,也和H.261建议中定义的QCIF和CIF一致:(4/3)*(288/352)。除了sub-QCIF格式的 纵横比为4:3。
解码器使用sub-QCIF以及QCIF格式等。编码器可对sub-QCIF和QCIF中的一种进行操作。
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
H.263 支持五种分辨率。除了 H.261 支持的 QCIF 和 CIF 外,还有 SQCIF、4CIF 和 16CIF。SQCIF 的分辨率大约是 QCIF 的一半,而 4CIF 和 16CIF 的分辨率分别是 CIF 的4倍和16倍。
在译码算法上,H.261 与 H.263 的不同点列表如下: |
图画格式 | 象素亮度 | 线条亮度 | H.261是否支持 | H.263是否支持 | 非压缩比特率(Mbits/s) | |||
10 frames/s | 30 frames/s | |||||||
灰色 | 彩色 | 灰色 | 彩色 | |||||
SQ_CIF | 128 | 96 | 是 | 1.0 | 1.5 | 3.0 | 4.4 | |
Q_CIF | 176 | 144 | 是 | 是 | 2.0 | 3.0 | 6.1 | 9.1 |
CIF | 352 | 288 | 可选 | 可选 | 8.1 | 12.2 | 24.3 | 36.5 |
4CIF | 704 | 576 | 可选 | 32.4 | 48.7 | 97.3 | 146.0 | |
16CIF | 1408 | 1152 | 可选 | 129.8 | 194.6 | 389.3 | 583.9 |
4、编解码原理图
5、h263编解码数据结构
H.263采用句法和语义学的方法对多路视频来管理的。
句法被划分为四层,四个层(从上到下)分别是图象(Picture)、块组(Group of Blocks)、宏块(Macroblock)、块(Block)。图象层每帧图象的数据包含一个图象头(a picture header),并紧跟着块组数据(Group of Blocks),最后是一个end-of-sequence码和填塞位。其中包括有图象开始码(PSC) (22 bits)、时域参照(TR)(8 bits)、类型信息 (PTYPE) (13 bits) 和量化器信息 (PQUANT) (5 bits)等十三个选项。
PSC TR PTYPE PQUANT CPM PSBI TRB DBQUANT PEI PSPARE PEI Group of Blocks ESTUF EOS PSTUF
22 8 1 5 5 1 2 3 2 0/8/16 Vari 22 Vari (structure of Picture Lay)
每个块组层(GOB)包含了一个块组层头(a GOB header),紧跟着宏块数据(Macroblocks)。每个GOB包含了一行或多行宏块。对于每帧图象的第一个GOB(0号),不需要传送GOB头。而对于其它的GOB,GOB头可以为空,这决定于编码策略。译码器可以通过外部手段发送信号给远程变码器要求只传送非空GOB头,例如建议H.245。
GSTUF GBSC GN GSBI GFID GQUANT Macroblock Data
每个宏块(Macroblocks)中包含了一个宏块头(a macroblock header)和后续的块数据(data for blocks)。COD只出现在用PTYPE指定为"INTER"的图象帧中,对于这些图象中的宏块,当COD指定或PTYPE指示为"INTRA"时会出现宏块类型 & 色度的编码块样式(MCPBC)。如果PTYPE指示了"PB帧",对于B块的宏块 (MODB)会出现。只有在MODB中指定时才会出现CBPB(指示将传送宏块的B系数)和B宏块的运动矢量数据 (MVDB) (变长)。当MCPBC和CBPY中指定时会出现"块数据"。
COD MCBPC MODB CBPB CBPY DQUANT MVD MVD2 MVD3 MVD4 MVDB Block Data
块层如果不在PB帧模式,一个宏块包含四个亮度块和两个色差块。在PB帧模式下,一个宏块包含12个块。在缺省H.263模式下,首先传送6个P块数据,然后是6个B块数据。
5、RTP PAYLOAD FOR H263 STREAM 协议结构(在RTP中传输h263数据流)
当在网络中传输H263视频数据流时,可直接封装编码器的输出数据,对于每一视频帧,H263数据比特流无改变的封装在RTP中被传输,包括图片开始处理、整个图片头,还有混合长度处理,可变长度处理。被编码后的数据并没有加上装帧信息,所以多元的音频、视频信号不适合被封装在同一个包中,UDP和RTP提供了一个更加有效的方法来处理多元化。
RTP并不能提供一个可靠的、有次序的数据传输,因此数据包有可能丢失。为了使丢包得到最大程度的恢复,解码器必须能够处理已经到达的数据包。因而,能够独立处理每一个数据包是符合要求的。一些帧信息包含在每个数据包中,例如:source format 和 flag for optional features 能够帮助解码器在丢失数据包的情况下正确、高效的处理帧。
在RTP中H263视频数据流将被装载成payload data,一个新的H263载荷头部被定义在载荷头部第5个区域(section 5),这个区域定义了RTP头和H263视频数据包结构。
每一个RTP封包都有一个复合的RTP头,下面是H263视频数据的RTP封包的混合头部:Marker bit (M bit)、Payload Type(PT)、Timestamp.一个H263的TRP包如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP header | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263 payload header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263 bitstream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
每一个RTP包中只有一个H263 Video packet,H263 payload header 与 H263 video packet 一一对应。H.263 有效载荷头定义了三种格式(模式 A、模式 B 和模式 C)。在模式 A 中,在实际压缩 H.263 视频比特流之前存在4字节的 H.263 有效载荷头。这样允许在 GOB 边界有分段。在模式 B 中,使用的是8字节的 H.263 有效载荷头,且每个数据包从 MB 边界开始,没有 PB 帧选项。最后,模式 C 中使用的是12字节的 H.263 有效载荷头,采用 PB 帧选项支持在 MB 边界的帧分段。
H.263 有效载荷头定义了三种格式(模式 A、模式 B 和模式 C)。在模式 A 中,在实际压缩 H.263 视频比特流之前存在4字节的 H.263 有效载荷头。这样允许在 GOB 边界有分段。在模式 B 中,使用的是8字节的 H.263 有效载荷头,且每个数据包从 MB 边界开始,没有 PB 帧选项。最后,模式 C 中使用的是12字节的 H.263 有效载荷头,采用 PB 帧选项支持在 MB 边界的帧分段。 模式 A 中的头格式如下所示: |
1 | 2 | 5 | 8 | 11 | 12 | 13 | 14 | 15 | 16 bit |
F | P | SBIT | EBIT | SRC | I | U | S | A | R |
R (cont.) | DBQ | TRB | TR |
模式 B 中的头格式如下所示: |
1 | 2 | 5 | 8 | 11 | 16 bit | ||||||
F | P | SBIT | EBIT | SRC | QUANT | ||||||
GOBN | MBR | R | |||||||||
I | U | S | A | HMV1 | VMV1 | HMV2 | VMV2 | ||||
模式 C 中的头格式如下所示: |
1 | 2 | 5 | 8 | 11 | 16bit | ||||||
F | P | SBIT | EBIT | SRC | QUANT | ||||||
GOBN | MBR | R | |||||||||
I | U | S | A | HMV1 | VMV1 | HMV2 | VMV2 | ||||
RR | |||||||||||
RR(c) | DBR | TRB | TR | ||||||||
关于 F、P、SBIT、EBIT、SRC、I、U、S、A、DBQ、TRB 和 TR 各定义请参照模式 A。关于 QUANT、GOBN、MBA、HMV1、VMV1、HMV2 和 VNV2 各定义请参照模式 B。 RR ― 预留,设置为0(19 bits)。 |