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

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

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

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

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

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

6、外視頻通話的研究情況以及今后的發(fā)展前景，對(duì)實(shí)現(xiàn)視頻通話所涉及到的協(xié)議和相關(guān)技術(shù)進(jìn)行了分析，在此基礎(chǔ)上提出了一種可行的網(wǎng)絡(luò)視頻通話設(shè)計(jì)方案，并通過(guò)需求分析、詳細(xì)設(shè)計(jì)、編碼實(shí)現(xiàn)、單元測(cè)試以及集成測(cè)試等過(guò)程完成了本系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。</p><p>　　本系統(tǒng)實(shí)現(xiàn)了跨平臺(tái)視頻通話，使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 國(guó)內(nèi)外發(fā)展現(xiàn)狀2</p><p>　　1.3 研究?jī)?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實(shí)時(shí)傳輸協(xié)議6</p><p>　　2.2.2 RTCP實(shí)時(shí)傳輸協(xié)議8</p><p>　　2.3 FFmpeg視頻編解碼技術(shù)9</p><p>　　2.3.1 FFmpeg簡(jiǎn)介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è)計(jì)22</p><p>　　4.1 概要設(shè)計(jì)22</p><p>　　4.1.1 系統(tǒng)軟件體系結(jié)構(gòu)的設(shè)計(jì)22</p><p>　　4.1.2 系統(tǒng)功能模塊23</p><p>　　4.1.3 模

21、塊功能分析23</p><p>　　4.2.3 數(shù)據(jù)庫(kù)設(shè)計(jì)29</p><p>　　4.2 本章小結(jié)30</p><p>　　第5章 系統(tǒng)實(shí)現(xiàn)31</p><p>　　5.1 功能子模塊的實(shí)現(xiàn)31</p><p>　　5.1.1 硬件檢測(cè)模塊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 會(huì)話參與者管理模塊39</p><p>　　5.2 本章小結(jié)40</p><p>　　第6章　系統(tǒng)測(cè)試41</p><p>　　6.1 單元測(cè)試41</p><p>　　6.2 集成測(cè)試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>　　隨著移動(dòng)通信網(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)。由于其具有的開放性使得仟何廠商和個(gè)人都可以作為其開發(fā)者參與其中，Android在發(fā)布的隨后幾年中得到了迅猛的發(fā)展。包括設(shè)

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

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

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

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

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

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

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

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

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

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

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

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

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

39、總結(jié)與展望。對(duì)工作做了簡(jiǎn)要的總結(jié)，并對(duì)后續(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程序員做到了以跨平臺(tái)與設(shè)備無(wú)關(guān)的方式訪問音、視頻設(shè)備，提供了分布式應(yīng)用環(huán)境下實(shí)時(shí)媒體回放技術(shù)，還定義了一系列API插件，允許高級(jí)開發(fā)人員和技術(shù)人員對(duì)其進(jìn)行定制功能擴(kuò)展，實(shí)現(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) 用來(lái)制作實(shí)時(shí)的音、視頻廣播服務(wù)。</p><p>　　2.1.2 JMF中的數(shù)據(jù)源</p><p>　　JMF API可以同步播放來(lái)自各種數(shù)據(jù)源 (DataSource)的時(shí)基媒體，例如本地或網(wǎng)絡(luò)數(shù)據(jù)文件等。數(shù)據(jù)源封裝了媒體數(shù)據(jù)流、媒體的具體位置和用于傳輸媒體的協(xié)議，一個(gè)數(shù)據(jù)源一旦被

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

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

45、x.media包中的Player接口的其他類創(chuàng)建的對(duì)象即可實(shí)現(xiàn)媒體播放器，通過(guò)MediaPlayer類中提供的方法可以操作各種媒體數(shù)據(jù)的播放。</p><p>　　在JMF媒體播放器從啟動(dòng)媒體播放器到開始播放媒體數(shù)據(jù)的過(guò)程中，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í)例化，但并不知道需要播放的媒體數(shù)據(jù)的任何信息。</p><p>　　(2) Realizing狀態(tài)：當(dāng)調(diào)用realize()方法時(shí)，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()方法時(shí)，JMF媒體播放器的狀態(tài)從Realized狀態(tài)變?yōu)镻refetching狀態(tài)，在該狀態(tài)下，JMF媒體播放器正在為播放媒體數(shù)據(jù)做一些準(zhǔn)備工作，其中包括加載媒體數(shù)據(jù)，獲得需要獨(dú)占的資源等。</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()方法來(lái)釋放媒體播放器使用的獨(dú)占資源。</p><p>　　2.1.4 JM

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

50、　　繼承Processor接口的媒體播放器對(duì)象除了具有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媒體播放器對(duì)象進(jìn)入該狀態(tài)。在該狀態(tài)下，Processor媒體播放器對(duì)象鏈接到數(shù)據(jù)

51、源并獲取輸入媒體數(shù)據(jù)的格式(類型)信息。</p><p>　　Configured狀態(tài):當(dāng)完成數(shù)據(jù)源連接，獲得輸入數(shù)據(jù)格式的信息后，Processor媒體播放器對(duì)象就處于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ù)時(shí)出現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

72、用。FFmpeg包含了豐富的視頻編解碼庫(kù)，支持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、庫(kù)主要由以下一些子庫(kù)組成[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：一個(gè)HTTP多媒體即時(shí)廣播服務(wù)器。</p><p>　　(8) ffp

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

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

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

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

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

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

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

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

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

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

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

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

87、考慮到硬件檢測(cè)，并由用戶來(lái)選擇具體使用哪個(gè)。為了方便用戶使用，在Android端使用SQLite數(shù)據(jù)庫(kù)來(lái)保存IP地址和端口號(hào)。在視頻過(guò)程中可以實(shí)現(xiàn)截屏功能來(lái)截取當(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í)行過(guò)程可以進(jìn)行相應(yīng)的角色識(shí)別和用例分析。本系統(tǒng)的主要參與者就是視頻通話的參與者。</p><p>　　根據(jù)以上分析，從而得到PC端的用例模型。整個(gè)PC端包含了三個(gè)用例，分別是選擇硬件設(shè)備、開始視頻通話、結(jié)束視頻通話。其中選擇硬件設(shè)備又包含了選擇音頻設(shè)備和選擇視頻設(shè)備。圖3.2是PC端的用例圖。</p><p>　　圖3.2 PC端

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

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

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

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

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

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

95、.8所示。</p><p>　　表3.8修改參與者用例</p><p>　　Android端刪除參與者用例主要功能是刪除指定參與者。選定參與者，然后點(diǎn)擊刪除。刪除參與者用例如表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)，分為兩個(gè)客戶端，運(yùn)行在兩個(gè)不同的操作系統(tǒng)上——Windows和Android。因此采用不同的技術(shù)來(lái)實(shí)現(xiàn)。</p><p>　　PC端采用成熟的Java多媒體框架JMF。該核心框架支持不同媒體（如：音頻輸出和視頻輸出）間的時(shí)鐘同步。它是一個(gè)標(biāo)準(zhǔn)的擴(kuò)展框架，允許用戶制作純音頻流和視頻流。JMF技術(shù)提供了先進(jìn)的媒體處理能力和編碼支持，如M-JPFEG、H.263、MP3、RTP/RTSP(實(shí)時(shí)傳送協(xié)

99、議和實(shí)時(shí)流轉(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è)開放的媒體架構(gòu)，可使開發(fā)人員靈活采用各種媒體回放、捕獲組件，或采用他們自己的定制的內(nèi)插組件。JMF提供了四種不同的專用版本，滿足專業(yè)

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

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

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

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

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

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

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

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

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

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