基于MPEG-4和RTP的网络视频监控系统研究.doc

基于MPEG-4和RTP的网络视频监控系统研究文/北京邮电大学通信网络综合技术研究所 龚猷龙 刘勇摘 要：随着计算机、网络及多媒体通信技术的发展，视频监控在业界得到了广泛的应用，许多先进的技术被逐渐引入视频监控系统。本文采用了递进的方式，先介绍了IP网络视频监控系统的组成及其关键技术，接着阐述了MPEG-4视频流的RTP分组净荷格式。最后，在视频流的RTP传输中，着重分析了MPEG-4视频流的封装格式，并给出相应的实现方法。关键词：视频监控，MPEG-4，RTP，视频流封装一、引言随着计算机、网络及通信技术的快速发展和成熟，视频监控系统从模拟视频监控系统逐渐转向以数字化和网络化为特色的网络数字视频监控系统。早期的模拟视频监控系统主要应用于闭路电视的监控，监控的范围仅限于本地网络。近十多年来，市场对视频监控业务的需求量越来越大，特别是需求形式越来越广泛。计算机系统处理能力的提升，图像压缩技术的更加完善，以及互联网应用的蓬勃兴起，这些技术的进步为视频监控的发展提供了保证，给视频监控系统带来了巨大商机。受到市场和技术的驱动，视频监控的应用领域和应用的灵活性也已经远远超出传统的安防监控所定义的范畴，其应用面得到了大大地推广，逐步渗透到许多对视频业务有极大需求的新兴行业市场。如银行监控、交通监控、医疗监护、通信机房监控等系统，给人们的生活和工作带来了极大的便利。视频监控系统既可以采用专线组网，也可用IP方式组网。采用专线组网的视频监控系统具有带宽充足、图像质量好、易维护等特点，但是费用高。TCP/IP网络是面向全球用户，资源共享是TCP/IP最大的优点。TCP/IP是目前最流行采用的互联网技术，而且使用价格低廉，满足大众化的需求，其应用前景十分广阔。因此，采用IP组网是视频监控系统朝网络化发展的趋势。下文主要介绍IP网络视频监控系统的特点及其采用的关键技术。二、IP网络监控系统结构IP网络视频监控系统主要由视频监控端、服务器端和客户端组成，如图1所示。其中视频监控端包括若干台摄像机、一台矩阵切换器和一台MPEG-4编码器；服务器端由一个主控中心组成，包括用于业务平台管理和调度的网络服务器，MPEG-4解码器和显示设备；客户端包括一个接入IP网的集线器和各个PC机终端。各部分通过以太网相连接。图1 IP网络监控系统从网络视频监控系统可以看出，系统中主要存在两种数据流：视频监控端向客户端发送的媒体流和客户端向视频监控端发送的控制信息流。系统的数据流程如图2所示。?图2 系统数据流程图传输两种数据流所采用的协议是不一样的。控制信息流对服务器平台业务管理、客户端与视频端的接入、调度及解码显示等都是十分重要的，可见在控制信息流的传输过程中不允许有丢包，因此采用面向连接、可靠传输的TCP协议传输控制信息。然而TCP传输需要的网络开销较大，通过降低有效性来换取传输的可靠性，不能达到实时传输媒体流的目的。UDP协议是面向无连接、不可靠传输的控制协议，传输之前不需要先建立连接，在传输时延及带宽利用率方面都要强于TCP，正好满足了媒体流实时性的特点，通常采用UDP作为媒体流的传输协议。不过，采用UDP传输媒体流同样存在不可靠性的问题：UDP数据包没有编号，无法提供差错控制，也不保证包不丢失，更不能加载媒体流的时间信息。导致在客户端显示的视频图像存在延时和抖动，在一定程度上仍然不能达到实时传输的效果。表1给出的是中国电信有关IP承载网络端到端通信质量要求，可供参考。表1 网络通信质量要求丢包率上限网络延时上限延时抖动上限1/1000150ms50ms为了弥补UDP协议存在的缺点，使IP网络具有提供媒体流实时传输的能力，IP网络视频监控系统采用由IETF制定的实时传输协议RTP。RTP由两个相关协议组成：实时传输协议RTP和实时传输控制协议RTCP。视频压缩编解码技术是视频监控系统的核心技术。视频监控端采集的原始数据量很大，不适合直接在带宽受限的网络中传输，需要先对原始数据进行压缩。视频压缩标准主要有两个系列，一个是由ITU-T制定的H.26x系列，另一个是由ISO制定的MPEG-x系列。目前比较看好的国际标准是H.264和MPEG-4。综合考虑算法的复杂度、性能、市场占有率及今后的发展等因素，选择MPEG-4作为视频监控系统的压缩编码框架。三、视频监控系统的关键技术1MPEG-4压缩标准 MPEG-4标准采用的仍然是以前标准(H.261/3和MPEG-1/2)的基本编码框架，即典型的三步：预测编码、变换量化和熵编码。新的压缩编码标准都是基于优化的思想进行设计的，将先前标准中的某些技术加以改进，例如在原来的基础上提出1/4和1/8像素精度的运动补偿技术，使得预测编码的性能大大提高，或加入以前标准中没有的新技术。与MPEG-1和MPEG-2有很大的不同，MPEG-4标准不仅仅给出了具体压缩算法，它是针对数字电视、交互式多媒体应用、视频监控等整合及压缩技术的需要而制定的。MPEG-4将多种多媒体应用集成在一个完整的框架里，为不同的应用提供相应地档次和级别。 MPEG-4标准中最大的特点是：采用了基于对象的编码理念。传统的视频编码方法依照信源编码理论的框架，利用输入信号的随机特性达到压缩的目的，而并没有考虑信息获取者的主观意义和主观特性，还有事件本身的具体含义、重要性及后果等。MPEG-4标准中引用了视频对象的概念，打破了过去以宏块为单位编码的限制，其目的在于采用现代图像编码方法，利用人眼视觉特性，抓住图像信息传输的本质，从轮廓、纹理的思路出发，支持基于视频内容的交互功能。以上这些都是根据人眼感兴趣的一些特性提出来的。 视频序列中每一帧由不同的场景组成，这些场景可以根据人的主观性进行划分，每一个场景可看成是一个VOP，而同一对象连续的VOP称为视频对象VO。VO可以是视频序列中的人物或具体的景物，也可以是计算机生成的二维或三维图形。视频监控系统中，视频监控端主要采集的是自然景物的图片，因此这里只考虑MPEG-4中自然视频序列的编码档次。MPEG-4是以VOP为单位进行编解码，编解码过程如图3所示。 图3 MPEG-4编解码基本过程 编码器包含三个主要部分，形状编码、运动信息编码及纹理编码。(1)? 形状编码VOP的形状信息有两类：二值形状信息和灰度形状信息。二值形状信息用0，1来表示VOP的形状；灰度形状信息用0255之间的数值表示VOP内各像素的透明度。目前的标准中采用矩阵的形式来表示二值或灰度形状信息，称之为位图(或alpha平面)。试验表明，位图表示法具有较高的编码效率和较低的运算复杂度。(2)? 运动信息编码VOP的编码有三种模式，即帧内编码模式(I-VOP)，帧间预测编码模式(P-VOP)，帧间双向预测编码模式(B-VOP)。为了适应任意形状的VOP，MPEG-4引入了图像填充技术和多边形匹配技术。对于标准宏块的运动估计和补偿，可采用传统的基于块的方法。而对于VOP边界的轮廓宏块，则要采用图像填充技术，再用多边形匹配技术进行运动估计/补偿。(3)? 纹理编码一个视频平面的纹理信息可以表示为亮度Y和两个色度成分Cr、Cb。在帧内情况下，纹理信息直接包含亮度和色度成分，在运动补偿的情况下，纹理信息表示经过运动补偿后的残差。2RTP协议 RTP是由IETF音视频工作组制定的实时传输协议，专门用于交互式语音、视频传输等实时多媒体应用。RTP可以在点对点或点对多点的传输情况下工作，而且通常使用UDP来传送数据。当应用程序开始一个RTP会话时，同时还要开启RTCP协议，因为RTP协议并不能提供差错控制和保证的网络的QoS，需要和RTCP配合使用。此时的会话将使用两个端口：一个给RTP，另一个给RTCP。 RTP协议的设计目的是提供实时数据传输中的时间戳信息及各数据流的同步功能。RTP提供序列号以恢复数据包的顺序，实现丢包检测，为实时传输提供网络拥塞等信息；提供时间戳用于媒体同步，使接收端按正确的速率回放数据；提供同步源标志使接收端有可能获得有关发送方的信息。RTCP的主要功能是提供有关QoS的信息反馈。网络终端系统可根据这些反馈信息来调整数据的发送速率。RTCP包共有五种类型：发送端报告(SR)、接收端报告(RR)、源描述(SDES)、BYE和APP。其中，SR用来描述发送端的发送和接收统计数据；RR用来描述接收端的接收统计数据。这些统计数据包括发送包数、发送字节数、累计丢包数、已收报文的最大序列号、达到时间间隔抖动等。实时传输协议RTP和传输控制协议RTCP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传输RTCP包。服务器利用RTCP包中所包含的信息动态地改变传输速率，甚至改变有效载荷类型。因此，RTP用来传送实时多媒体数据信息，而RTCP用来传送控制信息。四、视频监控系统的视频流传输视频监控端采集的视频数据，先被送入MPEG-4编码器进行压缩，生成MPEG-4视频流，然后将此视频流打包成RTP数据包再传输。以下将详细分析这个过程。1RTP打包传输视频流通过RTP打包传输，RTP数据包由RTP包头和不定长的连续媒体数据载荷组成。RTP数据包如图4所示，其中的载荷是MPEG-4视频流。 4 RTP数据包格式 几个关键字段的含义前面已给出，RTP包头字段的含义与以前的IP数据包头的类似，这里不再详细说明。其中，MPEG-4 Visual stream表示MPEG-4的视频流，被称为RTP分组净荷(payload)。采用RTP协议发送MPEG-4码流的好处：(1)可以将MPEG-4码流和其他的RTP净荷相同步；(2)可以通过RTCP监视MPEG-4的传送性能；(3)使用RTP混合器能将从多个终端系统接收到的MPEG-4和其他实时数据流复合成一系列合并的码流；(4)通过使用RTP转换器实现数据类型的转换。2MPEG-4视频流格式 视频监控系统中，视频压缩编码采用的是MPEG-4标准。而MPEG-4标准定义了Profile&Level来适应不同的应用。Profile定义了一个码流可以采用哪些技术，Level则规定了复杂度，譬如支持多大的图像格式和大小，需要的缓存量。先进简单档次(Advanced Simple Profile)是为了适应因特网上流媒体应用的需求而新增加的，在简单档次的基础上改善了压缩性能，而且支持隔行扫描视频编码。本文讨论的视频监控系统采用的是MPEG-4标准中的先进简单档次(ASP)。（1）视频流的分片规则由于IP网络中传输的分组大小受限制，加上MPEG-4视频流是以VOP为单位编码的特点，传输MPEG-4视频流时，需要先将视频流加上包头信息，进行RTP打包封装。MPEG-4视频流的打包要遵循两个原则： 为了提高效率和充分利用MPEG-4的编码特性，以VOP为单位进行打包； 考虑IP分组网络传送包长的限制，打包的长度L小于最大传输单元(MTU)。基于以上的两个原则，相应给出码流的分片规则如下： 原则上是：一个VOP包单独放入单个RTP包中。但是，一个VOP在一个RTP包中放不下的情况下，此时要考虑将VOP进行分片，分别放入多个RTP包，此时须把VOP头部信息复制到每个RTP包，以去除包间的相关性，达到丢包的鲁棒性； 当一个VOP太小时，此时为了提高RTP传输的有效性(减少包数和降低开销)，需要将多个VOP放入一个RTP包中，这些VOP应该按照解码顺序放入RTP中。但是，即使最后一个包中仍有剩余空间，也不能将另一VOP中的宏块放入此包中； 同属于一个VOP的控制信息和数据信息必须同时出现在一个RTP包中； 一个VOP头不能分开放在两个或两个以上的RTP包中； 当将多个视频包串联到一个RTP包中时，VOP头不应放到RTP负载的中间。（2）视频流的封装MPEG-4视频流是RTP数据包中的载荷， 给MPEG-4视频流打包的目的是为了适应网络的传输，让解码端能够恢复MPEG-4数据流并进行回放。依照MPEG-4视频流的分片规则，可以将包格式简单的分为帧头配置信息和基本流信息。每个VO可对应多个视频对象层(VOL)，而且每个VOL可能属于多个VO。图5是MPEG-4视频流封装结构。图5 视频流封装结构 从图中可以看出，传输视频对象每一层的基本流信息时，都需要将这个基本流的属性同时传输。比如，传输VO1 Layer1的基本流信息，需要将所属的视频序列头、视频对象头和视频对象层头一同传输。而且传输VO1 Layer2的基本流信息时，也需要将这些属性再次传输。既可以保证基本流信息的完整性，又具有鲁棒性。 MPEG-4视频流由若干个视频对象序列(VS)组成。VS的每一帧可分割为一些任意形状的VO，一个视频对象VO又是由同一VOP的连续系列构成。在具体的实现中，需用分层的方式组织各个头信息。图6给出了视频流的分层语法结构。 图6 MPEG-4视频流分层结构上图中每个模块代表一个函数实现，模块的名字取于对应函数的首写字母组合。对应关系及功能如下： VS：VisualObjectSequence()，表示完整的MPEG-4的场景，给出了档次和级别信息； VO：VisualObject()，表示一个视频对象对应着场景中的一个特定对象； VOL：VideoObjectLayer()，给出了当前视频流的一些特性； GOP：Group_of_VideoObjectPlane()，提供码流的随机访问点； VOP：VideoObjectPlane()，包含了视频对象的运动参数、形状信息和纹理信息； MST：Motion_shape_texture()，给出了运动参数、形状信息和纹理信息； VPH：Video_packet_header()，视频包头信息； DPMST：data_partitioned_motion_shape_texture()，运动信息和纹理数据分开编码； CMST：combined_motion_shape_texture()，运动信息和纹理数据联合编码； MB：Macroblock()，给出了宏块数据，包括运动矢量和纹理信息。从以上的实现函数可以看到，在加入一系列头信息的情况下，整个视频流是以VOP对单位封装传输。而每个VOP的编码都是以宏块为单位，有关宏块级的数据流分析就不在加以描述了。MPEG-4视频流出现在RTP数据包的载荷部分，RTP数据包的结构比较清晰，因此RTP的组包过程比较容易实现。然而，MPEG-4视频流的分析过程非常复杂。MPEG-4视频标准一共定义了19种编码档次，其中用于自然编码的档次有15种，每一档次可能支持几种视频对象和级别。可见，设计一个视频监控系统，MPEG-4视频流的封装过程是十分重要的。五、结束语在视频监控系统的研究中，MPEG-4视频流实时传输是网络监控系统的一个重要课题，也是网络化进程中的难题。近年来，网络技术和视频压缩编码技术取得了极大的进步，特别是MPEG-4标准和RTP网络传输协议的提出，很好的解决了这个难题。文中将这两种关键技术相结合，给出了一种视频监控系统的码流传输方案。但是，随着科技的不断发展和市场需求的日益增多，目前的技术可能会被继续淘汰。因此不能安于现状，需要在网络音视频传输技术领域开展更多、更深入的研究。本备忘录的状态本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。版权声明Copyright(C)TheInternetSociety(2001).摘要本文描述了在RTP包中传输文本交谈内容的方法，关于文本交谈会话内容在ITU-T建议（T.1401）中有详细说明。文本交谈可以用来单独传输或与音视频等交谈工具一起构成多媒体交谈服务。本RTP负载包含可选的已传输数据包的冗余文本来降低包丢失的风险。冗余码参照RFC2198。目录1简介 21.1术语 32.RTP用法 32.1RTP包头 32.2附加头 42.3T.140文本结构 43.推荐过程 43.1基本推荐过程 53.2补偿丢包的推荐过程 53.3补偿乱序包的推荐过程 53.4使用冗余时的“静音期”传输 54.范例 65安全性考虑 76.MIMEMEDIATYPEREGISTRATIONS 76.1RegistrationofMIMEmediatypetext/t140 7鸣谢 8作者地址 8参考 8版权说明 9致谢 91简介本文定义了一种用于在RTP包中传输文本交谈会话内容的负载格式，文本交谈会话内容在ITU-T建议（T.1401）中有详细说明。文本交谈可单独传输或与音视频等交谈工具共同构成多媒体交谈服务。文本交谈中的文本应尽快传输，或者经过一个小的缓冲延迟。文本的输入通常是以键盘、手写识别、语音识别或是其它输入方法。字符的输入率通常为每秒几个字符。这样，期望的字符传输率也较低。通常每个包中只有很少的新字符需要传输。在T.140中指定文本和其它T.140元素必须以经过UTF-8变换的ISO10646-1码来传送。这些有助于实现国际化应用，并且易于处理现代信息技术环境中的文本。本文RTP负载中的文本编码严格遵守T.140，没有任何附加帧。通常是UTF-8编码的ISO10646单字符。T.140要求字符按照原始顺序，没有重复的传输。文本交谈的使用者希望文本传输没有或尽可能少丢失。当然，如果能标识出丢失的信息，则丢失的可接受程度会高些。因此，这里介绍了一个基于RTP的机制。它将按照原始顺序，无重复传输，并且提供丢失检测和指示。它同时也提供一个可选方案，利用重复的冗余数据来降低丢失文本风险。考虑到包开销通常远远大于T.140内容，传输通道中增加冗余数据造成的负担很小。1.1术语本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建议”，“或许”，“可选的”在RFC21194中解释。2.RTP用法当RTP传输中需要传输T.140文本交谈，应该使用本文所述的负载。这种负载格式的文本交谈RTP包的格式包括：一个RTP头（在RFC18892中有定义），其后紧接着是一个T.140数据块（这里被定义为“T140block”）。该负载格式没有附加头。T140块包括1中定义的一个或多个T.140码元素。大部分T.140码元素为ISO106455单字符，但是也有一些是多字符序列。其中每个字符均为UTF-8编码6的一个或多个字节。这说明不管单个字符中有几个字节，每一块必须包含UTF-8码的整数倍。这也说明任何组合的字符序列（CCS）应该被放到同一块中。T140块可能会根据RFC21983所定义的负载格式传输冗余数据。这样，RTP头后将是一或多个冗余数据块头，个数与从携带的冗余T140块数相同，最后是此包的新T140块。2.1RTP包头每个RTP包开始于一个固定的RTP头。下面列出了用于T.140文本流的几个RTP头字段。负载类型（PT）：RTP负载类型的分配是使用该负载格式的RTP框架特定的。对于利用动态负载类型号的协议子集，这种负载格式被命名为T140（参照第六节）。如果按照RFC2198使用冗余数据，负载类型中必须指定负载格式（RED）。顺序号：顺序号必须严格按照每个新传送包以一递增。它用于包丢失和乱序检测，同时也可以用于获取冗余文本，重组文本和标记丢失文本。时间戳：RTP时间戳记录了包中主文本块采样时间的近似值。必须使用1000赫兹的时钟频率。连续包不能使用相同的时间戳。由于包不按固定间隔发送，所以时间戳不能直接被用于指示包丢失。2.2附加头本负载格式没有定义专门的附加头。当要按RFC2198传输冗余数据时，RTP头后紧跟者一个或多个冗余数据块头，每个冗余数据块都要有一个对应的冗余数据块头。这些头部均提供了时间戳位移和相应的数据块长度，以及指示了这种负载格式(T140)的负载类型号。2.3T.140文本结构T.140文本是按T.140协议规定经过UTF-8编码的，没有额外组帧。当用该格式传输冗余数据时，发送者会选择每个包中要传输的T140block数。数越高则将丢包保护性越好，但同时也会增加数据传输率。由于数据包并非按一定的时间间隔产生，如果不提供附加信息，时间戳在包丢失时就无法标识出该包。冗余数据头并没有提供顺序号，所以必须遵循附加规则才能将丢失主数据所对应的冗余数据正确的插入T140blocks主数据流中：1. 每个冗余数据块必须与先前传输原始数据的T140块数据相同，并标识为相同的时间戳位移。2. 冗余数据必须按照时间顺序放置，最近的冗余T140块位于冗余区的最后。3. 必须包括从最早的T140blocks到新数据块前的T140blocks所有的T140块，。通过这些规则，冗余T140块的顺序号可以从当前RTP头的序号反向推算得到。结果就是负载中的所有文本都是连续且顺序的。3.推荐过程这部分描述了负载格式使用的推荐过程，根据接受包的信息，接收者可以：1. 把错乱文本重新排序。2. 标识丢失文本。3. 用冗余数据补偿丢失包。3.1基本推荐过程只有合法的T.140格式的数据包才被传输，T.140数据的排序要使用顺序号。在接收端，将RTP顺序号与最后一次正确接收包的序号相比较，如果是连续的，就从中取出T140block。3.2补偿丢包的推荐过程为了减少包丢失时的数据丢失，可以根据RFC2198在包中使用冗余数据。如果无法得知网络条件，建议每一包中只使用一个冗余T140块。如果RTP序号出现空隙，且后续包中的冗余T140块可用，则可以通过包中RTP头的序号逆向推算出冗余T140块的序号。如果该冗余T140块的序号与丢失的相吻合，就用冗余T140块来替换丢失T140块。无论是否使用冗余数据，都应该在T140块的接收流中插入一个丢失文本标记来标志丢失的数据，见ITU-TT.140附录。3.3补偿乱序包的推荐过程对于乱序包的检测，接收端应该采取下属程序。如果接收包序号有空隙，但没有可用的冗余数据来填充那个空隙，则接收包将被存储在缓存中来等待丢失包的到达。建议等待时间限于0.5秒。如果使用了冗余，并且冗余数乘以T.140缓冲时间比0.5秒长，则等待时间应延长到该乘积。如果空隙数据包在限制时间内到达，则将它被插入到空隙中，这样从空隙前沿开始的T140块就恢复连续了。任何没有在限制时间内到达的T140块将被视为丢失。3.4使用冗余时的“静音期”传输当使用冗余传输模式且T.140没有数据要传输时，最后传输的一个T140块有可能在作冗余数据传送之前就失效。这样就不能对文本输入序列的末尾提供有效的丢包保护。为了要避免这种情况，应该传送一个0长度的携带冗余数据的原始T140块。根据2.3节，为了能正确推算冗余T140块的序号，任何被当作原始数据为0长度的T140块必须如同正常文本块一样在接下来的包中当作冗余传输。最后一个T140块的冗余不应该由重复传送同一个包（相同序号）来解决，因为这样会造成RTCP报告的包丢失数量减少。4.范例这是一个没有冗余的T140RTP包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|T140PT|顺序号|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|时间戳(1000Hz)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+T.140编码数据+|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+这是一个携带冗余数据的RTP包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|REDPT|主序号|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|原始数据时间戳|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1|T140PT|R时间戳位移|R块长度|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|T140PT|+-+-+-+-+-+-+-+-+|+RT.140编码冗余数据+|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PT.140编码原始数据|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+附图：RTP文本包的例子5安全性考虑既然本负载格式的目的是在文本交谈中携带文本，加密的安全性度量就变得十分重要。文本传输的数量很少，这样我们可以选择任何加密方法来对T.140会话或者整个RTP包进行加密。如果数据包中包含了冗余数据，要使用同RFC2198一样的安全性考虑。6.MIMEMediaTypeRegistrations本文档描述了一种新的RTP负载名称和相应的MIME类型，T140(text/t140).6.1RegistrationofMIMEmediatypetext/t140MIMEmediatypename:textMIMEsubtypename:t140必需参数:无可选参数:无编码考虑:按RFC2793规定传输T140文本。安全性考虑：无互操作考虑:无已发行规范:ITU-T建议T.140，RFC2793.使用该媒体类型的应用:文本通信终端和文本会议工具。附加信息:无Magicnumber(s):无文件扩展:无Macintosh文件类型码:无联系办法:GunnarHellstrome-mail:gunnar.hellstromomnitor.se预期使用:COMMONAuthor/Changecontroller:GunnarHellstrom|IETFavtWGgunnar.hellstromomnitor.se|c/oSteveC鸣谢感谢StephenCasner和ColinPerkins在本文写作时给予的细查和建议。感谢Ericsson公司的MickeyNasiri提供的实验环境。感谢MicheleMizarro验证了负载格式的可用性。作者地址GunnarHellstromOmnitorABAlsnogatan7,4trSE-11641StockholmSwedenPhone:+46708204288/+46855600203Fax:+46855600206EMail:gunnar.hellstromomnitor.se参考1ITU-TRecommendationT.140(1998)-Textconversationprotocolformultimediaapplication,withamendment1,(2000).2Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,RTP:ATransportProtocolforReal-TimeApplications,RFC1889,January1996.3Perkins,C.,Kouvelas,I.,Hardman,V.,Handley,M.andJ.Bolot,RTPPayloadforRedundantAudioData,RFC2198,September1997.4Bradner,S.,KeywordsforuseinRFCstoIndicateRequirementLevels,BCP14,RFC2119,March1997.5ISO/IEC10646-1:(1993),UniversalMultipleOctetCodedCharacterSet.6Yergeau,F.,UTF-8,atransformationformatofISO10646,RFC2279,January1998.版权说明Copyright(C)TheInternetSociety(2000).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.ThisdocumentandtheinformationcontainedhereinisprovidedonanASISbasisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE. 致谢FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： * RTP 传送具有实时属性的数据； * RTP 控制协议（RTCP） 监控服务质量并传送正在进行的会话参与者的相关信息。RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。 协议结构1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC (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 贡献源标识符。识别该数据包中的有效载荷的贡献源。 RTP 控制协议（RTCP）采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的 UDP 端口号。 RTCP 主要完成四个功能服务： 1. RTCP 提供数据分发质量反馈信息。这是 RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。 2. RTCP 为 RTP 源携带一个持久性传输层标识符，称为规范名或 CNAME 。由于一旦发现冲突或程序重启时， SSRC 标识符会随之改变，所以接收方需要 CNAME 来跟踪每一个参与者。同时接收方还要求 CNAME 能够与一组相关 RTP 会话中来自于给定参与者的多重数据流相关联，例如同步视频和音频。 3. 上述前两个功能要求所有的参与者都要发送 RTCP 包，因此必须控制速率以便 RTP 按比例增加大量的参与者。通过每一个参与者发送各自的控制包给其它所有参与者，每一个参与者能够独立观察到参与者数量，该数量可用来计算控制包的发送速率。 4. OPTIONAL 功能用于传送最少会话控制信息，例如在用户界面显示参与者标识。这对于“松散受控”会话（在没有成员控制或阐述协商的情况下，参与者可以加入或退出该会话）是非常有用的。 上述功能 1 3 适用于所有环境，尤其是 IP 组播环境。 RTP 应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。在某些情况下如单向链接中，不可能有来自接收方的反馈，所以 RTCP 的传输就可能由发送方和接收方分别独立控制。协议结构23816 bitVersion PRCPacket typeLength* Version 识别 RTP 版本。 RTP 数据包中的该值与 RTCP 数据包中的一样。 当前规范定义的版本值为 2 。 * P 间隙（Padding）。设置时， RTCP 数据包包含一些其它 padding 八位位组，它们不属于控制信息。 Padding 的最后八位是用于计算应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding 字段。在一个复合 RTCP 数据包中，只有最后的个别数据包中才需要使用 padding ，这是因为复合数据包是作为一个整体来加密的。 * RC 接收方报告计数。包含在该数据包中的接收方报告块的数量，有效值为 0 。 * Packet type 包括常量 200 ，识别这是一个 RTCP SR 数据包。 * Length RTCP 数据包的大小（32 位字减去 1），包含头和任意间隙 （偏移量的引入使得 0 成为有效值，并避免了扫描复合 RTCP 数据包过程中的无限循环现象，而采用 32 位字计数方法则避免了对 4 的倍数的有效性校验）。RTP/RTCP（实时传输协议/实时传输控制协议）基于UDP派生出的协议，并增加了对实时传输的控制。一般用于网上传输实时视频数据，比如远程视频监控，视频点播等。有一本名叫多媒体网络传输协议的书上对此2个协议的结构和原理做了比较详细的介绍，好象是清华大学出版社出版的。? 我去年做远程视频监控系统时，曾用基于2个协议，用Wonsock工具封装了一个网络传输动态连接库，专门用于局域网组播传输实时视频数据。以下是我针对此2个协议定义的相关C结构。? /*Current protocol version. */#define RTP_VERSION? 2#define MIN_SEQUENTIAL? 1#define RTP_SEQ_MOD (116)#define RTP_MAX_SDES 255? /* maximum text length for SDES */#define MID_BUFFER_NUM? 2#define MAX_DROPOUT? 25typedef enum ? RTCP_SR? = 200,? RTCP_RR? = 201,? RTCP_SDES = 202,? RTCP_BYE? = 203,? RTCP_APP? = 204 rtcp_type_t;typedef enum ? RTCP_SDES_END? = 0,? RTCP_SDES_CNAME = 1,? RTCP_SDES_NAME? = 2,? RTCP_SDES_EMAIL = 3,? RTCP_SDES_PHONE = 4,? RTCP_SDES_LOC? = 5,? RTCP_SDES_TOOL? = 6,? RTCP_SDES_NOTE? = 7,? RTCP_SDES_PRIV? = 8 rtcp_sdes_type_t;/*?* RTP data header?*/typedef struct ? unsigned int version:2;? /* protocol version */? unsigned int p:1;? /* padding flag */? unsigned int x:1;?