毕业设计（论文）基于RTP协议的流媒体的实时传输的实现.doc

《毕业设计（论文）基于RTP协议的流媒体的实时传输的实现.doc》由会员分享，可在线阅读，更多相关《毕业设计（论文）基于RTP协议的流媒体的实时传输的实现.doc（74页珍藏版）》请在三一办公上搜索。

1、 毕 业 设 计（论 文）题 目：基于RTP协议的流媒体的实时传输的实现系 别：电子信息科学系专 业：电子信息科学与技术班 级：学生姓名：学 号：指导教师：学位论文原创性声明本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。本人完全意识到本声明的法律后果由本人承担。作者签名： 钟蕾 2009年 6 月 14 日 学位论文版权使用授权书本学位论文作者完全了解学校有关保障、使用学位论文的规定，同意学校保留并向有关学位论文管理部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本

2、人授权省级优秀学士学位论文评选机构将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。本学位论文属于1、 保密 ，在_年解密后适用本授权书。2、 不保密。（请在以上相应方框内打“”）作者签名： 钟蕾 2009年6月14日 导师签名： 张涛 2009年6月15日摘要基于IP的网络中提供的尽力而为的服务并不适合流媒体的传输4。本文的研究项目由网络流媒体传输需求提出，旨在研究基于RTP协议的流媒体的实时传输，使之能够适应网络状态的变化。论文的论述从以下三个方面展开：（1）本文首先分析了网络多媒体应用中常用的流媒体技术，视频压缩编码技术。（2）本

3、文深入分析了RTP/RTCP的特点、内容，认为该协议非常适合多媒体信息的网上传输。（3）为了实现实时传输，本文采用sun公司所提供的平台。利用JAVA提供的宽松的格式支持和基于JMF组件对象模型的特征，研究了JMF的体系结构、基本原理和基本构件，利用JMF的体系结构和已有的采集、编码组件，实现了一套完整的流媒体传输实验模型。关键词：RTP；流媒体传输；JMF；InternetAbstractThe best-effort service based on IP provided by Internet isnt suitable for the transmission of Streamin

4、g Media information.Coming from a Streaming Media transmission need in networked multimedia application,the research project the thesis discusses is to research an RTP-based Streaming Media transmission which can adapt to the changes of network states.The thesis includes the following three parts: F

5、irstly,this thesis analyzes stream media technology and video compression coding technology in networked multimedia application. Secondly,this thesis lucubrates the contents and characters of RTP/RTCP and thinks that RTP is well suitable for the Streaming Media information transmission.Fourt-hly,in

6、order to realize RTP and transmission control policy,this thesis makes use of the platform of SUN .Using the wide variety of formats supported by JAVA and the characters based on JMF component object model,this thesis researches the architecture of JMF,its basic theory and construction of its basic

7、component. With the help of existing capture and encode components,making use of JMF architecture,this thesis realizes an integrated Streaming Media transmission experiment model.Keywords: RTP; Streaming Media Transmission;JMF;Internet目录第一章绪论11.1课题的背景11.2本课题所做的工作11.3流媒体技术21.3.1视频技术发展的现状21.3.2多媒体数据压缩

8、技术31.4实时传输协议RTP/RTCP71.4.1 RTP的特点71.4.2 RTP的数据包格式81.4.3 RTP在协议层中的位置91.4.4 RTCP的控制功能101.4.5 RTCP发送方报告数据包格式11第二章 总体方案设计142.1 方案论证142.1.1方案一.采用DirectShow框架实现流媒体实时传输142.1.2 方案二. 在嵌入式平台下实现流媒体实时传输152.1.3 方案三. 采用JAVA媒体框架（JMF）实现流媒体实时传输162.2.系统总体设计172.3 系统处理流程图172.4 系统模块的划分及功能描述182.5 JMF体系结构182.6 建立Java多媒体开发

9、环境所需的硬件和软件192.6.1 硬件环境192.6.2 软件环境192.7一种流媒体传输控制方法的提出202.7.1流媒体传输控制的特点202.7.2流媒体传输控制的研究212.7.3 本文提出的控制方法23第三章 用Java实现流媒体实时传输243.1服务器端媒体处理程序243.1.1 发送端程序流程图243.1.2 流媒体的捕获253.1.3 流媒体的压缩263.1.4 流媒体的实时传输273.1.5 停止传输流媒体293.2 采用JMF RTP API 接收流媒体数据303.2.1 JMF的回放机制303.2.2接收端程序流程图313.2.3 流媒体的接收323.2.4 流媒体解压缩

10、、实时播放333.2.5 监听接收媒体流事件343.2.6 监听数据是否接收完毕353.3 本章小节36第四章 系统测试374.1 系统测试结果与分析374.2本章小节37第五章 结束语38致 谢39参考文献40附件42第一章绪论1.1课题的背景目前，多媒体技术和计算机网络通信技术都有了很大的发展。主要表现在视频压缩编码算法的不断完善，IP网规模的进一步扩展。伴随着流媒体技术的出现，诸如视频会议、视频点播之类的网络多媒体应用开始进入人们的生活。人们又一次体会到了信息技术带给人们的方便和无穷乐趣。在实际应用中，许多网络流媒体传输还存在着模拟信号的传输。采用模拟信号传输带来的问题就是系统的造价高，

11、建设周期长，适应性不强。当系统的规模很大时，需要铺设的电缆线又粗又长。一旦系统结构变化，还要铺设新的管线，有时还需要更改现有的线路。这使得系统的实施和更新变得非常不方便。于是，许多研究人员将目光投向了规模不断扩大的IP网。基于分组交换的IP网具有良好的扩展性，也不需要专门铺设流媒体电缆和控制电缆，成本低，可充分利用现有的网络资源。然而，TCP协议严格的建立连接、断开连接的三次握手和差错重发机制并不适合数据量大、实时性强的流媒体数据。面向无连接的UDP协议由于毫无数据纠错和排序，似乎也不太符合要求。而且，网络还不够强大，带宽资源有限，不能很好的保证服务质量。因此，提出了研究IP网络中的流媒体传输

12、控制，希望利用现有的网络协议和网络资源，对服务质量加以控制以获得较好的多媒体传输效果。此外，为了实现流媒体传输控制的策略，流媒体的捕捉和回放也是应解决的问题之一。由SUN提供的JMF技术基于组件对象模型技术，支持宽松的格式变化，提供高品质的流媒体捕捉和回放。利用它可以在普通微机中实现流媒体的客户端处理，还可以提高系统的通用性和可扩展性。1.2本课题所做的工作本文的研究目标是：研究一种基于RTP协议的流媒体实时传输。本课题的工作有： （1）介绍网络多媒体视频技术发展的现状，流媒体技术，多媒体数据压缩技术。 （2）研究了用于流媒体信息传输的实时传输协议RTP/RTCP。 （4）研究了基于任何平台的

13、流媒体处理技术JMF的体系结构，基本原理。 （5）设计一个小型流媒体传输实验模型系统，实现了基于RTP的流媒体传输控制方法。1.3流媒体技术流媒体（Streaming Media），就是应用流技术在网络上传输的多媒体文件。流（Streaming）是对在网路上传输特别的编码数字媒体内容如音频、视频、动画片、图形、照片、文本到最终用户的一种描述1。只要是用流服务器传输媒体，通过网络向用户计算机连续、实时传送数据包，用户能够立即、不中断播放，并且不需要固定的存储空间在最终用户的磁盘上，都可以说是流。众所周知，在Internet上传输音/视频（A/V）等多媒体信息，目前主要有下载和流式传输两种方式。传

14、统的文件传输方式是，一个互连网的用户在观看一个视频文件前必须要完全下载此文件。传统文件30秒的视频剪辑在正常的每秒56Kbps Internet接入下，传输需要将近30分钟的时间。那么就算是一个广告短片最少也需要1个小时的下载，这还是在网络状况极其良好的情况下。下载一个A/V文件花上数小时可谓是家常便饭。显然这个速度是大多数人都无法忍受的。通常A/V文件相对于其他类型的文件而言容量较大。因此，在网络带宽的限制下，必须要寻找别的解决方法。流技术正是为了绕过互连网的这个局限而设计的。观看的时候不用把文件完全下载，可以像看电视和听广播一样，在观看和收听前才接受图像和声音。实际上在服务器端一个媒体文件

15、就被分隔成很小的一片，而这一小片文件的长度是非常小的。但并不是说文件整体就变小了，原始文件依然很大。为了实现流，有些不太必要的数据就要丢失掉，以图像和文件的质量损失为代价使完整数据包传输更加快捷。1.3.1视频技术发展的现状 随着信息技术的发展，人们对信息的需求已不满足于传统的电报电话业务及传统的文件传输、电子邮件等数据业务，而是追求更高品质的集视频、图像、声音、文字、甚至动画等为一体的多媒体应用服务。视频技术是多媒体技术中的一个重要组成部分。视频信息以其数据量大、实时性强、冗余多等特点倍受研究人员的关注5。为了提高视频数据的传输效率，针对不同的视频信号产生了不同的视频数据压缩标准，如：MPE

16、G-1，MPEG-2，MPEG-4，H.263+。新的视频压缩标准H.264于2003年3月公布于众，新的压缩技术在测试过程中，其数据交换速度约为1Mbps，为宽带网络视频文件的传输铺平了道路。另外，视频信息的传输正从模拟向数字化方向转变。早期的INTERNET带宽窄、路由瓶颈、接入速率低、延迟大而不确定，使得实时性强的视音频流质量不能得到保证，限制了IP多媒体的广泛应用。第四代IP多媒体通信技术已被武汉大学成功攻克，并自主成功地研制了视讯会议系统、IP可视电话等一系列产品，并应用于上海APEC会议多媒体通信系统、酒泉卫星指挥中心等20多个单位，从而使我国成为世界上少数几个全面掌握第四代IP多

17、媒体通信技术平台核心技术的国家之一。第四代基于IP网络的多媒体通信技术是当前尖端的通信技术，此前基于电视广播技术交换的通信技术、基于电路交换的通信技术、基于分组交换的通信技术，被称为第一代、第二代和第三代。在“2002视频通讯技术应用与发展专题研讨会”上，基于IP的多媒体通信基础、IP视频通信的标准、电信级视频运营网络及视频通信中的质量保障等话题成为关注的热点。数据压缩标准的不断完善，多媒体视频技术和IP技术的发展和成熟，都为网络多媒体的应用发展提供了基础，带来了新的发展机遇。1.3.2多媒体数据压缩技术多媒体信息的编码技术是多媒体信息处理技术中的一个关键问题，多媒体数据的压缩标准为多媒体技术

18、的广泛应用提供了前提。数字化的视音频信息，其数据量非常大。不仅需要大容量的存储设备，而且对网络的传输和数据的处理也提出了很高的要求。即使硬件技术发展得再快，如果不对信息进行压缩，多媒体技术也很难有大的发展，多媒体技术的应用也会受到很大的限制。另外以视频和音频为典型代表的多媒体信息本身具有很大的压缩潜力。在一个视频帧中，像素与像素之间无论是在横向还是竖向上都有很大的相关性，而且，帧和帧之间的相关性很大，如对前一个帧的数据作微小的变化，可能就能够得到当前的信息。1.3.2.1 常用的视频数据压缩标准这方面的工作主要是由国际标准化组织（ISO）和国际电信联盟（ITU）来进行的。下面介绍其中几种视频压

19、缩标准2,3。1数字声像存储压缩编码标准MPEG-1。 该标准是为速率为1.5Mbps的数字声像信息的存储而制定的。由于MPEG-1是针对数字存储而制定的，因此它的编解码器是不对称的，编码器往往比位于用户端的解码器复杂得多。 视频分辨率为352X240（NTSC）和352X288（PAL），视频帧速率为30帧/秒，压缩后的视频数据量为1.2Mbps；音频按44.lKHz采样，16bit量化精度，双声道，压缩后的音频数据量为0.192Mbps；控制视频及声音复用的系统流数据量为0.1Mbps。它主要用于中等图像质量的视频存储，传输的编码表示和解码规定。优点：图像质量较好，同时还有伴音。缺点：数据

20、量较大。2数字声像存储压缩编码标准MPEG-2。MPEG-2是由ISO的活动专家组和ITU-T的15研究组于1995年共同制定的，在ITU-T的标准中，被称为H.262。设计目标是高级工业标准的图像质量和更高的传输率。数据速率在3Mbps到10Mbps之间。与MPEG-1相比，它增加了以下功能：处理隔行扫描视频信号的能力；更高的色信号取样模式；可伸缩的视频编码方式。视频分辨率为720X480（NTSC）和720X576（PAL）。它主要用于数字视频广播（DVB）、高清晰度电视（HDTV）和数字视频光盘（DVD）等高质量的视频存储，传输的编码表示和解码规定。优点：图像质量很好，有伴音。缺点：数据

21、量非常大。3低比特率音频与视频对象压缩编码标准MPEG-4。 MPEG-4由ISO的MPEG-4工作组制定。目标是支持多种多媒体应用（主要侧重于对多媒体信息内容的访问），可根据应用的不同要求现场配置解码器。编码系统是开放的，可以随时加入新的有效的算法模块。 MPEG-4是4.8Kbps10Mbps下的可变码率的音频和视频压缩编码标准。视频分辨率为352X288（CIF）和176X144（QCIF）等。它主要用于可视电话、视频电子邮件等的压缩标准，它也支持不同传输信道的不同码率，如：4.8Kbps64kbps的低速通道；64Kbps384Kbps的中速通道；384Kbps2Mbps的高速通道。优

22、点：图像质量可以调节，有伴音，数据量从小到大可变，具有基于内容检索功能。缺点：目前成熟的软硬件产品不多。4低比特率视频会议压缩编码标准H.263。 H.263使用户可以扩展带宽利用率，可以低达128Kbps的速率实现全运动视频（每秒30帧）。H.263以其灵活性及节省带宽和存储空间的特性，具有低总拥有成本并提供了迅速的投资回报。H.263是为以低达20Kbps到24Kbps带宽传送视频流而开发的，基于H.261编解码器来实现。 H.263算法还可以为开发人员所二次开发，以产生更好的结果和更佳的压缩方案，而这反过来为最终用户在选择最适合他们业务应用的H.263实现中提供了更多的选择。视频分辨率为

23、352X288（CIF）和176X144（QCIF）等。它主要用于电视会议和可视电话等压缩标准。优点：图像质量可以调节，压缩率高，数据量从小到大可变，软硬件产品成熟。缺点：仅有视频压缩不包括声音压缩。1.3.2.2 H.263压缩算法H.263算法的基本编码思想是利用离散余弦变换（DCTDiscrete CosineTransformation）和运动补偿（Motion Compensation）算法，根据运动补偿获得的运动矢量找出预测值，接着求出当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。 H.263的视频编码、解码算法是基于H.261算法的，是H.261算法的改进。H.

24、263算法采用帧间与帧内编码相结合的混合编码技术，若前后两帧很相似，其帧间差值小于某阀值，则采用帧间预测（Inter-frame Predicting），然后对帧间预测差进行CT；若前后两帧的帧间预测误差较大，则采用帧内编码，即将当前帧图像直接进行DCT编码。 在H.263中，帧主要分成两种类型：I帧（Intraframe）和P帧（Predicted-frame）。I帧是利用图像自身的相关性压缩，对I帧图像编码时无须参考其它帧，I帧提供了压缩数据流中的随机存取点，它包括全部图像的信息，数据量最大。P帧是利用最近的前一个I帧或P帧经预测编码得到的，生成的P帧又可以作为下一次预测的参考帧。 H.2

25、63的视频编码过程首先是判断图像信号是属于I帧还是P帧，如果是I帧则只做DCT和可变长编码。如果是P帧则首先做运动补偿，根据运动补偿获得的运动矢量找出预测值，接着求当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。 由于受到传输信道带宽的限制，为了控制H.263的编码速率，在编码器端采用自适应量化器来控制码率，也就是说，H.263是一个可变码率的甚低码率视频压缩编码标准。自适应量化器能根据预测的比特数自适应修改量化器的量化系数，即自动调整量化间隔大小，以此方式控制码率。根据量化定义：如果设量化电平数（量化系数或量化分级数）为J，量化精度为R，则有RLog2J。例如，如果量化系数J

26、取64、256、512或2048等，则量化精度R就分别为6bit、8bit、9bit或11bit等。可见对于均匀量化，量化系数越大（即量化分级越多或者说量化间隔越小），量化精度就越高，量化误差就越小，编码误差也就越小，重构图像质量就越好，但是其数字化编码所用的二进制码位数就越多，数字化的数据量就越大。在用H.263进行实时视频压缩编码时，要考虑当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，为了使总数据量不超过传输信道的最高数据传输率，应采取图像质量优先方式或者帧率优先方式进行压缩。图像质量优先的H.263实时视频压缩编码方案是把图像质量（图像清晰度）要求放在首位，而对图像的连

27、续性（即帧率）要求并不特别注重的视频压缩算法。当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，数据量将大大增加，H.263算法通过自动减少数字视频的时间分辨率，即丢掉一些帧，来减少数据量。这样便可以在保持数字视频的空间分辨率不下降（即图像的清晰度优先）的情况下使总数据量不超过传输信道的最高数据传输率。而当视频图像缓慢变化或者图像中活动部分占整个图像的比例很小时，数据量将明显减小，这时在维持原来数字视频的空间分辨率不变的条件下，H.263实时视频压缩算法会自动减少丢失帧数，从而提高一些帧率。帧率优先的H.263实时视频压缩编码方案是把图像的连续性（图像帧率）要求放在首位的视频压缩

28、算法。也就是说，当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，数据量将大大增加，这时的H.263实时视频压缩算法自动调整自适应量化器的量化系数（减少量化等级系数，即增大量化间隔）来减少数字化的数据量，以便保持数字视频的时间分辨率不下降（也即图像的帧率优先）的情况下使总数据量不超过传输信道的最高数据传输率，当然增大量化间隔必然会增大量化误差，降低了图像质量。H.263是一种混合编码，它的算法中既包括了如Huffman编码、游程编码（RLERun Length Encoding）等无损压缩算法（通常压缩比不大），又包括了如DCT变换、运动补偿预测技术、运动补偿插值技术等有损压缩算

29、法（通常压缩比可以很大）。所以压缩比越大，压缩后的数据量就越小；但是压缩后的图像损失就越大，以后解压重构图像的质量就越差。通常，对静态图像采用有损压缩技术时，为保证图像的质量，压缩率一般限制在7：1到25：1之间；对活动视频采用有损压缩技术，为保证图像质量，压缩率常限制在150：1以下。总之，压缩比越大图像质量损失越大。因此图像压缩比与图像质量显然也是相互矛盾的两个对立面。1.4实时传输协议RTP/RTCP1.4.1 RTP的特点为了支持网络实时传输服务，提供数据实时传输的标准，1996年IETF（Internet Engineering Task Force）的视频/音频工作组制订了RTP实

30、时传输协议。 在RFC1889中，RTP被定义为紧密相关的两个部分： 1实时传输协议RTP（Real-time Transport Protocol），用来传输具有实时特点的数据。 2RTP控制协议RTCP（RTP Control Protocol），用来控制服务质量，并在正在进行的会话里传送参加方的信息。RTP提供端到端的实时数据传输服务，包括载荷标识，数据序号，时戳和传输控制。RTP数据（如表1.4）通常采用UDP/IP封装，它利用UDP的多路复用及校验和服务，共同完成实时数据传输功能。表1.4 数据格式MAC HeaderIP HeaderUDP HeaderRTP Message在协议

31、设计时，RTP遵循Clark和Tennenhouse提出的alf&ilp（applicationlevel framing and integrated layer processing）原则，即：集成共性，个性扩展。在实现时RTP与应用程序紧密结合，根据应用的特点和要求构造与剪裁控制策略，提高会话质量和网络服务的公平性。总的来说，RTP协议具有以下特点： 一、简单性RTP协议不具备传输层的完整功能，其本身也不提供任何机制来保证实时地传输数据，不保证服务质量，而是依赖下层协议提供的服务来完成这些任务。它不保证提交或防止乱序提交，也不假设下层网络是可靠的并且提交的分组是有序的。RTP报文甚至不包

32、括长度和报文边界的描述，而是依靠下层协议提供长度标识和长度限制。另外，RTP协议将部分传输层协议功能（比如流量控制）上移到应用层完成，简化了传输层处理，提高了该层的执行效率。 二、灵活性 RTP协议的数据报文和控制报文使用相邻的不同端口，数据流和控制流分离，这样大大地提高了协议的灵活性，处理也简单。三、支持多播如果下层网络支持，RTP可支持采用多播的传送方式将实时数据传送到多个目的地，满足多媒体会话的需要。四、可扩展性RTP协议通常为一个具体的应用提供服务，通过一个具体的应用进程实现，而不作为OSI体系结构中单独的一层来实现，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩

33、展。1.4.2 RTP的数据包格式 RTP数据包由RTP头和不定长连续媒体数据组成，其中前12字节为固定的RTP头，媒体数据可以是编码数据。RTP数据包头格式如表1.5所示。表1.5 RTP数据包头格式版本号(2位)补充位（1位）扩展位（1位）CSRC数（4位）标记（1位）负载类型（7位）序列号（16位）时间戳（32位）SSRC标识符（32位）CSRC标识符0（32位）版本号：表示RTP的版本，一般设为2。 补充位：如果为1，表示数据包的末尾包含有一个或多个附加的补充字节，它们不是有效载荷的一部分。在使用某些加密算法时或为了在低层协议中携带多个RTP包时可能会用到补充位。扩展位：如果为1，表示

34、固定头部后将跟随一个头部扩展。CSRC数(参与者计数)：表示固定头部后CSRC标识的个数。标记：可用于标识流中的重要事件。 负载类型：指定了RTP数据包的负载格式及编码压缩方法。常见的负载类型有：PCM，MPEG1/MPEG2，H261视频流，JPEG视频等，用户可以根据需要定义负载类型。 序列号：每发送一个RTP数据包序列号加1。接收方可以发现是否有数据包丢失并重新排序。初始值为随机数。虽然源本身没有被加密，但数据包经过解释器（translator）后就被加密，随即产生的序列号使对加密的攻击变得更加困难。 时间戳：记录了RTP数据包中首字节的采样时间。采样时间可以取自一个单调递增非线性的，允

35、许同步和抖动计算的时钟。该时钟的分辨率应对于同步和计算包到达时间的同步是足够的。接收方利用时间戳实现媒体的同步，控制数据的回放速率。初始值也是随机数。某些较大的数据块，如视频帧，被分成许多小块放在连续的RTP包中，它们的时间戳是一样的。可以使用序列号恢复数据包的顺序。 SSRC标识符（同步源标识符）：标识出同步源。提供了对实时传输交互性的支持，使接收方能够获得有关发送方的信息。为了使同一个RTP会话中的两个同步源标识符不相同，采用随机选择产生SSRC标识符。CSRC列表：仅出现在有混合器的情况下。可以有0-15项。 RTP数据包没有包含长度域或其它边界，因此RTP依赖下层网络提供一个长度的表示

36、，RTP包的长度仅受下层网络的限制。1.4.3 RTP在协议层中的位置从实时传输协议RTP名字来看，实时传输协议RTP应该是传输层上的一层协议，但实际上并不是这样。RTP是一个轻型协议，它本身不提供数据传输的功能，而是由底层的传输协议完成数据传输，一般情况下利用UDP进行。这样可以利用UDP的多路技术和数据校验服务，而多路技术对于控制报文的传输是非常必要的。这表明RTP的数据传输是面向无连接、无差错控制的报文传输，两个协议共同完成了传输层协议的功能。如图1.4所示，很好的说明了RTP在协议层中所处的位置。图1.4 UDP/IP封装的RTP数据首先用RTP协议标准把数据封装，再用UDP协议对RT

37、P数据包进行封装，最后由IP网络层封装为IP数据包进行传输。所以可以说，RTP是面向应用的一个协议。1.4.4 RTCP的控制功能 RTCP是RTP的控制协议，它用于监视网络的服务质量和数据接发双方传递信息。RTCP的做法是周期性地进行通信，采用和数据包分配传递的相同机制来发送控制。每个RTCP包的前一部分是固定的，类似于RTP的数据包，后面的结构根据包的类型不同长度也不同，但总是32位的整数倍。长度在固定部分的长度域中标明。多个RTCP包不需要任何分隔符就可以组合成一个混合RTCP包，然后用下层协议的一个包发送出去，例如UDP包。RTCP包周期性地在会话成员之间组播，起着会员活动指示器的作用

38、。在RFC1889中定义了许多RTCP分组，分别承担不同的控制功能。RTCP的数据包分如下5类： 1SR（Sender report）：发送方报告。由处于活跃状态的信源发送方发送，SR报文不仅提供该端系统作为接收方的数据接收质量反馈信息（与RTCP RR报文相同），而且还提供SSRC（同步源）标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等与发送有关的信息。 2RR（Receiver report）：接收方报告。由实时数据接收方发送，RR报文针对每个信源都提供报文丢失数、已收报文的最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。 3SDES（Sour

39、ce description items）：源描述项。提供信源的描述信息，包括CNAME（信源端系统标识）、NAME（用户名）、EMAIL（电子邮件地址）、PHONE（电话号码）、LOC（地理位置）、TOOL（应用程序或工具名）、NOTE（通知/状态）、PRIV（用户定义项）等SDES报文项。 4BYE：将某参与者退出信息通知会话，并可提供退出原因。 5APP：应用程序特殊功能。 借助于上述控制包，RTCP可完成下列控制功能： 1QOS监测和拥塞控制。这是RTCP的一个重要功能。无论对发送方、接收方还是网络管理员，RTCP提供的数据传输反馈信息都是非常有用的。发送方可根据RTCP RR报文调整

40、数据实时传输方式，保证端系统正常接收；接收方可确定网络拥塞的范围是在本地、本区域还是全局，有的放矢地采取对策；网络管理员及时监视网络实时传输的性能。 2媒体同步。RTCP的SR报文包含与RTP时间戳相对应的实时信息，可以像视频帧同步一样实现媒体同步。 3信源标识。RTP数据包只能通过随机产生的32位的识别符来标识源，不能满足诸如会议这样的复杂应用的需求。而RTCP的SEDS包中有足够的文本信息，如CNAME项可标识信源端系统，NAME项可标识用户名，Email项可标识电子邮件地址，PHONE项可标识电话号码，LOC项可标识信源的地理位置，可以满足复杂应用的需要。方便实时数据传输的接收方获得发送

41、信源的有关信息。4会议大小估计和控制信息量的调节。参与会话的每个成员周期性地发送RTCP包，各站点可据此估计或计算出参与通信的人数，以便及时调节实时控制的信息量，使得控制信息量和媒体业务量达到平衡（在多媒体会议中，控制信息量一般为媒体业务量的5%左右）。RTP在IP多播环境中使用时，功能1-3是必须的，也是在所有环境中推荐的。1.4.5 RTCP发送方报告数据包格式RTCP发送方报告（SR）数据包格式如图3-4所示。该数据包分三部分，如果需要还可以根据具体应用加上扩展部分。 （1）头部，共8字节。分别是： 版本号（V）：2位，表示RTP版本。补充位（P）：1位，若此位被设置，RTCP的尾部包含

42、一些附加的补充位。接收报告计数（RC）：5位，此包中的接收报告块数，0是允许的。包类型（PT）：8位，发送方报告的RTCP包定义为200。长度：16位，RTCP以32位计的长度。同步源（SSRC）：此包的同步源标识符。 （2）包体，共20字节，它描述发送方的数据传送。 NTP时间戳：64位，定义本包发送时间，可以与接收方报告包中的时间戳比较，估计往返时间。RTP时间戳：32位，与NTP时间戳对应，而且与数据包中的RTP时间戳有相同的单位和相同的偏移值。发送RTP包计数：32位，发送方从开始发送到发送本报通告为止共发送的负载字节数，如果SSRC定义符被改变，本字段被重置。发送字节计数：32位，发

43、送方从开始发送到发送本报告为止发送的负载字节数，如果SSRC定义符被改变，本字段被重置。表1.7 RTCP发送方数据包0 16 31VPPt=sr=200长度SSRC同步源NTP时间戳高位NTP时间戳低位RTP时间戳发送者包计数发送者字节数SSRC_1（第一个发送源）丢失率累计丢包数扩展的最大顺序号间隔到达抖动最近发送方报告的时间戳自最近发送方报告之后的延迟SSRC_2（第二个发送源）. .文本扩展部分（3）包含0个或多个接收报告块，它取决于发送方从上次报告起知道的其它源数，每个接收报告块要表示从一个同步源RTP包的接收统计。当源由于冲突改变它的SSRC标识符时，接收方不发送统计。统计项包括：

44、 SSRC_n（源标识符）：32位，SSRC源标识符； 丢失率：3位，自上一次发送SR或RR后，源SSRC_n的RTP数据包丢失率； 累计丢失包数：24位，接收开始后丢失包数的累计； 扩展的最大顺序号：32位，低16位包含来自源SSRC_n的RTP数据包的最大顺序号，高16位使用相应的顺序号循环计数时顺序号的扩展； 间隔到达抖动：32位，使用无符号整数； 最近发送方报告的时间戳（LSR）：32位，最近接收的RTCP发送方报告包中NTP时间戳的中间32位，如无SR被接收，此字段为0； 自最近发送方报告之后的延迟（DLSR）：32位，从源SSRC_n接收的最后的SR包到发送此接收报告块之间的延迟，

45、如无SR包从源SSRC_n被接收，则DLSR字段置0；接收方报告包（RR）的格式同SR包基本相同。不同点在于RR的包类型为201，并且5个发送者信息被省略（NTP和RTP时间戳，发送者的包和字节计数）其它字段均相同。第二章 总体方案设计2.1 方案论证2.1.1方案一.采用DirectShow框架实现流媒体实时传输DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的开发包，与DirectX开发包一起发布6,7。 DirectShow为多媒体流的捕捉和回放提供了强有力的支持。运用DirectShow，可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期

46、处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换。更值得一提的是，DirectShow提供的是一种开放式的开发环境，我们可以根据自己的需要定制自己的组件。在处理多媒体信息时，可能会碰到以下问题：1.媒体流中包含大量的数据，必须得到快速的处理。2.声音和视频要同步。两者应同时开始，同时结束，协调工作。3.多媒体数据的来源很广，包括：本地磁盘文件，计算机网络，电视广播和摄像机。4.多媒体数据的格式很多，包括：ASF，AVI，MPEG和DV。5.程序员事先不知道用户端系统用的是什么样的硬件设备。DirectShow的设计正是针对以上问题。它的主要设计目标是把数