6A文基于RTP协议的流媒体的实时传输的实现.docx
《6A文基于RTP协议的流媒体的实时传输的实现.docx》由会员分享，可在线阅读，更多相关《6A文基于RTP协议的流媒体的实时传输的实现.docx（74页珍藏版）》请在冰点文库上搜索。
6A文基于RTP协议的流媒体的实时传输的实现
毕业设计（论文）
题目：
基于RTP协议的流媒体的实时传输的实现
系别：
电子信息科学系
专业：
电子信息科学与技术
班级：
学生姓名：
学号：
指导教师：
学位论文原创性声明
本人郑重声明：
所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。
除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。
本人完全意识到本声明的法律后果由本人承担。
作者签名：
20GG年6月14日
学位论文版权使用授权书
本学位论文作者完全了解学校有关保障、使用学位论文的规定，同意学校保留并向有关学位论文管理部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。
本人授权省级优秀学士学位论文评选机构将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
本学位论文属于
1、保密□，在_________年解密后适用本授权书。
2、不保密√。
（请在以上相应方框内打“√”）
作者签名：
20GG年6月14日
导师签名：
20GG年6月15日
摘要
基于IP的网络中提供的尽力而为的服务并不适合流媒体的传输[4]。
本文的研究项目由网络流媒体传输需求提出，旨在研究基于RTP协议的流媒体的实时传输，使之能够适应网络状态的变化。
论文的论述从以下三个方面展开：
（1）本文首先分析了网络多媒体应用中常用的流媒体技术，视频压缩编码技术。
（2）本文深入分析了RTP/RTCP的特点、内容，认为该协议非常适合多媒体信息的网上传输。
（3）为了实现实时传输，本文采用sun公司所提供的平台。
利用JAVA提供的宽松的格式支持和基于JMF组件对象模型的特征，研究了JMF的体系结构、基本原理和基本构件，利用JMF的体系结构和已有的采集、编码组件，实现了一套完整的流媒体传输实验模型。
关键词：
RTP；流媒体传输；JMF；Internet
Abstract
Thebest-effortservicebasedonIPprovidedbyInternetisn’tsuitableforthetransmissionofStreamingMediainformation.ComingfromaStreamingMediatransmissionneedinnetworkedmultimediaapplication,theresearchprojectthethesisdiscussesistoresearchanRTP-basedStreamingMediatransmissionwhichcanadapttothechangesofnetworkstates.Thethesisincludesthefollowingthreeparts:
Firstly,thisthesisanalyzesstreammediatechnologyandvideocompressioncodingtechnologyinnetworkedmultimediaapplication.Secondly,thisthesislucubratesthecontentsandcharactersofRTP/RTCPandthinksthatRTPiswellsuitablefortheStreamingMediainformationtransmission.Fourt-hly,inordertorealizeRTPandtransmissioncontrolpolicy,thisthesismakesuseoftheplatformofSUN.UsingthewidevarietyofformatssupportedbyJAVAandthecharactersbasedonJMFcomponentobjectmodel,thisthesisresearchesthearchitectureofJMF,itsbasictheoryandconstructionofitsbasiccomponent.WiththehelpofeGistingcaptureandencodecomponents,makinguseofJMFarchitecture,thisthesisrealizesanintegratedStreamingMediatransmissioneGperimentmodel.
Keywords:
RTP;StreamingMediaTransmission;JMF;Internet
目录
第一章绪论1
1.1课题的背景1
1.2本课题所做的工作1
1.3流媒体技术2
1.3.1视频技术发展的现状2
1.3.2多媒体数据压缩技术3
1.4实时传输协议RTP/RTCP7
1.4.1RTP的特点7
1.4.2RTP的数据包格式8
1.4.3RTP在协议层中的位置9
1.4.4RTCP的控制功能10
1.4.5RTCP发送方报告数据包格式11
第二章总体方案设计14
2.1方案论证14
2.1.1方案一.采用DirectShow框架实现流媒体实时传输14
2.1.2方案二.在嵌入式平台下实现流媒体实时传输15
2.1.3方案三.采用JAVA媒体框架（JMF）实现流媒体实时传输16
2.2.系统总体设计17
2.3系统处理流程图17
2.4系统模块的划分及功能描述18
2.5JMF体系结构18
2.6建立Java多媒体开发环境所需的硬件和软件19
2.6.1硬件环境19
2.6.2软件环境19
2.7一种流媒体传输控制方法的提出20
2.7.1流媒体传输控制的特点20
2.7.2流媒体传输控制的研究21
2.7.3本文提出的控制方法23
第三章用Java实现流媒体实时传输24
3.1服务器端媒体处理程序24
3.1.1发送端程序流程图24
3.1.2流媒体的捕获25
3.1.3流媒体的压缩26
3.1.4流媒体的实时传输27
3.1.5停止传输流媒体29
3.2采用JMFRTPAPI接收流媒体数据30
3.2.1JMF的回放机制30
3.2.2接收端程序流程图31
3.2.3流媒体的接收32
3.2.4流媒体解压缩、实时播放33
3.2.5监听接收媒体流事件34
3.2.6监听数据是否接收完毕35
3.3本章小节36
第四章系统测试37
4.1系统测试结果与分析37
4.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流媒体技术
流媒体（StreamingMedia），就是应用流技术在网络上传输的多媒体文件。
流（Streaming）是对在网路上传输特别的编码数字媒体内容——如音频、视频、动画片、图形、照片、文本到最终用户的一种描述[1]。
只要是用流服务器传输媒体，通过网络向用户计算机连续、实时传送数据包，用户能够立即、不中断播放，并且不需要固定的存储空间在最终用户的磁盘上，都可以说是流。
众所周知，在Internet上传输音/视频（A/V）等多媒体信息，目前主要有下载和流式传输两种方式。
传统的文件传输方式是，一个互连网的用户在观看一个视频文件前必须要完全下载此文件。
传统文件30秒的视频剪辑在正常的每秒56KbpsInternet接入下，传输需要将近30分钟的时间。
那么就算是一个广告短片最少也需要1个小时的下载，这还是在网络状况极其良好的情况下。
下载一个A/V文件花上数小时可谓是家常便饭。
显然这个速度是大多数人都无法忍受的。
通常A/V文件相对于其他类型的文件而言容量较大。
因此，在网络带宽的限制下，必须要寻找别的解决方法。
流技术正是为了绕过互连网的这个局限而设计的。
观看的时候不用把文件完全下载，可以像看电视和听广播一样，在观看和收听前才接受图像和声音。
实际上在服务器端一个媒体文件就被分隔成很小的一片，而这一小片文件的长度是非常小的。
但并不是说文件整体就变小了，原始文件依然很大。
为了实现流，有些不太必要的数据就要丢失掉，以图像和文件的质量损失为代价使完整数据包传输更加快捷。
1.3.1视频技术发展的现状
随着信息技术的发展，人们对信息的需求已不满足于传统的电报电话业务及传统的文件传输、电子邮件等数据业务，而是追求更高品质的集视频、图像、声音、文字、甚至动画等为一体的多媒体应用服务。
视频技术是多媒体技术中的一个重要组成部分。
视频信息以其数据量大、实时性强、冗余多等特点倍受研究人员的关注[5]。
为了提高视频数据的传输效率，针对不同的视频信号产生了不同的视频数据压缩标准，如：
MPEG-1，MPEG-2，MPEG-4，H.263+。
新的视频压缩标准H.264于20GG年3月公布于众，新的压缩技术在测试过程中，其数据交换速度约为1Mbps，为宽带网络视频文件的传输铺平了道路。
另外，视频信息的传输正从模拟向数字化方向转变。
早期的INTERNET带宽窄、路由瓶颈、接入速率低、延迟大而不确定，使得实时性强的视音频流质量不能得到保证，限制了IP多媒体的广泛应用。
第四代IP多媒体通信技术已被武汉大学成功攻克，并自主成功地研制了视讯会议系统、IP可视电话等一系列产品，并应用于上海APEC会议多媒体通信系统、酒泉卫星指挥中心等20多个单位，从而使我国成为世界上少数几个全面掌握第四代IP多媒体通信技术平台核心技术的国家之一。
第四代基于IP网络的多媒体通信技术是当前尖端的通信技术，此前基于电视广播技术交换的通信技术、基于电路交换的通信技术、基于分组交换的通信技术，被称为第一代、第二代和第三代。
在“20GG视频通讯技术应用与发展专题研讨会”上，基于IP的多媒体通信基础、IP视频通信的标准、电信级视频运营网络及视频通信中的质量保障等话题成为关注的热点。
数据压缩标准的不断完善，多媒体视频技术和IP技术的发展和成熟，都为网络多媒体的应用发展提供了基础，带来了新的发展机遇。
1.3.2多媒体数据压缩技术
多媒体信息的编码技术是多媒体信息处理技术中的一个关键问题，多媒体数据的压缩标准为多媒体技术的广泛应用提供了前提。
数字化的视音频信息，其数据量非常大。
不仅需要大容量的存储设备，而且对网络的传输和数据的处理也提出了很高的要求。
即使硬件技术发展得再快，如果不对信息进行压缩，多媒体技术也很难有大的发展，多媒体技术的应用也会受到很大的限制。
另外以视频和音频为典型代表的多媒体信息本身具有很大的压缩潜力。
在一个视频帧中，像素与像素之间无论是在横向还是竖向上都有很大的相关性，而且，帧和帧之间的相关性很大，如对前一个帧的数据作微小的变化，可能就能够得到当前的信息。
1.3.2.1常用的视频数据压缩标准
这方面的工作主要是由国际标准化组织（ISO）和国际电信联盟（ITU）来进行的。
下面介绍其中几种视频压缩标准[2,3]。
1．数字声像存储压缩编码标准MPEG-1。
该标准是为速率为1.5Mbps的数字声像信息的存储而制定的。
由于MPEG-1是针对数字存储而制定的，因此它的编解码器是不对称的，编码器往往比位于用户端的解码器复杂得多。
视频分辨率为352G240（NTSC）和352G288（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相比，它增加了以下功能：
处理隔行扫描视频信号的能力；更高的色信号取样模式；可伸缩的视频编码方式。
视频分辨率为720G480（NTSC）和720G576（PAL）。
它主要用于数字视频广播（DVB）、高清晰度电视（HDTV）和数字视频光盘（DVD）等高质量的视频存储，传输的编码表示和解码规定。
优点：
图像质量很好，有伴音。
缺点：
数据量非常大。
3．低比特率音频与视频对象压缩编码标准MPEG-4。
MPEG-4由ISO的MPEG-4工作组制定。
目标是支持多种多媒体应用（主要侧重于对多媒体信息内容的访问），可根据应用的不同要求现场配置解码器。
编码系统是开放的，可以随时加入新的有效的算法模块。
MPEG-4是4.8Kbps—10Mbps下的可变码率的音频和视频压缩编码标准。
视频分辨率为352G288（CIF）和176G144（QCIF）等。
它主要用于可视电话、视频电子邮件等的压缩标准，它也支持不同传输信道的不同码率，如：
4.8Kbps－64kbps的低速通道；64Kbps－384Kbps的中速通道；384Kbps－2Mbps的高速通道。
优点：
图像质量可以调节，有伴音，数据量从小到大可变，具有基于内容检索功能。
缺点：
目前成熟的软硬件产品不多。
4．低比特率视频会议压缩编码标准H.263。
H.263使用户可以扩展带宽利用率，可以低达128Kbps的速率实现全运动视频（每秒30帧）。
H.263以其灵活性及节省带宽和存储空间的特性，具有低总拥有成本并提供了迅速的投资回报。
H.263是为以低达20Kbps到24Kbps带宽传送视频流而开发的，基于H.261编解码器来实现。
H.263算法还可以为开发人员所二次开发，以产生更好的结果和更佳的压缩方案，而这反过来为最终用户在选择最适合他们业务应用的H.263实现中提供了更多的选择。
视频分辨率为352G288（CIF）和176G144（QCIF）等。
它主要用于电视会议和可视电话等压缩标准。
优点：
图像质量可以调节，压缩率高，数据量从小到大可变，软硬件产品成熟。
缺点：
仅有视频压缩不包括声音压缩。
1.3.2.2H.263压缩算法
H.263算法的基本编码思想是利用离散余弦变换（DCT—DiscreteCosine
Transformation）和运动补偿（MotionCompensation）算法，根据运动补偿获得的运动矢量找出预测值，接着求出当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。
H.263的视频编码、解码算法是基于H.261算法的，是H.261算法的改进。
H.263
算法采用帧间与帧内编码相结合的混合编码技术，若前后两帧很相似，其帧间差值小于某阀值，则采用帧间预测（Inter-framePredicting），然后对帧间预测差进行CT；若前后两帧的帧间预测误差较大，则采用帧内编码，即将当前帧图像直接进行DCT编码。
在H.263中，帧主要分成两种类型：
I帧（Intra－frame）和P帧（Predicted-
frame）。
I帧是利用图像自身的相关性压缩，对I帧图像编码时无须参考其它帧，I帧提供了压缩数据流中的随机存取点，它包括全部图像的信息，数据量最大。
P帧是利用最近的前一个I帧或P帧经预测编码得到的，生成的P帧又可以作为下一次预测的参考帧。
H.263的视频编码过程首先是判断图像信号是属于I帧还是P帧，如果是I帧则只做DCT和可变长编码。
如果是P帧则首先做运动补偿，根据运动补偿获得的运动矢量找出预测值，接着求当前值和预测值的差，再将这个差值做DCT变换，最后做可变长编码。
由于受到传输信道带宽的限制，为了控制H.263的编码速率，在编码器端采用自适应量化器来控制码率，也就是说，H.263是一个可变码率的甚低码率视频压缩编码标准。
自适应量化器能根据预测的比特数自适应修改量化器的量化系数，即自动调整量化间隔大小，以此方式控制码率。
根据量化定义：
如果设量化电平数（量化系数或量化分级数）为J，量化精度为R，则有R＝Log2J。
例如，如果量化系数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编码、游程编码（RLE—RunLengthEncoding）等无损压缩算法（通常压缩比不大），又包括了如DCT变换、运动补偿预测技术、运动补偿插值技术等有损压缩算法（通常压缩比可以很大）。
所以压缩比越大，压缩后的数据量就越小；但是压缩后的图像损失就越大，以后解压重构图像的质量就越差。
通常，对静态图像采用有损压缩技术时，为保证图像的质量，压缩率一般限制在7：
1到25：
1之间；对活动视频采用有损压缩技术，为保证图像质量，压缩率常限制在150：
1以下。
总之，压缩比越大图像质量损失越大。
因此图像压缩比与图像质量显然也是相互矛盾的两个对立面。
1.4实时传输协议RTP/RTCP
1.4.1RTP的特点
为了支持网络实时传输服务，提供数据实时传输的标准，1996年IETF（InternetEngineeringTaskForce）的视频/音频工作组制订了RTP实时传输协议。
在RFC1889中，RTP被定义为紧密相关的两个部分：
1．实时传输协议RTP（Real-timeTransportProtocol），用来传输具有实时特点的数据。
2．RTP控制协议RTCP（RTPControlProtocol），用来控制服务质量，并在正在进行的会话里传送参加方的信息。
RTP提供端到端的实时数据传输服务，包括载荷标识，数据序号，时戳和传输控制。
RTP数据（如表1.4）通常采用UDP/IP封装，它利用UDP的多路复用及校验和服务，共同完成实时数据传输功能。
表1.4数据格式
MACHeader
IPHeader
UDPHeader
RTPMessage
在协议设计时，RTP遵循Clark和Tennenhouse提出的alf&ilp（application
levelframingandintegratedlayerprocessing）原则，即：
集成共性，个性扩展。
在实现时RTP与应用程序紧密结合，根据应用的特点和要求构造与剪裁控制策略，提高会话质量和网络服务的公平性。
总的来说，RTP协议具有以下特点：
一、简单性
RTP协议不具备传输层的完整功能，其本身也不提供任何机制来保证实时地传输数据，不保证服务质量，而是依赖下层协议提供的服务来完成这些任务。
它不保证提交或防止乱序提交，也不假设下层网络是可靠的并且提交的分组是有序的。
RTP报文甚至不包括长度和报文边界的描述，而是依靠下层协议提供长度标识和长度限制。
另外，RTP协议将部分传输层协议功能（比如流量控制）上移到应用层完成，简化了传输层处理，提高了该层的执行效率。
二、灵活性
RTP协议的数据报文和控制报文使用相邻的不同端口，数据流和控制流分离，这样大大地提高了协议的灵活性，处理也简单。
三、支持多播
如果下层网络支持，RTP可支持采用多播的传送方式将实时数据传送到多个目的地，满足多媒体会话的需要。
四、可扩展性
RTP协议通常为一个具体的应用提供服务，通过一个具体的应用进程实现，而不作为OSI体系结构中单独的一层来实现，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。
1.4.2RTP的数据包格式
RTP数据包由RTP头和不定长连续媒体数据组成，其中前12字节为固定的RTP
头，媒体数据可以是编码数据。
RTP数据包头格式如表1.5所示。
表1.5RTP数据包头格式
版本号
（2位）
补充位
（1位）
扩展位
（1位）
CSRC数
（4位）
标记
（1位）
负载类型
（7位）
序列
升级会员 