基于Android的视频通话系统的设计与实现毕业设计论文.docx
- 文档编号:14501299
- 上传时间:2023-06-24
- 格式:DOCX
- 页数:63
- 大小:519.18KB
基于Android的视频通话系统的设计与实现毕业设计论文.docx
《基于Android的视频通话系统的设计与实现毕业设计论文.docx》由会员分享,可在线阅读,更多相关《基于Android的视频通话系统的设计与实现毕业设计论文.docx(63页珍藏版)》请在冰点文库上搜索。
基于Android的视频通话系统的设计与实现毕业设计论文
基于Android的视频通话系统的设计与实现
摘要
近年来,智能手机操作系统发展迅速,尤其是Android系统的迅猛发展已经将全球智能手机市场引领到了非常火爆的状态。
随着手机社交网络、手机多媒体通信和手机游戏等应用程序不断被开发出来,各种基于智能手机操作系统的应用程序正在逐渐影响和改变人们的生活方式。
实时视频流技术在可视电话、远程教育、视频点播等方面得到了广泛的应用。
本文设计并实现的基于Android的视频通话系统采用C/S架构,包括PC和手机两个客户端。
手机端使用Android2.3操作系统。
本系统共包含四个子系统:
PC端接收子系统、发送子系统,Android端接收子系统、发送子系统。
接收子系统实现数据接收、转码和呈现,发送子系统现实数据采集、编码压缩和数据发送。
PC端基于JMF框架来实现,Android端使用AndroidCamera类及其相关类来实现。
本文对国内外视频通话的研究情况以及今后的发展前景,对实现视频通话所涉及到的协议和相关技术进行了分析,在此基础上提出了一种可行的网络视频通话设计方案,并通过需求分析、详细设计、编码实现、单元测试以及集成测试等过程完成了本系统的设计与实现。
本系统实现了跨平台视频通话,使PC与Android之间的视频通话成为了可能,可以起到丰富人们日常生活交流和娱乐方式的作用。
关键词:
Android,视频通话,JMF,PC,RTP/RTCP
DesignandImplementationofanAndroid-BasedVideoCallingSystem
Abstract
Inrecentyears,therapiddevelopmentofsmartphoneoperatingsystem,especiallyAndroidsystem,hasledtheglobalsmartphonemarketintoexplosionstate.Withsomeapplicationsuchasmobilesocialnetworking,mobilemediacommunicationsandmobilegamesbeingcontinuallydeveloped,avarietyofapplicationonsmartphoneoperationsystemsareincreasinglyaffectingandchangingpeople’slifestyles.Thereal-timevideostreamstechnologyisusedwidelyinsuchaspectsasvideophone,distanceeducationandvideoondemand.
Thesystembasedonandroidusesc/sarchitecture.Itincludestwoclients.OneisontheWindowssystem,theotheroneisontheAndroid2.3system.Therearefoursubsystems.Eachofclientshasasendsubsystemandareceiversubsystem.Themainfunctionofthereceiversubsystemistoreceiverdatafrominternetanddecodesthatdata.Afterthat,itwilldisplaythatdataassoonaspossible.Themainfunctionofthesendsubsystemistocollectdatafromcameraandthenencodesthedata.Afterthat,thedatawillbesandedtotheInternet.OnthePCclient,weusetheJMFframework.OnetheAndroidclient,weuseAndroidAPI.Thispaperfirstlyintroducestheresearchconditionofthevideocallanddevelopmenttendency.Itanalysissometechnologiesaboutthevideocallingsystemandcomesupwithafeasibleplan.Itintroducesthevideocallingsystemaboutrequirementanalysis,detaileddesign,realizeandtesting.
Thissystemachievesthecross-platformvideocalling.ItbecomespossibletomakevideocallingbetweenPCandAndroidandwillenrichthepeople’scommunicationandentertainmentintheirdailylives.
Keywords:
Android,videocall,JMF,PC,RTP/RTCP
第1章 绪论
1.1课题概述
1.1.1课题背景
随着移动通信网络与多媒体技术的飞速发展,很多智能手机以及其应用软件的产生和发展正在逐渐改变人们的生活方式和生活习惯。
Android是Google公司于2007年11月5日发布的一款基于Linux内核的开放源代码的智能手机操作系统。
由于其具有的开放性使得仟何厂商和个人都可以作为其开发者参与其中,Android在发布的随后几年中得到了迅猛的发展。
包括设备生产商、芯片制造商、应用开发商及网络运营商在内的商业公司和组织,以及全世界的应用程序开发者都致力于开发出最新最具影响力的手机硬件及软件。
近年来,基于IP网络的语音及视频服务越来越多地进入人们的视线,也有越来越多的公司致力于开发VoIP和VideoCall的应用软件。
如Skype公司的Skype软件,Apple公司的FaceTime软件等,不仅能为用户带来更全面的体验,而且也提升了自身产品的市场竞争力。
人们不再局限于使用传统的电信网和移动网来拨打电话,而一部手机是否支持网络语音及视频实时通话功能也成为人们购买手机的一个考虑因素。
在这一方面,Android之前推出的一系列操作系统版木都没能很好地适应多媒体实时通信的发展。
这个问题一直持续到2010年12月7日,Google发布了代号为Gingerbread的Android2.3操作系统。
这一版本的操作系统相比之前的版本有了很多的改进,其中一部分就是对多媒体实时通信有了更好的支持。
其中包括对VoIP及SIP的支持,以及对前置摄像头开发的支持,开发者已经可以根据现有的资源对Android系统进行二次开发,并做出应用性很强的即时视频通话软件。
1.1.2课题的目的及意义
在Android多媒体应用开发领域,充斥着很多公司和个人开发者开发的多媒体播放器、手机Radio、手机电视和手机语音聊大等多媒体应用软件。
但是成形的手机视频通话软件却不多见,本课题致力于对Android移动平台下的网络多媒体开发进行深入细致的研究和分析,并开发出一个可以在手机和PC之间进行高效的、稳定的视频通话的应用软件。
本课题力求实现以下目标:
(1)Android2.3系统增加了对前置摄像头的开发许可。
本课题要在充分研究并掌握Android平台的原理与软件开发的相关知识基础上,实现基于Android2.3移动平台的实时视频通话。
(2)本课题在Android端使用第三方开源RTP库Jlibrtp,使实时多媒体码流的发送和控制更方便。
PC端使用成熟的Java多媒体框架JMF完成视频采集、编码、发送、接收、解码。
(3)为了保证本系统的友好性,本课题致力于开发一套拥有友好用户界而与稳定用户数据后台支持的应用软件,尽量保证软件使用起来更方便。
随着无线网络的快速发展,手机+Wifi接入互联网的方式已经越来越普遍地为手机用户所使用。
Wifi技术基于IEEE制定的802.11标准,不仅覆盖范围能达到接近100米,而且网络速率可以达到1Mbps,这为基于移动终端的多媒体实时通信创造了良好的条件。
基于Android记移动终端的视频通话系统的实现与优化,对于人们日常生活的交流和娱乐方式会有很重要的意义。
1.2国内外发展现状
Google是Androd系统的创始者和发布者,但是并不是最先推出基于Android移动终端视频通话应用软件的。
在2010年末的时候,一款搭载了Android操作系统的视频通话软件Fring便进入了人们的视线。
Fring可以在两台使用了前置摄像头的Android手机上进行视频通话,并使用了自主研发的动态视频质量(DVQ)技术来保证服务质量。
该技术利用当前网络带宽作为依据来调整视频编码比特率和帧速率,从而带来流畅清晰的视频体验。
Google于2011年5月也正式在GoogleTalk中加入了视频通话部分,使任意两个拥有Gmail账号的用户都可以使用搭载了Android2.3操作系统版本以上的手机来进行视频通话[1]。
另外,Yahoo也在其Messenger中加入了视讯通信的插件供用户下载使用。
在国内,基于Wifi的免费视频通话软件并不多,而且对网络的适应性也不是很强。
1.3研究内容
本课题一个涉及到两个客户端。
PC端基于JMF框架,Android端基于Android2.3并使用开源RTP传输框架Jlibrtp,在此基础上设计并实现了视频通话系统。
本系统没有对网络NAT穿透,因此目前只能在局域网环境中进行视频通话。
但只要搭载一个成型的NAT模块,系统即可在任何网络环境中进行视频通话。
(1)研究并掌握了Android平台的原理与软件开发的相关知识,实现了对AndroidCamera的实时数据采集与回显,实现了应用于Android2.3移动平台上基于RTP的视频通话系统。
(2)深入研究并分析了第三方开源RTP/RTCP库Jlibrtp并应用于Android平台上。
对于Java多媒体框架也有了深入的了解。
(3)详细分析并设计了视频通话系统的框架以及各个功能模块之间的协同工作机制,并在此基础上开发了一套友好的应用软件界面,保证了用户数据后台支持,使软件使用起来更方便。
1.4组织结构
本文分六个章节来进行介绍:
第1章绪论。
介绍了本课题的背景、目的、意义以及国内外的发展情况。
第2章相关技术。
介绍Java多媒体框架,重点介绍了RTP/RTCP传输协议的原理。
第3章需求分析。
通过用例的方式对基于Android的视频通话系统进行需求分析,包括功能性需求分析和非功能性需求分析,进而得出视频通话的用例模型。
第4章系统设计。
完成详细的功能设计,进行软件架构分析,对软件模块进行划分。
包括视频采集、编解码、实时传输以及视频呈现等模块。
附加了其它模块,如数据库操作,GUI等。
第5章系统实现。
完成需求分析提出的各个功能模块,实现了基于Android的视频通话系统。
第6章系统测试。
对各个功能模块编写基本的测试用例进行测试。
第7章总结与展望。
对工作做了简要的总结,并对后续工作提出了设想。
第2章 相关技术
2.1Java多媒体框架
JavaMediaFramework(JMF)是SUN和IBM共同开发的能够在Java应用程序和小应用程序中显示,获取多媒体数据的一套类的集合[2]。
JMFAPI使Java程序员做到了以跨平台与设备无关的方式访问音、视频设备,提供了分布式应用环境下实时媒体回放技术,还定义了一系列API插件,允许高级开发人员和技术人员对其进行定制功能扩展,实现特殊的音、视频捕获、处理和回放效果。
JMF支持大多数标准的媒体内容类型,如AIFF、AU、AVI、GSM、MIDI、MPEG、QuickTime、RMF和WAV。
2.1.1JMF的功能
JMF的主要功能有:
(1)在Java的应用程序和Applet中,播放各种媒体格式文件。
(2)在Internet中播放流媒体数据。
(3)可以在麦克风和数字摄像机的帮助下采集音频和视频数据,并且将这些数据保存为多种格式的文件。
(4)在Internet中发布自己的音、视频流。
(5)用来制作实时的音、视频广播服务。
2.1.2JMF中的数据源
JMFAPI可以同步播放来自各种数据源(DataSource)的时基媒体,例如本地或网络数据文件等。
数据源封装了媒体数据流、媒体的具体位置和用于传输媒体的协议,一个数据源一旦被获取,它将不能再用于传输其他媒体数据。
JMFAPI支持的两种类型的数据源是Pull数据源和Push数据源。
一个媒体播放器的数据源可以用一个JMFMediaLocator或一个URL来定位。
MediaLcator是一个描述某媒体播放器显示的媒体数据的类,它类似于URL类,并可由URL类来构造。
另外,JMF还支持数据源的合并,即可以将多个数据源合并成一个数据源,例如将视频数据源和音频数据源合并在一起作为一个多媒体数据源在网络中传输。
2.1.3JMF中的媒体播放器
媒体播放器是JMF的一个基本功能,视频、音频等多媒体的表现都需要用到它的支持,媒体播放器的应用程序接口包括一个可视构件(VisualComponent)和一个控制面板构件(ControlPanelComPonent)。
应用MediaPlayer类创建的对象或继承Javax.media包中的Player接口的其他类创建的对象即可实现媒体播放器,通过MediaPlayer类中提供的方法可以操作各种媒体数据的播放。
在JMF媒体播放器从启动媒体播放器到开始播放媒体数据的过程中,JMF中定义了6种工作状态,在正常情况下,JMF媒体播放器需要经历每种状态,然后才能开始播放媒体数据,以下是JMF中定义的6种工作状态。
(1)Unrealized状态:
在该工作状态下,JMF媒体播放器己经被实例化,但并不知道需要播放的媒体数据的任何信息。
(2)Realizing状态:
当调用realize()方法时,JMF媒体播放器的状态从unrealized状态变为Realizing状态,在这种状态下,JMF媒体播放器正在确定它需要占用的资源。
(3)Realized状态:
在这种状态下,JMF媒体播放器已经确定了它需要占用的资源,并且也知道了需要播放的媒体数据的类型。
(4)Prefetching状态:
当调用prefectch()方法时,JMF媒体播放器的状态从Realized状态变为Prefetching状态,在该状态下,JMF媒体播放器正在为播放媒体数据做一些准备工作,其中包括加载媒体数据,获得需要独占的资源等。
(5)Prefetched状态:
当JMF媒体播放器完成了获取操作后就处于该状态。
(6)Started状态:
当调用start()方法后,JMF媒体播放器进入该状态并播放媒体数据。
而要停止媒体播放器则调用stop()方法,还可以调用deallocate()方法来释放媒体播放器使用的独占资源。
2.1.4JMF中的媒体处理器
在JMFAPI的Javax.media包中定义的Processor接口即为媒体处理器接口,它继承了Player接口,即它也是一种媒体播放器,继承Processor接口的对象除了支持Player对象支持的所有功能外,他还可以控制输入的多媒体数据流进行何种处理以及通过数据源向其他的Player对象或Processor对象输出数据[3]。
继承Processor接口的媒体播放器对象除了具有Player播放器的6种状态外,还包括如下两种新的状态,这两种状态是在Unrealized状态之后,Realizing状态之前的Configuring和Configured状态。
Configuring状态:
当调用configure()方法后,Processor媒体播放器对象进入该状态。
在该状态下,Processor媒体播放器对象链接到数据源并获取输入媒体数据的格式(类型)信息。
Configured状态:
当完成数据源连接,获得输入数据格式的信息后,Processor媒体播放器对象就处于Configured状态。
2.1.5JMF中的事件模型
为了使基于JMFAPI的应用程序知道媒体系统目前所处的状态,也为了让应用程序对处理媒体数据时出现的错误情况能够做出反应,JMFAPI使用了一种结构化的事件报告机制。
当JMFAPI对象需要报告目前所处的状态时,就产生一个MediaEvent事件,对每一种可以产生MediaEvent事件的JMF对象,JMFAPI都定义了一种相应的监听接口,为了接收MediaEvent消息,则需要实现相应的事件监听接口,并将该监听类注册给要产生消息的对象,通过继承MediaEvent事件可以产生许多JMF媒体播放器特有的事件,这些事件都是遵循JavaBeans事件模型标准的。
2.2RTP/RTCP协议
2.2.1RTP实时传输协议
实时传输协议RTP(RealtimeTransportProtocol):
是针对Internet上多媒体数据流的一个传输协议,由IETF作为RFC1889发布,现在最新的为RFC3550。
RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。
RTP的典型应用建立在UDP上,但也可以在TCP等其他协议之上工作。
RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务[4]。
RTP报文头格式如图2.1所示。
图2.1RTP报文头格式
以上域具体意义如下:
版本(V):
2比特,此域定义了RTP的版本,此协议定义的版本是2。
(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中)。
填料(P):
1比特,若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分。
填料的最后一个字节包含可以忽略多少个填充比特。
填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包。
扩展(X):
1比特,若设置扩展比特,固定头后面跟随一个头扩展。
CSRC计数(CC):
4比特,CSRC计数包含了跟在固定头后面CSRC识别符的数目。
标志(M):
1比特,标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围。
规定该标志在静音后的第一个语音包时置位。
负载类型(PT):
7比特,此域定义了负载的格式,由具体应用决定其解释。
协议可以规定负载类型码和负载格式之间一个默认的匹配。
其他的负载类型码可以通过非RTP方法动态定义。
RTP发射机在任意给定时间发出一个单独的RTP负载类型,此域不用来复用不同的媒体流。
序列号(sequencenumber):
16比特每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列。
序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。
时间标志(timestamp):
32比特,时间标志反映了RTP数据包中第一个比特的抽样瞬间。
抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算。
时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量。
时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明。
若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟。
例如,对于固定速率语音,时间标志钟可以每个抽样周期加1。
若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩。
时间标志的起始值是随机的,如同序列号。
多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生,如属于同一个图像帧。
若数据没有按照抽样的顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图像帧。
同步源(SSRC):
32比特,SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。
尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。
若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源。
有贡献源(CSRC)表:
0到15项,每项32比特,CSRC列表识别在此包中负载的有贡献源。
识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个。
CSRC识别符由混合器插入,用有贡献源的SSRC识别符。
例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者。
注意:
前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表。
2.2.2RTCP实时传输协议
实时传输控制协议RTCP(RealtimeTransportControlProtocol)负责管理传输质量,在当前应用进程之间交换控制信息,提供流量控制和拥塞控制服务。
在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。
RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。
RTCP协议的功能是通过不同的RTCP数据报文来实现的,主要有如下几种类型:
(1)SR(SenderReport)发送端报告,所谓发送端是指发出RTP数据报的应用程序或者终端,发送端同时也可以是接收端。
(2)RR(ReceiverReport)接收端报告,所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
(3)SDES源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。
(4)BYE通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。
(5)APP由应用程序自己定义,解决了RTCP的扩展性问题,并且为协议的实现者提供了很大的灵活性。
RTCP数据报携带有服务质量监控的必要的信息,能够对服务质量进行动态的调整,并且能够对网络拥塞进行有效的控制。
由于RTCP数据报采用的是组播方式,因此会话中的所有的成员都可以通过RTCP数据报返回的控制信息,来了解其他参与者的当前情况。
例如在流媒体应用场合下,发送媒体流的应用程序将周期性地产生发送端报告SR,该RTCP数据报含有不同媒体流间的同步信息,以及已经发送的数据报和字节的计数,接收端根据这些信息可以估计出实际的数据传输速率。
另一方面,接收端会向所有已知的发送端发送接收端报告RR,该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息,发送端
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 Android 视频 通话 系统 设计 实现 毕业设计 论文