东北大学毕业设计（论文） 第1章 绪论
(1) 研究并掌握了Android平台的原理与软件开发的相关知识，实现了对Android Camera的实时数据采集与回显，实现了应用于Android 2.3移动平台上基于RTP的视频通话系统。
(2) 深入研究并分析了第三方开源RTP/RTCP库Jlibrtp并应用于Android平台上。对于Java多媒体框架也有了深入的了解。
(3) 详细分析并设计了视频通话系统的框架以及各个功能模块之间的协同工作机制，并在此基础上开发了一套友好的应用软件界面，保证了用户数据后台支持，使软件使用起来更方便。
1.4 组织结构
本文分六个章节来进行介绍：
第1章 绪论。介绍了本课题的背景、目的、意义以及国内外的发展情况。 第2章 相关技术。介绍Java多媒体框架，重点介绍了RTP/RTCP传输协议的原理。 第3章 需求分析。通过用例的方式对基于Android的视频通话系统进行需求分析，包括功能性需求分析和非功能性需求分析，进而得出视频通话的用例模型。
第4章 系统设计。完成详细的功能设计，进行软件架构分析，对软件模块进行划分。包括视频采集、编解码、实时传输以及视频呈现等模块。附加了其它模块，如数据库操作，GUI等。
第5章 系统实现。完成需求分析提出的各个功能模块，实现了基于Android的视频通话系统。
第6章 系统测试。对各个功能模块编写基本的测试用例进行测试。 第7章 总结与展望。对工作做了简要的总结，并对后续工作提出了设想。
-3-
东北大学毕业设计（论文） 第2章 相关技术
第2章 相关技术
2.1 Java多媒体框架
Java Media Framework(JMF)是SUN和IBM共同开发的能够在Java应用程序和小应用程序中显示，获取多媒体数据的一套类的集合[2]。JMF API使Java程序员做到了以跨平台与设备无关的方式访问音、视频设备，提供了分布式应用环境下实时媒体回放技术，还定义了一系列API插件，允许高级开发人员和技术人员对其进行定制功能扩展，实现特殊的音、视频捕获、处理和回放效果。JMF支持大多数标准的媒体内容类型，如AIFF、AU、AVI、GSM、MIDI、MPEG、QuickTime、RMF和WAV。
2.1.1 JMF的功能
JMF的主要功能有：
(1) 在Java的应用程序和Applet中，播放各种媒体格式文件。 (2) 在Internet中播放流媒体数据。
(3) 可以在麦克风和数字摄像机的帮助下采集音频和视频数据, 并且将这些数据保存为多种格式的文件。
(4) 在Internet中发布自己的音、视频流。 (5) 用来制作实时的音、视频广播服务。
2.1.2 JMF中的数据源
JMF API可以同步播放来自各种数据源 (DataSource)的时基媒体，例如本地或网络数据文件等。数据源封装了媒体数据流、媒体的具体位置和用于传输媒体的协议，一个数据源一旦被获取，它将不能再用于传输其他媒体数据。 JMF API支持的两种类型的数据源是Pull数据源和Push数据源。
一个媒体播放器的数据源可以用一个JMF MediaLocator或一个URL来定位。MediaLcator是一个描述某媒体播放器显示的媒体数据的类，它类似于URL类，并可由URL类来构造。另外，JMF还支持数据源的合并，即可以将多个数据源合并成一个数据源，例如将视频数据源和音频数据源合并在一起作为一个多媒体数据源在网络中传输。
2.1.3 JMF中的媒体播放器
媒体播放器是JMF的一个基本功能，视频、音频等多媒体的表现都需要用到它的
-4-
东北大学毕业设计（论文） 第2章 相关技术
支持，媒体播放器的应用程序接口包括一个可视构件(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.4 JMF中的媒体处理器
在JMF API的Javax.media包中定义的Processor接口即为媒体处理器接口，它继承了Player接口，即它也是一种媒体播放器，继承Processor接口的对象除了支持Player对象支持的所有功能外，他还可以控制输入的多媒体数据流进行何种处理以及通过数据源向其他的Player对象或Processor对象输出数据[3]。
继承Processor接口的媒体播放器对象除了具有Player播放器的6种状态外，还包括如下两种新的状态，这两种状态是在Unrealized状态之后，Realizing状态之前的Configuring和Configured状态。
Configuring状态:当调用configure()方法后，Processor媒体播放器对象进入该状态。在该状态下，Processor媒体播放器对象链接到数据源并获取输入媒体数据的格式(类型)
-5-
东北大学毕业设计（论文） 第2章 相关技术
信息。
Configured状态:当完成数据源连接，获得输入数据格式的信息后，Processor媒体播放器对象就处于Configured状态。
2.1.5 JMF中的事件模型
为了使基于JMF API的应用程序知道媒体系统目前所处的状态，也为了让应用程序对处理媒体数据时出现的错误情况能够做出反应，JMFAPI使用了一种结构化的事件报告机制。当 JMFAPI对象需要报告目前所处的状态时，就产生一个MediaEvent事件，对每一种可以产生MediaEvent事件的JMF对象，JMFAPI都定义了一种相应的监听接口，为了接收MediaEvent消息，则需要实现相应的事件监听接口，并将该监听类注册给要产生消息的对象，通过继承MediaEvent事件可以产生许多JMF媒体播放器特有的事件，这些事件都是遵循JavaBeans事件模型标准的。
2.2 RTP/RTCP协议
2.2.1 RTP实时传输协议
实时传输协议RTP（Real time Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务[4]。
RTP报文头格式如图2.1所示。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图2.1 RTP报文头格式
以上域具体意义如下：
-6-
东北大学毕业设计（论文） 第2章 相关技术
版本(V)：2比特，此域定义了RTP的版本，此协议定义的版本是2。(值1被RTP草案版本使用，值0用在最初\语音工具使用的协议中)。
填料(P):1比特，若填料比特被设置,此包包含一到多个附加在末端的填充比特，不是负载的一部分。填料的最后一个字节包含可以忽略多少个填充比特。填料可能用于某些具有固定长度的加密算法，或者在底层数据单元中传输多个RTP包。
扩展(X):1比特，若设置扩展比特，固定头后面跟随一个头扩展。
CSRC计数(CC):4比特，CSRC计数包含了跟在固定头后面CSRC识别符的数目。 标志(M):1比特，标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件，如帧范围。规定该标志在静音后的第一个语音包时置位。
负载类型(PT):7比特，此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发射机在任意给定时间发出一个单独的RTP负载类型，此域不用来复用不同的媒体流。
序列号(sequence number):16比特 每发送一个RTP数据包，序列号加一,接收机可以据此检测包损和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身不加密时(有时包要通过翻译器,它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。
时间标志(timestamp):32比特，时间标志反映了RTP数据包中第一个比特的抽样瞬间。抽样瞬间必须由随时间单调和线形增长的时钟得到，以进行同步和抖动计算。时钟的分辨率必须满足要求的同步准确度，足以进行包到达抖动测量。时钟频率与作为负载传输的数据格式独立，在协议中或定义此格式的负载类型说明中静态定义，也可以在通过非RTP方法定义的负载格式中动态说明。若RTP包周期性生成，可以使用由抽样时钟确定的额定抽样瞬间，而不是读系统时钟。例如，对于固定速率语音,时间标志钟可以每个抽样周期加1。若语音设备从输入设备读取覆盖160个抽样周期的数据块，对于每个这样的数据块，时间标志增加160，无论此块被发送还是被静音压缩。时间标志的起始值是随机的，如同序列号。多个连续的RTP包可能由同样的时间标志，若他们在逻辑上同时产生，如属于同一个图像帧。若数据没有按照抽样的顺序发送，连续的RTP包可以包含不单调的时间标志，如MPEG交织图像帧。
同步源(SSRC):32比特，SSRC域用以识别同步源.标识符被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。尽管多个源选择同一个SSRC识别符的概率很低，所有RTP实现工具都必须准备检测和解决冲突。若一个源改
-7-