流媒体传输控制的研究

毕 业 设 计（论 文）题 目：基于RTP协议的流媒体的实时传输的实现系 别：电子信息科学系专 业：电子信息科学与技术班 级：T583-1学生姓名：钟 蕾学 号：20050830119指导教师：张 涛摘要基于IP的网络中提供的尽力而为的服务并不适合流媒体的传输4。本文的研究项目由网络流媒体传输需求提出，旨在研究基于RTP协议的流媒体的实时传输，使之能够适应网络状态的变化。论文的论述从以下三个方面展开：（1）本文首先分析了网络多媒体应用中常用的流媒体技术，视频压缩编码技术。（2）本文深入分析了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 Streaming 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: Firstly,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 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 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多媒体数据压缩技术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多媒体开发环境所需的硬件和软件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 流媒体解压缩、实时播放333.2.5 监听接收媒体流事件343.2.6 监听数据是否接收完毕353.3 本章小节36第四章 系统测试374.1 系统测试结果与分析374.2本章小节37第五章 结束语38致 谢39参考文献40附件42第一章绪论1.1课题的背景目前，多媒体技术和计算机网络通信技术都有了很大的发展。主要表现在视频压缩编码算法的不断完善，IP网规模的进一步扩展。伴随着流媒体技术的出现，诸如视频会议、视频点播之类的网络多媒体应用开始进入人们的生活。人们又一次体会到了信息技术带给人们的方便和无穷乐趣。在实际应用中，许多网络流媒体传输还存在着模拟信号的传输。采用模拟信号传输带来的问题就是系统的造价高，建设周期长，适应性不强。当系统的规模很大时，需要铺设的电缆线又粗又长。一旦系统结构变化，还要铺设新的管线，有时还需要更改现有的线路。这使得系统的实施和更新变得非常不方便。于是，许多研究人员将目光投向了规模不断扩大的IP网。基于分组交换的IP网具有良好的扩展性，也不需要专门铺设流媒体电缆和控制电缆，成本低，可充分利用现有的网络资源。然而，TCP协议严格的建立连接、断开连接的三次握手和差错重发机制并不适合数据量大、实时性强的流媒体数据。面向无连接的UDP协议由于毫无数据纠错和排序，似乎也不太符合要求。而且，网络还不够强大，带宽资源有限，不能很好的保证服务质量。因此，提出了研究IP网络中的流媒体传输控制，希望利用现有的网络协议和网络资源，对服务质量加以控制以获得较好的多媒体传输效果。此外，为了实现流媒体传输控制的策略，流媒体的捕捉和回放也是应解决的问题之一。由SUN提供的JMF技术基于组件对象模型技术，支持宽松的格式变化，提供高品质的流媒体捕捉和回放。利用它可以在普通微机中实现流媒体的客户端处理，还可以提高系统的通用性和可扩展性。1.2本课题所做的工作本文的研究目标是：研究一种基于RTP协议的流媒体实时传输。本课题的工作有： （1）介绍网络多媒体视频技术发展的现状，流媒体技术，多媒体数据压缩技术。 （2）研究了用于流媒体信息传输的实时传输协议RTP/RTCP。 （4）研究了基于任何平台的流媒体处理技术JMF的体系结构，基本原理。 （5）设计一个小型流媒体传输实验模型系统，实现了基于RTP的流媒体传输控制方法。1.3流媒体技术流媒体（Streaming Media），就是应用流技术在网络上传输的多媒体文件。流（Streaming）是对在网路上传输特别的编码数字媒体内容如音频、视频、动画片、图形、照片、文本到最终用户的一种描述1。只要是用流服务器传输媒体，通过网络向用户计算机连续、实时传送数据包，用户能够立即、不中断播放，并且不需要固定的存储空间在最终用户的磁盘上，都可以说是流。众所周知，在Internet上传输音/视频（A/V）等多媒体信息，目前主要有下载和流式传输两种方式。传统的文件传输方式是，一个互连网的用户在观看一个视频文件前必须要完全下载此文件。传统文件30秒的视频剪辑在正常的每秒56Kbps Internet接入下，传输需要将近30分钟的时间。那么就算是一个广告短片最少也需要1个小时的下载，这还是在网络状况极其良好的情况下。下载一个A/V文件花上数小时可谓是家常便饭。显然这个速度是大多数人都无法忍受的。通常A/V文件相对于其他类型的文件而言容量较大。因此，在网络带宽的限制下，必须要寻找别的解决方法。流技术正是为了绕过互连网的这个局限而设计的。观看的时候不用把文件完全下载，可以像看电视和听广播一样，在观看和收听前才接受图像和声音。实际上在服务器端一个媒体文件就被分隔成很小的一片，而这一小片文件的长度是非常小的。但并不是说文件整体就变小了，原始文件依然很大。为了实现流，有些不太必要的数据就要丢失掉，以图像和文件的质量损失为代价使完整数据包传输更加快捷。1.3.1视频技术发展的现状 随着信息技术的发展，人们对信息的需求已不满足于传统的电报电话业务及传统的文件传输、电子邮件等数据业务，而是追求更高品质的集视频、图像、声音、文字、甚至动画等为一体的多媒体应用服务。视频技术是多媒体技术中的一个重要组成部分。视频信息以其数据量大、实时性强、冗余多等特点倍受研究人员的关注5。为了提高视频数据的传输效率，针对不同的视频信号产生了不同的视频数据压缩标准，如：MPEG-1，MPEG-2，MPEG-4，H.263+。新的视频压缩标准H.264于2003年3月公布于众，新的压缩技术在测试过程中，其数据交换速度约为1Mbps，为宽带网络视频文件的传输铺平了道路。另外，视频信息的传输正从模拟向数字化方向转变。早期的INTERNET带宽窄、路由瓶颈、接入速率低、延迟大而不确定，使得实时性强的视音频流质量不能得到保证，限制了IP多媒体的广泛应用。第四代IP多媒体通信技术已被武汉大学成功攻克，并自主成功地研制了视讯会议系统、IP可视电话等一系列产品，并应用于上海APEC会议多媒体通信系统、酒泉卫星指挥中心等20多个单位，从而使我国成为世界上少数几个全面掌握第四代IP多媒体通信技术平台核心技术的国家之一。第四代基于IP网络的多媒体通信技术是当前尖端的通信技术，此前基于电视广播技术交换的通信技术、基于电路交换的通信技术、基于分组交换的通信技术，被称为第一代、第二代和第三代。在“2002视频通讯技术应用与发展专题研讨会”上，基于IP的多媒体通信基础、IP视频通信的标准、电信级视频运营网络及视频通信中的质量保障等话题成为关注的热点。数据压缩标准的不断完善，多媒体视频技术和IP技术的发展和成熟，都为网络多媒体的应用发展提供了基础，带来了新的发展机遇。1.3.2多媒体数据压缩技术多媒体信息的编码技术是多媒体信息处理技术中的一个关键问题，多媒体数据的压缩标准为多媒体技术的广泛应用提供了前提。数字化的视音频信息，其数据量非常大。不仅需要大容量的存储设备，而且对网络的传输和数据的处理也提出了很高的要求。即使硬件技术发展得再快，如果不对信息进行压缩，多媒体技术也很难有大的发展，多媒体技术的应用也会受到很大的限制。另外以视频和音频为典型代表的多媒体信息本身具有很大的压缩潜力。在一个视频帧中，像素与像素之间无论是在横向还是竖向上都有很大的相关性，而且，帧和帧之间的相关性很大，如对前一个帧的数据作微小的变化，可能就能够得到当前的信息。1.3.2.1 常用的视频数据压缩标准这方面的工作主要是由国际标准化组织（ISO）和国际电信联盟（ITU）来进行的。下面介绍其中几种视频压缩标准2,3。1数字声像存储压缩编码标准MPEG-1。 该标准是为速率为1.5Mbps的数字声像信息的存储而制定的。由于MPEG-1是针对数字存储而制定的，因此它的编解码器是不对称的，编码器往往比位于用户端的解码器复杂得多。 视频分辨率为352X240（NTSC）和352X288（PAL），视频帧速率为30帧/秒，压缩后的视频数据量为1.2Mbps；音频按44.lKHz采样，16bit量化精度，双声道，压缩后的音频数据量为0.192Mbps；控制视频及声音复用的系统流数据量为0.1Mbps。它主要用于中等图像质量的视频存储，传输的编码表示和解码规定。优点：图像质量较好，同时还有伴音。缺点：数据量较大。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）等高质量的视频存储，传输的编码表示和解码规定。优点：图像质量很好，有伴音。缺点：数据量非常大。3低比特率音频与视频对象压缩编码标准MPEG-4。 MPEG-4由ISO的MPEG-4工作组制定。目标是支持多种多媒体应用（主要侧重于对多媒体信息内容的访问），可根据应用的不同要求现场配置解码器。编码系统是开放的，可以随时加入新的有效的算法模块。 MPEG-4是4.8Kbps10Mbps下的可变码率的音频和视频压缩编码标准。视频分辨率为352X288（CIF）和176X144（QCIF）等。它主要用于可视电话、视频电子邮件等的压缩标准，它也支持不同传输信道的不同码率，如：4.8Kbps64kbps的低速通道；64Kbps384Kbps的中速通道；384Kbps2Mbps的高速通道。优点：图像质量可以调节，有伴音，数据量从小到大可变，具有基于内容检索功能。缺点：目前成熟的软硬件产品不多。4低比特率视频会议压缩编码标准H.263。 H.263使用户可以扩展带宽利用率，可以低达128Kbps的速率实现全运动视频（每秒30帧）。H.263以其灵活性及节省带宽和存储空间的特性，具有低总拥有成本并提供了迅速的投资回报。H.263是为以低达20Kbps到24Kbps带宽传送视频流而开发的，基于H.261编解码器来实现。 H.263算法还可以为开发人员所二次开发，以产生更好的结果和更佳的压缩方案，而这反过来为最终用户在选择最适合他们业务应用的H.263实现中提供了更多的选择。视频分辨率为352X288（CIF）和176X144（QCIF）等。它主要用于电视会议和可视电话等压缩标准。优点：图像质量可以调节，压缩率高，数据量从小到大可变，软硬件产品成熟。缺点：仅有视频压缩不包括声音压缩。1.3.2.2 H.263压缩算法H.263算法的基本编码思想是利用离散余弦变换（DCTDiscrete CosineTransformation）和运动补偿（Motion Compensation）算法，根据运动补偿获得的运动矢量找出预测值，接着求出当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。 H.263的视频编码、解码算法是基于H.261算法的，是H.261算法的改进。H.263算法采用帧间与帧内编码相结合的混合编码技术，若前后两帧很相似，其帧间差值小于某阀值，则采用帧间预测（Inter-frame Predicting），然后对帧间预测差进行CT；若前后两帧的帧间预测误差较大，则采用帧内编码，即将当前帧图像直接进行DCT编码。 在H.263中，帧主要分成两种类型：I帧（Intraframe）和P帧（Predicted-frame）。I帧是利用图像自身的相关性压缩，对I帧图像编码时无须参考其它帧，I帧提供了压缩数据流中的随机存取点，它包括全部图像的信息，数据量最大。P帧是利用最近的前一个I帧或P帧经预测编码得到的，生成的P帧又可以作为下一次预测的参考帧。 H.263的视频编码过程首先是判断图像信号是属于I帧还是P帧，如果是I帧则只做DCT和可变长编码。如果是P帧则首先做运动补偿，根据运动补偿获得的运动矢量找出预测值，接着求当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。 由于受到传输信道带宽的限制，为了控制H.263的编码速率，在编码器端采用自适应量化器来控制码率，也就是说，H.263是一个可变码率的甚低码率视频压缩编码标准。自适应量化器能根据预测的比特数自适应修改量化器的量化系数，即自动调整量化间隔大小，以此方式控制码率。根据量化定义：如果设量化电平数（量化系数或量化分级数）为J，量化精度为R，则有RLog2J。例如，如果量化系数J取64、256、512或2048等，则量化精度R就分别为6bit、8bit、9bit或11bit等。可见对于均匀量化，量化系数越大（即量化分级越多或者说量化间隔越小），量化精度就越高，量化误差就越小，编码误差也就越小，重构图像质量就越好，但是其数字化编码所用的二进制码位数就越多，数字化的数据量就越大。在用H.263进行实时视频压缩编码时，要考虑当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，为了使总数据量不超过传输信道的最高数据传输率，应采取图像质量优先方式或者帧率优先方式进行压缩。图像质量优先的H.263实时视频压缩编码方案是把图像质量（图像清晰度）要求放在首位，而对图像的连续性（即帧率）要求并不特别注重的视频压缩算法。当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，数据量将大大增加，H.263算法通过自动减少数字视频的时间分辨率，即丢掉一些帧，来减少数据量。这样便可以在保持数字视频的空间分辨率不下降（即图像的清晰度优先）的情况下使总数据量不超过传输信道的最高数据传输率。而当视频图像缓慢变化或者图像中活动部分占整个图像的比例很小时，数据量将明显减小，这时在维持原来数字视频的空间分辨率不变的条件下，H.263实时视频压缩算法会自动减少丢失帧数，从而提高一些帧率。帧率优先的H.263实时视频压缩编码方案是把图像的连续性（图像帧率）要求放在首位的视频压缩算法。也就是说，当视频图像出现剧烈变化或者图像中活动部分占整个图像的比例较大时，数据量将大大增加，这时的H.263实时视频压缩算法自动调整自适应量化器的量化系数（减少量化等级系数，即增大量化间隔）来减少数字化的数据量，以便保持数字视频的时间分辨率不下降（也即图像的帧率优先）的情况下使总数据量不超过传输信道的最高数据传输率，当然增大量化间隔必然会增大量化误差，降低了图像质量。H.263是一种混合编码，它的算法中既包括了如Huffman编码、游程编码（RLERun Length Encoding）等无损压缩算法（通常压缩比不大），又包括了如DCT变换、运动补偿预测技术、运动补偿插值技术等有损压缩算法（通常压缩比可以很大）。所以压缩比越大，压缩后的数据量就越小；但是压缩后的图像损失就越大，以后解压重构图像的质量就越差。通常，对静态图像采用有损压缩技术时，为保证图像的质量，压缩率一般限制在7：1到25：1之间；对活动视频采用有损压缩技术，为保证图像质量，压缩率常限制在150：1以下。总之，压缩比越大图像质量损失越大。因此图像压缩比与图像质量显然也是相互矛盾的两个对立面。1.4实时传输协议RTP/RTCP1.4.1 RTP的特点为了支持网络实时传输服务，提供数据实时传输的标准，1996年IETF（Internet Engineering Task Force）的视频/音频工作组制订了RTP实时传输协议。 在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在协议设计时，RTP遵循Clark和Tennenhouse提出的alf&ilp（applicationlevel framing and integrated layer processing）原则，即：集成共性，个性扩展。在实现时RTP与应用程序紧密结合，根据应用的特点和要求构造与剪裁控制策略，提高会话质量和网络服务的公平性。总的来说，RTP协议具有以下特点： 一、简单性RTP协议不具备传输层的完整功能，其本身也不提供任何机制来保证实时地传输数据，不保证服务质量，而是依赖下层协议提供的服务来完成这些任务。它不保证提交或防止乱序提交，也不假设下层网络是可靠的并且提交的分组是有序的。RTP报文甚至不包括长度和报文边界的描述，而是依靠下层协议提供长度标识和长度限制。另外，RTP协议将部分传输层协议功能（比如流量控制）上移到应用层完成，简化了传输层处理，提高了该层的执行效率。 二、灵活性 RTP协议的数据报文和控制报文使用相邻的不同端口，数据流和控制流分离，这样大大地提高了协议的灵活性，处理也简单。三、支持多播如果下层网络支持，RTP可支持采用多播的传送方式将实时数据传送到多个目的地，满足多媒体会话的需要。四、可扩展性RTP协议通常为一个具体的应用提供服务，通过一个具体的应用进程实现，而不作为OSI体系结构中单独的一层来实现，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。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，表示固定头部后将跟随一个头部扩展。CSRC数(参与者计数)：表示固定头部后CSRC标识的个数。标记：可用于标识流中的重要事件。 负载类型：指定了RTP数据包的负载格式及编码压缩方法。常见的负载类型有：PCM，MPEG1/MPEG2，H261视频流，JPEG视频等，用户可以根据需要定义负载类型。 序列号：每发送一个RTP数据包序列号加1。接收方可以发现是否有数据包丢失并重新排序。初始值为随机数。虽然源本身没有被加密，但数据包经过解释器（translator）后就被加密，随即产生的序列号使对加密的攻击变得更加困难。 时间戳：记录了RTP数据包中首字节的采样时间。采样时间可以取自一个单调递增非线性的，允许同步和抖动计算的时钟。该时钟的分辨率应对于同步和计算包到达时间的同步是足够的。接收方利用时间戳实现媒体的同步，控制数据的回放速率。初始值也是随机数。某些较大的数据块，如视频帧，被分成许多小块放在连续的RTP包中，它们的时间戳是一样的。可以使用序列号恢复数据包的顺序。 SSRC标识符（同步源标识符）：标识出同步源。提供了对实时传输交互性的支持，使接收方能够获得有关发送方的信息。为了使同一个RTP会话中的两个同步源标识符不相同，采用随机选择产生SSRC标识符。CSRC列表：仅出现在有混合器的情况下。可以有0-15项。 RTP数据包没有包含长度域或其它边界，因此RTP依赖下层网络提供一个长度的表示，RTP包的长度仅受下层网络的限制。1.4.3 RTP在协议层中的位置从实时传输协议RTP名字来看，实时传输协议RTP应该是传输层上的一层协议，但实际上并不是这样。RTP是一个轻型协议，它本身不提供数据传输的功能，而是由底层的传输协议完成数据传输，一般情况下利用UDP进行。这样可以利用UDP的多路技术和数据校验服务，而多路技术对于控制报文的传输是非常必要的。这表明RTP的数据传输是面向无连接、无差错控制的报文传输，两个协议共同完成了传输层协议的功能。如图1.4所示，很好的说明了RTP在协议层中所处的位置。图1.4 UDP/IP封装的RTP数据首先用RTP协议标准把数据封装，再用UDP协议对RTP数据包进行封装，最后由IP网络层封装为IP数据包进行传输。所以可以说，RTP是面向应用的一个协议。1.4.4 RTCP的控制功能 RTCP是RTP的控制协议，它用于监视网络的服务质量和数据接发双方传递信息。RTCP的做法是周期性地进行通信，采用和数据包分配传递的相同机制来发送控制。每个RTCP包的前一部分是固定的，类似于RTP的数据包，后面的结构根据包的类型不同长度也不同，但总是32位的整数倍。长度在固定部分的长度域中标明。多个RTCP包不需要任何分隔符就可以组合成一个混合RTCP包，然后用下层协议的一个包发送出去，例如UDP包。RTCP包周期性地在会话成员之间组播，起着会员活动指示器的作用。在RFC1889中定义了许多RTCP分组，分别承担不同的控制功能。RTCP的数据包分如下5类： 1SR（Sender report）：发送方报告。由处于活跃状态的信源发送方发送，SR报文不仅提供该端系统作为接收方的数据接收质量反馈信息（与RTCP RR报文相同），而且还提供SSRC（同步源）标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等与发送有关的信息。 2RR（Receiver report）：接收方报告。由实时数据接收方发送，RR报文针对每个信源都提供报文丢失数、已收报文的最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。 3SDES（Source description items）：源描述项。提供信源的描述信息，包括CNAME（信源端系统标识）、NAME（用户名）、EMAIL（电子邮件地址）、PHONE（电话号码）、LOC（地理位置）、TOOL（应用程序或工具名）、NOTE（通知/状态）、PRIV（用户定义项）等SDES报文项。 4BYE：将某参与者退出信息通知会话，并可提供退出原因。 5APP：应用程序特殊功能。 借助于上述控制包，RTCP可完成下列控制功能： 1QOS监测和拥塞控制。这是RTCP的一个重要功能。无论对发送方、接收方还是网络管理员，RTCP提供的数据传输反馈信息都是非常有用的。发送方可根据RTCP RR报文调整数据实时传输方式，保证端系统正常接收；接收方可确定网络拥塞的范围是在本地、本区域还是全局，有的放矢地采取对策；网络管理员及时监视网络实时传输的性能。 2媒体同步。RTCP的SR报文包含与RTP时间戳相对应的实时信息，可以像视频帧同步一样实现媒体同步。 3信源标识。RTP数据包只能通过随机产生的32位的识别符来标识源，不能满足诸如会议这样的复杂应用的需求。而RTCP的SEDS包中有足够的文本信息，如CNAME项可标识信源端系统，NAME项可标识用户名，Email项可标识电子邮件地址，PHONE项可标识电话号码，LOC项可标识信源的地理位置，可以满足复杂应用的需要。方便实时数据传输的接收方获得发送信源的有关信息。4会议大小估计和控制信息量的调节。参与会话的每个成员周期性地发送RTCP包，各站点可据此估计或计算出参与通信的人数，以便及时调节实时控制的信息量，使得控制信息量和媒体业务量达到平衡（在多媒体会议中，控制信息量一般为媒体业务量的5%左右）。RTP在IP多播环境中使用时，功能1-3是必须的，也是在所有环境中推荐的。1.4.5 RTCP发送方报告数据包格式RTCP发送方报告（SR）数据包格式如图3-4所示。该数据包分三部分，如果需要还可以根据具体应用加上扩展部分。 （1）头部，共8字节。分别是： 版本号（V）：2位，表示RTP版本。补充位（P）：1位，若此位被设置，RTCP的尾部包含一些附加的补充位。接收报告计数（RC）：5位，此包中的接收报告块数，0是允许的。包类型（PT）：8位，发送方报告的RTCP包定义为200。长度：16位，RTCP以32位计的长度。同步源（SSRC）：此包的同步源标识符。 （2）包体，共20字节，它描述发送方的数据传送。 NTP时间戳：64位，定义本包发送时间，可以与接收方报告包中的时间戳比较，估计往返时间。RTP时间戳：32位，与NTP时间戳对应，而且与数据包中的RTP时间戳有相同的单位和相同的偏移值。发送RTP包计数：32位，发送方从开始发送到发送本报通告为止共发送的负载字节数，如果SSRC定义符被改变，本字段被重置。发送字节计数：32位，发送方从开始发送到发送本报告为止发送的负载字节数，如果SSRC定义符被改变，本字段被重置。表1.7 RTCP发送方数据包0 16 31VPPt=sr=200长度SSRC同步源NTP时间戳高位NTP时间戳低位RTP时间戳发送者包计数发送者字节数SSRC_1（第一个发送源）丢失率累计丢包数扩展的最大顺序号间隔到达抖动最近发送方报告的时间戳自最近发送方报告之后的延迟SSRC_2（第二个发送源）. .文本扩展部分（3）包含0个或多个接收报告块，它取决于发送方从上次报告起知道的其它源数，每个接收报告块要表示从一个同步源RTP包的接收统计。当源由于冲突改变它的SSRC标识符时，接收方不发送统计。统计项包括： 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包到发送此接收报告块之间的延迟，如无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驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换。更值得一提的是，DirectShow提供的是一种开放式的开发环境，我们可以根据自己的需要定制自己的组件。在处理多媒体信息时，可能会碰到以下问题：1.媒体流中包含大量的数据，必须得到快速的处理。2.声音和视频要同步。两者应同时开始，同时结束，协调工作。3.多媒体数据的来源很广，包括：本地磁盘文件，计算机网络，电视广播和摄像机。4.多媒体数据的格式很多，包括：ASF，AVI，MPEG和DV。5.程序员事先不知道用户端系统用的是什么样的硬件设备。DirectShow的设计正是针对以上问题。它的主要设计目标是把数字媒体应用程序与复杂的数据传输，多样的硬件设备和同步隔离开，从而简化在Windows平台上创建程序的工作。为了达到视频流和声音流需要的吞吐量，只要可能，DirectShow会调用Direc-tDraw和DirectSound。这些技术将多媒体数据通过用户的显卡和声卡有效的表现出来。DirectShow将媒体数据封装到带有时间戳的样本中，以实现同步回放。为了适应数据来源、格式和硬件设备的多变，DirectShow采用模块化的系统结构，其中由应用程序将不同的软件组件过滤器组合并匹配起来。DirectShow提供有支持基于WDM驱动程序的捕捉和调谐设备的过滤器，也有支持早期的VFW视频捕捉卡的过滤器以及为ACM（Audio Compression Manager）和VCM（Video Compression Manager）接口编写的编解码器。2.1.2 方案二. 在嵌入式平台下实现流媒体实时传输在几种嵌入式操作系统中，几款商业操作系统像WindowCE和VxW6kr，不仅具有较高的性能和良好的移植性，而且也提供了良好的开发环境和技术服务。但是都需要较高的成本，这是在嵌入式系统设计中必须考虑的一个问题。另外，商业操作系统一般都不提供源码，这使对嵌入式操作系统的研究无法深入。Linux是完全符合GNU/GPL许可的操作系统内核。它的源码是完全公开的和免费的。Linux内核支持众多的处理器，并且针对特定的处理器做了许多性能优化工作。目前在很多的嵌入式处理器上都己经成功的移植了嵌入式Linux操作系统。虽然Linux在实时性方面不如一些商业的嵌入式操作系统，但是在一些对实时性要求不是很高的嵌入式系统中得到了广泛地应用。随着Linux2.6版本的推出，对实时性的支持有了很大的提高。Linux内核得到了GNU组织的支持，提供了一系列的嵌入式系统开发工具。GNU工具链支持嵌入式开发的整个过程。嵌入式Linux操作系统兼容UNIX操作系统。许多UNIX应用程序无需任何改动，就可以直接在Linux系统中编译运行。Linux操作系统具有UNIX操作系统几乎一致的编程接口，这给习惯了UNIX操作系统的软件开发者转向Linux操作系统提供了很大的便利。按照是否经过了厂商的优化，可以将嵌入式Linux操作系统分成两类:商业化的嵌入式Linux操作系统以及非商业化的嵌入式Linux内核。只有嵌入式Linux内核，是无法进行嵌入式系统开发的，还需要很多的GNU项目支持，包括GNU工具链、文件系统等。而商业化的嵌入式Linux操作系统，除了完成上述的工作以外，还对嵌入式Linux操作系统做了一些改进，包括实时性扩展以及技术支持培训服务等。选择商业化的嵌入式Linux操作系统可以减小很多的工作并且提高了系统的性能，另外，使用商业化的嵌入式Linux操作系统是不需要版权费，只需付给商家一定的服务费。本设计中，选择商业化的MiziLinux操作系统在嵌入式平台运行。相应的交叉开发环境选用:宿主机(CP机)采用FedoraCore3，采用CMO口和目标体通信;交叉环境使用arm-gcc-2.95.3;嵌入式操作系统内核版本为1inux-2.4.18-mrk7-pxal-mZ4。所以在基于ARMS3C2440的嵌入式平台下的linux操作系统下系统设计如下：图2.1 网络媒体流实时传输系统设计 总的设计方案可以见图2.1.本地服务子系统可以作为一个独立的嵌入式系统进行设计8,9。本地服务子系统包括两个基本的工作模块：编码模块以及Linux操作系统下编写硬件的驱动程序和网络服务模块(利用嵌入式平台的TCP/IP网络功能，实现专用的RTP/RTCP协议)。然后编写客户端子系统。2.1.3 方案三. 采用JAVA媒体框架（JMF）实现流媒体实时传输 JMF是一种采用Java语言开发流式媒体应用的API，它采用统一的结构和消息传递协议，可以提供数据的回放，控制，处理及传输等功能。它支持大多数标准的媒体类型，如AIFF,AU,AVI,GSM,MIDI,MPEG,QuickTime,RMF以及WAV。JMF RTP API是JMF中支持RTP应用开发的应用程序接口，可以在网络中实时传输和接收媒体流10,11。在JMF的高层结构中RTP API位于JMF API和插件结构Plug-in API之间。JMF RTP API 可以无缝地与JMF的获取，回放及处理功能一起工作。同处理其他媒体内容一样，Player和Processor对象用来回放RTP媒体流。用户可以将采集和保存的媒体数据以媒体流的形式在网络中传输。第一种方案是Windows平台上进行流媒体处理，没有可移植性。第二种方案是在嵌入式平台下实现服务器子系统和在PC机上实现客户子系统。难度太大，所以选择了第三种方案，这种方案是基于Java的，能够实现基于RTP协议的流媒体实时传输，而且Java具有跨平台的优点，基于Java开发的流媒体实时传输系统有望移植到嵌入式平台上。例如：手机网络平台的开发一般是基于Java的，凭着Java跨平台的优点，基于Java开发的流媒体实时传输系统有望移植到手机平台。所以我先择了第三种方案。2.2.系统总体设计基于RTP协议的网络多媒体应用程序 ，主要分为两个部分，一部分是负责通过网络发送数据的主机端（RTP Servers）程序 ，另一部分是接收数据的客户端（RTP Clients）程序。 在流媒体实时传输应用中，视频传输是很重要的一部分。它直接关系到系统的运行效果，关系到系统能否被客户接收。为了保证流媒体传输的效果，人们提出了多种流媒体传输控制的方法，希望改进服务质量。在实时传输协议RTP的基础上，实现流媒体实时传输。图2.2 连接示意图2.3 系统处理流程图 系统采用客户/服务器结构，流媒体信息发送端为服务器端，流媒体信息接收端为客户端。系统结构分为两大部分：流媒体发送端和流媒体接收端。流媒体发送端的系统流程图如图2.3所示。图2.3 流媒体发送端的系统流程图流媒体接收端的系统流程图如图2.4所示。图2.4 流媒体接收端的系统流程图2.4 系统模块的划分及功能描述 基于以上系统流程的分析，可以分为以下几个模块： 流媒体捕获模块：该模块从摄像头采集流媒体数据，经其内部的硬件初步压缩后输入计算机，等待下一步的处理。 流媒体压缩模块：该模块从缓冲区获取数据，采用H.263压缩算法进一步压缩，然后将数据传给下一个模块。 RTP传输模块：该模块得到流媒体数据后，将其用RTP协议打包，媒体类型采用H.263。每隔一段时间，接收RTCP包并加以分析，发现网络拥塞后调整H.263的压缩参数。 RTP分析模块：该模块从网络上接收RTP包，重组后分析出媒体数据供下面的模块解压缩。每隔一段时间，发送RTCP包报告RTP包的接收情况。 流媒体播放模块：该模块将解压缩的流媒体数据显示在屏幕上。2.5 JMF体系结构Java作为一种优秀的面向对象的编程语言,具有简单、可移植、分布式、多线程、安全等诸多特点。Java最显而易见的优点是其平台无关性,可以“编译一次,到处运行”,而且Java几乎从一开始就和网络联系在一起,是一种比较理想的网络编程语言。Java提供了丰富的类库,由SunMicrosystem公司单独提供(指不包含在标准JDK中)的Java Media Framework(JMF)提供了对多媒体编程的比较完善的支持。JMF可以分为两部分:JMF API和JMF RTP API。前者提供了处理器(Processor)、插件(Plug-in)、Data Sink。Processor和Plug-in用于处理媒体数字信号,Data Sink可用于存储和显示媒体内容。把Processor、Plug-in和Data Sink整合到一块,就可以完成捕获、存储、处理、播放和压缩媒体内容的任务。后者JMF RTP API是JMF提供的实时传输多媒体数据流的API,即RTP(包含RTCP)包。JMF RTP API能与JMF的捕获设备、播放器、处理器和处理能力无缝结合。除了上面提到的四个管理器之外, Session-Manager用于与RTP会话一同工作。SessionManager可跟踪会话参与方以及所传送的流,还用于处理RTCP控制通道,为发送方和接收方提供支持。JMF提供的模型可大致分为七类：数据（data source）,截取设备（Capture Device,包括视频和音频截取设备），播放器（Player），处理器（Processor）,数据池（DataSink）,数据格式（Format）,管理器（Manager）。2.6 建立Java多媒体开发环境所需的硬件和软件2.6.1 硬件环境 至少两台能运行Windows操作系统的PC,运行该实例时,其中一台用来当发送端,另一台当接收端。摄像头，麦克风等。2.6.2 软件环境1）安装JDK1.5:jdk-1_5_0_17-windows-i586-p.exeJDK默认安装目录为d:Program FilesJavajdk-1_5_0_17。右键点击Windows桌面我的电脑-属性,在弹出系统特性对话框中选择高级选项卡,点击环境变量按钮,弹出环境变量对话框,单击新建(W)按钮,弹出新建系统变量对话框,在该对话框中输入变量名为JAVA_HOME和变量值为d:Program FilesJavajdk-1_5_0_17。用同样的办法设置CLASSPATH=%JAVA_HOME%libdt.jar;%JAVA_HOME%libtools.jar和PATH=%JAVA_HOME%bin。2）安装JMF:jmf-2_1_1e-windows-i586.exe选择将JMF的开发和运行环境安装在JDK的路径d:Program FilesJava jdk-1_5_0_17中,使JMF与JDK融为一体,这样可以免去操作系统中设置Java环境变量。3）安装J3D：j3d-1_5_2-windows-i586.exe。4）安装JBuilder2006（集成开发环境）。2.7一种流媒体传输控制方法的提出2.7.1流媒体传输控制的特点目前，网络多媒体技术的应用和发展正在迅速的增长。一些较常见的例子有网络电话，视频会议，视频点播。流媒体信息的传输控制作为其中一个重要的组成部分，有其不同于普通数据传输控制的特点。一、传输高质量的流媒体信息需要高网络带宽的支持。此外，大多数网络多媒体应用为了提供有效的服务，满足基本的视/音频效果，还需要有最小的吞吐量保证。而普通数据传输的吞吐量可以在很短的时间内减少到接近为零。二、为支持交互性的对话，确保属于不同媒体流或在同一媒体流的数据同步，端到端的延迟和延迟的最大变化量应该有上界的限制。三、普通数据的传输服务可以随时改变传输速率，而连续的多媒体数据的传输服务必须有几十秒的适应阶段，以避免由于速率的突然改变而引起质量的明显改变。四、普通数据传输的服务对差错控制有很高的要求，一段数据的丢失可能引起大批数据失效，因而过分地依赖于数据重发，进行差错恢复。而一小段多媒体数据的丢失往往不会造成严重的后果，再加上为保证数据的实时特征，一般不要求数据重发，所以对差错控制的要求很低。五、为保证传输质量，普通数据传输使用TCP传输协议，但TCP协议不适合实时传输多媒体数据，因特网中多媒体应用程序通常使用UDP作为传输协议。2.7.2流媒体传输控制的研究流媒体传输控制的特点给传统网络提出了许多要求。这些要求可以用服务质量（QOS）参数来说明，比如流量，丢失分组数，延迟和抖动。在提供无差别的、尽力而为的服务，且无任何QOS支持机制的网络中，可用带宽、时延和丢包率都是时变参量。由于这些参量受到整个网络中其他连接行为的影响，因而是很难提前知道的，在这样的网络中为流媒体传输等应用提供可以预测的服务相当困难。另一方面，由于UDP协议没有任何拥塞控制机制，高带宽要求的网络多媒体应用程序往往会成为因特网的负担，并且可能占用基于TCP上的应用程序本应平等分得的那份带宽资源。为解决以上问题，人们提出了不同的方法20,21：1在尽力而为的服务的基础上增加其它的提供不同程度行为保证的服务。这需要在网络中实现具体的资源分配和预留机制，许可控制机制及特殊的调度机制。或者通过在交换机上提供有差别的，分优先级的服务实现一定程度的QOS支持。2根据当前的网络状态调整应用程序使用的带宽实现相应的自适应操作。相对于前一种方法，这种方法可以最大限度的利用随时间变化的网络资源。该方法正被广