基于android的视频通话系统的设计与实现毕业设计论文.doc

《基于android的视频通话系统的设计与实现毕业设计论文.doc》由会员分享，可在线阅读，更多相关《基于android的视频通话系统的设计与实现毕业设计论文.doc（52页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、东北大学毕业设计（论文） 摘要基于Android的视频通话系统的设计与实现摘 要近年来，智能手机操作系统发展迅速，尤其是Android系统的迅猛发展已经将全球智能手机市场引领到了非常火爆的状态。随着手机社交网络、手机多媒体通信和手机游戏等应用程序不断被开发出来，各种基于智能手机操作系统的应用程序正在逐渐影响和改变人们的生活方式。实时视频流技术在可视电话、远程教育、视频点播等方面得到了广泛的应用。本文设计并实现的基于Android的视频通话系统采用C/S架构，包括PC和手机两个客户端。手机端使用Android2.3操作系统。本系统共包含四个子系统：PC端接收子系统、发送子系统，Android端接

2、收子系统、发送子系统。接收子系统实现数据接收、转码和呈现，发送子系统现实数据采集、编码压缩和数据发送。PC端基于JMF框架来实现，Android端使用Android Camera类及其相关类来实现。本文对国内外视频通话的研究情况以及今后的发展前景，对实现视频通话所涉及到的协议和相关技术进行了分析，在此基础上提出了一种可行的网络视频通话设计方案，并通过需求分析、详细设计、编码实现、单元测试以及集成测试等过程完成了本系统的设计与实现。本系统实现了跨平台视频通话，使PC与Android之间的视频通话成为了可能，可以起到丰富人们日常生活交流和娱乐方式的作用。关键词：Android，视频通话，JMF，P

3、C，RTP/RTCP-II-东北大学毕业设计（论文） AbstractDesign and Implementation of an Android-Based Video Calling SystemAbstractIn recent years, the rapid development of smart phone operating system, especially Android system, has led the global smart phone market into explosion state. With some application such as mo

4、bile social networking, mobile media communications and mobile games being continually developed, a variety of application on smart phone operation systems are increasingly affecting and changing peoples lifestyles. The real-time video streams technology is used widely in such aspects as videophone,

5、 distance education and video on demand.The system based on android uses c/s architecture. It includes two clients. One is on the Windows system, the other one is on the Android 2.3 system. There are four subsystems. Each of clients has a send subsystem and a receiver subsystem. The main function of

6、 the receiver subsystem is to receiver data from internet and decodes that data. After that, it will display that data as soon as possible. The main function of the send subsystem is to collect data from camera and then encodes the data. After that, the data will be sanded to the Internet. On the PC

7、 client, we use the JMF framework. One the Android client, we use Android API. This paper firstly introduces the research condition of the video call and development tendency. It analysis some technologies about the video calling system and comes up with a feasible plan. It introduces the video call

8、ing system about requirement analysis, detailed design, realize and testing.This system achieves the cross-platform video calling. It becomes possible to make video calling between PC and Android and will enrich the peoples communication and entertainment in their daily lives.Key words: Android, vid

9、eo call, JMF, PC, RTP/RTCP东北大学毕业设计（论文） 目录目 录摘 要IAbstractII第1章绪 论11.1 课题概述11.1.1 课题背景11.1.2 课题的目的及意义11.2 国内外发展现状21.3 研究内容21.4 组织结构3第2章相关技术42.1 Java多媒体框架42.1.1 JMF的功能42.1.2 JMF中的数据源42.1.3 JMF中的媒体播放器42.1.4 JMF中的媒体处理器52.1.5 JMF中的事件模型62.2 RTP/RTCP协议62.2.1 RTP实时传输协议62.2.2 RTCP实时传输协议82.3 FFmpeg视频编解码技术92.3.

10、1 FFmpeg简介92.3.2 组成102.3.3 编码框架102.3.4 解码框架112.4 本章小结12第3章 系统分析133.1 需求分析133.1.1 系统总体需求133.1.3 用例分析143.2 系统运行环境与开发环境193.2.1 运行环境193.2.3 开发环境203.3 系统可行性分析203.3.1 技术可行性203.4 本章小结21第4章 系统设计224.1 概要设计224.1.1 系统软件体系结构的设计224.1.2 系统功能模块234.1.3 模块功能分析234.2.3 数据库设计294.2 本章小结30第5章 系统实现315.1 功能子模块的实现315.1.1 硬件

11、检测模块315.1.2 数据采集模块315.1.3 压缩编码模块335.1.4 数据发送模块345.1.5 数据接收模块365.1.6 解码模块375.1.7 呈现模块385.1.8 会话参与者管理模块395.2 本章小结40第6章系统测试416.1 单元测试416.2 集成测试436.3 本章小结44第7章结论45参考文献46致 谢47-IV-东北大学毕业设计（论文） 第1章 绪论第1章绪 论1.1 课题概述1.1.1 课题背景随着移动通信网络与多媒体技术的飞速发展，很多智能手机以及其应用软件的产生和发展正在逐渐改变人们的生活方式和生活习惯。Android是Google公司于2007年11月

12、5日发布的一款基于Linux内核的开放源代码的智能手机操作系统。由于其具有的开放性使得仟何厂商和个人都可以作为其开发者参与其中，Android在发布的随后几年中得到了迅猛的发展。包括设备生产商、芯片制造商、应用开发商及网络运营商在内的商业公司和组织，以及全世界的应用程序开发者都致力于开发出最新最具影响力的手机硬件及软件。近年来，基于IP网络的语音及视频服务越来越多地进入人们的视线，也有越来越多的公司致力于开发VoIP和 Video Call的应用软件。如Skype公司的Skype软件，Apple公司的 Face Time软件等，不仅能为用户带来更全面的体验，而且也提升了自身产品的市场竞争力。人

13、们不再局限于使用传统的电信网和移动网来拨打电话，而一部手机是否支持网络语音及视频实时通话功能也成为人们购买手机的一个考虑因素。在这一方面，Android之前推出的一系列操作系统版木都没能很好地适应多媒体实时通信的发展。这个问题一直持续到2010年12月7日，Google发布了代号为Gingerbread的Android 2.3操作系统。这一版本的操作系统相比之前的版本有了很多的改进，其中一部分就是对多媒体实时通信有了更好的支持。其中包括对VoIP及SIP的支持，以及对前置摄像头开发的支持，开发者已经可以根据现有的资源对Android系统进行二次开发，并做出应用性很强的即时视频通话软件。1.1.

14、2 课题的目的及意义在Android多媒体应用开发领域，充斥着很多公司和个人开发者开发的多媒体播放器、手机Radio、手机电视和手机语音聊大等多媒体应用软件。但是成形的手机视频通话软件却不多见，本课题致力于对Android移动平台下的网络多媒体开发进行深入细致的研究和分析，并开发出一个可以在手机和PC之间进行高效的、稳定的视频通话的应用软件。本课题力求实现以下目标：(1) Android 2.3系统增加了对前置摄像头的开发许可。本课题要在充分研究并掌握Android平台的原理与软件开发的相关知识基础上，实现基于Android 2.3移动平台的实时视频通话。(2) 本课题在Android端使用第

15、三方开源RTP库Jlibrtp，使实时多媒体码流的发送和控制更方便。PC端使用成熟的Java多媒体框架JMF完成视频采集、编码、发送、接收、解码。(3) 为了保证本系统的友好性，本课题致力于开发一套拥有友好用户界而与稳定用户数据后台支持的应用软件，尽量保证软件使用起来更方便。随着无线网络的快速发展，手机+Wifi接入互联网的方式已经越来越普遍地为手机用户所使用。Wifi技术基于IEEE制定的802.11标准，不仅覆盖范围能达到接近100米，而且网络速率可以达到 1Mbps，这为基于移动终端的多媒体实时通信创造了良好的条件。基于Android记移动终端的视频通话系统的实现与优化，对于人们日常生活

16、的交流和娱乐方式会有很重要的意义。1.2 国内外发展现状Google是Androd系统的创始者和发布者，但是并不是最先推出基于Android移动终端视频通话应用软件的。在2010年末的时候，一款搭载了Android操作系统的视频通话软件Fring便进入了人们的视线。Fring可以在两台使用了前置摄像头的Android手机上进行视频通话，并使用了自主研发的动态视频质量(DVQ)技术来保证服务质量。该技术利用当前网络带宽作为依据来调整视频编码比特率和帧速率，从而带来流畅清晰的视频体验。Google于2011年5月也正式在 GoogleTalk中加入了视频通话部分，使任意两个拥有Gmail账号的用户

17、都可以使用搭载了 Android2.3操作系统版本以上的手机来进行视频通话1。另外，Yahoo也在其Messenger中加入了视讯通信的插件供用户下载使用。在国内，基于Wifi的免费视频通话软件并不多，而且对网络的适应性也不是很强。1.3 研究内容本课题一个涉及到两个客户端。PC端基于JMF框架，Android端基于Android 2.3并使用开源RTP传输框架Jlibrtp，在此基础上设计并实现了视频通话系统。本系统没有对网络NAT穿透，因此目前只能在局域网环境中进行视频通话。但只要搭载一个成型的NAT模块，系统即可在任何网络环境中进行视频通话。(1) 研究并掌握了Android平台的原理与

18、软件开发的相关知识，实现了对Android Camera的实时数据采集与回显，实现了应用于Android 2.3移动平台上基于RTP的视频通话系统。(2) 深入研究并分析了第三方开源RTP/RTCP库Jlibrtp并应用于Android平台上。对于Java多媒体框架也有了深入的了解。(3) 详细分析并设计了视频通话系统的框架以及各个功能模块之间的协同工作机制，并在此基础上开发了一套友好的应用软件界面，保证了用户数据后台支持，使软件使用起来更方便。1.4 组织结构本文分六个章节来进行介绍：第1章 绪论。介绍了本课题的背景、目的、意义以及国内外的发展情况。第2章 相关技术。介绍Java多媒体框架，

19、重点介绍了RTP/RTCP传输协议的原理。第3章 需求分析。通过用例的方式对基于Android的视频通话系统进行需求分析，包括功能性需求分析和非功能性需求分析，进而得出视频通话的用例模型。第4章 系统设计。完成详细的功能设计，进行软件架构分析，对软件模块进行划分。包括视频采集、编解码、实时传输以及视频呈现等模块。附加了其它模块，如数据库操作，GUI等。第5章 系统实现。完成需求分析提出的各个功能模块，实现了基于Android的视频通话系统。第6章 系统测试。对各个功能模块编写基本的测试用例进行测试。第7章 总结与展望。对工作做了简要的总结，并对后续工作提出了设想。 -46-东北大学毕业设计（论

20、文） 第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

21、的主要功能有：(1) 在Java的应用程序和Applet中，播放各种媒体格式文件。(2) 在Internet中播放流媒体数据。(3) 可以在麦克风和数字摄像机的帮助下采集音频和视频数据, 并且将这些数据保存为多种格式的文件。(4) 在Internet中发布自己的音、视频流。(5) 用来制作实时的音、视频广播服务。2.1.2 JMF中的数据源JMF API可以同步播放来自各种数据源 (DataSource)的时基媒体，例如本地或网络数据文件等。数据源封装了媒体数据流、媒体的具体位置和用于传输媒体的协议，一个数据源一旦被获取，它将不能再用于传输其他媒体数据。 JMF API支持的两种类型的数据源是

22、Pull数据源和Push数据源。一个媒体播放器的数据源可以用一个JMF MediaLocator或一个URL来定位。MediaLcator是一个描述某媒体播放器显示的媒体数据的类，它类似于URL类，并可由URL类来构造。另外，JMF还支持数据源的合并，即可以将多个数据源合并成一个数据源，例如将视频数据源和音频数据源合并在一起作为一个多媒体数据源在网络中传输。2.1.3 JMF中的媒体播放器媒体播放器是JMF的一个基本功能，视频、音频等多媒体的表现都需要用到它的支持，媒体播放器的应用程序接口包括一个可视构件(VisualComponent)和一个控制面板构件(ControlPanelComPon

23、ent)。应用MediaPlayer类创建的对象或继承Javax.media包中的Player接口的其他类创建的对象即可实现媒体播放器，通过MediaPlayer类中提供的方法可以操作各种媒体数据的播放。在JMF媒体播放器从启动媒体播放器到开始播放媒体数据的过程中，JMF中定义了6种工作状态，在正常情况下，JMF媒体播放器需要经历每种状态，然后才能开始播放媒体数据，以下是JMF中定义的6种工作状态。(1) Unrealized状态：在该工作状态下，JMF媒体播放器己经被实例化，但并不知道需要播放的媒体数据的任何信息。(2) Realizing状态：当调用realize()方法时，JMF媒体播放

24、器的状态从unrealized状态变为Realizing状态，在这种状态下，JMF媒体播放器正在确定它需要占用的资源。(3) Realized状态：在这种状态下，JMF媒体播放器已经确定了它需要占用的资源，并且也知道了需要播放的媒体数据的类型。(4) Prefetching状态：当调用prefectch()方法时，JMF媒体播放器的状态从Realized状态变为Prefetching状态，在该状态下，JMF媒体播放器正在为播放媒体数据做一些准备工作，其中包括加载媒体数据，获得需要独占的资源等。(5) Prefetched状态：当JMF媒体播放器完成了获取操作后就处于该状态。(6) Starte

25、d状态：当调用start()方法后，JMF媒体播放器进入该状态并播放媒体数据。而要停止媒体播放器则调用stop()方法，还可以调用deallocate()方法来释放媒体播放器使用的独占资源。2.1.4 JMF中的媒体处理器在JMF API的Javax.media包中定义的Processor接口即为媒体处理器接口，它继承了Player接口，即它也是一种媒体播放器，继承Processor接口的对象除了支持Player对象支持的所有功能外，他还可以控制输入的多媒体数据流进行何种处理以及通过数据源向其他的Player对象或Processor对象输出数据3。继承Processor接口的媒体播放器对象除了

26、具有Player播放器的6种状态外，还包括如下两种新的状态，这两种状态是在Unrealized状态之后，Realizing状态之前的Configuring和Configured状态。Configuring状态:当调用configure()方法后，Processor媒体播放器对象进入该状态。在该状态下，Processor媒体播放器对象链接到数据源并获取输入媒体数据的格式(类型)信息。Configured状态:当完成数据源连接，获得输入数据格式的信息后，Processor媒体播放器对象就处于Configured状态。2.1.5 JMF中的事件模型为了使基于JMF API的应用程序知道媒体系统目前所

27、处的状态，也为了让应用程序对处理媒体数据时出现的错误情况能够做出反应，JMFAPI使用了一种结构化的事件报告机制。当 JMFAPI对象需要报告目前所处的状态时，就产生一个MediaEvent事件，对每一种可以产生MediaEvent事件的JMF对象，JMFAPI都定义了一种相应的监听接口，为了接收MediaEvent消息，则需要实现相应的事件监听接口，并将该监听类注册给要产生消息的对象，通过继承MediaEvent事件可以产生许多JMF媒体播放器特有的事件，这些事件都是遵循JavaBeans事件模型标准的。2.2 RTP/RTCP协议2.2.1 RTP实时传输协议实时传输协议RTP（Real

28、time Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务4。RTP报文头格式如图2.1所示。图2.1 RTP报文头格式以上域具体意义如下： 版本(V)：2比特，此域定义了RTP的版本，此协议定义的版本是2。(值

29、1被RTP草案版本使用，值0用在最初vat语音工具使用的协议中)。填料(P):1比特，若填料比特被设置,此包包含一到多个附加在末端的填充比特，不是负载的一部分。填料的最后一个字节包含可以忽略多少个填充比特。填料可能用于某些具有固定长度的加密算法，或者在底层数据单元中传输多个RTP包。扩展(X):1比特，若设置扩展比特，固定头后面跟随一个头扩展。CSRC计数(CC):4比特，CSRC计数包含了跟在固定头后面CSRC识别符的数目。标志(M):1比特，标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件，如帧范围。规定该标志在静音后的第一个语音包时置位。负载类型(PT):7比特，此域定义了负

30、载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发射机在任意给定时间发出一个单独的RTP负载类型，此域不用来复用不同的媒体流。序列号(sequence number):16比特 每发送一个RTP数据包，序列号加一,接收机可以据此检测包损和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身不加密时(有时包要通过翻译器,它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。时间标志(timestamp):32比特，时间标志反映了RTP数据包中第一个比特的抽样瞬间。抽样瞬间必须由随时间单调和线形增

31、长的时钟得到，以进行同步和抖动计算。时钟的分辨率必须满足要求的同步准确度，足以进行包到达抖动测量。时钟频率与作为负载传输的数据格式独立，在协议中或定义此格式的负载类型说明中静态定义，也可以在通过非RTP方法定义的负载格式中动态说明。若RTP包周期性生成，可以使用由抽样时钟确定的额定抽样瞬间，而不是读系统时钟。例如，对于固定速率语音,时间标志钟可以每个抽样周期加1。若语音设备从输入设备读取覆盖160个抽样周期的数据块，对于每个这样的数据块，时间标志增加160，无论此块被发送还是被静音压缩。时间标志的起始值是随机的，如同序列号。多个连续的RTP包可能由同样的时间标志，若他们在逻辑上同时产生，如属于

32、同一个图像帧。若数据没有按照抽样的顺序发送，连续的RTP包可以包含不单调的时间标志，如MPEG交织图像帧。同步源(SSRC):32比特，SSRC域用以识别同步源.标识符被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。尽管多个源选择同一个SSRC识别符的概率很低，所有RTP实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的SSRC识别符，以避免被当作一个环路源。有贡献源(CSRC)表:0到15项，每项32比特，CSRC列表识别在此包中负载的有贡献源。识别符的数目在CC域中给定.若有贡献源多于15个，仅识别15个。CSRC识别符由混合器插入

33、，用有贡献源的SSRC识别符。例如语音包，混合产生新包的所有源的SSRC标识符都被陈列，以期在接收机处正确指示交谈者。注意：前12个字节出现在每个RTP包中，仅仅在被混合器插入时，才出现CSRC识别符列表。2.2.2 RTCP实时传输协议实时传输控制协议RTCP（Real time Transport Control Protocol）负责管理传输质量，在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RT

34、P和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。RTCP协议的功能是通过不同的RTCP数据报文来实现的，主要有如下几种类型：(1) SR(Sender Report)发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。(2) RR(Receiver Report)接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。(3) SDES源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。(4) BYE通知离开，主要功能是指示

35、某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。(5) APP由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。RTCP数据报携带有服务质量监控的必要的信息，能够对服务质量进行动态的调整，并且能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是组播方式，因此会话中的所有的成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。例如在流媒体应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。

36、另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。RTCP具有以下四个功能： (1) 基本功能是提供数据传输质量的反馈.这是RTP作为一种传输协议的主要作用，它与其他协议的流量和阻塞控制相关.反馈可能对自适应编码有直接作用，但是IP组播的实验表明它对于从接收机得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使观察员

37、评估这些问题是局部的还是全局的。利用类似多点广播的传输机制，可以使某些实体，诸如没有加入会议的网络业务观察员,接收到反馈信息并作为第三类监视员来诊断网络故障.反馈功能通过RTCP发射机和接收机报告实现。(2) RTCP为每个RTP源传输一个固定的识别符，称为标称名或CNAME。由于当发生冲突或程序重启时SSRC可能改变,接收机要用CNAME来跟踪每个成员。接收机还要用CNAME来关联一系列相关RTP会话期中来自同一个成员的多个数据流,例如同步语音和图像。(3) 前两个功能要求所有成员都发送RTCP包，因此必须控制速率以使RTP成员数可以逐级增长。通过让每个成员向所有成员发送控制包，各个成员都可

38、以独立地观察会议中所有成员的数目。(4) 可选的功能是传输最少的会议控制信息，例如在用户接口中显示的成员识别.这最可能在松散控制的会议中起作用，在松散控制会议里，成员可以不经过资格控制和参数协商而加入或退出会议。RTCP作为一个延伸到所有成员的方便通路，必须要支持具体应用所需的所有控制信息通信。2.3 FFmpeg视频编解码技术2.3.1 FFmpeg简介FFmpeg是一个集视频录制、转换和音视频编解码功能于一体的开源C代码库。FFmpeg最初的开发是基于Linux操作系统，但是经过编译和移植后也可以在人多数操作系统中使用。FFmpeg包含了丰富的视频编解码库，支持MPEG、DivX、MPEG

39、-4、AC3、DV、FLV等40多种编码以及AVI、MPEG、OGG、Matroska、ASF等90多种解码。为了保证编解码质量和可移植性，FFmpeg里很多视频编解码的codec都是从头开发的5。2.3.2 组成FFmpeg开源库主要由以下一些子库组成6：(1) libavformat：用于生成和解析各种音视频封装格式，配置和获取编解码器的信息和上下文结构。(2) libavcodec：包含了所有的音视频编解码器。(3) libavutil：包含了一些工具组件函数。(4) libswscale：用于在不同的颜色空间进行转换和视频比例缩放等。(5) libpostproc：用后期的效果处理。(

40、6) ffmpeg：提供了一些可以直接进行格式转换、编解码的工具。(7) ffserve：一个HTTP多媒体即时广播服务器。(8) ffplay：一个简单的用ffmpeg进行解析和解码的播放器。2.3.3 编码框架在使用FFmpeg库中的任何功能之前，都必须对FFmpeg进行注册，否则任何codec和format将无法使用，FFmpeg库中的初始化注册功能由av_register_all()函数来实现。第二步要根据所使用的编码格式申请FFmpeg中的编码器，可以使用两种方法来申请编码器，分别是根据编码器的CODEC_ID来申请和根据设置的文件名格式来申请，例如将CODEC_ID设置为CODEC

41、_ID_MPEG4和将文件名后缀.mp4传入申请编码器的函数，都可以申请到MPEG_ 4格式的编码器。FFmpeg支持现有的大多数视频编码器，如MPEG_1、MPEG_2、MPEG_3、H.261、H.263等，但是目前FFmpeg还不支持H.264编码器，如需要H.264编码器，需要将其他的开源H.264库(如X264库)集成到FFmpeg中，本文不加赘述。在申请好了编码器之后，需要对编码器的各种编码参数进行一些必要的设置以满足不同的要求。其中比较重要的参数有视频尺寸、编码比特率、运动估计算法、GOP大小和像素格式等。视频尺寸即视频的宽度和高度。编码比特率即码率，它决定了编码的质量和压缩率，

42、编码比特率越大，采样率就越高，相应的编码质量也越高，但是压缩率会变小，即需要传送的数据量变大，反之，编码比特率越小，采样率就越低，相应的编码质量就越低，但是压缩率会变大，传送的数据量也会变小。运动估计算法可以有效地去除帧间的冗余，在传输视频时对于减少网络负载量具有非常重要的意义。GOP(Group of Pictures)大小是指以帧数来表示的一组连续画面的大小，在这组连续的画面所对应的帧中，只需要把第一帧作为I帧，其余帧都可以作为P帧或B帧。像素格式是指视频帧中的像素所使用的颜色空间格式，如YUV420P、YUV422P和RGB24等。在编码器准备就绪开始编码之前，还需要分配编码所需的内存空

43、间，这些内存空间包括一帧原始视频图像大小的临时缓存区、一帧原始视频图像大小的图像存放区和一个输出缓存区，输出缓存区可以在不会发生数据溢出的前提下自行设定大小。在前期的准备工作完成之后，就可以对视频序列进行编码了。编码的过程为：首先提取出视频序列的一帧，将这一帧图像拷贝到临时缓冲区中。然后利用月FFmpeg提供的sws_scale()方法将图像像素转换为之前设定的像素格式并存放在图像存放区中;最后使用FFmpeg的avcodec_encode_video()方法将这帧图像编码并存放在输出缓存区中等待发送。当结束编码时，会将之前中请的FFmpeg中的资源和系统内存中的资源进行释放和回收，等待下一次

44、开始编码。编码过程如图2.2所示。图2.2 使用FFmpeg编码过程2.3.4 解码框架本课题对FFmpeg的解码实现过程与编码过程大致类似，有点需要说明的是在分配待解码图像输入缓冲区的时候，所需申请的内存大小要比实际大一个尺寸，这个尺寸在FFmpeg中定义为FF_INPUT_BUFFER_PADDING_SIZE。这是因为有一些解码器在从输入缓冲区读取视频流的时候会以32位或64位为步长，这就有内存溢出的可能性。在输入缓冲区的后面加入一定长度的保护单元，可以避免这种情况的发生，对解码也不会产生影响。如果在分配输入缓冲区的时候忽略了这一点，将会导致无法解码出正确的图像数据的情况。解码过程如图2

45、.3所示。图2.3 使用FFmpeg解码过程2.4 本章小结本章对基于Android的视频通话系统关键技术进行了简单的介绍，并结合本系统介绍了各个技术在实际背景下的具体应用。第一节介绍了Java多媒体框架里在本应用中使用到的重要组件。第二节介绍了RTP/RTCP协议，包括RTP实时传输的原理。第三节介绍了本系统所使用的编解码器，并简单分析了其特点。本章内容是本课题的技术构成，也是本课题能够实现的关键。东北大学毕业设计（论文） 第3章 系统分析第3章 系统分析系统分析在整个软件开发中有着至关重要的作用，只有通过实际的系统分析才能有更好更实用的系统设计，从而实现出令客户满意的软件产品7。本章主要介

46、绍对视频通信系统的需求分析工作，系统的需求来源于项目组专业的需求分析人员与客户交流沟通所得。需求明确，来源可靠，是基于Android视频通话系统需求的一部分。通过详细分析客户需求，初步明确系统的功能性和非功能性需求，其中功能性需求主要通过用例图和详细的用例说明来描述。3.1 需求分析3.1.1 系统总体需求基于Android的视频通话系统主要功能是实现Android系统和PC端之间的视频通话。根据需要本系统只是简单的点到点的视频传输，不需要中间服务器。因此本系统只包含两个客户端。PC端基于Windows操作系统。Android端基于Android 2.3操作系统。两个客户端之间的数据传输通过Wifi。从整体上来看每个客户端都分为两部分，发送端和接收端。由于这两个部分不存在任何联系，因此可以作为两个独立的模块来开发。发送端需要完成从摄像头和麦克风获得原始的数据，将数据编码压缩，然后再发送出去。接收端负责接收数据，将数据解码并显示出来。由于PC端和Android端情况不太一样，因此还需要考虑其它的因素。PC端硬件的复杂多样性，比如有的PC上没有摄像头，有的PC上有多个摄像头。因此必须考虑到硬件检测，并由用户来选择具体使用哪个。为了方便用户使用，在Android端使用SQLite数据库来保存IP地址和端口号。在视频过程中可以实现截屏功能来截取当前图像并保存供用户使用。图3.