2．2 分析的步骤
    由于在视频传输的仿真中，需要将真实的视频流在仿真的网络环境中传输，因此必须对NS一2进行扩展与修改，添加视频传输仿真过程中所需的网络元素，包括代理的设计。本文利用文献中作者设计的3个代理MyTrafficTrace，MyUDP和 MyUDPSink。MyTraffic—Trace代理按照发送trace文件，在适当的时间发送分组给低层UDP，发送时间是根据视频帧发送率在trace文件中设定的。MyUDP是UDP代理的延伸，它记录每个传输分组的时间戳，分组id和分组大小。Myl5DPSink是接收代理，接收MyUDP发送的视频分组，这个代理在指定的文件中记录每个接收分组的时间戳、分组id和分组大小。另外，如果研究者需要验证其提出的传输策略，就要使用C++和OTcl对网络元素编程，并将其提出的策略加到网络元素中去，然后重新编译NS。在完成了对NS一2的扩展以后，就可以利用NS进行仿真。
2．2．1 产生仿真用的trace文件
    由于视频编码软件不能直接产生用来仿真的trace文件。因此需要将视频编码器产生的视频压缩文件转换成trace文件，trace文件的格式是<分组传送时间，分组标识，分组类型，分组大小>。转换的基本原理就是读取视频文件中的时间戳和分组的大小，并将这些信息存储到trace文件中。例如数据<O．066 667，id8，udp，407>，就是图像测试序列mother_daughter．yuv经编码后，产生的trace文件中的一组数据，表示在0．066 667 s发送大小为407 B、分组标识为id8的分组。
2．2．2 仿真配置
    (1)根据实际网络的要求，定义网络节点，配置网络拓朴结构，确定链路的基本特性，如延迟、带宽等。
    (2)建立协议代理，包括端设备的协议绑定和通信业务量模型的建立，将视频流和各种背景流绑定到代理中。配置业务量模型的参数，确定网络上的业务量分布。
    (3)设置Trace对象。Trace对象把仿真过程中发生的特定类型事件记录在trace文件中。NS一2通过trace文件保存整个仿真过程。仿真完成后，可以对trace文件进行分析研究。
    (4)编写其他的辅助过程，设定仿真结束时间，至此OTcl脚本编写完成，再用NS一2解释执行已编写的OTcl脚本，进行仿真。
2．2．3 对传输后视频文件的恢复与解码
    网络仿真器能为每个传输的分组产生相应的记录，仿真后产生trace文件，记录模拟过程的所有trace数据。通过MyUDPSink代理生成目标trace文件，它的格式是<分组到达时间，分组标识，分组类型，分组大小>。例如，数据<O．275093，id 8，udp，407>，就表示在上例中O．066 667 s发送的大小为407 B的分组id8在时刻O．275 093 s被接收到，若在目标trace文件中没有对应的分组数据说明该分组丢失。以下两组数据：<O．510840，idl3，udp，102>，<O．608045，id 14，udp，306>是分别对应于连续两帧图像的分组，由于两分组之间延时o．097 205 s超过了设定的帧间最大间隔，故在实时视频传输中分组14由于延时超过限制，将不能用来解码。
    可见根据目标trace文件就可以判断压缩视频分组中哪些分组要在传输过程中丢失，哪些分组因为延时超过了一定的限制而不能用来解码。基于这样的方法，可以从压缩视频文件中将传输丢失的分组和延时超过限制的分组丢弃，从而产生新的传输以后的视频压缩文件。解码器对该文件进行解码便得到重建视频，从而进行质量的评估。

3 实例分析
    图2所示是本文进行实例分析的视频传输系统的结构示意图，摄像机产生视频文件，通过节点S1适时传输到节点D1，中间通过节点R1和R2；节点S1带有1个CBR流量发生器，也通过中间节点R1和R2，向节点D2发送，作为影响视频传输的背景流。链路的带宽如图中标注所示。本实例仿真主要想说明CBR的背景流对视频传输质量的影响，从而论证本分析方案的可行性。

本例使用250帧的图像测试序列mother_daughter．yuv，利用JVT给出的参考模型JMl．7 H．264编码器进行编码，产生mother_daughter．264压缩视频文件，编写程序读取压缩视频文件，产生名为mother_daughter．trc的trace文件。按照图2配置网络拓扑结构，确定链路的基本特性。将视频trace文件注入NS一2部分代码如下：