畢業(yè)設(shè)計--基于android的視頻通話系統(tǒng)的設(shè)計與實現(xiàn)

1、<p>　　基于Android的視頻通話系統(tǒng)的設(shè)計與實現(xiàn)</p><p>　　Design and Implementation of an Android-Based Video Calling System</p><p>　　畢業(yè)設(shè)計（論文）任務(wù)書</p><p>　畢業(yè)設(shè)計（論文）題目：</p><p>　基于Android

2、的視頻通話系統(tǒng)的設(shè)計與實現(xiàn)</p><p>　基本內(nèi)容： 學(xué)習(xí)Java多媒體框架（JMF）的結(jié)構(gòu)特點，了解其對實時傳輸協(xié)議（RTP）的支持，熟練的使用JMF來采集視頻、壓縮視頻、傳輸視頻、接收視頻以及顯示視頻。分析基于安卓的視頻通話系統(tǒng)的功能需求。研究基于安卓的視頻系統(tǒng)的設(shè)計與實現(xiàn)技術(shù)。完成基于安卓的視頻通話系統(tǒng)的總體設(shè)計與詳細(xì)設(shè)計，實現(xiàn)端到端的視頻通話。最后對所實現(xiàn)的功能進(jìn)行測試和評價。翻譯一篇與畢設(shè)內(nèi)容相關(guān)的

3、外文資料，譯文漢字字?jǐn)?shù)不少于4000字。</p><p>　畢業(yè)設(shè)計（論文）專題部分：題目：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　基本內(nèi)容：</p><p>　學(xué)生接受畢業(yè)設(shè)計（論文）題目日期第 1 周指導(dǎo)教師簽字：2012年 3 月 2 日</p><p>　　基于Android的視頻通話系統(tǒng)的設(shè)計與實現(xiàn)</p><

4、p><b>　　摘 要</b></p><p>　　近年來，智能手機(jī)操作系統(tǒng)發(fā)展迅速，尤其是Android系統(tǒng)的迅猛發(fā)展已經(jīng)將全球智能手機(jī)市場引領(lǐng)到了非?；鸨臓顟B(tài)。隨著手機(jī)社交網(wǎng)絡(luò)、手機(jī)多媒體通信和手機(jī)游戲等應(yīng)用程序不斷被開發(fā)出來，各種基于智能手機(jī)操作系統(tǒng)的應(yīng)用程序正在逐漸影響和改變?nèi)藗兊纳罘绞健崟r視頻流技術(shù)在可視電話、遠(yuǎn)程教育、視頻點播等方面得到了廣泛的應(yīng)用。</p&g

5、t;<p>　　本文設(shè)計并實現(xiàn)的基于Android的視頻通話系統(tǒng)采用C/S架構(gòu)，包括PC和手機(jī)兩個客戶端。手機(jī)端使用Android2.3操作系統(tǒng)。本系統(tǒng)共包含四個子系統(tǒng)：PC端接收子系統(tǒng)、發(fā)送子系統(tǒng)，Android端接收子系統(tǒng)、發(fā)送子系統(tǒng)。接收子系統(tǒng)實現(xiàn)數(shù)據(jù)接收、轉(zhuǎn)碼和呈現(xiàn)，發(fā)送子系統(tǒng)現(xiàn)實數(shù)據(jù)采集、編碼壓縮和數(shù)據(jù)發(fā)送。PC端基于JMF框架來實現(xiàn)，Android端使用Android Camera類及其相關(guān)類來實現(xiàn)。本文對國內(nèi)

6、外視頻通話的研究情況以及今后的發(fā)展前景，對實現(xiàn)視頻通話所涉及到的協(xié)議和相關(guān)技術(shù)進(jìn)行了分析，在此基礎(chǔ)上提出了一種可行的網(wǎng)絡(luò)視頻通話設(shè)計方案，并通過需求分析、詳細(xì)設(shè)計、編碼實現(xiàn)、單元測試以及集成測試等過程完成了本系統(tǒng)的設(shè)計與實現(xiàn)。</p><p>　　本系統(tǒng)實現(xiàn)了跨平臺視頻通話，使PC與Android之間的視頻通話成為了可能，可以起到豐富人們?nèi)粘Ｉ罱涣骱蛫蕵贩绞降淖饔谩?lt;/p><p>　　

7、關(guān)鍵詞：Android，視頻通話，JMF，PC，RTP/RTCP</p><p>　　Design and Implementation of an Android-Based Video Calling System</p><p><b>　　Abstract</b></p><p>　　In recent years,

8、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 mobile social networking, mobile media communica

9、tions and mobile games being continually developed, a variety of application on smart phone operation systems are increasingly affecting and changing people’s lifestyles. The real-time video streams technology is used wi

10、dely in such aspects as videophone, distanc</p><p>　　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. Ther

11、e are four subsystems. Each of clients has a send subsystem and a receiver subsystem. The main function of the receiver subsystem is to receiver data from internet and decodes that data. After that, it will display that

12、data as soon as possible. The main function of the send subsystem is to collect data from camera and then encodes the data. Af</p><p>　　This system achieves the cross-platform video calling. It becomes possi

13、ble to make video calling between PC and Android and will enrich the people’s communication and entertainment in their daily lives.</p><p>　　Key words: Android, video call, JMF, PC, RTP/RTCP</p><p

14、><b>　　目 錄</b></p><p><b>　　摘 要I</b></p><p>　　AbstractII</p><p>　　第1章　緒 論1</p><p>　　1.1 課題概述1</p><p>　　1.1.1 課題背景1</p

15、><p>　　1.1.2 課題的目的及意義1</p><p>　　1.2 國內(nèi)外發(fā)展現(xiàn)狀2</p><p>　　1.3 研究內(nèi)容2</p><p>　　1.4 組織結(jié)構(gòu)3</p><p>　　第2章　相關(guān)技術(shù)4</p><p>　　2.1 Java多媒體框架4</p>

16、;<p>　　2.1.1 JMF的功能4</p><p>　　2.1.2 JMF中的數(shù)據(jù)源4</p><p>　　2.1.3 JMF中的媒體播放器4</p><p>　　2.1.4 JMF中的媒體處理器5</p><p>　　2.1.5 JMF中的事件模型6</p><p>　　2.2

17、 RTP/RTCP協(xié)議6</p><p>　　2.2.1 RTP實時傳輸協(xié)議6</p><p>　　2.2.2 RTCP實時傳輸協(xié)議8</p><p>　　2.3 FFmpeg視頻編解碼技術(shù)9</p><p>　　2.3.1 FFmpeg簡介9</p><p>　　2.3.2 組成10</p

18、><p>　　2.3.3 編碼框架10</p><p>　　2.3.4 解碼框架11</p><p>　　2.4 本章小結(jié)12</p><p>　　第3章 系統(tǒng)分析13</p><p>　　3.1 需求分析13</p><p>　　3.1.1 系統(tǒng)總體需求13</p&g

19、t;<p>　　3.1.3 用例分析14</p><p>　　3.2 系統(tǒng)運(yùn)行環(huán)境與開發(fā)環(huán)境19</p><p>　　3.2.1 運(yùn)行環(huán)境19</p><p>　　3.2.3 開發(fā)環(huán)境20</p><p>　　3.3 系統(tǒng)可行性分析20</p><p>　　3.3.1 技術(shù)可行性2

20、0</p><p>　　3.4 本章小結(jié)21</p><p>　　第4章 系統(tǒng)設(shè)計22</p><p>　　4.1 概要設(shè)計22</p><p>　　4.1.1 系統(tǒng)軟件體系結(jié)構(gòu)的設(shè)計22</p><p>　　4.1.2 系統(tǒng)功能模塊23</p><p>　　4.1.3 模

21、塊功能分析23</p><p>　　4.2.3 數(shù)據(jù)庫設(shè)計29</p><p>　　4.2 本章小結(jié)30</p><p>　　第5章 系統(tǒng)實現(xiàn)31</p><p>　　5.1 功能子模塊的實現(xiàn)31</p><p>　　5.1.1 硬件檢測模塊31</p><p>　　5.1

22、.2 數(shù)據(jù)采集模塊31</p><p>　　5.1.3 壓縮編碼模塊33</p><p>　　5.1.4 數(shù)據(jù)發(fā)送模塊34</p><p>　　5.1.5 數(shù)據(jù)接收模塊36</p><p>　　5.1.6 解碼模塊37</p><p>　　5.1.7 呈現(xiàn)模塊38</p><

23、p>　　5.1.8 會話參與者管理模塊39</p><p>　　5.2 本章小結(jié)40</p><p>　　第6章　系統(tǒng)測試41</p><p>　　6.1 單元測試41</p><p>　　6.2 集成測試43</p><p>　　6.3 本章小結(jié)44</p><p>　　第

24、7章　結(jié)　論45</p><p><b>　　參考文獻(xiàn)46</b></p><p><b>　　致 謝47</b></p><p><b>　　第1章　緒 論</b></p><p><b>　　1.1 課題概述</b></p>

25、<p>　　1.1.1 課題背景</p><p>　　隨著移動通信網(wǎng)絡(luò)與多媒體技術(shù)的飛速發(fā)展，很多智能手機(jī)以及其應(yīng)用軟件的產(chǎn)生和發(fā)展正在逐漸改變?nèi)藗兊纳罘绞胶蜕盍?xí)慣。Android是Google公司于2007年11月5日發(fā)布的一款基于Linux內(nèi)核的開放源代碼的智能手機(jī)操作系統(tǒng)。由于其具有的開放性使得仟何廠商和個人都可以作為其開發(fā)者參與其中，Android在發(fā)布的隨后幾年中得到了迅猛的發(fā)展。包括設(shè)

26、備生產(chǎn)商、芯片制造商、應(yīng)用開發(fā)商及網(wǎng)絡(luò)運(yùn)營商在內(nèi)的商業(yè)公司和組織，以及全世界的應(yīng)用程序開發(fā)者都致力于開發(fā)出最新最具影響力的手機(jī)硬件及軟件。</p><p>　　近年來，基于IP網(wǎng)絡(luò)的語音及視頻服務(wù)越來越多地進(jìn)入人們的視線，也有越來越多的公司致力于開發(fā)VoIP和 Video Call的應(yīng)用軟件。如Skype公司的Skype軟件，Apple公司的 Face Time軟件等，不僅能為用戶帶來更全面的體驗，而且也提升了自

27、身產(chǎn)品的市場競爭力。人們不再局限于使用傳統(tǒng)的電信網(wǎng)和移動網(wǎng)來撥打電話，而一部手機(jī)是否支持網(wǎng)絡(luò)語音及視頻實時通話功能也成為人們購買手機(jī)的一個考慮因素。在這一方面，Android之前推出的一系列操作系統(tǒng)版木都沒能很好地適應(yīng)多媒體實時通信的發(fā)展。這個問題一直持續(xù)到2010年12月7日，Google發(fā)布了代號為Gingerbread的Android 2.3操作系統(tǒng)。這一版本的操作系統(tǒng)相比之前的版本有了很多的改進(jìn)，其中一部分就是對多媒體實時通信有

28、了更好的支持。其中包括對VoIP及SIP的支持，以及對前置攝像頭開發(fā)的支持，開發(fā)者已經(jīng)可以根據(jù)現(xiàn)有的資源對Android系統(tǒng)進(jìn)行二次開發(fā)，并做出應(yīng)用性很強(qiáng)的即時視頻通話軟件。</p><p>　　1.1.2 課題的目的及意義</p><p>　　在Android多媒體應(yīng)用開發(fā)領(lǐng)域，充斥著很多公司和個人開發(fā)者開發(fā)的多媒體播放器、手機(jī)Radio、手機(jī)電視和手機(jī)語音聊大等多媒體應(yīng)用軟件。但是成

29、形的手機(jī)視頻通話軟件卻不多見，本課題致力于對Android移動平臺下的網(wǎng)絡(luò)多媒體開發(fā)進(jìn)行深入細(xì)致的研究和分析，并開發(fā)出一個可以在手機(jī)和PC之間進(jìn)行高效的、穩(wěn)定的視頻通話的應(yīng)用軟件。</p><p>　　本課題力求實現(xiàn)以下目標(biāo)：</p><p>　　(1) Android 2.3系統(tǒng)增加了對前置攝像頭的開發(fā)許可。本課題要在充分研究并掌握Android平臺的原理與軟件開發(fā)的相關(guān)知識基礎(chǔ)上，實現(xiàn)

30、基于Android 2.3移動平臺的實時視頻通話。</p><p>　　(2) 本課題在Android端使用第三方開源RTP庫Jlibrtp，使實時多媒體碼流的發(fā)送和控制更方便。PC端使用成熟的Java多媒體框架JMF完成視頻采集、編碼、發(fā)送、接收、解碼。</p><p>　　(3) 為了保證本系統(tǒng)的友好性，本課題致力于開發(fā)一套擁有友好用戶界而與穩(wěn)定用戶數(shù)據(jù)后臺支持的應(yīng)用軟件，盡量保證軟件

31、使用起來更方便。</p><p>　　隨著無線網(wǎng)絡(luò)的快速發(fā)展，手機(jī)+Wifi接入互聯(lián)網(wǎng)的方式已經(jīng)越來越普遍地為手機(jī)用戶所使用。Wifi技術(shù)基于IEEE制定的802.11標(biāo)準(zhǔn)，不僅覆蓋范圍能達(dá)到接近100米，而且網(wǎng)絡(luò)速率可以達(dá)到 1Mbps，這為基于移動終端的多媒體實時通信創(chuàng)造了良好的條件。基于Android記移動終端的視頻通話系統(tǒng)的實現(xiàn)與優(yōu)化，對于人們?nèi)粘Ｉ畹慕涣骱蛫蕵贩绞綍泻苤匾囊饬x。</p>

32、<p>　　1.2 國內(nèi)外發(fā)展現(xiàn)狀</p><p>　　Google是Androd系統(tǒng)的創(chuàng)始者和發(fā)布者，但是并不是最先推出基于Android移動終端視頻通話應(yīng)用軟件的。在2010年末的時候，一款搭載了Android操作系統(tǒng)的視頻通話軟件Fring便進(jìn)入了人們的視線。Fring可以在兩臺使用了前置攝像頭的Android手機(jī)上進(jìn)行視頻通話，并使用了自主研發(fā)的動態(tài)視頻質(zhì)量(DVQ)技術(shù)來保證服務(wù)質(zhì)量。該

33、技術(shù)利用當(dāng)前網(wǎng)絡(luò)帶寬作為依據(jù)來調(diào)整視頻編碼比特率和幀速率，從而帶來流暢清晰的視頻體驗。Google于2011年5月也正式在 GoogleTalk中加入了視頻通話部分，使任意兩個擁有Gmail賬號的用戶都可以使用搭載了 Android2.3操作系統(tǒng)版本以上的手機(jī)來進(jìn)行視頻通話[1]。另外，Yahoo也在其Messenger中加入了視訊通信的插件供用戶下載使用。在國內(nèi)，基于Wifi的免費視頻通話軟件并不多，而且對網(wǎng)絡(luò)的適應(yīng)性也不是很強(qiáng)。&l

34、t;/p><p><b>　　1.3 研究內(nèi)容</b></p><p>　　本課題一個涉及到兩個客戶端。PC端基于JMF框架，Android端基于Android 2.3并使用開源RTP傳輸框架Jlibrtp，在此基礎(chǔ)上設(shè)計并實現(xiàn)了視頻通話系統(tǒng)。本系統(tǒng)沒有對網(wǎng)絡(luò)NAT穿透，因此目前只能在局域網(wǎng)環(huán)境中進(jìn)行視頻通話。但只要搭載一個成型的NAT模塊，系統(tǒng)即可在任何網(wǎng)絡(luò)環(huán)境中進(jìn)行

35、視頻通話。</p><p>　　(1) 研究并掌握了Android平臺的原理與軟件開發(fā)的相關(guān)知識，實現(xiàn)了對Android Camera的實時數(shù)據(jù)采集與回顯，實現(xiàn)了應(yīng)用于Android 2.3移動平臺上基于RTP的視頻通話系統(tǒng)。</p><p>　　(2) 深入研究并分析了第三方開源RTP/RTCP庫Jlibrtp并應(yīng)用于Android平臺上。對于Java多媒體框架也有了深入的了解。<

36、/p><p>　　(3) 詳細(xì)分析并設(shè)計了視頻通話系統(tǒng)的框架以及各個功能模塊之間的協(xié)同工作機(jī)制，并在此基礎(chǔ)上開發(fā)了一套友好的應(yīng)用軟件界面，保證了用戶數(shù)據(jù)后臺支持，使軟件使用起來更方便。</p><p><b>　　1.4 組織結(jié)構(gòu)</b></p><p>　　本文分六個章節(jié)來進(jìn)行介紹：</p><p>　　第1章 緒論。介

37、紹了本課題的背景、目的、意義以及國內(nèi)外的發(fā)展情況。</p><p>　　第2章 相關(guān)技術(shù)。介紹Java多媒體框架，重點介紹了RTP/RTCP傳輸協(xié)議的原理。</p><p>　　第3章 需求分析。通過用例的方式對基于Android的視頻通話系統(tǒng)進(jìn)行需求分析，包括功能性需求分析和非功能性需求分析，進(jìn)而得出視頻通話的用例模型。</p><p>　　第4章 系統(tǒng)設(shè)計。完成

38、詳細(xì)的功能設(shè)計，進(jìn)行軟件架構(gòu)分析，對軟件模塊進(jìn)行劃分。包括視頻采集、編解碼、實時傳輸以及視頻呈現(xiàn)等模塊。附加了其它模塊，如數(shù)據(jù)庫操作，GUI等。</p><p>　　第5章 系統(tǒng)實現(xiàn)。完成需求分析提出的各個功能模塊，實現(xiàn)了基于Android的視頻通話系統(tǒng)。</p><p>　　第6章 系統(tǒng)測試。對各個功能模塊編寫基本的測試用例進(jìn)行測試。</p><p>　　第7章

39、總結(jié)與展望。對工作做了簡要的總結(jié)，并對后續(xù)工作提出了設(shè)想。</p><p><b>　　第2章　相關(guān)技術(shù)</b></p><p>　　2.1 Java多媒體框架</p><p>　　Java Media Framework(JMF)是SUN和IBM共同開發(fā)的能夠在Java應(yīng)用程序和小應(yīng)用程序中顯示，獲取多媒體數(shù)據(jù)的一套類的集合[2]。JMF

40、API使Java程序員做到了以跨平臺與設(shè)備無關(guān)的方式訪問音、視頻設(shè)備，提供了分布式應(yīng)用環(huán)境下實時媒體回放技術(shù)，還定義了一系列API插件，允許高級開發(fā)人員和技術(shù)人員對其進(jìn)行定制功能擴(kuò)展，實現(xiàn)特殊的音、視頻捕獲、處理和回放效果。JMF支持大多數(shù)標(biāo)準(zhǔn)的媒體內(nèi)容類型，如AIFF、AU、AVI、GSM、MIDI、MPEG、QuickTime、RMF和WAV。</p><p>　　2.1.1 JMF的功能</p>

41、;<p>　　JMF的主要功能有：</p><p>　　(1) 在Java的應(yīng)用程序和Applet中，播放各種媒體格式文件。</p><p>　　(2) 在Internet中播放流媒體數(shù)據(jù)。</p><p>　　(3) 可以在麥克風(fēng)和數(shù)字?jǐn)z像機(jī)的幫助下采集音頻和視頻數(shù)據(jù), 并且將這些數(shù)據(jù)保存為多種格式的文件。</p><p>　

42、　(4) 在Internet中發(fā)布自己的音、視頻流。</p><p>　　(5) 用來制作實時的音、視頻廣播服務(wù)。</p><p>　　2.1.2 JMF中的數(shù)據(jù)源</p><p>　　JMF API可以同步播放來自各種數(shù)據(jù)源 (DataSource)的時基媒體，例如本地或網(wǎng)絡(luò)數(shù)據(jù)文件等。數(shù)據(jù)源封裝了媒體數(shù)據(jù)流、媒體的具體位置和用于傳輸媒體的協(xié)議，一個數(shù)據(jù)源一旦被

43、獲取，它將不能再用于傳輸其他媒體數(shù)據(jù)。 JMF API支持的兩種類型的數(shù)據(jù)源是Pull數(shù)據(jù)源和Push數(shù)據(jù)源。</p><p>　　一個媒體播放器的數(shù)據(jù)源可以用一個JMF MediaLocator或一個URL來定位。MediaLcator是一個描述某媒體播放器顯示的媒體數(shù)據(jù)的類，它類似于URL類，并可由URL類來構(gòu)造。另外，JMF還支持?jǐn)?shù)據(jù)源的合并，即可以將多個數(shù)據(jù)源合并成一個數(shù)據(jù)源，例如將視頻數(shù)據(jù)源和音頻數(shù)據(jù)源

44、合并在一起作為一個多媒體數(shù)據(jù)源在網(wǎng)絡(luò)中傳輸。</p><p>　　2.1.3 JMF中的媒體播放器</p><p>　　媒體播放器是JMF的一個基本功能，視頻、音頻等多媒體的表現(xiàn)都需要用到它的支持，媒體播放器的應(yīng)用程序接口包括一個可視構(gòu)件(VisualComponent)和一個控制面板構(gòu)件(ControlPanelComPonent)。應(yīng)用MediaPlayer類創(chuàng)建的對象或繼承Java

45、x.media包中的Player接口的其他類創(chuàng)建的對象即可實現(xiàn)媒體播放器，通過MediaPlayer類中提供的方法可以操作各種媒體數(shù)據(jù)的播放。</p><p>　　在JMF媒體播放器從啟動媒體播放器到開始播放媒體數(shù)據(jù)的過程中，JMF中定義了6種工作狀態(tài)，在正常情況下，JMF媒體播放器需要經(jīng)歷每種狀態(tài)，然后才能開始播放媒體數(shù)據(jù)，以下是JMF中定義的6種工作狀態(tài)。</p><p>　　(1)

46、Unrealized狀態(tài)：在該工作狀態(tài)下，JMF媒體播放器己經(jīng)被實例化，但并不知道需要播放的媒體數(shù)據(jù)的任何信息。</p><p>　　(2) Realizing狀態(tài)：當(dāng)調(diào)用realize()方法時，JMF媒體播放器的狀態(tài)從unrealized狀態(tài)變?yōu)镽ealizing狀態(tài)，在這種狀態(tài)下，JMF媒體播放器正在確定它需要占用的資源。</p><p>　　(3) Realized狀態(tài)：在這種狀態(tài)

47、下，JMF媒體播放器已經(jīng)確定了它需要占用的資源，并且也知道了需要播放的媒體數(shù)據(jù)的類型。</p><p>　　(4) Prefetching狀態(tài)：當(dāng)調(diào)用prefectch()方法時，JMF媒體播放器的狀態(tài)從Realized狀態(tài)變?yōu)镻refetching狀態(tài)，在該狀態(tài)下，JMF媒體播放器正在為播放媒體數(shù)據(jù)做一些準(zhǔn)備工作，其中包括加載媒體數(shù)據(jù)，獲得需要獨占的資源等。</p><p>　　(5)

48、Prefetched狀態(tài)：當(dāng)JMF媒體播放器完成了獲取操作后就處于該狀態(tài)。</p><p>　　(6) Started狀態(tài)：當(dāng)調(diào)用start()方法后，JMF媒體播放器進(jìn)入該狀態(tài)并播放媒體數(shù)據(jù)。</p><p>　　而要停止媒體播放器則調(diào)用stop()方法，還可以調(diào)用deallocate()方法來釋放媒體播放器使用的獨占資源。</p><p>　　2.1.4 JM

49、F中的媒體處理器</p><p>　　在JMF API的Javax.media包中定義的Processor接口即為媒體處理器接口，它繼承了Player接口，即它也是一種媒體播放器，繼承Processor接口的對象除了支持Player對象支持的所有功能外，他還可以控制輸入的多媒體數(shù)據(jù)流進(jìn)行何種處理以及通過數(shù)據(jù)源向其他的Player對象或Processor對象輸出數(shù)據(jù)[3]。</p><p>

50、　　繼承Processor接口的媒體播放器對象除了具有Player播放器的6種狀態(tài)外，還包括如下兩種新的狀態(tài)，這兩種狀態(tài)是在Unrealized狀態(tài)之后，Realizing狀態(tài)之前的Configuring和Configured狀態(tài)。</p><p>　　Configuring狀態(tài):當(dāng)調(diào)用configure()方法后，Processor媒體播放器對象進(jìn)入該狀態(tài)。在該狀態(tài)下，Processor媒體播放器對象鏈接到數(shù)據(jù)

51、源并獲取輸入媒體數(shù)據(jù)的格式(類型)信息。</p><p>　　Configured狀態(tài):當(dāng)完成數(shù)據(jù)源連接，獲得輸入數(shù)據(jù)格式的信息后，Processor媒體播放器對象就處于Configured狀態(tài)。</p><p>　　2.1.5 JMF中的事件模型</p><p>　　為了使基于JMF API的應(yīng)用程序知道媒體系統(tǒng)目前所處的狀態(tài)，也為了讓應(yīng)用程序?qū)μ幚砻襟w數(shù)據(jù)時出現(xiàn)

52、的錯誤情況能夠做出反應(yīng)，JMFAPI使用了一種結(jié)構(gòu)化的事件報告機(jī)制。當(dāng) JMFAPI對象需要報告目前所處的狀態(tài)時，就產(chǎn)生一個MediaEvent事件，對每一種可以產(chǎn)生MediaEvent事件的JMF對象，JMFAPI都定義了一種相應(yīng)的監(jiān)聽接口，為了接收MediaEvent消息，則需要實現(xiàn)相應(yīng)的事件監(jiān)聽接口，并將該監(jiān)聽類注冊給要產(chǎn)生消息的對象，通過繼承MediaEvent事件可以產(chǎn)生許多JMF媒體播放器特有的事件，這些事件都是遵循Java

53、Beans事件模型標(biāo)準(zhǔn)的。</p><p>　　2.2 RTP/RTCP協(xié)議</p><p>　　2.2.1 RTP實時傳輸協(xié)議</p><p>　　實時傳輸協(xié)議RTP（Real time Transport Protocol）：是針對Internet上多媒體數(shù)據(jù)流的一個傳輸協(xié)議, 由IETF作為RFC1889發(fā)布，現(xiàn)在最新的為RFC3550。RTP被定義為在一

54、對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP等其他協(xié)議之上工作。RTP本身只保證實時數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)[4]。</p><p>　　RTP報文頭格式如圖2.1所示。</p><p>　　圖2.1 RTP報文頭格式</p>

55、<p>　　以上域具體意義如下： </p><p>　　版本(V)：2比特，此域定義了RTP的版本，此協(xié)議定義的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"語音工具使用的協(xié)議中)。</p><p>　　填料(P):1比特，若填料比特被設(shè)置,此包包含一到多個附加在末端的填充比特，不是負(fù)載的一部分。填料的最后一個字節(jié)包含可以忽略多少個填充比特。

56、填料可能用于某些具有固定長度的加密算法，或者在底層數(shù)據(jù)單元中傳輸多個RTP包。</p><p>　　擴(kuò)展(X):1比特，若設(shè)置擴(kuò)展比特，固定頭后面跟隨一個頭擴(kuò)展。</p><p>　　CSRC計數(shù)(CC):4比特，CSRC計數(shù)包含了跟在固定頭后面CSRC識別符的數(shù)目。</p><p>　　標(biāo)志(M):1比特，標(biāo)志的解釋由具體協(xié)議規(guī)定.它用來允許在比特流中標(biāo)記重要的事

57、件，如幀范圍。規(guī)定該標(biāo)志在靜音后的第一個語音包時置位。</p><p>　　負(fù)載類型(PT):7比特，此域定義了負(fù)載的格式，由具體應(yīng)用決定其解釋。協(xié)議可以規(guī)定負(fù)載類型碼和負(fù)載格式之間一個默認(rèn)的匹配。其他的負(fù)載類型碼可以通過非RTP方法動態(tài)定義。RTP發(fā)射機(jī)在任意給定時間發(fā)出一個單獨的RTP負(fù)載類型，此域不用來復(fù)用不同的媒體流。</p><p>　　序列號(sequence number):

58、16比特 每發(fā)送一個RTP數(shù)據(jù)包，序列號加一,接收機(jī)可以據(jù)此檢測包損和重建包序列。序列號的初始值是隨機(jī)的(不可預(yù)測)，以使即便在源本身不加密時(有時包要通過翻譯器,它會這樣做)，對加密算法泛知的普通文本攻擊也會更加困難。</p><p>　　時間標(biāo)志(timestamp):32比特，時間標(biāo)志反映了RTP數(shù)據(jù)包中第一個比特的抽樣瞬間。抽樣瞬間必須由隨時間單調(diào)和線形增長的時鐘得到，以進(jìn)行同步和抖動計算。時鐘的分辨率必

59、須滿足要求的同步準(zhǔn)確度，足以進(jìn)行包到達(dá)抖動測量。時鐘頻率與作為負(fù)載傳輸?shù)臄?shù)據(jù)格式獨立，在協(xié)議中或定義此格式的負(fù)載類型說明中靜態(tài)定義，也可以在通過非RTP方法定義的負(fù)載格式中動態(tài)說明。若RTP包周期性生成，可以使用由抽樣時鐘確定的額定抽樣瞬間，而不是讀系統(tǒng)時鐘。例如，對于固定速率語音,時間標(biāo)志鐘可以每個抽樣周期加1。若語音設(shè)備從輸入設(shè)備讀取覆蓋160個抽樣周期的數(shù)據(jù)塊，對于每個這樣的數(shù)據(jù)塊，時間標(biāo)志增加160，無論此塊被發(fā)送還是被靜音壓縮

60、。時間標(biāo)志的起始值是隨機(jī)的，如同序列號。多個連續(xù)的RTP包可能由同樣的時間標(biāo)志，若他們在邏輯上同時產(chǎn)生，如屬于同一個圖像幀。若數(shù)據(jù)沒有按照抽樣的順序發(fā)送，連續(xù)的RTP包可以包含不單調(diào)的時間標(biāo)志，如MPEG交織圖像幀。</p><p>　　同步源(SSRC):32比特，SSRC域用以識別同步源.標(biāo)識符被隨機(jī)生成，以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符。盡管多個源選擇同一個SSRC識別符的

61、概率很低，所有RTP實現(xiàn)工具都必須準(zhǔn)備檢測和解決沖突。若一個源改變本身的源傳輸?shù)刂罚仨氝x擇新的SSRC識別符，以避免被當(dāng)作一個環(huán)路源。</p><p>　　有貢獻(xiàn)源(CSRC)表:0到15項，每項32比特，CSRC列表識別在此包中負(fù)載的有貢獻(xiàn)源。識別符的數(shù)目在CC域中給定.若有貢獻(xiàn)源多于15個，僅識別15個。CSRC識別符由混合器插入，用有貢獻(xiàn)源的SSRC識別符。例如語音包，混合產(chǎn)生新包的所有源的SSRC標(biāo)識符

62、都被陳列，以期在接收機(jī)處正確指示交談?wù)摺?lt;/p><p>　　注意：前12個字節(jié)出現(xiàn)在每個RTP包中，僅僅在被混合器插入時，才出現(xiàn)CSRC識別符列表。</p><p>　　2.2.2 RTCP實時傳輸協(xié)議</p><p>　　實時傳輸控制協(xié)議RTCP（Real time Transport Control Protocol）負(fù)責(zé)管理傳輸質(zhì)量，在當(dāng)前應(yīng)用進(jìn)程之間交換

63、控制信息，提供流量控制和擁塞控制服務(wù)。在RTP會話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實時數(shù)據(jù)。</p><p>　　RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報文來實現(xiàn)的，主要有如下幾種類型：

64、</p><p>　　(1) SR(Sender Report)發(fā)送端報告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報的應(yīng)用程序或者終端，發(fā)送端同時也可以是接收端。</p><p>　　(2) RR(Receiver Report)接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的應(yīng)用程序或者終端。</p><p>　　(3) SDES源描述，主要功能是作為會話成員有關(guān)標(biāo)識

65、信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達(dá)會話控制信息的功能。</p><p>　　(4) BYE通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。</p><p>　　(5) APP由應(yīng)用程序自己定義，解決了RTCP的擴(kuò)展性問題，并且為協(xié)議的實現(xiàn)者提供了很大的靈活性。</p><p>　　RTCP數(shù)據(jù)

66、報攜帶有服務(wù)質(zhì)量監(jiān)控的必要的信息，能夠?qū)Ψ?wù)質(zhì)量進(jìn)行動態(tài)的調(diào)整，并且能夠?qū)W(wǎng)絡(luò)擁塞進(jìn)行有效的控制。由于RTCP數(shù)據(jù)報采用的是組播方式，因此會話中的所有的成員都可以通過RTCP數(shù)據(jù)報返回的控制信息，來了解其他參與者的當(dāng)前情況。</p><p>　　例如在流媒體應(yīng)用場合下，發(fā)送媒體流的應(yīng)用程序?qū)⒅芷谛缘禺a(chǎn)生發(fā)送端報告SR，該RTCP數(shù)據(jù)報含有不同媒體流間的同步信息，以及已經(jīng)發(fā)送的數(shù)據(jù)報和字節(jié)的計數(shù)，接收端根據(jù)這些信息

67、可以估計出實際的數(shù)據(jù)傳輸速率。另一方面，接收端會向所有已知的發(fā)送端發(fā)送接收端報告RR，該RTCP數(shù)據(jù)報含有已接收數(shù)據(jù)報的最大序列號、丟失的數(shù)據(jù)報數(shù)目、延時抖動和時間戳等重要信息，發(fā)送端應(yīng)用根據(jù)這些信息可以估計出往返時延，并且可以根據(jù)數(shù)據(jù)報丟失概率和時延抖動情況動態(tài)調(diào)整發(fā)送速率，以改善網(wǎng)絡(luò)擁塞狀況，或者根據(jù)網(wǎng)絡(luò)狀況平滑地調(diào)整應(yīng)用程序的服務(wù)質(zhì)量。</p><p>　　RTCP具有以下四個功能： </p>

68、<p>　　(1) 基本功能是提供數(shù)據(jù)傳輸質(zhì)量的反饋.這是RTP作為一種傳輸協(xié)議的主要作用，它與其他協(xié)議的流量和阻塞控制相關(guān).反饋可能對自適應(yīng)編碼有直接作用，但是IP組播的實驗表明它對于從接收機(jī)得到反饋信息以診斷傳輸故障也有決定性作用。向所有成員發(fā)送接收反饋可以使"觀察員"評估這些問題是局部的還是全局的。利用類似多點廣播的傳輸機(jī)制，可以使某些實體，諸如沒有加入會議的網(wǎng)絡(luò)業(yè)務(wù)觀察員,接收到反饋信息并作為第三

69、類監(jiān)視員來診斷網(wǎng)絡(luò)故障.反饋功能通過RTCP發(fā)射機(jī)和接收機(jī)報告實現(xiàn)。</p><p>　　(2) RTCP為每個RTP源傳輸一個固定的識別符，稱為標(biāo)稱名或CNAME。由于當(dāng)發(fā)生沖突或程序重啟時SSRC可能改變,接收機(jī)要用CNAME來跟蹤每個成員。接收機(jī)還要用CNAME來關(guān)聯(lián)一系列相關(guān)RTP會話期中來自同一個成員的多個數(shù)據(jù)流,例如同步語音和圖像。</p><p>　　(3) 前兩個功能要求所

70、有成員都發(fā)送RTCP包，因此必須控制速率以使RTP成員數(shù)可以逐級增長。通過讓每個成員向所有成員發(fā)送控制包，各個成員都可以獨立地觀察會議中所有成員的數(shù)目。</p><p>　　(4) 可選的功能是傳輸最少的會議控制信息，例如在用戶接口中顯示的成員識別.這最可能在"松散控制"的會議中起作用，在"松散控制"會議里，成員可以不經(jīng)過資格控制和參數(shù)協(xié)商而加入或退出會議。RTCP作為一個

71、延伸到所有成員的方便通路，必須要支持具體應(yīng)用所需的所有控制信息通信。</p><p>　　2.3 FFmpeg視頻編解碼技術(shù)</p><p>　　2.3.1 FFmpeg簡介</p><p>　　FFmpeg是一個集視頻錄制、轉(zhuǎn)換和音視頻編解碼功能于一體的開源C代碼庫。FFmpeg最初的開發(fā)是基于Linux操作系統(tǒng)，但是經(jīng)過編譯和移植后也可以在人多數(shù)操作系統(tǒng)中使

72、用。FFmpeg包含了豐富的視頻編解碼庫，支持MPEG、DivX、MPEG-4、AC3、DV、FLV等40多種編碼以及AVI、MPEG、OGG、Matroska、ASF等90多種解碼。為了保證編解碼質(zhì)量和可移植性，F(xiàn)Fmpeg里很多視頻編解碼的codec都是從頭開發(fā)的[5]。</p><p><b>　　2.3.2 組成</b></p><p>　　FFmpeg開源

73、庫主要由以下一些子庫組成[6]：</p><p>　　(1) libavformat：用于生成和解析各種音視頻封裝格式，配置和獲取編解碼器的信息和上下文結(jié)構(gòu)。</p><p>　　(2) libavcodec：包含了所有的音視頻編解碼器。</p><p>　　(3) libavutil：包含了一些工具組件函數(shù)。</p><p>　　(4) l

74、ibswscale：用于在不同的顏色空間進(jìn)行轉(zhuǎn)換和視頻比例縮放等。</p><p>　　(5) libpostproc：用后期的效果處理。</p><p>　　(6) ffmpeg：提供了一些可以直接進(jìn)行格式轉(zhuǎn)換、編解碼的工具。</p><p>　　(7) ffserve：一個HTTP多媒體即時廣播服務(wù)器。</p><p>　　(8) ffp

75、lay：一個簡單的用ffmpeg進(jìn)行解析和解碼的播放器。</p><p>　　2.3.3 編碼框架</p><p>　　在使用FFmpeg庫中的任何功能之前，都必須對FFmpeg進(jìn)行注冊，否則任何codec和format將無法使用，F(xiàn)Fmpeg庫中的初始化注冊功能由av_register_all()函數(shù)來實現(xiàn)。第二步要根據(jù)所使用的編碼格式申請F(tuán)Fmpeg中的編碼器，可以使用兩種方法來申請

76、編碼器，分別是根據(jù)編碼器的CODEC_ID來申請和根據(jù)設(shè)置的文件名格式來申請，例如將CODEC_ID設(shè)置為CODEC_ID_MPEG4和將文件名后綴.mp4傳入申請編碼器的函數(shù)，都可以申請到MPEG_ 4格式的編碼器。FFmpeg支持現(xiàn)有的大多數(shù)視頻編碼器，如MPEG_1、MPEG_2、MPEG_3、H.261、H.263等，但是目前FFmpeg還不支持H.264編碼器，如需要H.264編碼器，需要將其他的開源H.264庫(如X264庫

77、)集成到FFmpeg中，本文不加贅述。</p><p>　　在申請好了編碼器之后，需要對編碼器的各種編碼參數(shù)進(jìn)行一些必要的設(shè)置以滿足不同的要求。其中比較重要的參數(shù)有視頻尺寸、編碼比特率、運(yùn)動估計算法、GOP大小和像素格式等。視頻尺寸即視頻的寬度和高度。編碼比特率即碼率，它決定了編碼的質(zhì)量和壓縮率，編碼比特率越大，采樣率就越高，相應(yīng)的編碼質(zhì)量也越高，但是壓縮率會變小，即需要傳送的數(shù)據(jù)量變大，反之，編碼比特率越小，采

78、樣率就越低，相應(yīng)的編碼質(zhì)量就越低，但是壓縮率會變大，傳送的數(shù)據(jù)量也會變小。運(yùn)動估計算法可以有效地去除幀間的冗余，在傳輸視頻時對于減少網(wǎng)絡(luò)負(fù)載量具有非常重要的意義。GOP(Group of Pictures)大小是指以幀數(shù)來表示的一組連續(xù)畫面的大小，在這組連續(xù)的畫面所對應(yīng)的幀中，只需要把第一幀作為I幀，其余幀都可以作為P幀或B幀。像素格式是指視頻幀中的像素所使用的顏色空間格式，如YUV420P、YUV422P和RGB24等。在編碼器準(zhǔn)備就

79、緒開始編碼之前，還需要分配編碼所需的內(nèi)存空間，這些內(nèi)存空間包括一幀原始視頻圖像大小的臨時緩存區(qū)、一幀原始視頻圖像大小的圖像存放區(qū)和一個輸出緩存區(qū)，輸出緩存區(qū)可以在不會發(fā)生數(shù)據(jù)溢出的前提下自行設(shè)定大小。</p><p>　　在前期的準(zhǔn)備工作完成之后，就可以對視頻序列進(jìn)行編碼了。編碼的過程為：首先提取出視頻序列的一幀，將這一幀圖像拷貝到臨時緩沖區(qū)中。然后利用月FFmpeg提供的sws_scale()方法將圖像像素轉(zhuǎn)換

80、為之前設(shè)定的像素格式并存放在圖像存放區(qū)中;最后使用FFmpeg的avcodec_encode_video()方法將這幀圖像編碼并存放在輸出緩存區(qū)中等待發(fā)送。</p><p>　　當(dāng)結(jié)束編碼時，會將之前中請的FFmpeg中的資源和系統(tǒng)內(nèi)存中的資源進(jìn)行釋放和回收，等待下一次開始編碼。編碼過程如圖2.2所示。</p><p>　　圖2.2 使用FFmpeg編碼過程</p><

81、p>　　2.3.4 解碼框架</p><p>　　本課題對FFmpeg的解碼實現(xiàn)過程與編碼過程大致類似，有點需要說明的是在分配待解碼圖像輸入緩沖區(qū)的時候，所需申請的內(nèi)存大小要比實際大一個尺寸，這個尺寸在FFmpeg中定義為FF_INPUT_BUFFER_PADDING_SIZE。這是因為有一些解碼器在從輸入緩沖區(qū)讀取視頻流的時候會以32位或64位為步長，這就有內(nèi)存溢出的可能性。在輸入緩沖區(qū)的后面加入一定長

82、度的保護(hù)單元，可以避免這種情況的發(fā)生，對解碼也不會產(chǎn)生影響。如果在分配輸入緩沖區(qū)的時候忽略了這一點，將會導(dǎo)致無法解碼出正確的圖像數(shù)據(jù)的情況。解碼過程如圖2.3所示。</p><p>　　圖2.3 使用FFmpeg解碼過程</p><p><b>　　2.4 本章小結(jié)</b></p><p>　　本章對基于Android的視頻通話系統(tǒng)關(guān)鍵技術(shù)進(jìn)

83、行了簡單的介紹，并結(jié)合本系統(tǒng)介紹了各個技術(shù)在實際背景下的具體應(yīng)用。第一節(jié)介紹了Java多媒體框架里在本應(yīng)用中使用到的重要組件。第二節(jié)介紹了RTP/RTCP協(xié)議，包括RTP實時傳輸?shù)脑?。第三?jié)介紹了本系統(tǒng)所使用的編解碼器，并簡單分析了其特點。本章內(nèi)容是本課題的技術(shù)構(gòu)成，也是本課題能夠?qū)崿F(xiàn)的關(guān)鍵。</p><p><b>　　第3章 系統(tǒng)分析</b></p><p>

84、　　系統(tǒng)分析在整個軟件開發(fā)中有著至關(guān)重要的作用，只有通過實際的系統(tǒng)分析才能有更好更實用的系統(tǒng)設(shè)計，從而實現(xiàn)出令客戶滿意的軟件產(chǎn)品[7]。本章主要介紹對視頻通信系統(tǒng)的需求分析工作，系統(tǒng)的需求來源于項目組專業(yè)的需求分析人員與客戶交流溝通所得。需求明確，來源可靠，是基于Android視頻通話系統(tǒng)需求的一部分。通過詳細(xì)分析客戶需求，初步明確系統(tǒng)的功能性和非功能性需求，其中功能性需求主要通過用例圖和詳細(xì)的用例說明來描述。</p>&

85、lt;p><b>　　3.1 需求分析</b></p><p>　　3.1.1 系統(tǒng)總體需求</p><p>　　基于Android的視頻通話系統(tǒng)主要功能是實現(xiàn)Android系統(tǒng)和PC端之間的視頻通話。根據(jù)需要本系統(tǒng)只是簡單的點到點的視頻傳輸，不需要中間服務(wù)器。因此本系統(tǒng)只包含兩個客戶端。PC端基于Windows操作系統(tǒng)。Android端基于Android

86、2.3操作系統(tǒng)。兩個客戶端之間的數(shù)據(jù)傳輸通過Wifi。從整體上來看每個客戶端都分為兩部分，發(fā)送端和接收端。由于這兩個部分不存在任何聯(lián)系，因此可以作為兩個獨立的模塊來開發(fā)。發(fā)送端需要完成從攝像頭和麥克風(fēng)獲得原始的數(shù)據(jù)，將數(shù)據(jù)編碼壓縮，然后再發(fā)送出去。接收端負(fù)責(zé)接收數(shù)據(jù)，將數(shù)據(jù)解碼并顯示出來。由于PC端和Android端情況不太一樣，因此還需要考慮其它的因素。PC端硬件的復(fù)雜多樣性，比如有的PC上沒有攝像頭，有的PC上有多個攝像頭。因此必須

87、考慮到硬件檢測，并由用戶來選擇具體使用哪個。為了方便用戶使用，在Android端使用SQLite數(shù)據(jù)庫來保存IP地址和端口號。在視頻過程中可以實現(xiàn)截屏功能來截取當(dāng)前圖像并保存供用戶使用。圖3.1為基于Android視頻通話系統(tǒng)的運(yùn)行架構(gòu)圖。</p><p>　　圖3.1 基于Android視頻通話系統(tǒng)運(yùn)行架構(gòu)圖</p><p>　　3.1.3 用例分析</p><p&

88、gt;　　根據(jù)基于Android的視頻通話系統(tǒng)的業(yè)務(wù)流程和執(zhí)行過程可以進(jìn)行相應(yīng)的角色識別和用例分析。本系統(tǒng)的主要參與者就是視頻通話的參與者。</p><p>　　根據(jù)以上分析，從而得到PC端的用例模型。整個PC端包含了三個用例，分別是選擇硬件設(shè)備、開始視頻通話、結(jié)束視頻通話。其中選擇硬件設(shè)備又包含了選擇音頻設(shè)備和選擇視頻設(shè)備。圖3.2是PC端的用例圖。</p><p>　　圖3.2 PC端

89、用例圖</p><p>　　PC端選擇硬件設(shè)備用例主要功能是讓會話參與者來選擇系統(tǒng)硬件設(shè)備。當(dāng)系統(tǒng)啟動時會自動進(jìn)行硬件設(shè)備檢測并返回檢測結(jié)果。參與者跟據(jù)結(jié)果來選擇具體使用哪些設(shè)備來進(jìn)行下一步的視頻通話。表3.1為選擇硬件設(shè)備用例的用例規(guī)約。</p><p>　　表3.1 選擇硬件設(shè)備用例</p><p>　　PC端視頻通話用例是本系統(tǒng)的核心。主要功能是完成開始進(jìn)行視

90、頻通話這一動作。當(dāng)用戶選擇完硬件設(shè)備后，系統(tǒng)進(jìn)入視頻通話準(zhǔn)備界面。用戶點擊開始按鈕，進(jìn)入開始視頻通話。圖3.2為開始視頻通話用例。</p><p>　　表3.2 開始視頻通話用例</p><p>　　PC端結(jié)束視頻通話用例主要功能用來結(jié)束視頻通話。在視頻通話中點擊結(jié)束按鈕來結(jié)束本次結(jié)束視頻通話。結(jié)束視頻通話用例如表3.3所示。</p><p>　　表3.3 結(jié)束視頻

91、通話用例</p><p>　　Android端的用例圖。包含了四個用例。分別是會話參與者管理、開始會話、視頻截圖、結(jié)束會話四個用例。會話參與者管理又分為添加會話參與者、刪除會話參與者、修改會話參與者三個用例。圖3.3為Android端用例圖。</p><p>　　圖3.3 Android端用例圖</p><p>　　Android端視頻通話用例主要任務(wù)是完成Andr

92、oid端的視頻通話開始這一行為。為了完成視頻通話，必須首先選擇視頻通話對象。然后點擊連接按鈕進(jìn)行視頻通話。開始視頻通話用例如表3.4所示。</p><p>　　表3.4 視頻通話用例</p><p>　　Android端結(jié)束視頻通話主要用來結(jié)束本次視頻通話。點擊結(jié)束按鈕來結(jié)束本次視頻通話，同時釋放系統(tǒng)資源。結(jié)束視頻通話用例如表3.5所示。</p><p>　　表3.

93、5 結(jié)束視頻通話用例</p><p>　　續(xù)表3.5 結(jié)束視頻通話用例</p><p>　　Android端截圖用例的主要功能是對當(dāng)前視頻畫面進(jìn)行截圖并保存。點擊保存按鈕來保存當(dāng)前截圖。截圖用例規(guī)約如表3.6所示。</p><p><b>　　表3.6 截圖用例</b></p><p>　　Android端添加參與者用例

94、主要功能是新增視頻會話參與者。點擊添加按鈕來添加新的參與者。然后輸入用戶相關(guān)信息，最后點擊保存。添加參與者用例如表3.7所示。</p><p>　　表3.7 添加參與者用例</p><p>　　續(xù)表3.7 添加參與者用例</p><p>　　Android端修改參與者用例主要功能是修改參與者。點擊修改按鈕來修改參與者的相關(guān)信息，然后點擊保存。修改參與者用例規(guī)約如表3

95、.8所示。</p><p>　　表3.8修改參與者用例</p><p>　　Android端刪除參與者用例主要功能是刪除指定參與者。選定參與者，然后點擊刪除。刪除參與者用例如表3.9所示。</p><p>　　表3.9 刪除參與者用例</p><p>　　3.2 系統(tǒng)運(yùn)行環(huán)境與開發(fā)環(huán)境</p><p>　　3.2.1

96、 運(yùn)行環(huán)境</p><p>　　PC端運(yùn)行環(huán)境如表3.10。</p><p>　　表3.10 PC端運(yùn)行環(huán)境</p><p>　　Android端運(yùn)行環(huán)境如表3.11。</p><p>　　表3.11 Android端運(yùn)行環(huán)境</p><p>　　3.2.3 開發(fā)環(huán)境</p><p>　　系

97、統(tǒng)開發(fā)硬件環(huán)境如表3.12。</p><p>　　表3.12 系統(tǒng)開發(fā)硬件環(huán)境</p><p>　　系統(tǒng)開發(fā)軟件環(huán)境如表3.13。</p><p>　　表3.13 系統(tǒng)開發(fā)軟件環(huán)境</p><p>　　3.3 系統(tǒng)可行性分析</p><p>　　3.3.1 技術(shù)可行性</p><p>　　本

98、系統(tǒng)采用C/S架構(gòu)，分為兩個客戶端，運(yùn)行在兩個不同的操作系統(tǒng)上——Windows和Android。因此采用不同的技術(shù)來實現(xiàn)。</p><p>　　PC端采用成熟的Java多媒體框架JMF。該核心框架支持不同媒體（如：音頻輸出和視頻輸出）間的時鐘同步。它是一個標(biāo)準(zhǔn)的擴(kuò)展框架，允許用戶制作純音頻流和視頻流。JMF技術(shù)提供了先進(jìn)的媒體處理能力和編碼支持，如M-JPFEG、H.263、MP3、RTP/RTSP(實時傳送協(xié)

99、議和實時流轉(zhuǎn)協(xié)議)、Macromedias Flash、IBM的HotMedia和Beatniks的Rich Media Format (RMF)等[8]。JMF 2.1.1還支持廣受歡迎的媒體類型，如Quicktime、Microsofts AVI和MPEG-1等。此外，JMF 2.1.1軟件中包括了一個開放的媒體架構(gòu)，可使開發(fā)人員靈活采用各種媒體回放、捕獲組件，或采用他們自己的定制的內(nèi)插組件。JMF提供了四種不同的專用版本，滿足專業(yè)

100、開發(fā)人員的各類需求，第一個是一個輕便型版本，它完全采用Java語言編寫，適用于任何Java兼容系統(tǒng)。此外，開發(fā)人員還可選擇分別適用于Solaris、Windows或Linux等操作系統(tǒng)的性能最優(yōu)化軟件包，以提高性能和能力。JMF框架從發(fā)布至今經(jīng)歷了好幾代版本的更新，如今已近趨于穩(wěn)定。應(yīng)用J</p><p>　　Android端主要采用FFmpeg開源框架來實現(xiàn)視頻的編解碼。FFmpeg是一個開源免費跨平臺的視頻和

101、音頻流方案，屬于自由軟件，采用LGPL或GPL許可證（依據(jù)你選擇的組件）。它提供了錄制、轉(zhuǎn)換以及流化音視頻的完整解決方案。它包含了非常先進(jìn)的音頻/視頻編解碼庫libavcodec，為了保證高可移植性和編解碼質(zhì)量，libavcodec里很多codec都是從頭開發(fā)的。FFmpeg是一個集視頻錄制、轉(zhuǎn)換和音視頻編解碼功能于一體的開源C代碼庫。FFmpeg最初的開發(fā)是基于Linux操作系統(tǒng)，但是經(jīng)過編譯和移植后也可以在人多數(shù)操作系統(tǒng)中使用。FF

102、mpeg包含了豐富的視頻編解碼庫，支持MPEG、DivX、MPEG-4、AC3、DV、FLV等40多種編碼以及AVI、MPEG、OGG、Matroska、ASF等90多種解碼。依賴FFmpeg開源庫能夠高效快速的實現(xiàn)編解碼[9]。</p><p><b>　　3.4 本章小結(jié)</b></p><p>　　本章對系統(tǒng)的原始需求進(jìn)行了詳細(xì)的描述，并將原始需求用UML中的

103、用例圖的方式描述出來，對每個用例進(jìn)行了詳細(xì)的介紹。接著介紹了系統(tǒng)的開發(fā)環(huán)境以及對系統(tǒng)可行性進(jìn)行了分析。</p><p><b>　　第4章 系統(tǒng)設(shè)計</b></p><p>　　本章在第三章對基于Android的視頻通話系統(tǒng)詳細(xì)明確的需求分析的基礎(chǔ)上，重點明確系統(tǒng)的具體設(shè)計工作，包括框架設(shè)計，模塊設(shè)計，功能設(shè)計，數(shù)據(jù)庫的設(shè)計等。在系統(tǒng)設(shè)計方面主要通過框架圖、類圖、時

104、序圖以及表格來進(jìn)行詳細(xì)的描述。</p><p><b>　　4.1 概要設(shè)計</b></p><p>　　4.1.1 系統(tǒng)軟件體系結(jié)構(gòu)的設(shè)計</p><p>　　本系統(tǒng)在軟件體系結(jié)構(gòu)設(shè)計上主要分為多媒體I/O層、多媒體處理層、傳輸層、網(wǎng)絡(luò)層等四個層次，如圖4.1所示。</p><p>　　圖4.1 軟件體系結(jié)構(gòu)<

105、;/p><p>　　多媒體IO層：包含系統(tǒng)人機(jī)交互模塊，主要提供各種媒體特定語義的輸入輸出、應(yīng)用實體系統(tǒng)交互功能。</p><p>　　多媒體對象處理層：主要包含音、視頻的處理模塊，位于客戶端，可以直接訪問本地資源，如攝像頭和麥克風(fēng)。主要完成分布式多媒體處理功能的對象化封裝，提供系統(tǒng)所需的編解碼和各種媒體之間的同步控制等。</p><p>　　傳輸層：含RTP控制模塊和

106、RTCP控制模塊，本層提供壓縮媒體流的組包、解包、發(fā)送、接收功能，同時向下屏蔽網(wǎng)絡(luò)資源，向上提供媒體傳輸接口[10]。</p><p>　　4.1.2 系統(tǒng)功能模塊</p><p>　　根據(jù)需求調(diào)研結(jié)果確定了基于Android的視頻通話系統(tǒng)主要功能模塊。一共包括八個功能模塊，分別是硬件檢測模塊、數(shù)據(jù)采集模塊、編碼壓縮模塊、數(shù)據(jù)發(fā)送模塊、數(shù)據(jù)接收模塊、解碼模塊、呈現(xiàn)模塊以及參與者管理模塊。

107、整個系統(tǒng)功能結(jié)構(gòu)如圖4.2所示。</p><p>　　圖4.2 系統(tǒng)功能模塊</p><p>　　4.1.3 模塊功能分析</p><p>　　一個良好的軟件系統(tǒng)依賴于穩(wěn)定的系統(tǒng)平臺，依賴于先進(jìn)的技術(shù)基礎(chǔ)，更依賴于系統(tǒng)的設(shè)計與架構(gòu)。如果對系統(tǒng)的設(shè)計與架構(gòu)既能讓各個模塊獨立地完成各自的任務(wù)，又能讓各個模塊配合工作時得到最優(yōu)化的執(zhí)行效率，那么這個軟件系統(tǒng)才稱得上一個合

108、格的系統(tǒng)[11]。</p><p>　　依據(jù)系統(tǒng)的功能需求分析，該系統(tǒng)由兩個客戶端組成——PC端和Android端。每個客戶端又單獨包含了若干個模塊。在系統(tǒng)中，系統(tǒng)主模塊與各個功能模塊之間協(xié)同配合工作，分工明確，共同實現(xiàn)了本視頻通話系統(tǒng)。圖4.3描述了基于Android的視頻通話系統(tǒng)的總體框架。</p><p>　　圖4.3 系統(tǒng)總體框架</p><p>　　在系統(tǒng)

109、中，系統(tǒng)主模塊與各個功能模塊之間協(xié)同配合工作，分工明確。對系統(tǒng)進(jìn)行程序開發(fā)的過程中，系統(tǒng)各個模塊在Android系統(tǒng)架構(gòu)中的位置關(guān)系如圖4.4所示。在Android系統(tǒng)架構(gòu)的四層結(jié)構(gòu)中，最底層 (Android Layer I)為各個硬件及其抽象層。最上層(Android Layer IV)為應(yīng)用程序的軟件實體，而本系統(tǒng)的各個功能模塊主要集中在中間兩層(Android Layer II and Android Layer III)中。&