以后可能不会再继续做视频压缩方面的东东了，所以在对jsvm、jm、rm、sm等暂时告别之际，不舍之情还是有一些的，平时学习的资料可能到最后压个盘，也不会再拿出来好好的研究学习了，在ksarea里面放着或许还会偶尔翻翻。不管怎样，相信这段学习的经历永远是偶一笔不小的财富。

本人学习jsvm的时间不长，但是感触还是有一些的。在正式看jsvm代码之前，做了一段时间的理论学习工作，当然主要是针对可伸缩视频编码技术。在后期看代码的时候，才发觉得前段时间的理论学习是很重要的。看jsvm的速度完全取决于你对可伸缩编码技术的了解程度和对c++编程的熟练程度，当然，后者相对而言次要些，但是如果你要在jsvm上做一定修改的话，那么后者就显得相当重要了。

下面本人就自己对jsvm的认识做一个简单的介绍。由于当时看jsvm代码也不到1个月，所以认识很浅，文字也不够深入或许还存在一些认识上的错误，但本人的初衷是好的，希望能对读者有个抛砖引玉的作用吧，呵呵。

Jsvm里面工程很多，主要包括：编码、解码、采样、码流截取等等。在此主要面向编码部分。

• 首先从编码的配置文件说起吧，包括encoder.cfg 和 layer-i.cfg 。encoder.cfg 里面主要设置的是：输出文件名、待编码的帧数、帧率、质量增强层使用何种粒度大小、运动补偿参考帧是否采用增强层、GOP大小、I帧插入间隔、参考帧数目、基本层编码模式和运动搜索、环路滤波、空域增强层相关的配置情况等等，而layer-i.cfg主要是对空域可伸缩而言，layer0就是基本层了，其他的是逐步递增的空域增强层。其实在配置文件中，对时域、空域和质量都有设置，只是空域可伸缩的设置参数是单独拿出来的，而时域和质量的主要在encoder里面（时域->MCTF）。在layer-i.cfg中，就和普通的sm及jm的配置差不多了，基本上就是此层的输入文件大小、输入文件名、重建文件名、输入输出帧率、QP之类的，不同的是多了：NumFGSLayers、FGSMotion、InterLayerPred和BaseQuality，分别表示细粒度可伸缩层（即质量增强层）的层数、是否在FGS层中的改善运动矢量、本层是否采用向下的层间预测、本层基本质量层的质量级别（貌似是针对质量分层而言）。

• 然后再说说编码器里几个主要的类的定义：

在InputPicBuffer.h头文件中定义了class InputAccessUnit和class InputPicBuffer。

在SequenceStructure.h头文件中定义了class FrameSpec、class FormattedStringParser 和class SequenceStructure

其中，class SequenceStructure主要包括：

{

private:

定义自己的成员变量。。。。

定义class FrameDescriptor {}

定义class SequencePart {}

定义class FrameSequencePart : public SequencePart {}

其中FrameSequencePart公有继承于SequencePart，又自己增添了一些私有成员变量：

Bool m_bInit;

FrameDescriptor* m_pacFrameDescriptor;

UInt m_uiNumberOfFrames;

UInt m_uiCurrentFrame;

UInt m_uiNumberOfRepetitions;

UInt m_uiCurrentRepetition;

UInt m_uiMinDPBSizeRef;

UInt m_uiMinDPBSizeNonRef; 和一些公有成员函数。

定义class GeneralSequencePart : public SequencePart

其中GeneralSequencePart公有继承于SequencePart，又自己增添了一些私有成员变量：

Bool m_bInit;

SequencePart** m_papcSequencePart;

UInt m_uiNumberOfParts;

UInt m_uiCurrentPart;

UInt m_uiNumberOfRepetitions;

UInt m_uiCurrentRepetition;

UInt m_uiMinDPBSizeRef;

UInt m_uiMinDPBSizeNonRef; 和一些公有成员函数。

}

在GOPEncoder.h头文件中定义了class AccessUnit、class AccessUnitList、class MCTFEncoder和class PicOutputData ，其中class PicOutputData是模板类MyList的一个实例化对象：

typedef MyList<PicOutputData> PicOutputDataList;

在 h264AVCommonIf.h 中，定义模板类MyList，公共继承于std的list类。MyList中有popBack popFront pushBack pushFront find 函数及重载了+=操作符。

template< class T >

class MyList : public std::list< T >

{

public:

typedef typename std::list<T>::iterator MyIterator;

MyList& operator += ( const MyList& rcMyList)

{

   if ( ! rcMyList.empty() )

   { insert( this->end(), rcMyList.begin(), rcMyList.end());}

   return *this;

}

T popBack()

   { T cT = this->back(); this->pop_back(); return cT; }

T popFront()

   { T cT = this->front(); this->pop_front(); return cT; }

Void pushBack( const T& rcT )

   { if( sizeof(T) == 4) { if( rcT != NULL ){ push_back( rcT);} } }

Void pushFront( const T& rcT )

   { if( sizeof(T) == 4) { if( rcT != NULL ){ push_front( rcT);} } }

MyIterator find( const T& rcT )

   { return std::find( this->begin(), this->end(), rcT ); }

};

这个模板类通用于整个编解码过程当中，通过用不同类实例化此模板，从而可以得到编解码过程中所需要的所有列表。比如：参考帧列表、输入/输出列表、质量分层列表、及SEI信息列表等等。在这里：typedef MyList<PicOutputData> PicOutputDataList; 是定义了图像输出数据的链表。

在PicEncoder.h头文件中定义了class PicEncoder ；

在SliceEncoder.h头文件中定义了class SliceEncoder；

在MbCoder.h头文件中定义了class MbCoder；

在MBEncoder.h头文件中定义了class MbEncoder

class MbEncoder : protected MbCoder , public UvlcWriter , protected BitCounter

MbEncoder 保护继承于MbCoder，MbCoder的public 和protected成员都是MbEncoder的保护成员；MbEncoder 公共继承于UvlcWriter，UvlcWriter的public 和protected成员分别是MbEncoder的公共成员和保护成员；MbEncoder 保护继承于BitCounter，BitCounter的public 和protected成员都是MbEncoder的保护成员；

在CodingParameter.h头文件中定义了class CodingParameter、class EncoderConfigLineBase、class LayerParameters、class SampleWeightingParams 和class CodingParameter。

当然，jsvm里面的类是相当的多的，这里只是提出一部分比较重要的类拿出来说说。

• 接下来说说JSVM编码器的一些主要函数

Main函数：  （ H264AVCEncoderLibTest.cpp ）

主要部分是H264AVCEncoderTest 类对象指针pcH264AVCEncoderTest所指的go ()函数，在 H264AVCEncoderTest .cpp有函数原型。

Go函数 主要分为8部分：

1. 初始化

2. 写参数信息

3. 进入layer循环，输入必要的参数信息：

for( uiLayer = 0; uiLayer < uiNumLayers; uiLayer++ )

4. 开始一个帧一个帧的编码：

for( uiFrame = 0; uiFrame < uiMaxFrame; uiFrame++ )

{

    4-1 编码每一个帧时，layer循环 获取缓存存储图像，并且读入每个layer的帧信息：

    for( uiLayer = 0; uiLayer < uiNumLayers; uiLayer++ )

    {  m_apcReadYuv[uiLayer]->readFrame（。。。。。） }

    4-2 开始编码：m_pcH264AVCEncoder->process（。。。。。。）

    4-3 写每一帧编码后的传输单元NAL unit，并且释放临时缓存；

    4-4 写每一帧编码后的重建图像，并且释放临时缓存；

}

5. 结束编码

6. 写所有帧编码后的传输单元NAL unit，并且释放临时缓存

7. 写所有帧编码后的重建图像，并且释放临时缓存

8. 计算输出显示的参数信息，比如psnr值等等。

Process 函数，主要分为：  （PicEncoder.cpp）

===== fill lists =====

for( UInt uiLayer = 0; uiLayer <= uiHighestLayer; uiLayer++ )

判断编码模式，如果是AVC模式的话：（是否是AVC模式由编码配置文件encoder.cfg中的BaseLayerMode 项值决定）

则运行函数：m_pcPicEncoder ->process //见下面PicEncoder::process函数

否则：

运行函数m_pcH264AVCEncoder->process //见下面H264AVCEncoder::process函数

PicEncoder::process函数： （PicEncoder.cpp）

1. 输入图片信息

2. 编码图片头信息等

3. 得到下一帧

4. 初始化图像

5. 编码

6. 存储图像

H264AVCEncoder::process函数： （H264AVCEncoder.cpp）

1. 输入当前GOP信息

2. 编码当前GOP （运行函数：xProcessGOP）

3. 更新图像列表

xProcessGOP( apcPicBufferOutputList, apcPicBufferUnusedList )函数：（H264AVCEncoder.cpp）

1. 初始化GOP

2. 在GOP范围内获取每一层的可获得的信息单元，并且编码：

for( uiAUIndex = 0; uiAUIndex <= 64; uiAUIndex++ )

{

    for( uiLayer = 0;

           uiLayer < m_pcCodingParameter->getNumberOfLayers(); uiLayer ++ )

    { m_apcMCTFEncoder[uiLayer]->process（。。。。） 。。。。}

}

3. 更新图像缓存列表

for( uiLayer = 0; uiLayer < m_pcCodingParameter->getNumberOfLayers(); uiLayer++ )

{

    //—– set output list —–

    //—– update unused list —–

    //—– reset lists —–

}

MCTFEncoder::process函数： （GOPEncoder.cpp）

1. 初始化相关参数

2. 更新更高层图像（我认为：在编码一个GOP，特别是使用FGS技术时，为了提高编码效率，编码帧有时是需要参考已编码帧的高质量重建图像的，那么就需要在编码之前，整理好已编码重建帧的高质量图像，即需要更新更高层图像）

3. 编码此GOP内的anchor帧（即判断此帧是否是anchor帧，若是，则进入；若不是则进入4步骤），其中最主要的是xEncodeKeyPicture函数（后续介绍）

4. 编码此GOP内的非anchor帧，其中最主要的是xEncodeNonKeyPicture函数（后续介绍）

5. 结束GOP编码

在MCTFEncoder::xEncodeKeyPicture和MCTFEncoder::xEncodeNonKeyPicture函数中（GOPEncoder.cpp）比较主要的是xEncodeLowPassSignal、xEncodeHighPassSignal、xEncodeFGSLayer等函数。这些函数都是GOP层面的，至于其中的具体过程就不再一一的描述了。

在jsvm里面，虽然编码过程很复杂（因为可伸缩的算法本身就比较复杂），但是最底层的MB结构还是和普通的单层编码结构一样的，序列－－＞GOP－－＞frame－－＞slice－－＞Mb。只是在编码的过程中分了很多种情况，首先编一个frame时，除了考虑它是哪种类型（I/P/B）的帧外，还要考虑它在时域中（即GOP内）的位置情况：看它是不是anchor帧（GOP内第一个anchor帧应该是I帧，那么不参考其他帧编码，而第二个anchor帧可以是P帧或I帧，若是P帧，则要参考本GOP内前面anchor帧的重建图像），若不是anchor帧，则参考帧也必须在此GOP以内，为的是防止误差传递（这个属于参考帧管理的内容）；除了考虑时域外，还要同时考虑此帧是属于哪个空域层的，编码Mb时看是否需要做层间预测（此处说的层间预测包括-宏块划分方式层间预测、运动矢量层间预测和编码残差层间预测等）；最后还要考虑质量可伸缩问题（即FGS，这块本人不了解，所以就不深入了）。

• 另外，对于jsvm编码后的码流大小和普通的jm码流大小基本对比如下：

    （前提条件是 参数设置基本相同）

① svc码流 (cif +qcif)

② 单层的 h264码流 (cif)

③ h264的simulcast (cif+qcif)

通常是： ① * 1.3 ≈ ③   ；   ② * 1.1 ≈①    ；   ② * 1.43 ≈③

先写到此为止吧，写了这么多，真够累的。

本文应该尚未结束，我想。 呵呵， 待日后更新吧。

VisioWave公司是一家在智能视频安防领域居于世界领先地位的厂商，专注于数字图像处理和传输，设计建立了一套优秀的智能视频安防系统的体系架构，并围绕着这套优秀的体系架构开发出了相应的软硬件产品。视频监控系统智能化的前提条件是网络化和数字化。 VisioWave的解决方案就是完全构架在网络之上的，彻底摆脱了传统视频监控系统，甚至是普通产品的限制，视频流可以在整个系统的范围内自由地被调度、使用和管理，具备了前所未有的灵活性。智能视频监控系统对视频图像的数字化也提出了全新的要求。目前数字监控产品普遍采用了针对媒体市场开发的视频压缩标准，但是由于不具备可伸缩性，这类视频压缩标准恰恰不适合应用在视频监控领域，例如在大屏幕上监看需要很好的图像质量，进行自动图像分析却只需要较低质量的图像，这就要求视频压缩算法具备可伸缩性，即一个编码器能同时输出不同分辨率、不同帧率的视频流或者一路视频流可以同时被解码为不同分辨率、不同帧率的图像，否则就需要消耗巨大的计算能力、网络资源和存储空间才能实现上述功能，从而导致系统造价大幅上扬，客户难以承受。

VisioWave的产品全部采用了可伸缩视频压缩算法，这正是能够成功构建多个超大规模智能视频监控系统的前提条件。可伸缩视频压缩算法克服了针对媒体市场开发的视频压缩标准所具有的高品质图像与低编码延时不可兼得的缺点，使得值班人员从此可以自如地查看摄像头的高品质图像。

以下将详细阐述可伸缩视频压缩算法的应用情况：
VisioWave采用可伸缩视频压缩技术，先后赢得巴黎、纽约、伦敦三大地铁的智能视频安防项目，其中纽约地铁项目摄像头的数量达到了惊人的25000多个，安装在纽约227个地铁站；伦敦地铁在2005年7月完成了对其2500个CCTV监控系统价值3070万美元的升级，并且继续增加投资，用于增加智能视频监控系统。巴黎地铁系统计划部署一个低风险、功能强大的、高效率的视频监控系统。选择visiowave的首先是因为Visiowave是能够真正实现完全分布式构建、提供高质量数字视频监控的解决方案；更为重要的是Visiowave的解决方案能够完全符合巴黎地铁苛刻的需求。VisioWave还将可伸缩视频压缩技术运用与车载视频安防系统中，成为了世界上最大的车载视频安防系统供应商。

在巴黎RATP（法国地铁公司）项目中，visiowave的车载视频安防产品装备了近4000辆公共汽车和轻轨列车，管理着23000多个车载摄像头。多伦多国际机场采用了基于可伸缩视频压缩技术的智能视频安防解决方案，成为了新一代数字化机场的典范Visiowave的先进技术让Pearson机场的千兆网络能够被最大程度的优化使用。合理的网络应用、工业级的设备支持，让如此高复杂度的系统能够表现出几近完美的图像。其数字化视频监控方案无论对机场的旅客还是工作人员来说，都极大地改善了安全保障能力和服务质量。得益于它开放式的架构设计，使其能够非常方便地和AVLogic的视频管理系统（VMS）集成，从而获得了全方位的安防体系！

渥太华机场、苏黎世机场、斯德哥尔摩机场以及伦敦机场都采用了基于可伸缩视频压缩技术的VisioWave智能视频安防解决方案。为了减少城市的犯罪率以及违法行为的发生率，法国安纳西的地方议会在城市的中心地区部署了一套视频监控系统。出于对投资经济型以及系统可扩展性的综合考虑，地方当局决定选择分布式的数字视频监控技术，依托安纳西的千兆城域网来构建一个完整的视频监控系统。

法国安纳西的数字化城市监控系统成功的使用了Visiowave SDK定制的专用软件，有效地进行城市监控管理和预防性监控工作。

Barco公司（葡萄牙最大的公路运营商）和VisioWave 技术小组携手推出了新一代数字化视频监控中心，使其具有了同时对96路实况视频流进行监控的能力。中心使用了450个VisioBox，500台PTZ摄像机。公司为什么要选择visiowave？因为它可以提供高质量的实时数字视频系统，其体系架构具有十分优秀的可扩展性、基于IP的能力、还内置视频存储管理能力等。除此之外，最关键原因在于Visiowave具有可伸缩性能力的视频压缩技术，具有进一步的衍生能力，诸如通过转码形成低码率的适合Internet访问的视频流，使新一代的全数字的控制中心建设成为可能（全部采用软件解压技术）。

很多欧洲国家的高速公路、大型场馆、城市监控也纷纷采用了此智能视频安防解决方案，此外诸如摩托罗拉、空中客车、雷诺、雀巢等大型企业也是VisioWave产品的忠实客户。
VisioWave之所以能够具备如此大的影响力、成为全球化的超大规模智能视频安防厂商，与它产品所采用的核心技术是分不开的，而可伸缩视频压缩技术就是其核心技术之一。

前段时间依依不舍的从JSVM程序里钻出来，被迫要求快速掌握RM52j的程序。

其实从一个复杂庞大的程序到一个比较而言相对简单些的程序里，应该很快，但是以前的jsvm中有关预测和估计的细节部分没有完全的明白彻底，再加上RM里面太多难以理解的东西，容易误导人（说实话吧，因为RM是借用人家国外人的框架，修改部分的细节，性能比不上不说，还存在bug），所以看到现在才算完全的弄明白。

弄懂后又在是否做weighting prediction的问题上纠缠了2天，感觉这一块没得做了……正打算放弃的时候被组长教导了一番，呵呵。反思一下觉得说的确实也是：首先做研究就是要沉住气、静得下心，不能做到一半就轻易的放弃；第二任何决定和结论都要用事实说话，哪块可以做？哪块不可以做？都要做大量的测试、通过比较实验结果后才能下结论。被教导一番后自己心中也是觉得挺惭愧的。于是决定好好的先做实验，起初做实验是打算在小组讨论时用实验报告来证实自己的想法的，没有想到的是测试了序列之后居然发现这块还是有研究价值的，呵呵（再次应验她说的话很有道理～心中甚是崇拜加感谢～～）于是开始查找文献，看看别人是怎么在这块做创新的，发现有关加权预测的论文不怎么多。不过说实话，这一部分也确实不怎么好做，到现在还没有找出一条比较清晰的思路来，马上周五又要小组讨论了，其实自己心里确实是像做出点东西出来的，但是为什么就是没有那种思如泉涌的感觉呢？

现在才感觉到自己底气不足呀……思路很不开阔，容易受限制。可能最根本的原因还是自己论文看少了，本来就应该是厚积薄发的过程，没有平时的积累导致现在就没有灵感。

K说我不管怎么样，现在也要硬着头皮的把事情做完。想想确实也是的，只要自己好好搞，不管最后结果怎么样，自己都会有收获的。再不能象现在后悔以前没有好好看论文一样了，以前没有好好看当时肯定也是有各种各样的原因，但是不管什么原因都是自己没有全力以赴的学习，所以现在要克服这种浮躁心理，否则永远只能后悔以前没有做好，后悔以前不应该怎样怎样……

昨天应该小庆一番的，因为BitStream Switch的程序算实现出来啦。虽然先前计划demo版还没有完全弄好，但是第一阶段的任务算是完成了。呵呵，昨天下午的时候小组开了一个小会，看得出来上级对我的努力还算比较满意的吧……真高兴～ 接下来估计要对H.264的JSVM暂时离别一阵子了，经过这段时间和H.264的亲密接触，发现她越来越美丽了，哈哈……开始喜欢上她了，不过我现在对她的了解还算浅，等着把接下来提案的事情弄完再继续吧～还真有点舍不得呢……

从今天开始就要进入AVS的代码了，又要开始忙了呀……要提新思路，还要在5.0上实现，如果最后能够成功的话还要托给专门的单位做交叉测试。AVS是用c写的，哎，刚刚适应了c++的思维模式，总结出一套使用类的方法，又要跑到c上面来。不过过年的那段时间JM看得挺多的，估计AVS的程序和JM 差不多，算是有备而攻吧。（呵呵，又是自己组建的小词～）

喜欢这样的学习和生活，在别人眼里无比枯燥的事情却是我每天快乐的源泉之一。而且天天都可以和k在网上见面，偶尔的他还会来学校看看俺，that’s enough~

我发觉：当你沉下心来接受和慢慢了解所要面临的事物的时候，你都可以看到她真实美丽的一面的，不信你试试？

—-S

h.264的技术亮点
1、分层设计
h.264的算法在概念上可以分为两层：视频编码层（vcl：video coding layer）负责高效的视频内容表示，网络提取层（nal：network abstraction layer）负责以网络所要求的恰当的方式对数据进行打包和传送。在vcl和nal之间定义了一个基于分组方式的接口，打包和相应的信令属于nal的一部分。这样，高编码效率和网络友好性的任务分别由vcl和nal来完成。
vcl层包括基于块的运动补偿混合编码和一些新特性。与前面的视频编码标准一样，h.264没有把前处理和后处理等功能包括在草案中，这样可以增加标准的灵活性。
nal负责使用下层网络的分段格式来封装数据，包括组帧、逻辑信道的信令、定时信息的利用或序列结束信号等。例如，nal支持视频在电路交换信道上的传输格式，支持视频在internet上利用rtp/udp/ip传输的格式。nal包括自己的头部信息、段结构信息和实际载荷信息，即上层的vcl数据。（如果采用数据分割技术，数据可能由几个部分组成）。
2、高精度、多模式运动估计
h.264支持1/4或1/8像素精度的运动矢量。在1/4像素精度时可使用6抽头滤波器来减少高频噪声，对于1/8像素精度的运动矢量，可使用更为复杂的8抽头的滤波器。在进行运动估计时，编码器还可选择”增强”内插滤波器来提高预测的效果。
在h.264的运动预测中，一个宏块（mb）可以按图2被分为不同的子块，形成7种不同模式的块尺寸。这种多模式的灵活和细致的划分，更切合图像中实际运动物体的形状，大大提高了运动估计的精确程度。在这种方式下，在每个宏块中可以包含有1、2、4、8或16个运动矢量。
在h.264中，允许编码器使用多于一帧的先前帧用于运动估计，这就是所谓的多帧参考技术。例如2帧或3帧刚刚编码好的参考帧，编码器将选择对每个目标宏块能给出更好的预测帧，并为每一宏块指示是哪一帧被用于预测。
3、4×4块的整数变换
h.264与先前的标准相似，对残差采用基于块的变换编码，但变换是整数操作而不是实数运算，其过程和dct基本相似。这种方法的优点在于：在编码器中和解码器中允许精度相同的变换和反变换，便于使用简单的定点运算方式。也就是说，这里没有”反变换误差”。 变换的单位是4×4块，而不是以往常用的8×8块。由于用于变换块的尺寸缩小，运动物体的划分更精确，这样，不但变换计算量比较小，而且在运动物体边缘处的衔接误差也大为减小。为了使小尺寸块的变换方式对图像中较大面积的平滑区域不产生块之间的灰度差异，可对帧内宏块亮度数据的16个4×4块的dc系数（每个小块一个，共16个）进行第二次4×4块的变换，对色度数据的4个4×4块的dc系数（每个小块一个，共4个）进行2×2块的变换。
h.264为了提高码率控制的能力，量化步长的变化的幅度控制在12.5%左右，而不是以不变的增幅变化。变换系数幅度的归一化被放在反量化过程中处理以减少计算的复杂性。为了强调彩色的逼真性，对色度系数采用了较小量化步长。
4、统一的vlc
h.264中熵编码有两种方法，一种是对所有的待编码的符号采用统一的vlc（uvlc ：universal vlc），另一种是采用内容自适应的二进制算术编码（cabac：context-adaptive binary arithmetic coding）。cabac是可选项，其编码性能比uvlc稍好，但计算复杂度也高。uvlc使用一个长度无限的码字集，设计结构非常有规则，用相同的码表可以对不同的对象进行编码。这种方法很容易产生一个码字，而解码器也很容易地识别码字的前缀，uvlc在发生比特错误时能快速获得重同步。
5、帧内预测
在先前的h.26x系列和mpeg-x系列标准中，都是采用的帧间预测的方式。在h.264中，当编码intra图像时可用帧内预测。对于每个4×4块（除了边缘块特别处置以外），每个像素都可用17个最接近的先前已编码的像素的不同加权和（有的权值可为0）来预测，即此像素所在块的左上角的17个像素。显然，这种帧内预测不是在时间上，而是在空间域上进行的预测编码算法，可以除去相邻块之间的空间冗余度，取得更为有效的压缩。
如图4所示，4×4方块中a、b、…、p为16 个待预测的像素点，而a、b、…、p是已编码的像素。如m点的值可以由（j＋2k＋l＋2）/ 4 式来预测，也可以由（a+b+c+d+i+j+k+l）/ 8 式来预测，等等。按照所选取的预测参考的点不同，亮度共有9类不同的模式，但色度的帧内预测只有1类模式。
6、面向ip和无线环境
h.264 草案中包含了用于差错消除的工具，便于压缩视频在误码、丢包多发环境中传输，如移动信道或ip信道中传输的健壮性。为了抵御传输差错，h.264视频流中的时间同步可以通过采用帧内图像刷新来完成，空间同步由条结构编码（slice structured coding）来支持。同时为了便于误码以后的再同步，在一幅图像的视频数据中还提供了一定的重同步点。另外，帧内宏块刷新和多参考宏块允许编码器在决定宏块模式的时候不仅可以考虑编码效率，还可以考虑传输信道的特性。
除了利用量化步长的改变来适应信道码率外，在h.264中，还常利用数据分割的方法来应对信道码率的变化。从总体上说，数据分割的概念就是在编码器中生成具有不同优先级的视频数据以支持网络中的服务质量qos。例如采用基于语法的数据分割（syntax-based data partitioning）方法，将每帧数据的按其重要性分为几部分，这样允许在缓冲区溢出时丢弃不太重要的信息。还可以采用类似的时间数据分割（temporal data partitioning）方法，通过在p帧和b帧中使用多个参考帧来完成。
在无线通信的应用中，我们可以通过改变每一帧的量化精度或空间/时间分辨率来支持无线信道的大比特率变化。可是，在多播的情况下，要求编码器对变化的各种比特率进行响应是不可能的。因此，不同于mpeg-4中采用的精细分级编码fgs（fine granular scalability）的方法（效率比较低），h.264采用流切换的sp帧来代替分级编码。

h.264的性能比较
tml-8为h.264的测试模式，用它来对h.264的视频编码效率进行比较和测试。测试结果所提供的psnr已清楚地表明，相对于mpeg-4（asp：advanced simple profile）和h.263++（hlp：high latency profile）的性能，h.264的结果具有明显的优越性。
h.264的PSNR比mpeg-4（asp）和h.263++（hlp）明显要好，在6种速率的对比测试中，h.264的psnr比mpeg-4（asp）平均要高2db，比h.263（hlp）平均要高3db。6个测试速率及其相关的条件分别为：32 kbit/s速率、10f/s帧率和qcif格式；64 kbit/s速率、15f/s帧率和qcif格式；128kbit/s速率、15f/s帧率和cif格式；256kbit/s速率、15f/s帧率和qcif格式；512 kbit/s速率、30f/s帧率和cif格式；1024 kbit/s速率、30f/s帧率和cif格式。

—-S

最近两天在一心一意的弄代码，真想早点把BitStream Switch的demo版弄出来，大家也都期待着呢……哎……心里挺佩服那些完成h.264标准的人的，不愧为牛人呀！不过自己现在每天也都有一些大大小小的进展拉，争取这个月能够搞定呀，最少也要弄个85%出来，还有20天，加油！！到时候和k一起去好好的庆祝一番，去吃韩国烧烤好了！就这样定拉～嘿嘿，给自己增加一点动力，哈哈 ～

—-S