2.1介绍
视频编码是对一个数字视频信号的编码和解码的过程.这一章讨论了数字图象和视频信号的结构和特征以及对于视频编码来说很重要的一些基本概念,比如采样格式等.数字视频是对于一人自然的视觉场景的从时间和空间上进行采样的表示方式.一个场景是由通过在时间上对于点进行采样来得到帧从而产生的(一种对于在时间上点在整个视频场景中的表示方法)或是一个场(由奇数或偶数行的空间采样组成).采样在一定的时间间隔上(通常是1/25或1/30秒时间间隔)进行重复，从而产生一个可动的视频信号。一般来说，需要三种采样集来表示一个有色的场景。表示数字视频的流行的方法是使用ITU-R 601标准并使用"中间集"。对于一个视觉场景的重建的准确性必须被计算来决定一个视频通信系统的性能，这是一个出了名的困难和极为不准确的过程。主观的测量方法是极耗时间而且它与观察者对于变换的反应程序不同而不同。客观的测量方法实现起来就更简单一些，但是目前还不能与人类实际视觉感完完全全匹配。

2.2 自然视频场景

一个经典的“现实世界”或“自然世界“的视频场景是由多个有各自特征形状，深度，纹理和亮度的物体构成的。视频场景的颜色和明亮度在不同的场景中根据不同程序的光滑度而定。一个与视频处理和压缩相关的经典的自然视频场景包括空间特征（纹理变换，物体的数目和形状，颜色等）和时间特征（物体运动，亮度的变化，视点的移动等）

2.3 捕捉
一个自然视频场景在空间和时间上是连续的。用数字的形式表示一个视频场景包括在空间对实际场景进行采样(通常是通过在视频图形面上用长方形格处理)和时间采样(以一系列以某时间间隔采样得到的静态帧组成)。数字视频就是在数字形式下的一个视频场景的采样的表示方式。每一个时-空采样（像素）用一个数或一组数来表示，用来描述采样点的亮度和色度。

为了得到一个二维的采样图像，摄像头把一个视频场景的二维投影聚焦到传感器上，比如一组电荷耦合装置(CCD)。在带色的图像捕捉过程中，每一个颜色成员都分别被过滤并投影到一组CCD中。

2.3.1 空间采样
一组CCD的输出就是一个模拟的视频信号，一组可以表示一个视频图像的电信号。在时间上对一点进行采样就形成了一个有定值的采样点图像或帧。最常用的采样方法是把采样点置于一个正方形或长方形格中进行操作。然后对于每个格交点处的点进行采样，重建过程就以采样值对应到像素上进行显示。重建图的视觉效果取决于采样点的数量。选择一个粗糙的采样格会得到一个低分辨率的采样图像，而增加采样点的数量就会增加采样图像的分辨率。

2.3.2 时间采样
一个可动的视频图像是通过对信号在周期性的时间间隔上进行快照得到的。重放这一系列的帧会得到一个运动的效果。一个高的时间采样率(帧率)会产生更加平滑的运动但是它就要求有更多的采样要被捕捉并被保存。在10帧每秒之下的帧率有些被用于一些很低码率的视频通信中(因为被传输的数据量非常的小)但是运动却看起来很笨拙而且不自然。在10-20帧每秒是比较经典的低码率视频。在25-30帧每秒进行采样是标准电视信号图象的采样帧率(配合隔行扫描采样来达到更好的运动效果）。50-60帧每秒就可以形成平滑的运动(代价就是帧率太过高，传输和存储的压力大).

2.3.3 帧和场
一个视频信号可以被通过对于一系列帧(渐进采样)或一个序列的隔行扫描的场(隔行扫描采样)来进行采样。在一个隔行扫描采样的视频序列里，一帧的一半的数据是在每个时间采样间隔进行采样的。一个场由奇数个或偶数个扫描线组成，而一个隔行扫描的视频序列包括一系列的视频帧。这种采样方式的优点在于与有相同帧数的同样码率的渐进序列相比，可以在一秒中传输两倍多的场，这样就可以形成更加平滑的运动。比如，一个PAL视频序列由50场/秒的码率组成，在回放过程中，运动可以比与之相同的25帧每秒的用渐进视频序列形成的运动显得更加的平滑。

2.4 颜色空间
大多数数字视频程序都依赖于彩色视频的显示，这样的话，就需要一个来捕捉并表示颜色空间的表示方法。一个单色的图像只需要一个在空间内表示一个像素点的亮度或流明度的值就可以了。但对于颜色图像来说，对于一个像素点至少需要三个数来把颜色信息准确地表示出来。用来表示亮度和颜色的方法叫做颜色空间。

2.4.1 RGB
在RGB颜色空间中，一个带颜色的图象采样是用三个值来表示一个象素点的相对的红，绿和蓝色比(三种光线的主样构成颜色)。任何颜色都可以通过把红，绿和蓝来通过不同的比例相混得到。RGB颜色空间更加适合于捕捉并显示颜色图像。捕捉RGB图像包括过滤出红，绿和蓝色的构成比率，并用一个单独的传感器数组来捕捉。CRT和LCD通过分别对每个像素点的红绿蓝值进行显示来得到各种颜色。从一个通常的观察距离来看，不同的构成部分可以达到颜色上的真实感。

2.4.2 YCbCr
人类视觉系统(HVS)相比亮度来说对于颜色不是那么敏感的。在RGB颜色空间中，三种颜色被平等地看待，并用相同的分辨率存放起来。但是通过把亮度与颜色信息分离，并对亮度值取更高的分辨率可以更有效地表示一个颜色图像。

YCbCr颜色空间和它的变换(通常写为YUV)是一种流行而高效的表示一个颜色图像的方法。Y是亮度值，由R,G,B的加权平均可以得到： Y=krR + kgG + kbB
这里k是加权因子。

颜色信号可以由不同的颜色差别来表示：
Cb = B-Y
Cr = R-Y
Cg = G-Y
对于一个颜色图像的完整的描述由给定Y和三个色差:Cb,Cr,Cg来表示。

目前为止，我们的表示方法好像并不那么好，因为相比RGB表示来说，我们这次用了四个参数。然后Cb+Cr+Cg是一个常数，那么我们只需要两个色度参数就可以了，第三个可以通过其他两个计算出来。在YCbCr空间中，只有Y和Cb,Cr值被传输和存储，而且Cb和Cr的分辨率可以比Y低，因为人类视觉系统对于亮度更加敏感。这就减少了表示图像的数据量。通常的观察情况下，RGB和YCbCr表示的图像看上去没有什么不同。对于色度采用比亮度低的分辨率进行采样是一种简单而有效的压缩办法。

一个RGB图像可以在捕捉之后转换为YCbCr格式用来减少存储和传输负担。在显示图象之前，再转回为RGB.注意没有必要去指明分别的加权值kg（因为kb+kr+kg=1)，而且G可以从YCbCr中解压出来，这说明不需要存储和传输Cg参数。

Y = kr R + (1-kb-kr)G + kb B
Cb = 0.5/(1-kb) * (B-Y)
Cr = 0.5/(1-kr) * (R-Y)

R = Y + (1-kr)/0.5 * Cr
G = Y - 2kb(1-kb)/(1-kb-kr) * Cb - 2kr(1-kr)/(1-kb-kr) * Cr
B = Y + (1-kb)/0.5 * Cb

ITU-R的BT.601决议定义了kb=0.114,kr=0.299，那么代换参数就有了如下等式：

Y = 0.299R + 0.587G + 0.114B
Cb = 0.564(B - Y )
Cr = 0.713(R - Y )

R = Y + 1.402Cr
G = Y - 0.344Cb - 0.714Cr
B = Y + 1.772Cb

2.4.3 YCbCr采样格式
4:4:4采样就是说三种元素Y,Cb,Cr有同样的分辨率,这样的话,在每一个像素点上都对这三种元素进行采样.数字4是指在水平方向上对于各种元素的采样率,比如说,每四个亮度采样点就有四个Cb的Cr采样值.4:4:4采样完整地保留了所有的信息值.4:2:2采样中(有时记为YUY2),色度元素在纵向与亮度值有同样的分辨率,而在横向则是亮度分辨率的一半(4:2:2表示每四个亮度值就有两个Cb和Cr采样.)4:2:2视频用来构造高品质的视频彩色信号.

在流行的4:2:0采样格式中(常记为YV12)Cb和Cr在水平和垂直方向上有Y分辨率的一半.4:2:0有些不同，因为它并不是指在实际采样中使用4:2:0，而是在编码史中定义这种编码方法是用来区别于4:4:4和4:2:2方法的).4:2:0采样被广泛地应用于消费应用中，比如视频会议，数字电视和DVD存储中。因为每个颜色差别元素中包含了四分之一的Y采样元素量，那么4:2:0YCbCr视频需要刚好4:4:4或RGB视频中采样量的一半。

4:2:0采样有时被描述是一个"每像素12位"的方法。这么说的原因可以从对四个像素的采样中看出.使用4:4:4采样，一共要进行12次采样，对每一个Y,Cb和Cr，就需要12*8=96位，平均下来要96/4=24位。使用4:2:0就需要6*8=48位，平均每个像素48/4=12位。

在一个4:2:0隔行扫描的视频序列中，对应于一个完整的视频帧的Y,Cb,Cr采样分配到两个场中。可以得到，隔行扫描的总采样数跟渐进式扫描中使用的采样数目是相同的。

2.5 视频格式
这本书中描述的视频压缩标准可以压缩很多种视频帧格式。实际中，捕捉或转化一个中间格式或一系列中间格式是很平常的事情。CIF就是一种常见的流行的格式，并由它衍生出了4CIF和Sub-QCif。帧分辨率的选择取决于应用程序，可使用的存储量以及传输带宽。比如说4CIF对于标准定义的电视和DVD视频来说是合适的,CIF和QCIF在视频会议中是常被使用的格式。QCIF和SQCIF对于移动设备的多媒体程序来说是合适的，在这样的情况下，显示分辨率和码率都是有限的。以下是各种格式的具体使用位数的需求（使用4:2:0采样，对于每个元素用8个位大小表示)：

格式： Sub-QCIF 亮度分辨率： 128*96  每帧使用的位: 147456
格式： QCIF  亮度分辨率： 176*144  每帧使用的位: 304128
格式： CIF  亮度分辨率： 352*288  每帧使用的位: 1216512
格式：  4CIF  亮度分辨率： 704*576  每帧使用的位: 4866048

一种在电视信号中被应用的很广的数字视频信号编码格式就是ITU-R的BT.601-5 提案。亮度元素被在13.5MHz下采样，而亮度值则在6.75MHz下采样，这样就形成了一个4:2;2的Y:Cb:Cr采样结果。采样数字信号的参数取决于视频码率(对于NTSC来说是30Hz,对于PAL/SECAM来说是25Hz)。NTSC的30Hz是对低空间分辨率的补偿，这样总的码率就是216Mbps.实际显示的激活部分的区域要比总量小，因为它去掉了在一帧边缘处的水平和垂直空白间隔。
每一个采样都有0-255的采样范围。0和255两个等级被留作同步，而且激活的亮度信号被限制到26(黑色）到235(白色)之间.

2.6 质量
为了指定，评价和比较视频通信系统，我们需要决定向观察者显示的视频图像的质量。衡量视频信号的质量是一件困难的事情，通常也是不准确的，因为有太多的因素会影响到衡量的结果了。视觉质量与生俱来就是主观的因素，它被很多因素影响着，这就使对于这个衡量结果的准确性变得更难了。比如说，一个视频信号的质量对于一个观察者来说主要取决于任务本身，比如说，被动地观看一部DVD影片，主动地参与一个视频会议，用符号评议进行通信交流，或是试图从一个视频场景中认出一个人。衡量视频信号的客观分类给定了一个准确的可重复的结果，但是没有哪种客观的测量方法可以完全地模拟人类视觉主观的感受。

2.6.1  主观质量测量
2.6.1.1 影响主观质量的因素
对于一个视频场景的感觉是由人类视觉系统对于不同元素复杂交互性决定的----眼睛和大脑.对于视频信号的感知是受空间保真度的影响的(不管有没有明显的失真，问题在于我们是否可以清楚地看到一个场景的各个部分)和时间保真度(运动是否自然平滑)。然而，一个观察者对于质量的看法经常会被观察环境，观察者的心情和观察者与场景的交互程序相关。一个执行特定任务的用户需要关注于视频场景的一部分。观察一个场景常与看一个电影时的对于“好”的概念是不同的。例如，一个观察者的对视频质量的看法在观察环境好的情况下会更好一些（而这一点不取决于视频信号本身的好坏）

其他的重要的影响因素包括视觉焦点（一个观察者通过一系列的观察点而不是同时观察所有的内容）和所谓的"最新效应"（我们对于一个视频序列的看法总是更多地受更新看到的内容的影响而不是老的内容)。所有的这些因素都让衡量一个视频的质量的好坏的任务变得极为困难。

2.6.1.2 ITU-R 500
很多的关于主观质量认下的测试过程都在ITU-R BT.500-11中被定义。一个常用的过程就是Double Stimulus Continuous Quality Scale(DSCQS)方法，评价者被展示了一系列的图片或两个视频序列A和B（一个接一个地），然后被要求给出A和B的质量评价值，方法是在五个分隔着的评价值（从"Excellent"到"Bad")画连续线来定。在一个典型的测试会话中，评价者被展示了一系列的序列，并被要求对它们进行评价。对于每对序列来说，一个是未受损的"参考“序列，另一个是同样的序列，它被在测试的系统或过程中修改了。

这两个序列的顺序，原始的和有损的，在测试地过程中被随机的给出，这样评价者就不知道哪个是原始的，哪个是改变过的序列。这样就防止了评价者带偏见地比交这两个测试序列。在结束的时候，评分被转化到一个规范化的范围内，最终的结果是用平均评价值来说的，用它来指明相应的帧的质量。

像DSCQS这样的测试被广泛地接受，并被用来评价主观的视频效果。然而，这样的测试受实际问题的影响。这样结果对于评价者来说差别会非常大。这个不同会被在重复测试的过程中被弥补过来。一个有经验的评价者(对视频压缩失真了解的比较多的）会比那些非有经验性的用户会给出一个更带偏见的评分。这就意味着一个很大的评价用户群是需要的，因为没有经验的用户很快会发现被改变的视频的一些特征。这些因素使得使用DSCQS方式的代价更大。

2.6.2 客观的质量测量
主观测量质量的方法的复杂性和消耗性让用算法自动测量质量要更加的吸引人。视频压缩的开发者和视频处理系统很大程序上依赖于所谓的客观质量测量方法。最广泛应用的方法是PSNR方法，但是这种方法的局限性使人们不得不找更加复杂的方法来逼近人类视觉性。

2.6.2.1 PSNR
PSNR是用来在对数级上描述质量，并且依赖于原始信号和改变后信号的均方差（MSE）:
PSNR(db) = 10log(10)(2^n-1)^2/MSE

PSNR可以很方便而快速地被计算出来，这样它就成为了一种很流行使用的方法，并用来测量压缩和解码视频图像的质量。

PSNR方法有几个局限性，PSNR需要一个原始的图像做为对比，但是这也许是无法在所有情况下都可以实现的,也难保所谓的原始图象没受过影响。PSNR不能准确地给出主观的视频质量值。对于给定的一个图象或一个图象序列来说，高的PSNR通常说明质量高，低PSNR说明质量低。然而，一个特定的PSNR值并不等于绝对的主观的质量。主观上感觉好的图象不一定PSNR值高。这种情况下，人类的观察敏感区中心让人感觉清晰度很好，但信嗓比不一定高。

2.6.2.2 其他的客观质量衡量方法
因为PSNR方法的局限性，最近有很多工作用来开发更加复杂的客观的测试过程，而且表示更准确的主观信息。很多不同的方法都被提出了。但是没有一个可以完全代替主观测试。所以还没有一个比较标准的，准确的，可用的方法。意识到这一点之后，ITU-T视频质量专家组（VQEG）就致力于提出一种客观的视频质量评价机制。每一步就是测试并比较隐藏的模型与测试模型。在2000年三月，VQEG宣布有10个这样的测试系统备选。不幸的是，没有一种被认为是适合的。VQED在2003年进行了第二次的评估。除非非常在自动质量评价中有一个非常大的突破，否则这个问题是很难被解决了。

2.7 结论
采样模拟信号会形成数字视频信号，它有准确，高质量和对于数字媒体的存储传递等各种优势，但是会占用比较在的空间。与生俱来的问题包括空间和时间分辨率，颜色表示和视频质量的测量问题。下一章会介绍视频压缩的一些其他的基本理论.

3.1 介绍
压缩(compress) 动词： 挤压到更小的空间中;即condense
压缩(conpress) 名词： 压缩的行为或是压缩的状态

压缩是把数据用更小的空间来存放的技术.视频压缩(视频编码)是把数字视频流序列用更少的数据位进行存放的方法."Raw"或叫没压缩过的视频需要大量的码(大约每秒信息216M),而且压缩对于数字视频的存储和传输来说都是需要的.

压缩包括一对互补的系统,一个编码器(encoder)和一个解压器(decoder).编码器把原数据在传输或存放之前转变为压缩格式(占用更少的数据位),而解压器把压缩的格式转会到原来的视频数据格式上.编码器/解码器对经常被叫做CODEC(enCOder/DECoder)

数据压缩是通过移除数据冗余来实现的，比如说，对于数据重构过程中无用的数据。很多种数据都有统计上的冗余性，它们就可以通过无损压缩进行有效的压缩，这样的标准比如说JPEG-LS，它可以达到3-4倍的压缩。有损压缩可以达到更高的压缩比。在有损压缩系统中，解压数据与源码流数据是不同的，高压缩率是通过视频质量的下降来达到的。有损视频压缩系统是建立在删除主观冗余的原理之上的，从图象或视频中删掉的部分不会很大程度上影响观察者对于视频质量的认识的。

大多数视频编码方法寻找空间和时间上的冗余来达到压缩的效果。在时间域中，连续几帧的视频通常有很强的相关性，特别是当时域采样率是非常高的时候尤其如止。在空间域中，通常像素采样点之间是相互关联的，比如说，相邻象素之间很相近。

H.264和MPEG4视频标准共用了一部分特征。这两种标准都假设了一种以块(block）为基础的运动补偿，变换，量化和熵编码。我们主要关注到这些主要的方法中，并从时间模型开始，接下来是图象变换，量化，预测式编码和熵编码。并以对于一个图象采样块进行编码和解码的过程进行描述。

3.2 视频编解码器
一个视频编码器器把一个源图像或视频序列转化为一种压缩模式，并在解码器把它构造为源序列的一个拷贝的或是一个近似.如果解压了的视频序列与原序列是相同的，那么编码过程是无损的，如果解压序列与源序列是不同的，那么这个过程是有损的。

CODEC用一种模型来表示原始视频流(一个被有效编码的表示方式，并可以用它来重建视频数据的近似结果或尽量取得高的码率。这两个目标(压缩效率和高质量)通常是相矛盾的，因为一个低的压缩码率通常在解压部分会降低图象的质量。码率和质量的平衡我们会在之后进行介绍

视频编码器是由三个主要的功能部件实现的：时域模型，空域模型和熵编码。时域模型的输入为一个未压缩的视频流序列。时域模型试图用邻近帧的相似性来消除了时域冗余,通常是构造通当前帧的预测。在MPEG4视频部分和H.264中，预测通常从一个或多个之前或之后的帧来进行的，并通过对于帧之间的差别进行补偿。时域模型的输出是一个剩余帧(通过从实际当前帧中减去预测值得到)，而一系列的模型参数，通常是一系列用来描述运动是如何补偿的运动向量。

剩余帧构成了时域模型的输入，它会利用邻近采样点的相似性来降低空域的冗余。在MPEG4视频部分和H.264中，这通常通过一些变换来对样点进行处理来实现。变换把采样点转到其他的域中，在这些域中用变换系数来表示。这些系数被量化来删除不明显的值，只留下很少的大系数来对剩余帧进行表示。空域模型的输出是一系列的量化变换的系数。

时域模型的参数(通常是运动向量)和空域模型的参数(系数)通常用熵编码来进行压缩。这就删除掉了统计上的冗余度(比如，用短二进制码表示当前的向量和系数)并制造出一个压缩流或文件来进行传输或存储。一个压缩的序列由编码的运动向量参数，编码的剩余系数和头信息表示。

视频解吗器从一个压缩流中构造一个视频帧。系数和运动向量由熵解码器进行解码，然后空域模型构建出一个版本的剩余帧。解码器利用运动向量参数与一个或多个解压帧来构成一个对当前帧的预测，然后帧就可以通过加入这个剩余帧来得到。

3.3 时域模型
时域模型的目标是要减少减少传输帧的冗余性。这个过程的输出是一个剩余帧，而且预测过程越准确，剩余帧中包含的能量就越小。剩余帧被编码并送到解压器用来构造预测帧，加上解码的剩余帧来构成当前帧。预测帧是通过一个或多个过去或未来的帧(都叫做参考帧)来创建的。预测的准确性通常可以由参考帧和当前帧之间的运动补偿来改进。

3.3.1 从前一视频帧进行预测
时间域的预测的最简单的方法是从当前帧的前一帧进行预测。用两帧之间的差来做为剩余帧。这个方法的明显的问题在于剩余帧中的能量太多了，这也就是说在时域压缩之后还有大量的数据可以被压缩。大部分的剩余能量是由于在二帧中的物体运动可能造成两帧的运动补偿形成的。

3.3.2 由于运动造成的改变
在视频帧之间的改变可能是由物体的运动造成的(刚性的物体运动，比如说一辆运动着的汽车，或可变形物体运动，比如说移动的手臂），摄象头的移动，被去覆盖的区域(比如说一个运动场景中由于物体的运动致成背景的去覆盖性)和光线的变化。除去去覆盖和光线变化，差别都是由于帧间的像素点的运动造成的。这样构造的像素点的邻接被称为光流(optical flow)。完整的域包括对于每个像素位置的光流向量，但是这些域都是被子采样过的，这样的话，只有每隔两个像素点的向量才被显示出来。

如果光流域是准确描述的，那么它应该可以构成一个对大多数像素点准确的预测，方法即为沿着光流向量移动参考帧中的每个像素点。然而，种种原因之下，这并不是一个实用的运动补偿的方法.对于光流的准确的计算对于计算来说是非常敏感的而且把每个像素点的光流传给解码器也是必要的，以使它能重构造预测帧(这样就得到了大量的传输数据，与我们小剩余值的目标是相矛盾的）。

3.3.3 基于块的运动估计和补偿
一个实用并被广泛使用的运动补偿方法是为了裣一个矩形区域的运动或叫当前帧的“块”。下列的步骤对当前帧的一个M × N采样的块的处理过程：

1. 在参考帧中查找一帧(过去的或以后的，已被编码的或传输的)，来找到一个相匹配的M * N的区域。这是由在查找区域中比较M * N的块,并找到一个最接近这一块的区域。一个流行的匹配方式是用把两个块的能量作差，这样能量相差最小的两个区域被认为是最佳的匹配结果。这个查找匹配的过程被叫做运动估计。

2. 选定的区域成为对于当前M * N块的预测块，它被减掉当前的块来构成一个M*N的剩余块(运动补偿).

3. 剩余块被编码并传输，当前块和选定块的差值(运动向量)也被传输.

解码器使用接收到的运动向量来重建预测区域并解压剩余块，加上之前的预测块来重建一个原始块。

基于块的运动补偿这么流行是有很多原因的。它很直接，计算性上也很易处理，它与矩形视频帧很相适应，并且使用基于块的图形变换(比如DCT等)，而且它对于视频序列提供了一个有很效的时域模型。然而它也有一些缺点，比如说，实际物体中几乎没有平滑的边缘来进行矩形边界的匹配，物体通常在帧之间用很小的像素点位置移动（比如说可变形的物体，旋转和扭曲），而且很多种运动是难以用基于块的方法进行补偿的。尽管它有这些缺点，基于块的运动补偿是当前所有的视频标准使用的时域模型的基础.

3.3.4 对于一个宏块的运动补偿
宏块，对应于一个16*16的帧区域，是大多数编码标准(包括MPEG1,MPEG2,MPEG4,H.261,H.263和H.264)运动补偿预测方法的基本组成部分。对于源4:2:0的视频信号来说，一个对于源帧的16*16像素区域的是由256个亮度采样(用4个8*8的采样块排列)，64个Cb色度采样(用一个8*8的采样块排列),64个Cr色度采样(用一个8*8采样块排列)，这样就一共六个8*8的块。MPEG4或H.264的CODEC通过宏块来处理每一个视频帧.

运动估计
对于一个宏块的运动估计包括在参考帧中找一个与当前宏块相近的16*16的采样区域。参考帧是一个在之前被编码过的帧。参考帧的区域以当前宏块的位置为中心，宏块区域的查找16*16的相匹配区域做为最佳匹配结果。

运动补偿
在参考帧中选定的最佳匹配区域是从当前宏块中减掉的部分，它用来构成一个剩余帧，接着通过运动向量被编码和传输，它也描述了最佳对应区域。在编码器之内，剩余帧被编码和解码并被加到相应区域之中，来重构一个宏块，这个宏块被存为以后的运动补偿预测的参考帧。用一个解码的剩余帧来重构宏块来保证编码器和解码器在运动补偿的时候使用相同的参考帧。

在运动估计和补偿的过程中有很多不同方法。参考帧可以是之前的或之后的一帧，也可以是结合或是更多帧的搭配。。如果一个之后的帧用来进行参考的话，那么就要先对这一帧进行编码。在参考帧和当前帧之间有一个很大的改变的地方（比如说，一个场景的变化），也许不使用运动补偿进行编码宏块会更有效。这样编码器就选择帧内编码(在没有运动补偿的情况下进行编码.在移动场景中移动的物体很少符合16*16像素边缘而且这样也许使用可变的块大小进行运动估计和补偿会更高效。物体可能有很少的像素部分运动，这样使用在参考帧中插值法会是一种更加好的预测方法。

3.3.5 运动补偿块大小
视频序列中的连续两帧中图1是从图2中不通过运动补偿而进行减操作得到的一个剩余帧.剩余帧中的能量由于通过16*16的宏块做运动补偿而降低.每8*8块(而不是16*16)的块会更近一步降低剩余帧中的能量,4*4会更少.这个例子说明了小的运动补偿块可以得到更佳的运动补偿效果.然而,一个更小的运动补偿块会导致复杂度的升高(更多的搜索操作被执行了)，这样更多的运动向量就要被传输。发送每个运动向量需要一些位来做到，这个多余的负担会抵销剩余帧中能量的减少的优势。一个更有效的妥协的方法是采用调节图的块大小，比如说在相似的区域上选择一个大的块,而在高度细节化运动的部分选用更小的块。H.264使用了一种自适应的运动补偿块大小，在以后我们会提到。

3.3.6 子像素运动补偿
一些情况下，通过在参考帧中从插值采样位置来预测会得到更好的运动补偿预测。“子像素”运动估计和补偿包括寻找子采样的插值位置与整值采样位置，来寻找最佳匹配(比如说，最小化剩余帧的能量)并在这个位置使用整或子采样值来直行运动补偿预测。对于四分之一像素运动裣来说，第一步，运动估计会寻找对于整采样格的最佳匹配,接下来编码器在最佳匹配附近寻找半采样位置来看匹配是否可以被改进，如果需要的话，对半采样最佳匹配像素附近的四分之一采样位置进行寻找。最终的匹配（整，子或四分之一采样位置）由当前块或宏块相差得到。

用4*4的块大小得到的剩余帧可以使用半采样插值并有更低的剩余能量。这种方法可以由从四分之一采样格来得到更小的剩余帧能量得到扩展。总体上说，“更好的”插值可以达到更好的运动补偿性能（更小的剩余帧能量），代价则是复杂度会更高一些。这样得到的性能提升会因为插值的步骤的增多而抵销。半采样插值相比整采样有更好的性能，四分之一采样插值会给出更好的效果，八分之一更胜之，以此类推。

一个运动补偿过的参考帧被从当前帧中减去，剩余帧的能量如下（用总绝对误差来近似SAE）：
Sequence No motion compensation  Integer-pel  Half-pel  Quarter-pel
'Violin',QCIF 171945   153475   128320   113744
'Grasses',QCIF 248316   245784   228952   215585
'Carphone',QCIF 102418   73952  56492  47780

一个低的SAE表示更好的运动补偿性能。在每种情况下，子像素运动补偿相对整像素补偿都有更好的性能表现，而四分之一补偿会更好。"Grasses"序列有更复杂的运动，这样就更难以实施运动补偿，悲痛"Violen"和"Carphone"就更容易进行补偿了。

在四分之一采样插值中寻找一个匹配的4*4的块是比在没有插值的16*16的块中更加复杂的。除了更大的复杂度之外，因为每个块的运动向量都要被编码并传输到接收端以更好的重建图象，这样就有了编码上的性能损失了。因为块大小减小了，传输的向量数增加了。需要更多的位来表示半采样或四分之一采样向量，因为向量的更细节部分也必须被像整采样那样进行编码。这样有另复杂运动的补偿模式下就有编码效率上的平衡度了，因为运动补偿越准确，就有更多的数据来表示运动域，但是在不那么准确的情况下，就不需要那么多位了。
3.3.7 基于区域的运动补偿
在一个自然的视频场景中移动的物体很少被对很整齐地对齐到块的边缘，它们很可能是不规则形状的，放置在任意位置上，而且在帧间改变他们的形状。这样就很难在参考帧中找到一个理想的匹配，因为它覆盖了一部分运动着的物体，一部分静态的物体。

在图像的任意区域应用运动补偿是可以达到更好的性能的。比如说，如果我们试图在椭圆形的物体中进行运动补偿的话，我们可以在参考帧中找到一个理想的匹配。然而使用基于区域的运动补偿会遇到很多的实际困难，包括识别区域边界，指出边界的轮廓，在运动补偿之后编码剩余帧，MPEG-4视频包括了一系列的工具来支持基于区域的补偿和编码。

主要注意三个内容：

1. 编译QTE时，在其自定义配置文件（位于QTDIR/src/tools/qconfig-XXX.h，其XXX为自定义的名字，该特征字可以在configure时用-qconfig XXX指定）所应加的内容：

   #define QT_QWS_IPAQ

   #define QT_QWS_IPAQ_RAW

   去掉鼠标自动识别功能 ：#define QT_NO_QWS_MOUSE_AUTO

   去掉不用的鼠标驱动，（在实际中，这一步可以不要，但对于缩减QTE的大小很有帮助），方法主要是在configure时设置配置参数为-no-mouse-pc -no-mouse-bus -no-mouse-yopy -no-mouse-vr41xx 。

   以该编译好的QTE库为基础，编译应用程序；

2. 在目标机上，要将触摸屏驱动链接好。在QTE3.0的版本中，如果定义了上述的两个IPAQ相关的宏，其默认打开设备文件/dev/h3600_tsraw。如果只定义QT_QWS_IPAQ，则打开设备文件为/dev/h3600_ts。

3. 在目标机上，设定环境变量：QWS_MOUSE_PROTO=linuxtp:/dev/h3600_tsraw。

（2）使用tslib方法；

• 编译TSLIB1.3：

  • 进行如下操作

• #./autogen.sh #生成configure文件

• CC= $ARM_TOOL_PATH/arm-linux-gcc

• CXX= $ARM_TOOL_PATH/arm-linux-g++

• ./configure --host=arm-linux --target=arm-linux --disable-inputapi --prefix=$PWD/build

• make

• make install

• 将build的整个目录拷贝到目标机，然后在目标机做如下设定，修改/etc/profile文件，在其中加入以下环境变量的设置

  • export V_ROOT=/xxx/xxx/build #目标机上build所在的路径

  • export TSLIB_TSEVENTTYPE=H3600 #设定类型为H3600，其主要是对着tslib中的设备结构体定义，该定义要与触摸屏驱动中的一致

  • export TSLIB_CONSOLEDEVICE=none #设定控制台设备为none，否则默认为/dev/tty。在tslib1.3源码中，只要不是none，它就会打开$(TSLIB_CONSOLEDEVICE)1，默认的为/dev/tty1的设备，然后从中读取console的可用设置。这样可以避免出现“open consoledevice: No such file or directory KDSETMODE: Bad file descriptor”的错误

  • export TSLIB_FBDEVICE=/dev/fb0 #指定帧缓冲设备

  • export TSLIB_TSDEVICE=/dev/touchscreen/0raw #指定触摸屏设备节点文件

  • export TSLIB_CALIBFILE=$V_ROOT/etc/pointercal #指定触摸屏校准文件pintercal的存放位置

  • export TSLIB_CONFFILE=$V_ROOT/etc/ts.conf #指定TSLIB配置文件的位置

  • export TSLIB_PLUGINDIR=$V_ROOT/share/ts/plugins #指定触摸屏插件所在路径

• 编译TSLIB1.4（TSLIB07072006）

  • 进行如下操作：

    • echo "ac_cv_func_malloc_0_nonnull=yes" > tslib/arm-linux.autogen #为了防止出现undefined reference to `rpl_malloc' 错误

    • CONFIG_SITE=arm-linux.autogen ./configure CC=arm-linux-gcc CXX=arm-linux-g++ --host=arm-s3c2410-linux-gnu --target=arm-s3c2410-linux-gnu --disable-input --disable-arctic2 --disable-mk712 --disable-collie --disable-corgi --disable-ucb1x00 --disable-linear-h2200 --with-gnu-ld --prefix=$PWD/build

    • make

    • make install

  • 将build的整个目录拷贝到目标机，然后在目标机做如下设定，修改/etc/profile文件，在其中加入以下环境变量的设置。其解释类上，不同于TSLIB1.3的是，TLIB1.4通过配置文件ts.conf中module_raw h3600语句来加载对应的设备结构体定义。已废除了TSLIB_TSEVENTTYPE宏。

    • export V_ROOT=/xxx/xxx/build

    • export TSLIB_TSDEVICE=/dev/touchscreen/0raw

    • export TSLIB_CALIBFILE=/etc/pointercal

    • export TSLIB_CONFFILE=$V_ROOT/etc/ts.conf

    • export TSLIB_PLUGINDIR=$V_ROOT/lib/ts

    • export TSLIB_CONSOLEDEVICE=none

    • export TSLIB_FBDEVICE=/dev/fb0

  • 一个值得注意的问题是：TSLIB1.4在ts_config函数中通过while((p=fgets(buf,BUFF_SIZE,f))!=NULL)来加载ts.conf中的语句，而buf只有512byte。所以对于ts.conf没有用的定义语句，请将其删除，以防止误发生段错误。

• 以TSLIB库为基础，编译QTE。

  • QTE2.3.10直接支持-tslib选项开关的应用。不用修改任何文件。可以通过网上所说的拷贝tslib.h头文件及库文件到QTE相关目录来进行编译（对于tslib1.4，还要拷贝tslib_private.h）。也可以在./configure进指定-L<path to tslib library> -I<path to tslib header>来防止出现找不到相应库文件 的错误。（对于tslib1.4，应该还加上-lts选项）。

  • 对于其它版本的QTE，可以通过在QTE文件夹路径下执行grep -lir 'tslib' *来查看是否有对tslib的支持，如果没有则需要对源码进行相应的修改。（onebyte注：虽然网上说有补丁可下，但俺一直没找到相关的patch，但看看QTE2.3.10的源码后再做相应的修改还算比较方便：）

［onebyte后记］：

由于是一个人在做基于embedded linux的软件开发，没有他人直接的交流，所以摸索QTE触摸屏支持的过程是相当辛苦的！网上关于这一块的说法不一，使得自己对QTE触摸屏支持的方法很长时间辨不清方向。但在这里还是要非常感谢网上的许多朋友，正是通过大家的讨论才将这块内容逐渐理通。

在这里特将这些方法记载下来，送给同我一样经历过困惑的朋友们：P

［参考网站］

网上各论坛中关于TSLIB内容的帖子不少，这里只记一些主要的论坛网站，有兴趣的可以到这上面去看看：

[1] 北京理工大学嵌入式linux BBS

[2] 华恒嵌入论坛

[3] Qt中文论坛

[4] QT Forum

[5] China Linux Forum

onebyte注：前一阵子简略地分析了一下QT中触摸屏相关文件，现在把它共享出来。希望能对志同道合的朋友有所帮助：P

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

文件位于QTDIR/src/embedded/文件夹中。

（1）类结构示意图，如下图所示。

（2）与触摸屏相关主要函数进行解释如下：

• QWSLinuxTPMouseHandlerPrivate其构造函数

  在其中打开设备文件/dev/h3600_tsraw或h3600_ts或ts（视宏定义），并将其readMouseData()槽同QSocketNotifier的activated信号连接起来。

  QsocketNotifier由所打开的设备文件号初始化。这样就可以将驱动中的事件同上层应用程序中的鼠标动作联系起来。

• QWSLinuxTPMouseHandlerPrivate::readMouseData()

  该函数读取设备文件/dev/h3600_tsraw或h3600_ts，视宏定义。并在其内部将触摸屏设备坐标（也就是电压值）通过其父类：QWSCalibrateMouseHandler::transform()函数转换为屏幕坐标。并取一定点的平均值。

• QWSCalibrateMouseHandler::transform()

  通过a, b, c, d, e, f转换参数将设备坐标转换为屏幕坐标。

• QWSCalibrateMouseHandler::Calibration()

  求取坐标转换系数及偏差（a, b, c, d, e, f，实际用的是二点校正法：左上及右下点。）。并调用writeCalibration将参数值输出到/etc/pointcal文件中。

• QWSCalibrateMouseHandler::readCalibration()

  从/etc/pointcal文件读取坐标转换系统及偏差。

（3）上述类都是通过qmousedriverfatory进行初始创建的。

［编译环境注：］

宿主机Linux操作系统为Fedro Core 5

交叉编译工具链版本：arm-linux-g++ 2.95.3，

宿主机编译工具链GCC 版本为4.1.0

QT-X11版本为2.3.2

QT/E版本为2.3.7

QTOPIA版本为1.7.0

（1）编译QT-X11

• 解压qt-x11-2.3.2.tar.gz，并更改解压文件夹名为qt-x11

• cd qt-x11

• 更改qt-x11文件夹中src/tools/qvaluestack.h第57行源代码remove( this->fromLast() );为this->remove( this->fromLast() );否则，会出现[xml/qxml.o]错误

• 建立set-env文件

  export QTDIR=$PWD

  export PATH=$QTDIR/bin:$PATH

  export MANPATH=$QTDIR/doc/man:$MANPATH

  export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

  echo yes | ./configure -no-xft -no-opengl -no-sm

  make

• 在该文件夹下，执"source set-env"命令（.与set-env之间有空格）

（2）编译目标机版本的qte-2.3.7

• 为了编译QTOPIA，将QTOPIA文件夹下./src/qt/qconfig-qpe.h拷贝到QTE文件夹下 src/tools/

• 然后建立set-env文件

  #!/bin/bash

  #编译QTE脚本

  #此处$PWD指的是QTE所在的文件夹

  export QTDIR=$PWD

  export QTEDIR=$QTDIR

  export PATH=$QTDIR/bin:$PATH

  export PATH=/usr/local/arm/2.95.3/bin:$PATH

  export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

  echo yes | ./configure -platform linux-x86-g++ -xplatform linux-arm-g++ -qconfig qpe -depths 16,24,32

  make

• 执行"source set-env"

• 注意，在此处configure时，一定要写明platform及xplatform，且platform要设为linux-x86-g++，否则当使用linux-generic-g++时，会找当前系统默认的g++，由于前面在PATH处设定新的g++路径，所以会出现错误。

• 如果需要移植到目标机上，则将$QTEDIR/lib/libqte.so.x.y.z拷贝至目标机上lib文件夹下，并命名为/lib/libqte.so.x（根据前面的libqte编号而定）;

  将$QTEDIR/lib/fonts/fontdir拷贝到目标机上qt/e的安装路径上（通过在目标机上设置$QTDIR来实现），如/usr/local/qt-embedded/lib/fonts/fontdir

（3）编译目标机版本的qtopia-1.7.0

• 由于在编译qtopia时，需要用到QTE的uic命令来解释有关的资源，所以此处，需要将前面编译的qt-x11中bin目录下的uic命令拷贝至QTEDIR/bin下。

• 建立set-env文件：

  #!/bin/bash

  #安装QTOPIA

  export QPEDIR=$PWD

  #此处的QTDIR是前面编译的QT/E的路径

  export QTDIR=/friendly-arm/arm-qtopia/qt

  export QTEDIR=$QTDIR

  #本机工具链的位置，根据个人情况设置

  export PATH=/usr/local/arm/2.95.3/bin:$PATH

  export PATH=$QTDIR/bin:$PATH

  export PATH=$QPEDIR/bin:$PATH

  export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

  cd ./src

  echo yes | ./configure -platform linux-arm-g++

  make

• 执行"source set-env"

• 如果需要移植到目标机上，将QPEDIR目录下的bin, apps, etc, plugins, services, sounds, i18n, lib, pics, help文件夹拷贝到目标机上的QPEDIR处（通过设置QPEDIR来实现）

• 在目标机的bin目录下，建立qtopia脚本文件（如下）

  #!/bin/sh

  export set HOME=/root

  export set QTDIR=/opt/qt

  export set QPEDIR=/opt/qtopia

  export set QWS_KEYBOARD="USB:/dev/input/event1"

  export set QWS_MOUSE_PROTO="USB:/dev/input/mouse0"

  export set PATH=$QPEDIR/bin:$PATH

  export set LD_LIBRARY_PATH=$QTDIR/lib:$QPEDIR/lib

  $QPEDIR/bin/qpe > /dev/null 2>/dev/null

• 在目标机启动后，就可以使用qtopia直接启动

gcc -v ：GCC版本

-c：仅把源代友编译为目标代码；

-s：GCC在为C代码产生了汇编语言文件后，就停止编译。GCC产生的汇编语言文件的缺省扩展名为.s。

-E：指示编译器仅对输入文件进行预处理。此时，预处理器的输出被送到标准输出（如显示器）而不是储存在文件里。

-O：GCC对源码进行基本优化。

-O2：GCC产生尽可能小和尽可能快的代码

-g选项告诉GCC产生能被GNU调试器（如gdb）使用的调试信息，以便调试用户的程序。

-pg选项告诉GCC在用户的程序里加入额外的代码，执行时，产生gporf用的剖析信息以显示程序的耗时情况。

gcc info page：详细GCC编译器参数的说明，在Emacs内，按下C－hi，然后选“gcc”的选项。

2、使用gdb：

gdb filename：能直接指定想要调试的程序。也可用gdb去检查一个因程序异常终止而产生的core文件，或者与一个正在运行的程序相连。

（1）为使gdb正常工作，必须使程序在编译时包含调试信息。调试信息包含程序里的每个变量的类型、在可执行文件里的地址映射以及源代码的行号。

（2）gdb命令一览：

file：装入想要调试的可执行文件

kill：终止正在调试的程序；

list：列出产生执行文件的源代码的一部分

next：执行一行源代码但不进入函数内部；

step：执行一行源代码而且进入函数内部；

run：执行当前被调试的程序；

quit：终止gdb

watch：能监视一个变量的值 而不管它何时被改变；

print：显示表达示的值；

break：在代码里设置断点，这将使程序执行到这里时被挂起；

make：不退出gdb就可以重新产生可执行文件

shell：不离开gdb就执行UNIX shell命令

（3）可在gdb中按Tab键让gdb补齐一个命令。