玻璃瓶子

1 流媒体的概念
   
   　　数字视频和声音传输所涉及到的一个重要概念是所谓的"流媒体"概念。所谓流媒体是指视频、声音和数据从源端同时向目的地传输，它可以作为连续实时流在目的地被接收。这里的源指的是服务器端的应用，而目的地或称接收端是指客户端应用。
   流数据从服务器端应用传输后可由客户端应用接收并显示或回放，一般是客户端应用接收到足够的数据并将之存储在缓冲区后便立即将视频显示出来，或将音频回放出来。
   
   　　流媒体的一个重要特征是对时间的敏感性，这正是实时性要求高的应用所必需的，所以这类应用与流媒体密不可分就十分自然的了。流媒体的实现主要取决于网络带宽和压缩算法的提高。今天，随着网络协议的改善、网络基础设施和压缩技术的发展，流媒体的实现已经变得越来越容易了。
   
    2 流媒体传输方式
   
   　　流媒体的传输技术主要有三种：点对点(unicast)、多址广播(Multicast)和广播(Broadcast)。多址广播又称为组播。点对点的特点是流媒体的源和目的地是一一对应的，即流媒体从一个源(服务器端的应用)发送出去后只能到达一个目的地(客户端应用)。组播是一种基于"组"的广播，其源和目的地是一对多的关系，但这种一对多的关系只能在同一个组内建立，也就是说，流媒体从一个源(服务器端的应用)发送出去后，任何一个已经加入了与源同一个组号的目的地(客户端应用)均可以接收到，但该组以外的其他目的地(客户端应用)均接收不到。广播的源和目的地也是一对多的关系，但这种一对多的关系并不局限于组，也就是说，流媒体从一个源(服务器端的应用)发送出去后，同一网段上的所有目的地(客户端应用)均可以接收到，广播可以看作组播的一个特例。
   
   　　广播和组播对于流媒体传输来说是很有意义的，因为流媒体的数据量往往都很庞大，需要占用很大的网络带宽。如果采用点对点方式，那么有多少个目的地就得传输多少份流媒体，所以所需的网络带宽与目的地的数目成正比，如果采用广播或组播方式，那么流媒体在源端只需传输一份，组内或同一网段上的所有客户端应用均可以接收到，这就大大降低了网络带宽的占用。
   
    3 数字视频和声音传输技术
   
   　　数字视频和声音传输属于流媒体传输范畴。模拟视频和声音信号经过捕获设备转换成数字形式后，其数据量是非常惊人的，如果没有采用压缩技术，那么要实现数字视频和声音的网络传输是不可想象的。另一方面，数字视频和声音传输对时间的敏感性很强，实时性要求很高，如果不采用特别的网络传输协议是很难满足要求的。所以，实现数字视频和声音传输的一般做法是：在源端先将数字视频和声音信息进行压缩，然后经由诸如ATM这样的有服务质量(即QoS)保证的网络传输到目的地，再在目的地将之进行解压后显示或回放出来。如果需要在诸如IP网络这样的没有QoS保证的网络上传输，则至少也得采用实时传输协议(RTP)进行传输。
   
   　　目前已发展和正在发展的数字视频和音频压缩技术有很多种，不同的压缩技术有不同的侧重点，适应不同的应用。这些压缩技术中有的已经标准化，但还有很多并没有标准化。常用的已经标准化的压缩技术有MPEG-1、MPEG-2、H.261/H.263等，正在发展的有MPEG-4等。MPEG-1、MPEG-2适用于高带宽的能够提供高质量低延迟的视频和音频应用，而H.261、H.263以及正在发展MPEG-4则适用于低带宽的对图象质量的延迟要求不高的应用。
   
   　　图为数字视频和音频传输原理示意图，它包含了目前基于数字视频和音频流的几种典型的应用领域。由图可知，不同的应用领域基于不同的网络技术和不同的压缩技术。

IPv6的提出首先是由于IPv4的地址空间不足引起的，而其所涉及的领域远不止于此。越来越多的应用加载在IP网络之上，而对更高的质量保证等要求是网络应用的一个关键因素，对QoS问题认识的深刻程度将直接影响IPv6在今后网络中的实际应用效果。

　　

　　视频应用为时间灵敏性特别高的应用，其要求实时性和服务质量管理(QoS)，但是网上众多的应用多为尽力而为类数据。此类数据的特点是突发性强，这种突发性严重影响时间灵敏性特别高的应用，使这些应用的时延加大，同时出现抖动，从而产生严重的后果。例如，视频会议无法正常进行，产生图像马赛克效应，声音时断时续，甚至没有图像和声音。

　　

　　1981 年制定的IPv4协议正面临许多挑战：地址空间匮乏；网络安全漏洞多；服务质量难以保证；不易开展新业务；移动性支持有限，难以满足3G网络发展需求等等。因此，为了解决上述问题，下一代互联网协议IPv6的发展应运而生。

　　

　　IPv6以其超大地址容量可以轻松解决这个问题。解决了地址问题，实现端到端级实时通信基本上就不会有什么瓶颈了。而除了地址问题，IPv6对网络服务质量的作用也作了重大改进，将很大程度上改善服务质量。

　　

　　从“4”到“6”的主要变化

　　

　　扩展编址功能和自动配置机制

　　

　　IPv6的地址大小增加到128位。这解决了IPv4地址空间有限的问题，并提供了一个更深层次的编址层级以及更简单的配置。终有一天，你会忘却32位IP地址的感觉。网络管理员会喜欢协议内置的自动配置机制；多播路由得到了改进，多播地址通过一个范围字段得到了扩展；此外，还引进了一种新的地址类型，叫做Anycast(任播)地址，可以向工作组最近的单个成员发送消息。

　　

　　报头格式的简化

　　

　　IPv6的报头固定为40字节。这刚好容下8字节的报头和两个16字节的IP地址(源地址和目的地址)。IPv6的报头中去掉了IPv4报头中的一些字段，或者是将其变为可选项。这样，数据包可以在低处理消耗下更快地进行操作。

　　

　　改进的扩展和选项支持

　　

　　对于IPv4，选项集成于基本的IPv4报头中。而对于IPv6，这些选项被作为扩展报头(Extension header)来处理。

　　

　　扩展报头是可选项，如果有必要，可以插入到IPv6报头和实际数据之间。这样，IPv6数据包的生成变得很灵活且高效。IPv6数据包的转发效率要高很多。将来，要定义的新选项能够很容易地进行集成。

　　

　　身份验证和私密性的扩展

　　

　　IPv6指定了固有的对身份验证的支持，以及对数据完整性和数据机密性的支持。

　　

　　流标签功能

　　

　　属于同一传输流，且需要特别处理或需要服务质量的数据包，可以由发送者进行标记。实时服务就是这种应用的典型例子。

　　

　　更简单的报头 更快的处理速度

　　

　　即使IPv6报头的总长度是默认的IPv4报头的两倍长，达到了40字节，但它实际上还是被简化了的，因为报头的绝大部分被两个16字节的IPv6地址占据。这样，只剩8个字节可供其他报头信息使用。

　　

　　IPv4报头的长度可以从最小的20字节扩展为60字节，以便指定选项，如安全选项(Security Option)、源路由(Source Routing)或时间戳(Timestamping)。这项功能很少使用，因为会降低性能。例如，IPv4硬件转发实现必须把包含选项的数据包传递给予主处理程序(软件处理)。

　　

　　数据包的报头越简单，处理过程就越快。IPv6采用新方法来处理选项，显著地改善了处理速度，保证对数据报文的高速转发和较低的延时，提高了QoS。

　　

　　

　　IPv6下的ICMP变化

　　

　　IPv4试图通过IP报头的服务类型(Type of Service, ToS)字节对流量进行分类，却没有在整个互联网范围内取得成功，因为ToS字节是基于应用程序，根据业务流量属性进行公正的自我分类。在互联网早期的多媒体应用还少，因此对于解决此问题并没有实质性进展，并且从来没有统一地使用ToS字节。

　　

　　IP的重新设计为解决QoS以及其他一些新增功能等问题提供了契机。在IPv6中，不同的服务类别同样可以由不同的多播组实现，比如，可以定义同一音频流量的四种不同类别，每种都按不同品质进行编码(如5.5KHz、11KHz、22KHz和44KHz)。在这种范例下，甚至无须显式地表示优先级，因为它是和各多播组(必须通过由路由器和终端系统执行的不同的队列和处理来操作)隐式绑定的。

　　

　　现有的IPv6 ICMP(多播回放控制消息机制)可被用来塑造发送方和中间路由器的流量特点。不利的方面是，发送者将不得不多次提供基本相同的数据(但品质不同)，接收方需要知道预订哪个组，以便匹配特定的传输和终端系统功能。使用此范例的智能本地决定也包括对流量特征的监督以及在不同品质的多播信道之间动态切换。例如，要传输高品质(44KHz)的音频，分级编码可以用于编码为基本音频数据包的数据，其中包含5.5KHz品质的数据，第二个数据包包含5.5KHz～11KHz的数据，第三个数据包包含11KHz～22KHz的数据，而第四个数据包包含22～44KHz的数据。路由器则可以在拥塞的情况下，按第四、第三、第二和第一的顺序进行丢包处理。音频品质可能不同，但音频数据包只会在所有数据包都被丢弃的情况下才完全丢失。基于分类/优先级的QoS的副作用是，额外增加了发送者的负担(例如，IP报头管理和分级编码)，并且接收方得到的服务质量不同，也得不到保障。

　　

　　与QoS直接相关的元素

　　

　　IPv6协议在IP Base (基本) 和Extension(扩展)报头中包含了少量与特定于QoS的服务元素，可以按不同方式使用并可综合应用。

　　

　　IPv6基本报头中与QoS直接有关的服务元素包括流和相应的流标签。

　　

　　Traffic Class (流量类别)

　　

　　该节段代替了IPv4中的Type of Service字段，它有助于处理实时数据以及任何需要特别处理的数据。发送节点和转发路由器可以使用该字段来识别和分辨IPv6数据包的类别和优先级。

　　

　　流是从某个特定源发送到某个特定(单播或多播)目的地的一系列数据包，源需要由中间路由器进行特殊处理。该特殊处理的类型可以通过相应的控制协议(如RSVP)传送给路由器，或者通过流数据包自身的信息，如IP Base报头或Hop-by-Hop Extension报头。从发送者到接收者之间可能有多个活动流，以及和任何流都无关的数据流量。IP协议中的流通过源IP地址和非零流标签标识符的组合惟一地进行识别。不属于流的数据包的流标签为全零。

　　

　　Flow Label(流标签)

　　

　　该字段区分需要相同处理的数据包，以此来促进实时性流量的处理。发送主机能够用一组选项标记数据包的顺序。路由器跟踪数据流并更有效地处理属于相同数据流的数据包，因为他们无须重新处理每个数据包的报头。数据流由流标签和源节点的地址惟一标识。不支持Flow Label字段功能的节点需要在转发数据包时不加改变地传递该字段，并在接收数据包时忽略该字段。属于同一数据流的所有数据包必须具有相同的源IP地址和目的IP地址。

　　

　　IPv6报头中包含了一些关于控制QoS的信息(流类别和流标记)，通过路由器的配置可以实现优先级控制和QoS保证，将很大程度上改善服务质量，保障从VoIP到视频流的高质量传输。这也是美国国防部采用IPv6的重要原因之一。改善的QoS不仅使五角大楼能够获得了更好的传输服务，还允许军方根据不同的需要为信息分配不同的传输路径、所需带宽或者加密等级。例如，在一场战争中，对从战地指挥部发出的一封有关假期的邮件只分配很低的QoS，相反，指挥官与重要军官之间的VoIP电话将分配到很高的QoS。美国国防部将让所有类型的拓扑和平台都使用QoS标记。

　　

　　另外，今天互联网上的QoS还远没有标准化，设备制造商和网络平台采用不同的QoS机制，当数据离开某个IP网络到达下一个网关的时候，QoS的定义会突然发生变化。现在，向IPv6的过渡将给QoS的标准化提供一个很好的机会。因此IPv6产品必须通过产品测试和互操作性公开测试，同时为终端用户提供有关设备互通和一致性测试的信息。

　　

　　11月中旬，美国国防部刚刚完成了其新一轮的IP网络升级测试，内容之一即是在IPv6协议上实现互联网电话应用等。从该项目测试机构发布的消息看，在现实中部署这些IPv6应用仍然存在一些问题，但IPv6网络的整体基础架构表现是稳定可靠的，此次测试还对视频广播、无线局域网、网络安全等技术进行了评估。该测试将IPv6应用带入了一个新的阶段，美国国防部去年公布的计划是在2008年之前实现网络全面支持IPv6标准。

　　

　　在我国，IPv6工作的推进是在CNGI(下一代互联网示范工程)带动下进入全面实际部署应用阶段的。在11月29日新成立的我国首家专门致力于IPv6网络和技术发展的专业委员会——“北京通信信息协会IPv6推广应用专业委员会”更被认为是我国IPv6发展将步入新阶段的一个标志。

　　

　　此次成立的IPv6专业委员会的职责除了致力于积极推进IPv6在北京的应用和发展，实现各企业间的协助互补外，一个主要职责是进行研究IPv6的技术特点和优势，找出IPv6的创新应用，成为IPv6与传统行业有机结合的平台。该委员会已经吸引了中国电信北京研究院、方正科技、神州数码网络、北京软件产业促进中心、普天首信股份有限公司、国家气象信息中心、思科中国有限公司以及安奈特(中国)网络有限公司等四十余家单位参与。

1、Audodesk FLC

这是一种古老的编码方案，常见的文件后缀为FLC和FLI。由于FLC仅仅支持256色的调色板，因此它会在编码过程中尽量使用抖动算法（也可以设置不抖动），以模拟真彩的效果。这种算法在色彩值差距不是很大的情况下几乎可以达到乱真的地步，例如红色A（R:255,G:0,B:0）到红色B（R:255,G:128,B:0）之间的抖动。这种格式现在已经很少被采用了，但当年很多这种格式被保留下来，这种格式在保存标准256色调色板或者自定义256色调色板是是无损的，这种格式可以清晰到像素，非常适合保存线框动画，例如CAD模型演示。现在这种格式很少见了。 

 

　　2、Microsoft RLE

　　这是微软开发为AVI格式开发的一种编码，文件扩展名为AVI，使用了RLE压缩算法，这是一种无损的压缩算法，我们常见的tga格式的图像文件就使用了RLE算法。

　　什么是RLE算法呢？这是一种很简单的算法，举一个很简单的例子：

假设一个图像的像素色彩值是这样排列的：红红红红红红红红红红红红蓝蓝蓝蓝蓝蓝绿绿绿绿，经过RLE压缩后就成为了：红12蓝6绿4。这样既保证了压缩的可行性，而且不会有损失。而且可以看到，但颜色数越少时，压缩效率会更高。由于Microsoft RLE仅仅支持256色，而且没有抖动算法，在色彩处理方面，FLC明显的比Microsoft RLE要好很多。当然这也不表示Microsoft RLE一无是处，和FLC一样，Microsoft RLE在处理相邻像素时也没有色染，可以清晰的表现网格。因此同样可以优秀的表现单色字体和线条。只要色彩不是很复杂，FLC能做的，Microsoft RLE也可以做到。由于AVI可以拥有一个音频流，而且Windows系统给与了直接的支持，Microsoft RLE最常用的用途是，在256色显示模式下，通过配合抓屏生成AVI的工具制作一个软件的操作演示过程，以达到图文并茂，形声兼备的效果。 

 

　　3、Microsoft Video1

这也是由微软提供的一个AVI编码，任何Windows系统都自带了了它的Codec，这个编码支持真彩，画面质量很不错，Microsoft Video1的压缩效率非常低下，编码后的文件庞大得让人受不了。这个Microsoft Video1究竟有什么用呢？一般被用在保存一些没有渐变的小型视频素材方面。 

 

　　4、Indeo video R3.2

这个编码由intel架构实验室开发，对应的文件格式是AVI，相对之前的流行的编码，Indeo video R3.2最大的特点就是高压缩比（当然，比起现在的压缩方案，实在是不值得一提），intel声称压缩比可达8:1而没有明显的质量损失，解码速度也非常快，对系统要求不高，由于Windows9X中自带Indeo video R3.2的Codec，所以Indeo video R3.2一度成为了最流行的AVI编码方案。有不少游戏的过场动画和启动动画都是Indeo video R3.2编码的。Indeo video R3.2同样不适合高要求的环境，在要表现细线条或大色彩值变化的渐变时，Indeo video R3.2会表现得非常糟糕。如果画面的色彩值差异不是很大，也没有明显的色彩区域界限，Indeo video R3.2还是合适的，例如海天一色的场景。Indeo video R3.2已经基本被淘汰，如果不是为了播放以前遗留的一些Indeo video R3.2编码视频，恐怕Windows ME/2000都不会有Indeo video R3.2的Codec了。 

 

5、Indeo video 5.10

这个编码方案同样也是intel架构实验室开发的，它继承了Indeo video R3.2的优点，对应的文件格式仍然是AVI，解码速度同样非常快。Windows ME/2000自带了Indeo video 5.1的Codec，很多游戏也适用Indeo video 5.10来编码自己的演示动画。在没有DivX普及前，这几乎是最流行的AVI编码了，由于微软和intel的同时支持，这种编码方案被广泛采用。 

 

　　6、None

顾名思义，这是一个没有损失的视频编码方案，对应的文件扩展名为AVI。这种编码几乎是不压缩的，文件大得惊人！那么这种编码有什么用途呢？用途就是保存视频素材，因为是无损的，保存素材非常合适，代价就是大量的存储空间。 

 

　　7、MPEG1

我们熟知的VCD就是MPEG1编码的，对应的文件扩展名为MPG、MPEG或者DAT。事实上MPEG1可以工作于非PAL制和非NTSC制标准下。它可以自由设置数据流量和画面尺寸，只是这样非标准的文件无法直接刻录成VCD。

 

8、MPEG2

DVD的视频部分就是采用的MPEG2，SVCD同样也采用了MPEG2编码。对应的文件扩展名一般为VOB、MPG。MPEG2的设计目标就是提供接近广播级的高品质输出。 

 

9、DivX

DivX是近2年开始被大家认识的，DivX 视频编码技术可以说是一种对 DVD 造成威胁的新生视频压缩格式（有人说它是 DVD 杀手）对应的文件扩展名为AVI或者DivX，它由 Microsoft mpeg-4v3 修改而来，使用 MPEG-4 压缩算法。据说是美国禁止出口的编码技术。DivX最大的特点就是高压缩比和不错的画质，更可贵的是，DivX的对系统要求也不高，只要主频300的CPU就基本可以很流畅的播放了，因此从DivX诞生起，立刻吸引了大家的注意力。DivX拥有比Indeo video 5.10高太多的压缩效率，编码质量也远远比Indeo video 5.10好，我实在想不出Indeo video 5.10还会有什么前途。 

 

10、PICVideo MJPEG

MJPEG是很多视频卡支持的一种视频编码，随卡提供了Codec，安装完成后可以象使用其它编码一样生成AVI文件。MJPEG编码常用于非线性系统，批上了一层很专业的外衣。MJPEG的编码质量是相当高的，是一种以质量为最高要求的编码，这种编码的设置比较复杂，可以得到很高的压缩比，但牺牲了解码速度，如果要保证解码速度，编码后的压缩比确不是很理想，如果您希望从专业的非线性系统上捕捉视频，然后自行进行处理，这种格式是很有必要去了解一些的。 

 

11、RealNetworks RealVideo

REAL VIDEO（RA、RAM）格式由Real Networks公司开发的，一开始就定位在视频流应用方面的，也可以说是视频流技术的始创者。它可以在用 56K MODEM 拨号上网的条件实现不间断的视频播放。从RealVideo的定位来看，就是牺牲画面质量来换取可连续观看性。其实RealVideo也可以实现不错的画面质量，由于RealVideo可以拥有非常高的压缩效率，很多人把VCD编码成RealVideo格式的，这样一来，一张光盘上可以存放好几部电影。REAL VIDEO存在颜色还原不准确的问题，RealVideo就不太适合专业的场合，但RealVideo出色的压缩效率和支持流式播放的特征，使得RealVideo在网络和娱乐场合占有不错的市场份额。 

 

12、Windows Media video

Windows Media video就是微软为了和现在的Real Networks的RealVideo竞争而发展出来的一种可以直接在网上观看视频节目的文件压缩格式！由于它使用了MPEG4的压缩算法，所以压缩率和图像的质量都很不错。我们经常看到的ASF和WMV就是Windows Media video。Windows Media video的编码质量明显好于RealVideo，因为Windows Media video是微软的杰作，所以Windows系统给Windows Media video给与了很好的支持，Windows Media Player可以直接播放这些文件。

     自然界中的声音非常复杂，波形极其复杂，通常我们采用的是脉冲代码调制编码，即PCM编码。PCM通过抽样、量化、编码三个步骤将连续变化的模拟信号转换为数字编码。 

 

　　1、什么是采样率和采样大小（位/bit）？

声音其实是一种能量波，因此也有频率和振幅的特征，频率对应于时间轴线，振幅对应于电平轴线。波是无限光滑的，弦线可以看成由无数点组成，由于存储空间是相对有限的，数字编码过程中，必须对弦线的点进行采样。采样的过程就是抽取某点的频率值，很显然，在一秒中内抽取的点越多，获取得频率信息更丰富，为了复原波形，一次振动中，必须有2个点的采样，人耳能够感觉到的最高频率为20kHz，因此要满足人耳的听觉要求，则需要至少每秒进行40k次采样，用40kHz表达，这个40kHz就是采样率。我们常见的CD，采样率为44.1kHz。光有频率信息是不够的，我们还必须获得该频率的能量值并量化，用于表示信号强度。量化电平数为2的整数次幂，我们常见的CD位16bit的采样大小，即2的16次方。采样大小相对采样率更难理解，因为要显得抽象点，举个简单例子：假设对一个波进行8次采样，采样点分别对应的能量值分别为A1-A8，但我们只使用2bit的采样大小，结果我们只能保留A1-A8中4个点的值而舍弃另外4个。如果我们进行3bit的采样大小，则刚好记录下8个点的所有信息。采样率和采样大小的值越大，记录的波形更接近原始信号。 

 

　　2、有损和无损

根据采样率和采样大小可以得知，相对自然界的信号，音频编码最多只能做到无限接近，至少目前的技术只能这样了，相对自然界的信号，任何数字音频编码方案都是有损的，因为无法完全还原。在计算机应用中，能够达到最高保真水平的就是PCM编码，被广泛用于素材保存及音乐欣赏，CD、DVD以及我们常见的WAV文件中均有应用。因此，PCM约定俗成了无损编码，因为PCM代表了数字音频中最佳的保真水准，并不意味着PCM就能够确保信号绝对保真，PCM也只能做到最大程度的无限接近。我们而习惯性的把MP3列入有损音频编码范畴，是相对PCM编码的。强调编码的相对性的有损和无损，是为了告诉大家，要做到真正的无损是困难的，就像用数字去表达圆周率，不管精度多高，也只是无限接近，而不是真正等于圆周率的值。 

 

　　3、为什么要使用音频压缩技术

要算一个PCM音频流的码率是一件很轻松的事情，采样率值×采样大小值×声道数 bps。一个采样率为44.1KHz，采样大小为16bit，双声道的PCM编码的WAV文件，它的数据速率则为 44.1K×16×2 =1411.2 Kbps。我们常说128K的MP3，对应的WAV的参数，就是这个1411.2 Kbps，这个参数也被称为数据带宽，它和ADSL中的带宽是一个概念。将码率除以8,就可以得到这个WAV的数据速率，即176.4KB/s。这表示存储一秒钟采样率为44.1KHz，采样大小为16bit，双声道的PCM编码的音频信号，需要176.4KB的空间，1分钟则约为10.34M，这对大部分用户是不可接受的，尤其是喜欢在电脑上听音乐的朋友，要降低磁盘占用，只有2种方法，降低采样指标或者压缩。降低指标是不可取的，因此专家们研发了各种压缩方案。由于用途和针对的目标市场不一样，各种音频压缩编码所达到的音质和压缩比都不一样，在后面的文章中我们都会一一提到。有一点是可以肯定的，他们都压缩过。 

 

　　4、频率与采样率的关系

采样率表示了每秒对原始信号采样的次数，我们常见到的音频文件采样率多为44.1KHz，这意味着什么呢？假设我们有2段正弦波信号，分别为20Hz和20KHz，长度均为一秒钟，以对应我们能听到的最低频和最高频，分别对这两段信号进行40KHz的采样，我们可以得到一个什么样的结果呢？结果是：20Hz的信号每次振动被采样了40K/20=2000次，而20K的信号每次振动只有2次采样。显然，在相同的采样率下，记录低频的信息远比高频的详细。这也是为什么有些音响发烧友指责CD有数码声不够真实的原因，CD的44.1KHz采样也无法保证高频信号被较好记录。要较好的记录高频信号，看来需要更高的采样率，于是有些朋友在捕捉CD音轨的时候使用48KHz的采样率，这是不可取的！这其实对音质没有任何好处，对抓轨软件来说，保持和CD提供的44.1KHz一样的采样率才是最佳音质的保证之一，而不是去提高它。较高的采样率只有相对模拟信号的时候才有用，如果被采样的信号是数字的，请不要去尝试提高采样率。 

 

　　5、流特征

　　随着网络的发展，人们对在线收听音乐提出了要求，因此也要求音频文件能够一边读一边播放，而不需要把这个文件全部读出后然后回放，这样就可以做到不用下载就可以实现收听了。也可以做到一边编码一边播放，正是这种特征，可以实现在线的直播，架设自己的数字广播电台成为了现实。

 

一、NTSC彩色电视制式：

 

它是1952年由美国国家电视标准委员会指定的彩色电视广播标准，它采用正交平衡调幅的技术方式，故也称为正交平衡调幅制。美国、加拿大等大部分西半球国家以及中国的台湾、日本、韩国、菲律宾等均采用这种制式。

 

二、PAL制式：

 

它是西德在1962年指定的彩色电视广播标准，它采用逐行倒相正交平衡调幅的技术方法，克服了NTSC制相位敏感造成色彩失真的缺点。西德、英国等一些西欧国家，新加坡、中国大陆及香港，澳大利亚、新西兰等国家采用这种制式。PAL制式中根据不同的参数细节，又可以进一步划分为G、I、D等制式，其中PAL－D制是我国大陆采用的制式。

 

三、SECAM制式：

 

SECAM是法文的缩写，意为顺序传送彩色信号与存储恢复彩色信号制，是由法国在1956年提出，1966年制定的一种新的彩色电视制式。它也克服了NTSC制式相位失真的缺点，但采用时间分隔法来传送两个色差信号。使用SECAM制的国家主要集中在法国、东欧和中东一带。

 

为了接收和处理不同制式的电视信号，也就发展了不同制式的电视接收机和录像机。

 

一、              高频或射频信号

 

为了能够在空中传播电视信号，必须把视频全电视信号调制成高频或射频（RF－Radio Frequency）信号，每个信号占用一个频道，这样才能在空中同时传播多路电视节目而不会导致混乱。我国采样PAL制，每个频道占用8MHz的带宽；美国采用NTSC制，电视从2频道至69频道，每个频道的带宽为4MHz，电视信号频带共占用54 MHz至806 MHz的信道。有线电视CATV（Cable Television）的工作方式类似，只是它通过电缆而不是通过空中传播电视信号。

 

电视机在接收受到某一频道的高频信号后，要把全电视信号从高频信号中解调出来，才能在屏幕上重现视频图像。

 

二、复合视频信号

 

复合视频（Composite Video）信号定义为包括亮度和色度的单路模拟信号，也即从全电视信号中分离出伴音后的视频信号，这时的色度信号还是间插在亮度信号的高端。由于复合视频的亮度和色度是间插在一起的，在信号重放时很难恢复完全一致的色彩。这种信号一般可通过电缆输入或输出到家用录像机上，其信号带宽较窄，一般只有水平240线左右的分解率。早期的电视机都只有天线输入端口，较新型的电视机才备有复合视频输入和输出端（Video In，Video Out），也即可以直接输入和输出解调后的视频信号。视频信号已不包含高频分量，处理起来相对简单一些，因此计算机的视频卡一般都采用视频输入端获取视频信号。由于视频信号中已不包含伴音，故一般与视频输入、输出端口配套的还有音频输入、输出端口（Audio－In、Audio－Out），以便同步传输伴音。因此，有时复合式视频接口也称为AV（Audio Video）口。

 

三、S－Video信号

 

目前有的电视机还备有两分量视频输入端口（S－Video In），S－Video 是一种两分量的视频信号，它把亮度和色度信号分成两路独立的模拟信号，用两路导线分别传输并可以分别记录在模拟磁带的两路磁迹上。这种信号不仅其亮度和色度都具有较宽的带宽，而且由于亮度和色度分开传输，可以减少其互相干扰，水平分解率可达420线。与复合视频信号相比，S－Video可以更好地重现色彩。

 

两分量视频可来自于高档摄像机，它采用两分量视频的方式记录和传输视频信号。其它如高档录像机、激光视盘LD机的输出也可按分量视频的格式，其清晰度比从家用录像机获得的电视节目的清晰度要高得多。

 

不同制式的电视机只能接收和处理其对应制式的电视信号。当然，目前也发展了多制式或全制式的电视机，这为处理和转换不同制式的电视信号提供了极大的方便。全制式电视机可在各国各地区使用，而多制式电视机一般为指定范围的国家生产。如Panasonic TC-2188M多制式电视机，适用于PAL－D，I制和NTSC（3.58）制，也即它可以在中国大陆（PAL－D）、香港（PAL－I）和日本（NTSC 3.58）使用。

 

视频序列的SMPTE表示单位

 

通常用时间码来识别和记录视频数据流中的每一帧，从一段视频的起始帧到终止帧，其间的每一帧都有一个唯一的时间码地址。根据动画和电视工程师协会SMPTE（Society of Motion Picture and Television Engineers）使用的时间码标准，其格式是：小时：分钟：秒：帧，或 hours：minutes：seconds：frames。 一段长度为00：02：31：15的视频片段的播放时间为2分钟31秒15帧，如果以每秒30帧的速率播放，则播放时间为2分钟31.5秒。

 

根据电影、录像和电视工业中使用的帧率的不同，各有其对应的SMPTE标准。由于技术的原因NTSC制式实际使用的帧率是29.97fps而不是30fps，因此在时间码与实际播放时间之间有0.1%的误差。为了解决这个误差问题，设计出丢帧（drop-frame）格式，也即在播放时每分钟要丢2帧（实际上是有两帧不显示而不是从文件中删除），这样可以保证时间码与实际播放时间的一致。与丢帧格式对应的是不丢帧（nondrop-frame）格式，它忽略时间码与实际播放帧之间的误差。

 

视频压缩编码的基本概念

 

视频压缩的目标是在尽可能保证视觉效果的前提下减少视频数据率。视频压缩比一般指压缩后的数据量与压缩前的数据量之比。由于视频是连续的静态图像，因此其压缩编码算法与静态图像的压缩编码算法有某些共同之处，但是运动的视频还有其自身的特性，因此在压缩时还应考虑其运动特性才能达到高压缩的目标。在视频压缩中常需用到以下的一些基本概念：

 

一、有损和无损压缩：

 

在视频压缩中有损（Lossy ）和无损（Lossless）的概念与静态图像中基本类似。无损压缩也即压缩前和解压缩后的数据完全一致。多数的无损压缩都采用RLE行程编码算法。有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程中要丢失一些人眼和人耳所不敏感的图像或音频信息，而且丢失的信息不可恢复。几乎所有高压缩的算法都采用有损压缩，这样才能达到低数据率的目标。丢失的数据率与压缩比有关，压缩比越小，丢失的数据越多，解压缩后的效果一般越差。此外，某些有损压缩算法采用多次重复压缩的方式，这样还会引起额外的数据丢失。

 

二、帧内和帧间压缩：

 

帧内（Intraframe）压缩也称为空间压缩（Spatial compression）。当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩类似。帧内一般采用有损压缩算法，由于帧内压缩时各个帧之间没有相互关系，所以压缩后的视频数据仍可以以帧为单位进行编辑。帧内压缩一般达不到很高的压缩。

 

采用帧间（Interframe）压缩是基于许多视频或动画的连续前后两帧具有很大的相关性，或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息，根据这一特性，压缩相邻帧之间的冗余量就可以进一步提高压缩量，减小压缩比。帧间压缩也称为时间压缩（Temporal compression），它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧差值（Frame differencing）算法是一种典型的时间压缩法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与其相邻帧的差值，这样可以大大减少数据量。

 

 

三、对称和不对称编码：

 

对称性（symmetric）是压缩编码的一个关键特征。对称意味着压缩和解压缩占用相同的计算处理能力和时间，对称算法适合于实时压缩和传送视频，如视频会议应用就以采用对称的压缩编码算法为好。而在电子出版和其它多媒体应用中，一般是把视频预先压缩处理好，尔后再播放，因此可以采用不对称（asymmetric）编码。不对称或非对称意味着压缩时需要花费大量的处理能力和时间，而解压缩时则能较好地实时回放，也即以不同的速度进行压缩和解压缩。一般地说，压缩一段视频的时间比回放（解压缩）该视频的时间要多得多。例如，压缩一段三分钟的视频片断可能需要10多分钟的时间，而该片断实时回放时间只有三分钟。

 

MPEG（Moving Picture Experts Group）是1988年成立的一个专家组。这个专家组在1991年制定了一个MPEG－1国际标准，其标准名称为“动态图像和伴音的编码－－用于速率小于每秒约1.5兆比特的数字存储媒体（Coding of moving picture and associated audio－－for digital storage media at up to about 1.5Mbit / s）”。这里的数字存储媒体指一般的数字存储设备如CD－ROM、硬盘和可擦写光盘等。MPEG的最大压缩可达约1：200，其目标是要把目前的广播视频信号压缩到能够记录在CD光盘上并能够用单速的光盘驱动器来播放，并具有VHS的显示质量和高保真立体伴音效果。MPEG采用的编码算法简称为MPEG算法，用该算法压缩的数据称为MPEG数据，由该数据产生的文件称MPEG文件，它以MPG为文件后缀。

    实时传输协议RTP（Realtime Transport Protocol）被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，也可以在TCP或ATM等其他协议上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是应用程序代码的一部分。
    实时传输控制协议RTCP（Realtime Transport Control Protocol）和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包数量、丢失的数据包数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP的配合使用能以有效的反馈和最小的开销使传输速率最佳化，因而特别适合传送网上的实时数据

实时传输协议RTP与RTCP

　RTP（Real-timeTransportProtocol）是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。实时传输控制协议RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

6.2.1 RTP数据传输协议

　RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。

6.2.1.1 RTP固定头
　RTP 头格式如下：
　-----------------------------------------------------------------------------------------------
　|V=2|P|X| CC |M| PT | 系列号 |
　-----------------------------------------------------------------------------------------------
　| 时标 |
　-----------------------------------------------------------------------------------------------
　| 同步源标识(SSRC) |
　-----------------------------------------------------------------------------------------------
　| 作用标识 (CSRC) |
　| .... |
　-----------------------------------------------------------------------------------------------

　开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
　6.2.1.2 复用 RTP 连接
　为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
　如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
　RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
　RTP混合器不能将不兼容媒体流合并成一个流。
　在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。

6.2.1.3 对RTP头特定设置的修改
　可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
　其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变。

6.2.2 RTP控制协议-- RTCP
　 RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：
　 主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
　 RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系
　 前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。
　 第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在\"松散控制\"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。
　 在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
　
　 6.2.2.1 RTCP 包格式
　 下面定义几个携带不同控制信息的RTCP包类型：
　 SR： 发送报告，当前活动发送者发送、接收统计。
　 RR： 接收报告，非活动发送者接收统计。
　 SDES： 源描述项，包括CNAME。
　 BYE： 表示结束。
　 APP： 应用特定函数。
　 类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多哥RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。
　 组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但未了执行协议功能，强加如下约束：
　 接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP 包应包含报告包。
　 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。
　 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。
　 因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：
　 加密前缀（Encryption prefix）：
　 仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。
　 SR或RR：
　 组合包中第一个RTCP包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。
　 附加RR：
　 如报告统计源数目超过31，在初始报告包后应该有附加RR 包。
　
　 SDES：
　 包含CNAME 项的SDES包必须包含在每个组合RTCP包中。如应用要求，其他源描述项可选，但受到带宽限制。
　 BYE或APP：
　 其它RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。
　 建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。
　
　 6.2.2.2 RTCP传输间隔
　 RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
　 一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
　 这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
　 6.2.2.3 发送者与接收者报告
　 RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
　 丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
　 从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
　
　 6.2.2.4 SDES: 源描述RTCP包
　 SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下：
　 版本（V）、填充（P）、长度：
　 如SR包中所描述。
　 包类型（PT）：
　 8位，包含常数202，识别RTCP SDES包。
　 源计数（SC）：
　 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
　 源描述项内容如下：
　 CNAME: 规范终端标识SDES项
　 CNAME标识属性如下：
　 如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
　 象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。
　 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
　 为方便第三方监控，CNAME应适合程序或人员定位源。
　 NAME：用户名称SDES项
　 这是用于描述源的真正的名称，如\"John Doe, Bit Recycler, Megacorp\"，可是用户想要的任意形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中唯一依赖。
　 EMAIL：电子邮件地址SDES项
　 邮件地址格式由RFC822规定，如\"John.Doe@megacorp.com\"。连接期间，电子邮件仍希望保持为常数。
　 PHONE：电话号码SDES项
　 电话号码应带有加号，代替国际接入代码，如\"+1 908 555 1212\"即为美国电话号码。
　
　 LOC：用户地理位置SDES项
　 根据应用，此项具有不同程度的细节。对会议应用，字符串如\"Murray Hill, New Jersey\"就足够了。然而，对活动标记系统，字符串如\"Room 2A244, AT&T BL MH\"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。
　 TOOL：应用或工具名称SDES项
　 是一个字符串，表示产生流的应用的名称与版本，如\"videotool 1.2\"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。
　 NOTE: 通知/状态SDES项
　 该项的推荐语法如下所述，但这些或其它语法可在设置中显式定义。NOTE 项旨在描述源当前状态的过渡信息，如\"on the phone, can´t talk\"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。
　 当其为活动时，由于NOTE项对显示很重要，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20-30 RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。
　 PRIV: 专用扩展SDES项
　 该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
　 注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
　 6.2.2.5 BYE：断开RTCP包
　 如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
　 6.2.2.6 APP：定义应用的RTCP包
　 APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

实时流协议RTSP

　　实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

6.3 RTSP协议
　 实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
　 6.3.1 简介
　 6.3.1.1 目的
　 实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP***作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和***作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的***作如下：
　 从媒体服务器上检索媒体：
　 用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
　 媒体服务器邀请进入会议：
　 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
　 将媒体加到现成讲座中：
　 如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
　
　 6.3.1.2 协议特点
　 RTSP 特性如下：
　 可扩展性： 新方法和参数很容易加入RTSP。
　 易解析： RTSP可由标准 HTTP或MIME解吸器解析。
　 安全： RTSP使用网页安全机制。
　 独立于传输： RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
　 多服务器支持： 每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
　 记录设备控制： 协议可控制记录和回放设备。
　 流控与会议开始分离： 仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323 可用来邀请服务器入会。
　 适合专业应用： 通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑
　 演示描述中立： 协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。
　 代理与防火墙友好： 协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。
　 HTTP友好： 此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
　 适当的服务器控制： 如用户启动一个流，他必须也可以停止一个流。
　 传输协调： 实际处理连续媒体流前，用户 可协调传输方法。
　 性能协调： 如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。

　 6.3.1.3扩展RTSP
　 由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：
　 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
　 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
　 定义新版本协议，允许改变所有部分。（除了协议版本号位置）
　 6.3.1.4操作模式
　 每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
　 为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种***作模式：
　 单播： 以用户选择的端口号将媒体发送到RTSP请求源。
　 组播，服务器选择地址： 媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
　 组播，用户选择地址： 如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
　 6.3.1.5 RTSP状态
　 RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
　 SETUP： 让服务器给流分配资源，启动RTSP连接。
　 PLAY与RECORD： 启动SETUP 分配流的数据传输。
　 PAUSE： 　 临时停止流，而不释放服务器资源。
　 TEARDOWN： 　 释放流的资源，RTSP连接停止。
　 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连
　 接产生连接标识。
　
　 6.3.1.6 与其他协议关系
　 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
　 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
　 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。
　
　 6.3.2 协议参数
　
　 6.3.3 RTSP 信息
　 RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。
　 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
　 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
　 不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。
　 如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
　 服务器关闭连接。
　 注意：RTSP目前并不支持HTTP/1.1\"块\"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
　 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
　 6.3.4 实体
　 如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
　 实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
　 6.3.5 连接
　 RTSP请求可以几种不同方式传送：
　 1、持久传输连接，用于多个请求/响应传输。
　 2、每个请求/响应传输一个连接。
　 3、无连接模式。
　 传输连接类型由RTSP URI来定义。对 \"rtsp\" 方案，需要持续连接；而\"rtspu\"方案，调用RTSP 请求发送，而不用建立连接。
　 不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
　 6.3.6 方法定义
　 方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
　 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器***作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。
　 当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包 ，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
　 6.3.7 流水线操作
　 支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。
　 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
　 实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。

资源预订协议RSVP协议

　由于音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求之外，还需其他更多的条件。RSVP(ResourceReserveProtocol)是正在开发的Internet上的资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。

6.4 RSVP协议
　 6.4.1 背景
　 资源预订协议（RSVP）是网络控制协议，它使Internet应用传输数据流时能够获得特殊服务质量（QoSs），RSVP是非路由协议；它同路由协议协同工作，建立与路由协议计算出路由等价的动态访问列表， RSVP属OSI 七层协议栈中传输层，开始是研究人员构造的，IETF正朝标准化方向努力，图3.4 说明了RSVP运行环境。

图3.4 RSVP中主机信息通过数据流发送给接收者示意图
　 6.4.2 RSVP数据流
　 在RSVP中，数据流是一系列信息，有着相同的源、目的（可有多个）和服务质量，QoS要求通过网络以流说明形式通讯。流说明是互连网主机用来请求特殊服务的数据结构，保证互连网处理主机传输。RSVP支持三种传输类型：最好性能（best-effort），速率敏感（rate-sensitive）与延迟敏感（delay-sensitive）。用来支持这些传输类型的数据流服务依赖QoS实施，以下部分陈述传输类型与相关服务。
　 最好性能传输为传统IP传输。应用包括文件传输（如邮件传输）、磁盘映像、交互登录和事务传输。支持最好性能传输的服务称为最好性能服务。速率敏感传输放弃及时性，而确保速率。例如：速率敏感传输请求100 kbps带宽，如在扩展期实际发送200 kbps，路由器可能延迟传输。速率敏感传输目的不在通过电路交换网络传输，但它通常与电路交换网络（ISDN）应用有联系，现在正运行在数据报网络（IP）上。这类应用如H.323视频会议，设计运行在ISDN （H.320）或ATM（H.310）上，但发现在Internet上也有应用。H.323编码是常数速率或准常数速率，它需要常数传输速率。RSVP服务支持速率敏感传输，称为位速率保证服务。延迟敏感传输要求传输及时，并因而改变其速率。例如：MPEG-II视频根据图象改变量大小平均流量为3 到7 Mbps，3 Mbps可能对应一堵上色的墙，而7 Mbps 可能是海洋的波浪。MPEG-II视频源发送关键和增量帧。典型的，每秒一个或两个关键帧，描述整个图象，而每秒13或28帧描述关键帧之间的变化，增量帧通常比关键帧小。因此，帧与帧之间速率变化较大。但由于单个帧要求在一帧时间内发送出去，或解码器速度跟不上，必须对增量帧传输进行特定优先级别协调。RSVP服务支持延迟敏感传输，被看作控制延迟服务（非实时服务）与预报服务（实时服务）。
　 6.4.3 RSVP 数据流处理
　 RSVP数据流基本特征是连接，数据包在其上流通。连接是具有相同单播或组播目的数据流，RSVP分别处理每个连接。RSVP支持单播和组播连接（这里连接是一些发送者与另一些接收者的会话），而流总是从发送者开始的。特定连接的数据包被导向同一个IP目的地址或公开的目的端口。IP目的地址可能是组播发送的组地址，也可能是单个接收者的单播地址。公开目的端口可用UDP/TCP目的端口段、另外传输协议等价段或某些应用特定信息定义。
　 RSVP数据发布是通过组播或单播实现的。组播传输将某个发送者的每个数据包拷贝转发给多个目的。单播传输特征是只有一个接收者。即使目的地址是单播，也可能有多个接收者，以公开端口区分。多个发送者也可能存在单播地址，在这种情况下，RSVP可建立多对一传输的资源预订。每个RSVP发送者和接收者对应唯一的Internet主机。然而，单个主机可包括多个发送者和接收者，以公开端口区分。
　 RSVP服务质量(QoS)
　 在RSVP中，服务质量（QoS）是流规范指定的属性，流规范用于决定参加实体（路由器、接收者和发送者）进行数据交换的方式。主机和路由器使用RSVP指定QoS；其中主机代表应用数据流使用RSVP从网络申请QoS级别，而路由器使用RSVP发送QoS请求给数据流路经的其它路由器。这样做，RSVP就可维持路由器和主机状态来提供所请求的服务。
　 RSVP连接启动
　 为了初始化RSVP组播连接，接收者首先使用Internet组成员协议（IGMP）加入IP目的地址指定的组播组。对单播连接，单播路由就象IGMP结合协议无关组播（PIM）在组播时的作用。接收者加入组后，潜在的发送者就开始发送RSVP路径信息给IP目的地址。接收者应用收到路径信息，开始发送相应资源预订请求信息，使用RSVP指定欲点播的流描述。发送者应用接收到资源预订请求信息后，发送者开始发送数据包。
　 6.4.4 RSVP资源预订类型
　 资源预订类型指一套指定所支持参数的控制选项。RSVP支持两种主要资源预订：独占资源预订和共享资源预订。独占资源预订为每个连接中每个相关发送者安装一个流；而共享资源预订由互不相关的发送者使用。表3.10说明这两种资源预订协议的应用范围及所支持的范围与类型的组合情况。
　
　 6.4.5 RSVP软状态实现
　 对RSVP，软状态指可被某些RSVP信息更新的路由器和终端结点的状态。软状态特征允许RSVP网络支持动态组成员变化，并适应路由变化。一般说来，软状态由基于RSVP网络维护，使网络可在没有查询终端结点的情况下改变状态。对比电路交换结构，终端结点进行依次呼叫，如失败，进行依次新呼叫。
　 RSVP协议为创建和维护组播和单播混合发送路径的分布式资源预订状态提供了一个通用功能。为维护资源预订状态，RSVP跟踪路由器和主机结点的软状态。路径与资源预订请求信息创建并周期更新RSVP软状态。如在清除时间间隔到期前没有收到相应更新信息，就删除该状态，显式teardown 信息也可删除软状态。RSVP周期扫描欲建立的软状态，并转发路径与预订请求更新信息给下一跳。
　 当路由改变，下一个路径信息初始化新路由的路径状态，将来资源预订请求信息建立资源预订状态。现在未使用的网段状态标记为超时。（RSVP规范要求在拓扑改变后两秒通过网络初始化新资源预订）。当发生状态变化，RSVP无延迟的将变化从RSVP网络的一个终端传到另一个终端。如接收到的状态与存储状态不同，就更新存储状态。如结果改变了欲产生的更新信息，更新信息立即生成并转发出去。
　 6.4.6 RSVP 操作模型
　 在RSVP下，资源为简单数据流（单向数据流）预订起来。每个发送者逻辑上与接收者不同，但任何应用都可充当发送者和接收者，接收者负责请求资源预订。图3.5说明了其基本操作环境，紧接部分将提供特定事件序列的框架。

图3.5 RSVP 操作环境：为单向数据流预订资源
　 6.4.6.1基本RSVP协议操作
　 RSVP资源预订处理初始化开始于RSVP 后台服务查询本地路由协议以获得路由。主机发送IGMP消息加入组播组，而发送RSVP消息预订沿组路径的资源。每个能加入资源预订的路由器将收到的数据包传递给包分类器，然后将它们在包调度器中排队。RSVP包分类器决定每个包的路由和QoS类；RSVP调度器给每个接口所使用的特殊数据链路层媒介上传输分配资源。如数据链路层媒介有自身的QoS管理能力，包调度器负责协调数据链路层，获得RSVP所请求的QoS。调度器本身分配无源QoS媒介上包传输能力，如双铰线；也可分配其它系统资源，如CPU时间与缓存。QoS请求一般发源于接收者主机应用，而被传递到本地RSVP应用，如RSVP 后台服务。RSVP协议接着将对所有结点（路又器与主机）的请求沿逆向数据路径传到到数据源。在每个结点处，RSVP程序应用一个称为进入允许控制的本地决定程序决定是否能提供所请求的QoS。如进入允许控制成功，RSVP程序设置包分类和调度器的参数，以获得所申请的QoS。如进入允许控制在某结点处失败，RSVP程序给产生此请求的应用返回一个错误指示。
　 6.4.6.2 RSVP 隧道
　 在整个Internet上同时配置RSVP或任意其他协议都是不可能的。实际上，RSVP决不可能在每个地方都被配置。因此，RSVP必须提供正确协议操作，即使只有两个支持RSVP的路由器与一群不支持RSVP的路由器相连。一个中等规模不支持RSVP的网络不能执行资源预订，因而服务保证也就不能实现。然而，如该网络有充足额外容量，也可以提供可接受的实时服务。
　 为了支持RSVP网络连接通过不支持RSVP的网络，RSVP支持隧道技术。隧道技术要求RSVP和非RSVP路由器用本地路由表转发到目的地址的路径信息。当路径信息通过非RSVP 网络时，路径信息拷贝携带最后一个支持RSVP的路由器的IP地址。预订请求信息转发给下一个上游支持RSVP的路由器
　 6.4.7 加权平均排队方案
　 用技术来加强出现瓶颈处的有效资源预订（如Cisco的加权平均排队方案）有着正面影响。隧道技术仅在瓶颈出在非RSVP 域且不可避免时才有风险。图3.6表示基于RSVP网络间采用隧道技术的RSVP环境

图3.6 ：应用隧道技术的RSVP环境
　 6.4.8 RSVP 消息
　 RSVP支持四种基本消息类型：资源预订请求消息、路径消息、错误与确认消息和断开消息。
　 6.4.9 RSVP 包格式
　 表3.11说明了RSVP包格式，如下内容列出格式的头和对象段。
　 表3.11 RSVP包格式 RSVP消息头段（长度单位：位） 4 4 8 16 16 8 8 32 15 1 16 版本 标志 类型 校验和 长度 预订 发送TTL 消息ID 预订 MF 偏移量 RSVP对象段（长度单位：位） 16 8 8 可变 长度 分类号 C类型 对象内容
　 RSVP 消息头段
　 RSVP 消息头段组成：
　 版本号---4位，表示协议版本号（当前版本为1）。
　 标志---4位 ，当前没有定义标志段。
　 类型---8位， 有几种可能值，如表3.12所示。
　 表3.12：RSVP消息类型段取值 值 消息类型 1 路径 2 资源预订请求 3 路径错误 4 资源预订请求错误 5 路径断开 6 资源预订断开 7 资源预订请求确认 校验和---16位，表示基于RSVP消息的内容上标准TCP/UDP校验和。
　 长度---16-位，表示RSVP包的字节长度，包括公共头和随后的可变长度对象。如设置了MF标志，或片段偏移为非零值，这就是较大消息当前片段长度。
　 发送TTL---8位，表示消息发送的IP生存期。
　 消息ID---32位，提供下一RSVP跳/前一RSVP跳消息中所有片段共享标签。
　 更多片段 (MF) 标志---一个字节的最低位，其它7位预订，除消息的最后一个片段外，都将设置MF。
　 片段偏移---24位，表示消息中片段的字节偏移量。
　
　 RSVP 对象段
　 RSVP 对象段组成如下：
　 长度---16-位，包含总对象长度，以字节计（必须是4的倍数，至少是4）。
　 分类号---表示对象类型，每个对象类型都有一个名称。RSVP程序必须可识别分类，类型在表3.13列出。如没有识别出对象分类号，分类号高位决定结点采用什么行动。
　 C-类型---C类型，在分类号中唯一。最大内容长度是65528个字节。分类号和C-类型段(与标志位一起) 可用作定义每个对象唯一位的16位数。
　 对象内容---长度、类型号和C类型段指定对象内容的形式。
　
　 6.4.10 RSVP小结
　 RSVP运行在传输层，在IP上层。与ICMP和IGMP相比，它是一个控制协议。RSVP的组成元素有发送者、接收者和主机或路由器。发送者负责让接收者知道数据将要发送，以及需要什么样的QoS；接收者负责发送一个通知到主机或路由器，这样他们就可以准备接收即将到来的数据；主机或路由器负责留出所有合适的资源。
　 RSVP协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征，通过IP包中\"流标记\"来认证。发送一个流前，发送者传输一个路径信息到目的接收方，这个信息包括源IP地址、目的IP地址和一个流规格。这个流规格是由流的速率和延迟组成的，这是流的QoS需要的。接收者实现预定后，基于接收者的模式能够实现一种分布式解决方案。
　 RSVP领域的发展是非常迅速的，但目前并没有在任何一种网络上得到证实，它的应用只是局限在测试的小Intranet网络上。因为RSVP的预定必须建立在完全流方式的基础上，其可扩展性问题倍受关注。RSVP还存在诸如当一个服务请求被申请控制否决时网络应该怎样通知用户以及用户怎样应答这样的通知等问题。

实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。 　　RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： RTP ――传送具有实时属性的数据； RTP 控制协议（RTCP）――监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。

协议结构

1	2	3	8	9	16bit
V	P	X	CSRC Count	M	Payload Type
Sequence number				Timestamp
SSRC				CSRC (variable 0 – 15 items 32bits each)

V ― 版本。识别 RTP 版本。 P ― 间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。 X ― 扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。 CSRC Count ― 包含 CSRC 标识符（在固定头后）的编号。 M ― 标记。标记由 Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。 Payload Type ― 识别 RTP 有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从 Payload 编码到 Payload 格式的缺省静态映射。另外的 Payload Type 编码可能通过非 RTP 方法实现动态定义。 Sequence Number ― 每发送一个 RTP 数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。 Timestamp ― 反映 RTP 数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。 SSRC ― 同步源。该标识符随机选择，旨在确保在同一个 RTP 会话中不存在两个同步源具有相同的 SSRC 标识符。 CSRC ― 贡献源标识符。识别该数据包中的有效载荷的贡献源。

相关协议	RTCP、RTSP、UDP、TCP、IP
组织来源	RTP 由 IETF（www.ietf.org）定义在 RFC 3550和3551中。
相关链接	http://www.javvin.com/protocol/rfc3550.pdf: RTP: A Transport Protocol for Real-Time Applications http://www.javvin.com/protocol/rfc3551.pdf: RTP Profile for Audio and Video Conferences with Minimal Control

实时传输协议详解

实时传输协议RTP
1.RTP协议：
RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。. Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议.
RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。

2．RTP协议是如何工作的：
在前面说明过，威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。
在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。
RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。     

实时传输控制协议RTCP协议

1. RTCP协议：
RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。

2. RTCP协议如何工作：
当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
RTCP协议处理机根据需要定义了五种类型的报文——
RR: receiver report
SR: sender report
SDES: source description items. 
BYE: indicates end of participation. 
APP: application specific functions
它们完成接收、分析、产生和发送控制报文的功能。

实时流协议RTSP协议
1. RTSP协议：
RTSP（Real Time Streaming Protocol）协议定义了如何有效地通过IP网络传送多媒体数据，是一种客户端到服务器端的多媒体描述协议。
RTSP是一个非常类似于HTTP的应用层协议。每个发布和媒体文件也被定义为RTSP UPL。而媒体文件的发布信息被书写进一个被称为媒体发布文件里，这个文件在后面会说明。在这个文件说明的包括编码器，语言，RTSP ULS，地址，端口号以几其它参数。这个发布文件可以在客户端通过EMAIL形式或者HTTP形式获得。
RTSP是由RealNetworks和Netscape以及哥伦比亚大学共同提出的。它是从RealNetworks的"RealAudio" 和 Netscape的 "LiveMedia"的实践和经验发展来来的。第一份RTSP协议是由IETF 在1996年8月9日正式提交后作为INTERNET的标准，在此后此协议经过了很多明显的变化。它的应用现在是广泛的，APPLE、IBMNetscape, Apple, IBM, Silicon Graphics, VXtreme, Sun 还有其它公司都宣称它们的在线播放器支持RTSP协议，不过微软一直都坚持不支持此协议，不知道这种局面还会持续多久。

2. RTSP协议的特点：
RTSP是应用层协议,与RTP、RSVP一起设计来完全流式服务。
RTSP有很大的灵活性，可被用在多种操作系统上,它允许客户端和不同厂商的服务平台交互。
RTSP在体系结构上位于RTP和RTCP之上，它使用RTP完成数据传输。它将流式媒体数据可控制的通过网络传输到客户端。
RTSP可以保持用户计算机与传输流业务服务器之间的固定连接，用于观看者与单播（Unicast）服务器通信并且还允许双向通信，观看者可以同流媒体服务器通信.
提供类似“VCR”形式的例如暂停、快进、倒转、跳转等操作。操作的资源对象可以是直播流也可以是存储片段。
RTSP是设还提供了选择传输通道，如使用UDP还是多点UDP或是TCP。

资源预留协议RSVP 
1. RSVP协议：
RSVP (Resorce reSerVation Protocol) 资源预留协议并不是一个路由协议，而是一种IP网络中的信令协议，它与路由协议相结合来实现对网络传输服务质量（QoS）的控制。RSVP是为支持因特网综合业务而提出的。这是解决IP通信中QoS（服务质量）问题的一种技术，用来保证点端到端的传输带宽。

2. RSVP协议是如何工作：
RSVP使用控制数据报，这些数据报在向特定地址传输时包括了需要由路由器检查（有些时候需要更新）的信息,如果路由器需要决定是不是要检查数据报的内容的时候对上层数据内容进行语法分析。这种分析的代价可不小。现在的情况是，网络终端利用它向网络申请资源，在这种表明“申请” 的信号中，包含着如下的信息：业务的种类？ 使用者类型？ 什么时间？ 需要多大带宽？ 其他参考信息？ 网络在接收到上类信息后，会根据实际情况为此次连接分配一个优先代码，用户利用优先代码进行信息传递时，网络不需重新对业务进行分析与判别，从另外一个角度来说，利用RSVP 能从一定程度上减少网络对信息处理的时延，提高网络节点的工作效率，改善信息传输的服务质量（QoS）。实时应用用RSVP是为了在传输路径中保持必要的资源以保证请求能确保到达。
RSVP是IP路由器为提供更好的服务质量向前迈进的具有深刻意义的一步。传统上IP路由器只负责分组转发，通过路由协议知道邻近路由器的地址。而RSVP则类似于电路交换系统的信令协议一样，为一个数据流通知其所经过的每个节点（IP路由器），与端点协商为此数据流提供质量保证。RSVP协议一出现，立刻获得广泛的认同，基本上被任为较好地解决了资源预留的问题。

在前面我们讨论了一些实时媒体控制的相近的四个协议。在这里我再概括性的说明一下：
RTP是实时数据传输协议。它提供时间标志，序列号以及其它能够保证在实时数据传输时处理时间的方法。它是依靠RVSP保证服务质量标准的。

RTCP是RTP的控制部分,是用来保证服务质量和成员管理的。

RTSP是开始和指引流媒体数据从流媒体服务器。它又可叫做"网上录像机控制协议".它是提供远程的控制，具体的数据传输是交给RTP的。

RSVP是Internet上的资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。它是不传输数据的

实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。

　　RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。