标题：H.263视频编码
应用
应用程序视频会议和视频电信有很广泛的程序应用，包括：桌面环境或室内环境下的会议系统通过Internet或电话线路实现的视频通信电子监视和操作运程医疗（在运程进行医学咨询和诊断）基于计算机的培训与教育在每种应用中，视频信息（也许与音频信息一块儿）被通过电信通讯联接传输，包括网络，电话线路，ISDN和广播的形式。视频有宽频的特征（比如说每秒很多字节）这些，这些应用就需要对视频进行压缩或是进行编码来在传输之前降低带宽值。
视频编码
在源端视频信息帧被捕捉并被通过视频编码器进行编码。压缩的注被通过网络或是电信联接传输走，并在视频解码端进行解码。解码过的帧就可以被显示了。
设定
263系统有很多的视频编码的标准，它们每个都是为了特定的应用而设定：比如说，JPEG是为静态图片设定的，MPEG2是为数字电视信号设定的 ,H.261是为ISDN视频会议系统设定。H.263是特别面向低码率的视频编码而设定的(通常只有20-30kbps或更高) H.263标准指明了对于视频编码和解码器的需求。它不描述编码器和解码器自身：取而代之的是，它指明了编码流的格式与内容。一个典型的解码器和编码器被在这时描述出来。我们跳过过了很多的H.263的细节，比如说语法和编码模式

估计和补偿
H.263编码器运动估计和补偿降低带宽的第一步就是从当前帧中减去之前传输的帧，这样只有差值或叫残差值才被编码并传输。这就意味着帧中没有变化的内容就不被 编码。我们通过试图对于当前帧的内容的移动进行估计并补偿这个运动值来实现更高的压缩比。运动估计模块通过在当前帧中和在前些帧中周围的区域比较每个16*16的像素块(宏块)，并试图找到一个匹配的帧。匹配的区域从当前的宏块位置中由运动补偿模块删除掉。如果运动估计和补偿过程很有效率的话，剩余的宏块应该只包含很少量的信息。
离散余弦变换(DCT) DCT把一块像素值(或剩余帧值)变换到一系列“频域"系数中。这就好像利用快速傅里叶变换(FFT)把一个信号从时域转变到频域中一样的。 DCT在一个二维的像素块上(而不是一个一维的信号)进行操作，它尤其长于把块中的能量压缩到一系列的系数中去。这就意味着，通过很少量的DCT系数，我们就可以重建一个原始像素块的拷贝。 
量化对于一个典型的像素块来说，用DCT得到的大多数的系数都是接近于0的。量化器模块降低了每个系数的准确性，这样近似于0的值就被置 0，而且只有一些非0值留下来了。实际操作中，我们通过整数级因子来划分系数值，并截去结果。很重要的一点是我们在量化过程中“扔掉”了一些信息。
熵编码 一个熵编码器（比如说Huffman编码器）把常出现的值用更短的二进制码来表示，并且把不常出现的值用长一些的二进制码进行表示。 H.263中的熵编码是基于这个技术的，并被用来压缩量化后的DCT系数的。这个结果是一个序列的变长二进制。这些码组合起来用来同步和控制信息（比如重建运动补偿的参考帧时需要的运动向量)，用以进成编码的H.263码流。帧存储当前帧必须被存储掉，这样，它才可以在下一帧编码的时候被用做参考帧。我们不是简单地把当前存存储起来，而是把逆量化的量化因子，用逆DCT操作后的反变换以及用来重建一帧的加到运动补偿的参考块信息存放在存储区中。这就确保了在编码器端帧存储区中的内容与在解码器的存储区中的内容是相同的。当下一帧被编码的时候，运动估计使用帧存储区中的内容来决定运动补偿的最佳匹配区域。
原理
H.263解码器熵解码为了解压出系数值和运动向量信息，组成H.263码流的变长的编码被进行解码 重调节这是量化过程的反过程：系数被乘以一个在编码端量化器同样的标量因子。然而，因为量化器丢弃了小的因子，重调节之后的系数值不再同原始的系数值相等。 逆DCT IDCT是DCT过程的反变换。它构建了一块采样值：它们对应于编码器端运动补偿生成的差值。 运动补偿 差值被加到前一帧来重建区域信息。运动向量信息用来选择正确的区域（在编码器中使用相同的参考帧）。结果是一个原始帧的重建：注意它将与原始帧不同，因为量化过程是有损的。也就是说图像的质量会比原始帧差一些。重建的帧被放于一个帧存储区，而且它被用于对下一个接收到的帧进行运动补偿。
实现
实现途径实时的视频通信在实时情形下开发一个可以有效工作的视频编码和编码器时,有很多问题是要被说明的,包括: 码率控制 实际的通信信道对于每秒钟它们可以处理的能力有限度.在很多种情形下,码率是一个定值(比如说POTS,IDSN等) H.263编码器的基础是对于每个编码的帧生成一个变的码值.如果运动估计/补偿过程工作正常的话,那么就有更少的非0系数被用来编码. 然而,如果运动估计工作不那么正常的话(比如说当视频场景中包括复杂的运动时),就会有很多的非0系数来被编码.这样编码的值会增加. 为了映射这个可变的码率值到一个CBR(固定码率值)信道,编码器必须进行码率控制.编码器计算编码器输出的码率.如果它太高的话,它会通过增加标量化因子来提高压缩率:这会导致更高的压缩比(码率会更低),但也同时在解码器给出了更低的画质.如果码率下降的话,编码 器就通过降低量化器的标量化因子来进行压缩.这样会在解码端造成更高的友率和更佳的画质. 同步 编码器和解码器必须是同步的,特别是如果视频信号与音频信号一起的话.H.263码流包含了一定数目的"头"或叫标记:这些是特殊的记号用来标记解码器在当前帧的所处的位置.如果解码器失掉了同步,那么它就向前扫描下一个标记来重新同步并恢复解码.应该注意到甚至是很小的同步上的损失都会造成很严重的解码质量的问题.所以在这样一个充满了"嗓音"的传输环境中设计一个视频编码系统的时候必须非常小心. 音频和复用 H.263标准只描述了视频编码.在很多实际问题中,音频数据必须被压缩,传输和同步到视频信号中去.同步,复用和协议问题被像H.320 (基于ISDN的视频会议),H.324(基于POTS的视频电信)和H.323(LAN或基于IP的视频会议)这样的标准解决掉了.H.263提供了这些标准的视频编码方法.音频编码被很多标准所支持,包括G.723.1等.另外,相关的标准包含了像复用(H.223)和信号机制(H.245)软件实现像运动估计，变长编/解码和DCT这样的函数需要很大的处理能力来实现。然而，最近的处理器的发展，使得在Pentium级处理器实时地编解 H.263视频变成可能。 一个软件实现必须是高度优化的，来达到有效的视频质量（比如说，每秒多于10帧，352*288像素每帧）。这包括了一系列的操作比如说在计算密集处使用快速算法，最小化移动或拷贝操作并循环展开。在一些情况下，汇编代码会进一步加速运行（比如说使用Inter的MMX指令集）硬件实现像运动估计，变长编/解码和DCT这样的函数需要很大的处理能力来实现。然而，最近的处理器的发展，使得在Pentium级处理器实时地编解 H.263视频变成可能。 一个软件实现必须是高度优化的，来达到有效的视频质量（比如说，每秒多于10帧，352*288像素每帧）。这包括了一系列的操作比如说在计算密集处使对于高清晰的视频来说或当强大的处理器不存在的时候，硬件实现就是这个时候的解决方案了。一个典型的CODEC会对计算密集的部分使用专门的硬件逻辑来进行处理（比如说运动估计/补偿，DCT,量化器和熵编码），它们使用控制模块来定制事件顺序，并记录编码解码的参数。一个可编程的控制器是更佳的，因为很多的编码参数（比如说码率控制算法）可以通过适应不同的环境来进行修改或是调整。最近，一个 Intellectual Property中心对H.263提出了一个实现。一个逻辑核心是VHDL或者Verilog的设计，它可以与其他的功能模块组合而成为一个 ASIC或FPGA的一部分。