碩士論文-實(shí)時(shí)視頻系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

PAGE第1頁共39頁分類號(hào)：TP31UDC：D10621-408-(2016)1411-0密級(jí)：公開編號(hào)：2012051171學(xué)位論文實(shí)時(shí)視頻系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)論文作者姓名：申請(qǐng)學(xué)位專業(yè)：申請(qǐng)學(xué)位類別：論文提交日期：實(shí)時(shí)視頻系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)摘要隨著互聯(lián)網(wǎng)時(shí)代的不斷發(fā)展，移動(dòng)終端在社會(huì)的應(yīng)用不斷擴(kuò)大，傳統(tǒng)的PC端實(shí)時(shí)視頻通訊變得笨重而不方便，極大的降低了人們的工作效率。為了緩解這一情況，本文采用基于軟件工程的設(shè)計(jì)、分析方法，將傳統(tǒng)的PC端實(shí)時(shí)視頻通訊移植到Android端。由于條件限制，此系統(tǒng)的視頻是通過PC端的視頻攝像頭進(jìn)行采集，通過本地服務(wù)器的數(shù)據(jù)傳送，到達(dá)Android手機(jī)端進(jìn)行實(shí)時(shí)的視頻播放。在軟件平臺(tái)方面，是基于visualstudio2013進(jìn)行Win7上C++的開發(fā)，基于eclipse和AndroidSDK進(jìn)行Java服務(wù)器開發(fā)和Android端的開發(fā)。在技術(shù)層面，本系統(tǒng)在PC端使用了FFmpeg這種穩(wěn)定性較強(qiáng)、運(yùn)用范圍比較廣的開源三方庫進(jìn)行PC端的視頻采集和視頻轉(zhuǎn)碼。在服務(wù)器端，運(yùn)用socket套接字和固定端口監(jiān)聽實(shí)現(xiàn)客戶端的數(shù)據(jù)監(jiān)聽和數(shù)據(jù)傳輸。在Android端將FFmpeg開源庫進(jìn)行編譯，封裝成動(dòng)態(tài)庫，使用Jni實(shí)現(xiàn)C和Java端的數(shù)據(jù)通信和接口調(diào)用。本系統(tǒng)將運(yùn)算量較大的視頻采集和視頻編解碼用C語言來進(jìn)行處理，提高了效率。將服務(wù)器搭建、數(shù)據(jù)傳輸、數(shù)據(jù)同步以及界面交互這種較為繁瑣的工作用Java來進(jìn)行處理。很好的利用了C語言面向過程的高效性和Java面向?qū)ο笥押玫慕换バ?。使得系統(tǒng)即擁有較好的視頻處理性能，又具有友好的人機(jī)交互。本系統(tǒng)實(shí)現(xiàn)了對(duì)視頻的實(shí)時(shí)處理和傳輸，使人們脫離了傳統(tǒng)實(shí)時(shí)視頻通訊的地理位置現(xiàn)在，可以更加靈活的進(jìn)行視頻接收、查看，使人們的生活變得更加便捷，極大的提高了人們的工作效率。關(guān)鍵詞：實(shí)時(shí)視頻；視頻編解碼；FFmpeg；Jni；Android；socketDesignandImplementationofReal-timevideosystemAbstractWiththecontinuousdevelopmentoftheInternetage,expandingtheapplicationofmobileterminalsinsociety,thetraditionalPCreal-timevideocommunicationbecomesheavyandinconvenient,greatlyreducestheproductivity.Inordertoalleviatethesituation,inthispaper,basedonthedesignofsoftwareengineering,analysismethods,thetraditionalPCreal-timevideocommunicationtransplantationtoAndroid.Becauseoftheconstraints,thevideoofthissystemisthroughtheacquisitionofthevideocameraonthePCthroughthelocalserverdatatransfer,reachtheAndroidmobileterminalreal-timevideoplayback.Intheaspectofsoftwareplatform,whichisbasedonvisualstudio2013c++developmentonWindows7,basedoneclipseandtheAndroidSDKforJavaserverdevelopmentandthedevelopmentonAndroid.Atthetechnicallevel,thesystemstabilityinPCusingFFmpegthisstrong,usingrangeiswideopensourcelibraryforthePCvideocaptureandvideotranscoding.Ontheserverside,usesocketsocketandfixedportsfortheclient'sdatatomonitoranddatatransmission.OnAndroidwillFFmpegopensourcelibrariestocompile,encapsulatedintoadynamiclibrary,usingJnitorealizethedatacommunicationandinterfacecallonCandJava.ThissystemwillbethecomputationofthelargervideocaptureandvideocodectouseClanguagetoundertakeprocessing,improvetheefficiency.Theserverbuildinterfaceinteraction,datatransmission,datasynchronization,andthemoretediousworktouseJavaforprocessing.GooduseoftheClanguagetoprocessefficiencyandJavaobject-orientedfriendlyinteractive.Ismakesthesystempossessbetterperformanceofvideoprocessing,butalsohasafriendlyhuman-computerinteraction.Thissystemhasrealizedthereal-timeprocessingandtransmissionofvideo,makespeopleawayfromthetraditionalreal-timevideocommunicationlocationnow,canbevideoreceiving,amoreflexibleview,makepeople'slifebecomemoreconvenient,greatlyimprovedtheworkefficiencyofpeople.Keywords:Real-timevideo;videoencodeanddecode;FFmpeg;Jni;Android;socket目錄論文總頁數(shù)：34頁1 引言 11.1 課題背景 11.2 國(guó)內(nèi)外研究現(xiàn)狀 11.2.1 視頻技術(shù)發(fā)展現(xiàn)狀 21.2.2 視頻技術(shù)應(yīng)用現(xiàn)狀 21.2.3 本系統(tǒng)的相關(guān)技術(shù)現(xiàn)狀 31.2.4 本系統(tǒng)的應(yīng)用現(xiàn)狀 31.3 本課題研究的意義 41.4 本課題的研究方案 41.4.1 前人已實(shí)現(xiàn)方案 41.4.2 本系統(tǒng)使用方案 51.4.3 方案的確定及其優(yōu)缺點(diǎn) 61.5 全文結(jié)構(gòu) 62 系統(tǒng)概要設(shè)計(jì) 72.1 系統(tǒng)框架結(jié)構(gòu) 72.2 系統(tǒng)需求分析 82.2.1 系統(tǒng)功能模塊 82.2.2 系統(tǒng)數(shù)據(jù)傳輸 102.2.3 系統(tǒng)性能需求 102.3 系統(tǒng)重點(diǎn)技術(shù)簡(jiǎn)介 112.4 本章小結(jié) 133 系統(tǒng)詳細(xì)設(shè)計(jì) 133.1 視頻采集技術(shù)實(shí)現(xiàn)方法 133.1.1 攝像頭驅(qū)動(dòng)及FFmpeg平臺(tái)搭建 133.1.2 PC端獲取視頻解碼顯示 143.1.3 視頻編碼存儲(chǔ) 173.1.4 視頻緩存?zhèn)鬏?203.2 服務(wù)器傳輸技術(shù)實(shí)現(xiàn)方法 223.2.1 客戶端數(shù)據(jù)監(jiān)聽 223.2.2 數(shù)據(jù)傳輸和緩存處理 233.3 移動(dòng)終端視頻處理技術(shù)實(shí)現(xiàn)方法 233.3.1 數(shù)據(jù)接收和存儲(chǔ) 233.3.2 視頻數(shù)據(jù)解碼 243.3.3 界面設(shè)計(jì)及視頻播放 243.4 本章小結(jié) 254 特殊問題及解決方法 254.1 動(dòng)態(tài)庫運(yùn)用問題 254.2 C與Java數(shù)據(jù)通信問題 264.3 數(shù)據(jù)傳輸同步問題 264.4 編碼幀頻和參數(shù)設(shè)置問題 274.5 本章小結(jié) 285 系統(tǒng)測(cè)試分析 285.1 功能模塊測(cè)試概述 285.2 系統(tǒng)PC端測(cè)試 285.3 系統(tǒng)服務(wù)器測(cè)試 295.4 系統(tǒng)移動(dòng)終端測(cè)試 295.5 性能測(cè)試分析 295.6 本章小結(jié) 30結(jié)束語 31參考文獻(xiàn) 32致謝 33聲明 34第35頁共40頁引言課題背景即時(shí)通訊（Instant

Messaging）是目前Internet上最為流行的通訊方式。而視頻信息又是人們最直觀的理解的信息。而隨著移動(dòng)終端的不斷發(fā)展，移動(dòng)應(yīng)用在人們生活中的普及，使得實(shí)時(shí)視頻通訊有了發(fā)展到移動(dòng)終端設(shè)備上的必要性。而比較傳統(tǒng)的視頻實(shí)時(shí)通訊基本上都是建立在攝像頭和PC電腦之間，這極大的約束了人們的活動(dòng)范圍。而且占用一臺(tái)電腦資源，不能做其他事物，使得資源極其浪費(fèi)。而且這種視頻的通行方式僅僅限于短距離之間，不能做到遠(yuǎn)距離監(jiān)控。使得視頻傳輸?shù)牡赜蚴盏搅藰O大的限制。這就可能直接導(dǎo)致人們對(duì)于所關(guān)心的事物由于各種原因而不能達(dá)到實(shí)時(shí)關(guān)注的情況。而本系統(tǒng)的設(shè)計(jì)極大的彌補(bǔ)這一方面的不足，既能實(shí)時(shí)的通過視頻查看所關(guān)心的重要事物，又不用局限于地域和設(shè)備限制，極大提高了人們工作效率。國(guó)內(nèi)外研究現(xiàn)狀視頻技術(shù)在九十年代就已經(jīng)有了初步的發(fā)展，對(duì)視頻和音頻進(jìn)行編解碼。從最開始ITU-T頒布的H.261到現(xiàn)在的H.264以及MPEG系列，都有了較為成熟的發(fā)展。隨著近幾年來的網(wǎng)絡(luò)通訊越發(fā)發(fā)達(dá)，IP化成為了網(wǎng)絡(luò)發(fā)展的主流，也使得視頻音頻的編解碼協(xié)議發(fā)展變得更為重要，一些對(duì)視頻音頻進(jìn)行處理的軟件和開源項(xiàng)目的需求也變得急迫。而現(xiàn)在應(yīng)用比較廣泛和較為成熟的開源視頻編解碼的三方庫就是FFmpeg，它提供了錄制、轉(zhuǎn)換及流化音視頻的完整解決方案。而且支持多種編碼解碼方案。在這套三方庫推出以來，已經(jīng)有多個(gè)版本，使用的人也非常多，其對(duì)于音視頻處理的技術(shù)也是相當(dāng)成熟。而且有許多的播放器都是采用了基于FFmpeg的庫進(jìn)行開發(fā)的，比如VLC，Mplayer，HandBrake，GoogleChrome，DirectShow和ffdshow等等。由于FFmpeg是完全開源的項(xiàng)目，而且是在遵守LGPL/GPL的協(xié)議下發(fā)布的，因此也就因?yàn)槟承┸浖褂没蛘甙薋Fmpeg對(duì)應(yīng)的源碼，但是并沒有遵守LGPL/GPL協(xié)議對(duì)其軟件進(jìn)行開源化，而產(chǎn)生了FFmpeg恥辱柱(Hallofshame)。其中包括韓國(guó)名軟KMPlayer，以及國(guó)內(nèi)的暴風(fēng)影音、QQ影音等軟件，也由此引發(fā)了許多學(xué)者對(duì)于開源的基本規(guī)則和開發(fā)者如何尊重開源作者的一些思考。從這些方面，也可以看出FFmpeg在音視頻軟件行業(yè)以及計(jì)算機(jī)行業(yè)的一定影響力。其中VLC是基于它而制作出來的一款比較成功的開源軟件，和FFmpeg一樣，VLC也支持眾多音視頻解碼器及檔案格式，并支持DVD、VCD及各類串流協(xié)定。而且VLC也在此基礎(chǔ)上進(jìn)行了開發(fā)，能夠作為unicast或multicast的串流服務(wù)器在IP4或IP6高速網(wǎng)絡(luò)下的連接和使用。后續(xù)版本還提供了基于Mozilla和ActiveX的插件，使其在Mozilla和IE瀏覽器中也能夠正常的顯示。而且VLC還能夠播放那些并沒有下載完整的視頻文件，這也是它的一個(gè)非常好而強(qiáng)大的功能。而進(jìn)年來的移動(dòng)終端的流行，也推出了FFmpeg對(duì)應(yīng)的移植方法，應(yīng)用技術(shù)也相對(duì)成熟。下面就是對(duì)視頻技術(shù)相應(yīng)的模塊進(jìn)行細(xì)節(jié)的講解。視頻技術(shù)發(fā)展現(xiàn)狀網(wǎng)絡(luò)時(shí)代的不斷發(fā)展，網(wǎng)速的不斷提升，使得視頻技術(shù)也得到了不斷的提升和加強(qiáng)。從最起初的H.261的頒布到現(xiàn)在的MPEG-2，視頻通訊技術(shù)在不斷的完善。視頻通訊的相關(guān)協(xié)議的不斷成熟，以及編碼、信息壓縮技術(shù)和寬帶技術(shù)的不斷普及深化發(fā)展，使得現(xiàn)在的視頻通訊技術(shù)已經(jīng)達(dá)到了一個(gè)較為成熟的階段。不管是在視頻采集壓縮處理，視頻監(jiān)控，視頻電話，以及視頻會(huì)議，都能達(dá)到穩(wěn)定的通訊性能。目前的視頻技術(shù)發(fā)展方向是更加高清，更加現(xiàn)實(shí)以及數(shù)字轉(zhuǎn)換。也就是高清視頻的處理、虛擬現(xiàn)實(shí)的技術(shù)發(fā)展以及視頻數(shù)字化處理和信息提取這一方面的技術(shù)發(fā)展。高清視頻技術(shù)的發(fā)展多為高清720p(HD)和全高清1080P(Full-HD)類型的攝像頭獲取的視頻數(shù)據(jù)，傳輸?shù)膸l為25幀/秒，通常在經(jīng)過H.264或者M(jìn)PEG4等不同編碼格式的壓縮處理下進(jìn)行傳輸，碼率一般是在4-20MB/S。一般高清視頻的視頻數(shù)據(jù)量在每小時(shí)2-10G之間。當(dāng)然將這些數(shù)據(jù)進(jìn)行下載存儲(chǔ)播放，并不是什么太大的難題。但是如果要將這是數(shù)據(jù)進(jìn)行實(shí)時(shí)傳輸?shù)脑?，如此大量的?shù)據(jù)，在存儲(chǔ)、網(wǎng)絡(luò)環(huán)境、系統(tǒng)穩(wěn)定性等各個(gè)方面都會(huì)受到巨大的挑戰(zhàn)。這也算是現(xiàn)在高清視頻通話，高清視頻會(huì)議，以及其他高清視頻實(shí)時(shí)通訊的一個(gè)重難點(diǎn)所在。視頻數(shù)字化和信息提起主要是將視屏中的數(shù)據(jù)，或者是某個(gè)關(guān)鍵性的點(diǎn)進(jìn)行信息的提起，轉(zhuǎn)化成可以處理的數(shù)字信息。這也就是現(xiàn)在發(fā)展比較火熱的智能視頻分析技術(shù)。其中主要發(fā)展的形成的應(yīng)用有：目標(biāo)移動(dòng)軌跡跟蹤、目標(biāo)移動(dòng)范圍監(jiān)測(cè)、目標(biāo)移動(dòng)方向監(jiān)測(cè)、靜態(tài)物體監(jiān)測(cè)、特殊人體行為監(jiān)測(cè)、人臉識(shí)別、數(shù)量統(tǒng)計(jì)以及視頻圖像質(zhì)量診斷等等。這些更多的是應(yīng)用于嵌入式視頻處理的產(chǎn)品，以算法、結(jié)構(gòu)、硬件的優(yōu)化來提高視頻信息的處理，盡量使其更加自動(dòng)化、智能化，能更加快捷準(zhǔn)確的獲取某些有效信息。但是這些技術(shù)的發(fā)展還不夠成熟和穩(wěn)定，都有一定條件的限制。對(duì)于算法，前端設(shè)備的依賴性比較大，目前也是處于研發(fā)優(yōu)化狀態(tài)。視頻技術(shù)應(yīng)用現(xiàn)狀視頻技術(shù)的應(yīng)用在我們生活中可謂無處不見，小到平常的電影電視以及身邊的攝像監(jiān)控，大到天氣預(yù)報(bào)衛(wèi)星云圖?？梢哉f視頻技術(shù)的應(yīng)用幾乎涉及各個(gè)領(lǐng)域。下面就列舉幾個(gè)常見的領(lǐng)域。日常生活中的視頻應(yīng)用，莫過于在手機(jī)上、電視上或者電腦上觀看電視或者電影?；蛘哒f通過這些設(shè)備來進(jìn)行視頻通話，網(wǎng)絡(luò)直播這類實(shí)時(shí)視頻通訊的應(yīng)用。這類只是處理好視頻清晰度和網(wǎng)絡(luò)帶寬的問題，能夠清晰流暢的觀看視頻或者進(jìn)行視頻通話即可。隨著帶寬的發(fā)展，網(wǎng)絡(luò)技術(shù)的不斷提升，這一技術(shù)也已經(jīng)發(fā)展成熟。其次常見的就是醫(yī)療設(shè)備的視頻圖像處理，這類主要還是針對(duì)核磁共振，超聲波圖像這一類的醫(yī)學(xué)圖像處理。當(dāng)然這種技術(shù)也發(fā)展的較為成熟，已經(jīng)應(yīng)用到大多數(shù)的醫(yī)院。但醫(yī)學(xué)類的視頻圖像處理依舊還在發(fā)展中，使其能夠更加準(zhǔn)清晰的判斷病情。還有一類是在軍事國(guó)防方面的應(yīng)用，當(dāng)然這些應(yīng)用就對(duì)視頻信息的處理要求更加準(zhǔn)確，更加智能化，速度更快，安全性更強(qiáng)。軍事領(lǐng)域的應(yīng)用就跟加的復(fù)雜，技術(shù)難度也就越大。本系統(tǒng)的相關(guān)技術(shù)現(xiàn)狀本系統(tǒng)的技術(shù)主要是用到視頻的編碼與解碼，視頻數(shù)據(jù)的傳輸，視頻數(shù)據(jù)在移動(dòng)終端的編解碼以及播放。本系統(tǒng)視頻編解碼是基于FFmpeg的三方庫，進(jìn)行編解碼的?，F(xiàn)在使用的FFmpeg已經(jīng)到達(dá)了3.0的版本，而且有基于win平臺(tái)和基于Linux平臺(tái)兩個(gè)版本。官方還有對(duì)于的動(dòng)態(tài)庫，開發(fā)包以及源碼下載，幾乎都能夠滿足開發(fā)者的基本需求。對(duì)于FFmpeg的平臺(tái)移植，也有相應(yīng)的簡(jiǎn)介和平臺(tái)搭建方法，而且也有許多人在此基礎(chǔ)上進(jìn)行過開發(fā)，有相對(duì)成熟的經(jīng)驗(yàn)。不足的是，網(wǎng)上可利用的資源不多，許多問題的研究并不見得深入。對(duì)于PC端的視頻數(shù)據(jù)獲取和播放，使用的是SDL的三方庫?，F(xiàn)在官方也發(fā)布2.0版本，對(duì)于老式的vfw攝像頭驅(qū)動(dòng)和現(xiàn)在較多的directshow都有較好的支持，網(wǎng)絡(luò)上也有相應(yīng)的基礎(chǔ)應(yīng)用的示例，包含對(duì)應(yīng)的事件機(jī)制和緩沖刷新機(jī)制，能夠基本滿足攝像頭視頻獲取相應(yīng)的功能。視頻數(shù)據(jù)的傳輸是基于TCP協(xié)議的socket套接字的一個(gè)傳輸方式，這種方式適用于建立長(zhǎng)時(shí)間的連接，而且數(shù)據(jù)傳輸相對(duì)有保證，通常是應(yīng)用于即時(shí)傳輸。這類數(shù)據(jù)傳輸協(xié)議和傳輸方法，已經(jīng)有了較成熟的示例，但是要根據(jù)不同的應(yīng)用來加以更改，理解對(duì)于流數(shù)據(jù)的處理機(jī)制，才能更好的應(yīng)用。手機(jī)終端視頻解碼的處理和播放，是基于FFmpeg的方式進(jìn)行，由于Android平臺(tái)近年來才興起，對(duì)于FFmpeg的移植有先例，但是并不是完全的成熟，有許多的問題有待解決。作為開發(fā)者，這一方面網(wǎng)上的資源可謂也少了許多。至于Android前端界面的編寫，現(xiàn)在已經(jīng)是發(fā)展到了相當(dāng)成熟的階段，幾乎能夠滿足所有應(yīng)用的一種移植所需的前端設(shè)計(jì)。本系統(tǒng)的應(yīng)用現(xiàn)狀本系統(tǒng)的主要應(yīng)用更加趨向于視頻監(jiān)控方向，由于采集端是基于PC的攝像頭，可能要真正進(jìn)行應(yīng)用的話，還需要一定的改進(jìn)。目前基于Android移動(dòng)終端的視頻監(jiān)控還不常見，大多數(shù)都是基于PC的一個(gè)視頻監(jiān)控，并沒有將視屏傳輸?shù)椒?wù)器，與移動(dòng)終端進(jìn)行一定的交互，將視屏實(shí)時(shí)傳輸?shù)揭苿?dòng)終端。而大多數(shù)的攝像頭的開發(fā)精力主要是集中在智能視頻監(jiān)控方面，以及高清視頻監(jiān)控方面。少有對(duì)移動(dòng)終端方面的視頻監(jiān)控進(jìn)行研發(fā)。本系統(tǒng)研發(fā)成功后，在以后的智能家居這方面，對(duì)于私人的視頻監(jiān)控的應(yīng)用有著廣闊的空間。特別是在人們外出時(shí)，依舊可以在有網(wǎng)絡(luò)的情況下，對(duì)家中的一些情況進(jìn)行監(jiān)視和查看。例如：防止有陌生人物侵入自己的房間。家中小孩遇到的突發(fā)情況。配合紅外感應(yīng)及時(shí)查看和預(yù)防家中可能出現(xiàn)的火災(zāi)。若攝像頭的安裝方便，還可以根據(jù)自己的需求對(duì)于一些需要觀察監(jiān)視的物品進(jìn)行實(shí)時(shí)查看。本課題研究的意義本系統(tǒng)的研究，致力于將視頻監(jiān)控變得跟加方便化，人性化。在于傳統(tǒng)意義上的PC視頻監(jiān)控上，增加了服務(wù)器存儲(chǔ)，以免重要的視頻信息遺漏、丟失。而且可以同步實(shí)時(shí)傳輸?shù)綄?duì)應(yīng)的移動(dòng)終端。夠跟加方便人們出行時(shí)對(duì)于房屋、車庫或者自己所重視的東西進(jìn)行一個(gè)實(shí)時(shí)視頻查看的效果。能夠使人們更加快捷的對(duì)危險(xiǎn)情況進(jìn)行反應(yīng)和處理，保障人們財(cái)產(chǎn)和生命安全。與此同時(shí)，又不會(huì)極大的約束人們的生活節(jié)奏和工作活動(dòng)，與智能家居進(jìn)行配合合作，在智能家居進(jìn)行一些數(shù)字化的檢測(cè)過后，由視頻數(shù)據(jù)來進(jìn)行更加準(zhǔn)確的判定。例如在有人進(jìn)入你家中的時(shí)候，在智能家居感應(yīng)到時(shí)，你可以通過視頻數(shù)據(jù)來判定是否是你的家人，還是外來入侵者。這些與此相近的一系列的應(yīng)用能更加方便人們的生活，保障人們的財(cái)產(chǎn)。本課題的研究方案本系統(tǒng)在設(shè)計(jì)之前，對(duì)設(shè)計(jì)方案有過初始簡(jiǎn)單的了解和建立，F(xiàn)Fmpeg是個(gè)成熟穩(wěn)定的三方開源庫，而且支持?jǐn)z像頭視頻提取功能。并且可以通過Jni與Java通訊，能很好的移植到Android上?？傮w來說，這個(gè)方案的可行性更加高，而且和實(shí)際的需求有很高程度上的契合度，也依舊有一些缺陷和不足有待改進(jìn)和優(yōu)化。前人已實(shí)現(xiàn)方案Anychat即時(shí)通訊平臺(tái)，是一套基于相對(duì)成熟的即時(shí)通訊視頻解決方案，而且可以更好的融合不同平臺(tái)之間的通訊。針對(duì)的主要是視頻網(wǎng)絡(luò)視頻聊天和視頻游戲一類的需求開發(fā)的一套實(shí)現(xiàn)方案。其中也是基于第三方的開源技術(shù)進(jìn)行開發(fā)的。其中包含了FFmpeg、libvpx、libspeex、webrtc。在視頻壓縮編解碼方面是基于H.264的視頻編碼標(biāo)準(zhǔn)、AAC音頻編碼標(biāo)準(zhǔn)和P2P技術(shù)。其中包含了音視頻處理模塊、流媒體管理模塊、流媒體播放模塊以及P2P網(wǎng)絡(luò)模塊。對(duì)于底層的硬件操作比如音視頻采集、播放和流媒體處理比如音視頻的編碼解碼等非常專業(yè)的技術(shù)都進(jìn)行了封裝。只為上層提供了對(duì)應(yīng)的API接口，方便開發(fā)者進(jìn)行調(diào)用。但是由于此系統(tǒng)主要是針對(duì)上層進(jìn)行開發(fā)，重點(diǎn)突出的是跨平臺(tái)。更多用于大型的視頻實(shí)時(shí)通訊的一種解決方案，并且它對(duì)于底層的操作都進(jìn)行了封裝，在本系統(tǒng)的開發(fā)中自由度受到了限制。另一種實(shí)現(xiàn)方案相對(duì)與anychat來說，沒有那么多現(xiàn)成的功能較為豐富的API接口，但是提供了更多在基本音視頻處理方面的API接口。比如圖像縮放具體實(shí)現(xiàn)，每一幀視頻數(shù)據(jù)的提取處理一類的。具體是用FFmpeg獲取視頻并進(jìn)行壓縮轉(zhuǎn)碼，自行編碼服務(wù)器，進(jìn)行數(shù)據(jù)實(shí)時(shí)傳輸，移動(dòng)終端基于Android或者iOS對(duì)Ffmpeg又進(jìn)行平臺(tái)移植，自己編碼實(shí)現(xiàn)視頻數(shù)據(jù)的解碼，并用自帶的視頻顯示控件進(jìn)行播放。這一種實(shí)現(xiàn)方式是在網(wǎng)上看到的一些分塊的設(shè)計(jì)自行組合而成的，這個(gè)方案只是有人提出可以實(shí)現(xiàn)，但是并沒有相關(guān)的源碼。但是FFmpeg對(duì)視頻數(shù)據(jù)的獲取，編碼壓縮技術(shù)基本已經(jīng)成熟，而且也有相對(duì)應(yīng)參考文獻(xiàn)。關(guān)于FFmpeg在移動(dòng)平臺(tái)的移植技術(shù)也有先例，但是技術(shù)還并不成熟。這里面也有關(guān)于C和Java之間的數(shù)據(jù)傳輸問題，大多使用的都是Jni進(jìn)行接口調(diào)用，也有許多的參考資源。兩種方案比較，anychat開發(fā)更為簡(jiǎn)單快捷。比如使用anychat進(jìn)行視頻攝像頭調(diào)用，僅僅需要一個(gè)函數(shù)BRAC_SetVideoPos就可以啟用攝像頭，里面已近具體實(shí)現(xiàn)了攝像頭類型檢測(cè)，驅(qū)動(dòng)監(jiān)測(cè)和攝像頭開啟等工作。其他的功能也相對(duì)于FFmpeg來說，又進(jìn)行了豐富和集成。而且anychat還擁有一套的sdk可供不同平臺(tái)開發(fā)，免去了跨平臺(tái)的移植麻煩，也提供了對(duì)應(yīng)的服務(wù)器開發(fā)方案，用此來搭建服務(wù)器。但是，anychat比較FFmpeg封裝的較多，遇到問題不能直接看源碼實(shí)現(xiàn)，而且它支持的音視頻解碼器比FFmpeg少了許多。這就使得使用anychat的自由度少了許多。其實(shí)anychat也就是基于FFmpeg進(jìn)行開發(fā)的，并且相比FFmpeg，開發(fā)文檔和相關(guān)開發(fā)資料也少了許多。基于自由度、代碼開放度、開發(fā)資料的豐富程度選擇使用FFmpeg對(duì)應(yīng)的方案。本系統(tǒng)使用方案本系統(tǒng)由于相對(duì)接近底層，也就并沒有采用第一種Anychat的方案，Anychat是一種已經(jīng)實(shí)現(xiàn)和封裝好的即時(shí)通訊平臺(tái)，更加針對(duì)的是上層開發(fā)。也就采用了第二種實(shí)現(xiàn)方案，本系統(tǒng)也在此基礎(chǔ)上進(jìn)行細(xì)節(jié)性的更改，使其更加適合本項(xiàng)目的開發(fā)。本系統(tǒng)的方案具體為使用FFmpeg來對(duì)視頻數(shù)據(jù)進(jìn)行獲取、編碼、壓縮。由于此三方庫相對(duì)比較成熟，而且功能強(qiáng)大，網(wǎng)上資源較為豐富。但是想要靈活運(yùn)用比較困難。使用SDL三方庫來對(duì)視頻攝像頭的硬件驅(qū)動(dòng)進(jìn)行檢測(cè)，能夠有效的運(yùn)行對(duì)應(yīng)的驅(qū)動(dòng)來進(jìn)行視頻數(shù)據(jù)的獲取，并且對(duì)已經(jīng)解碼好的視頻數(shù)據(jù)進(jìn)行播放。由于SDL有消息機(jī)制以及緩存刷新機(jī)制，對(duì)于視頻的播放相對(duì)也比較流暢，對(duì)于基本的攝像頭驅(qū)動(dòng)也能很好的支持，是相對(duì)理想的選擇。在數(shù)據(jù)傳輸方面，使用的是基于TCP協(xié)議的Socket套接字來進(jìn)行數(shù)據(jù)是實(shí)時(shí)傳輸，這種方式適用于建立長(zhǎng)時(shí)間的連接，而且數(shù)據(jù)傳輸相對(duì)有保證，通常是應(yīng)用于即時(shí)傳輸。由于C和Java之間要建立通訊連接，故采用Jni技術(shù)來進(jìn)行接口的調(diào)用，這種調(diào)用方式能夠很好的支持字節(jié)、數(shù)組、對(duì)象等基本數(shù)據(jù)的參數(shù)傳遞和返回，也能實(shí)現(xiàn)C對(duì)Java函數(shù)的調(diào)用，以及回調(diào)。由于是基于FFmpeg的視頻壓縮處理，在Android移動(dòng)終端使用的也是基于FFmpeg的三方庫視頻解碼，和Android自帶的視頻播放控件。方案的確定及其優(yōu)缺點(diǎn)優(yōu)點(diǎn)：本系統(tǒng)的這套方案，每一個(gè)部分清晰明了，恰到好處的實(shí)現(xiàn)了對(duì)應(yīng)的功能。FFmpeg是專門針對(duì)視頻數(shù)據(jù)進(jìn)行處理的，支持許多的編解碼方案，性能穩(wěn)定，而且基于C有更高的效率。SDL(SimpleDirectMediaLayer)也是個(gè)簡(jiǎn)單的三方庫，專門針對(duì)視頻圖像和音頻圖像的輸出，而且能夠?qū)z像頭驅(qū)動(dòng)進(jìn)行有效的檢測(cè)和調(diào)用。對(duì)應(yīng)的服務(wù)器使用的是Socket套接字，相對(duì)于URL和webserver這類的通訊方式，這種方式更加適合于長(zhǎng)連接和即時(shí)通訊，而且數(shù)據(jù)也有所保障?；贏ndroid的移動(dòng)終端，現(xiàn)在Android手機(jī)的使用也很廣泛，開發(fā)技術(shù)也相對(duì)成熟，支持很多功能的實(shí)現(xiàn)，是個(gè)較為方便和成熟的平臺(tái)。缺點(diǎn)：由于運(yùn)用了Jni對(duì)Native進(jìn)行了調(diào)用，在系統(tǒng)的穩(wěn)定性和安全性上并沒有那么可靠。全文結(jié)構(gòu)第一章，引言部分，大致介紹了本系統(tǒng)的課題背景，現(xiàn)階段國(guó)內(nèi)外的研究現(xiàn)狀，本系統(tǒng)實(shí)現(xiàn)的方案選擇以及其優(yōu)缺點(diǎn)。第二章，系統(tǒng)概要設(shè)計(jì)，簡(jiǎn)單介紹了本系統(tǒng)的結(jié)構(gòu)框架，展示系統(tǒng)結(jié)構(gòu)框架圖，以及系統(tǒng)所需求的結(jié)構(gòu)、功能、性能等各方面的設(shè)計(jì)簡(jiǎn)潔。第三章，系統(tǒng)詳細(xì)設(shè)計(jì)，是本論文的重點(diǎn)部分。詳細(xì)的介紹了本系統(tǒng)的每個(gè)部分的詳細(xì)設(shè)計(jì)，設(shè)計(jì)框架結(jié)構(gòu)，數(shù)據(jù)詳細(xì)設(shè)計(jì)說明等。其中附有詳細(xì)的結(jié)構(gòu)圖和對(duì)應(yīng)的關(guān)鍵源程序代碼。第四章，是在本系統(tǒng)的開發(fā)過程中所遇到的一些比較有代表性的問題以及其解決方案，當(dāng)然也有尚未解決的問題。第五章，是對(duì)本系統(tǒng)的測(cè)試分析，主要是在本系統(tǒng)開發(fā)中的一些測(cè)試，及開發(fā)完成后完善的一些測(cè)試。本章小結(jié)，此章的重點(diǎn)就是在系統(tǒng)的總體簡(jiǎn)介之前對(duì)其課題背景的一個(gè)描述，和對(duì)當(dāng)前相關(guān)技術(shù)的一個(gè)大致了解。這其中大多數(shù)是從書籍、網(wǎng)絡(luò)上了解的知識(shí)，對(duì)于本系統(tǒng)的大體設(shè)計(jì)有著很大的幫助。除此之外，還學(xué)習(xí)了其他與視頻通訊相關(guān)的知識(shí)，有助于其他開發(fā)者的參考，也幫助我更加完善和改進(jìn)自己的設(shè)計(jì)。系統(tǒng)概要設(shè)計(jì)系統(tǒng)框架結(jié)構(gòu)系統(tǒng)框架結(jié)構(gòu)主要是通過PC采集視頻，由服務(wù)器進(jìn)行同步傳輸，再通過Android手機(jī)端進(jìn)行播放。其結(jié)構(gòu)框圖如下圖2-1：圖SEQ圖\*ARABIC1系統(tǒng)框架結(jié)構(gòu)圖下面是與之對(duì)應(yīng)的功能結(jié)構(gòu)框架圖：SEQ圖\*ARABIC2系統(tǒng)功能機(jī)構(gòu)圖系統(tǒng)需求分析本小結(jié)主要是針對(duì)系統(tǒng)的各個(gè)方面的性能進(jìn)行一個(gè)相關(guān)的闡述，對(duì)于各個(gè)模塊功能的大致需求。本系統(tǒng)的運(yùn)行環(huán)境硬件需求，win7的PC電腦一臺(tái)，支持directShow的視頻攝像頭，并且能夠正常的工作。PC端有對(duì)應(yīng)的無線網(wǎng)卡，能夠產(chǎn)生一個(gè)良好的局域網(wǎng)。本系統(tǒng)所需的軟件和其他條件，使用本軟件的人能夠熟練的運(yùn)用PC電腦和Android手機(jī)，對(duì)于網(wǎng)絡(luò)也要有一方面的了解。在本系統(tǒng)運(yùn)行之前，要對(duì)系統(tǒng)的局域網(wǎng)IP進(jìn)行查看，能夠獲取到對(duì)應(yīng)客戶端的局域網(wǎng)IP地址。而且本系統(tǒng)運(yùn)行時(shí)，確認(rèn)系統(tǒng)沒有其他軟件對(duì)9876(自定義端口，可更改)端口進(jìn)行占用，如果有占用，要先解除占用，本系統(tǒng)才能夠正常運(yùn)行。移動(dòng)終端的Android手機(jī)要基于4.0平臺(tái)以上，能夠正常工作的手機(jī)。并且要先安裝本系統(tǒng)對(duì)應(yīng)的Android客戶端軟件。系統(tǒng)功能模塊本系統(tǒng)的功能需求，是實(shí)現(xiàn)在PC端的數(shù)據(jù)采集和數(shù)據(jù)編解碼，并且在客戶端進(jìn)行顯示。獲取到數(shù)據(jù)編碼壓縮完畢后連接到服務(wù)器，進(jìn)行數(shù)據(jù)的同步傳輸。在移動(dòng)終端接收到數(shù)據(jù)過后進(jìn)行解碼，而后由手機(jī)端進(jìn)行同步播放。在此分別給出三個(gè)大模塊對(duì)應(yīng)的結(jié)構(gòu)框架圖：圖SEQ圖\*ARABIC4PC端結(jié)構(gòu)框架圖圖SEQ圖\*ARABIC5服務(wù)器結(jié)構(gòu)圖圖SEQ圖\*ARABIC6移動(dòng)終端結(jié)構(gòu)框架圖系統(tǒng)數(shù)據(jù)傳輸有關(guān)數(shù)據(jù)傳輸?shù)男枨?，主要是針?duì)數(shù)據(jù)傳輸?shù)耐叫院蛿?shù)據(jù)傳輸?shù)恼_性。從數(shù)據(jù)的獲取到數(shù)據(jù)最終的播放，都盡量做到數(shù)據(jù)的正確和同步。數(shù)據(jù)獲取階段，Buffer的創(chuàng)建是在Java代碼里面完成的，通過Jni的調(diào)用，將其對(duì)象的引用傳輸?shù)紺代碼里，用于存儲(chǔ)從攝像頭你獲取的視頻數(shù)據(jù)。如果存儲(chǔ)完成，則對(duì)標(biāo)志位置位。以此來通知Java代碼里的數(shù)據(jù)傳輸線程，可以讀取數(shù)據(jù)Buffer里的數(shù)據(jù)來進(jìn)行傳輸。在數(shù)據(jù)傳輸階段，在服務(wù)器與PC客戶端以及移動(dòng)終端的客戶端建立連接完成以后，服務(wù)器讀線程監(jiān)聽PC端傳輸過來的數(shù)據(jù)，并且讓寫進(jìn)程等待。當(dāng)PC端數(shù)據(jù)傳輸?shù)椒?wù)器后，存儲(chǔ)到建立的數(shù)據(jù)Buffer中，解除寫進(jìn)程等待，讓讀進(jìn)程進(jìn)行等待。此時(shí)寫進(jìn)程開始講數(shù)據(jù)Buffer中的數(shù)據(jù)寫入到移動(dòng)終端，完成后解除讀進(jìn)程等待。在移動(dòng)終端數(shù)據(jù)接收時(shí)，新建一個(gè)線程進(jìn)行服務(wù)器連接，獲取視頻數(shù)據(jù)Buffer，當(dāng)數(shù)據(jù)緩沖完成過后，傳輸?shù)紽Fmpeg對(duì)應(yīng)的動(dòng)態(tài)庫中進(jìn)行解碼，由相應(yīng)的視頻控件來進(jìn)行播放。同樣，在數(shù)據(jù)Buffer不同的讀寫操作時(shí)，要保證進(jìn)程間的互斥。系統(tǒng)性能需求系統(tǒng)性能需求主要集中的方面是數(shù)據(jù)傳輸?shù)乃俣?，和視頻播放的效果。在數(shù)據(jù)傳輸方面，由于在采集的時(shí)候采用的是延遲40毫秒采集一次視頻數(shù)據(jù)，也就是得到的視頻數(shù)據(jù)為25幀頻。每幀的數(shù)據(jù)在沒有壓縮的時(shí)候是460800個(gè)字節(jié)，也就是450kb。若不進(jìn)行壓縮就傳輸數(shù)據(jù)，那么一秒鐘傳輸?shù)臄?shù)據(jù)在10M左右，一般的帶寬都無法承受這樣的數(shù)據(jù)量。因此只能采用H264的壓縮方式來進(jìn)行壓縮，一般的H264的壓縮比在100:1左右，折算下來每秒鐘傳輸?shù)臄?shù)據(jù)為100kb左右，這樣的數(shù)據(jù)量在一般的網(wǎng)絡(luò)寬帶都能夠有效的支持。而在這40秒獲取到數(shù)據(jù)時(shí)，要同步傳輸?shù)綄?duì)應(yīng)的手機(jī)端并且能夠播放出來，其中包括視頻數(shù)據(jù)解碼，傳輸，在服務(wù)器中進(jìn)行讀取各個(gè)方面的操作。由于從視頻獲取、解碼、編碼、傳輸、數(shù)據(jù)獲取、解碼播放都是一個(gè)線性操作，加上網(wǎng)絡(luò)的傳輸不穩(wěn)定因素。因此要保證在通訊連接建立過后不掉幀的難度很大，但是在范圍程度內(nèi)的掉幀不影響播放效果是可以接受的。在第三章中會(huì)對(duì)H264的編碼結(jié)構(gòu)和其中的I，P幀進(jìn)行詳解。視頻播放效果質(zhì)量主要是在數(shù)據(jù)編碼和數(shù)據(jù)傳輸?shù)恼_性方面。由于視頻采集的時(shí)候，得到的是YUV數(shù)據(jù)，要轉(zhuǎn)碼成為H264編碼的格式，進(jìn)行壓縮方便傳輸和播放。但是在編碼時(shí)，要注意時(shí)間的控制，以及編碼方式的控制。要不就會(huì)出現(xiàn)編碼過后與原來的幀頻不能有效的對(duì)應(yīng)，使得播放過快或者過慢。同樣，視頻播放的速度也取決于數(shù)據(jù)傳輸?shù)乃俣龋瑪?shù)據(jù)傳輸?shù)乃俣炔荒苡行M足，實(shí)時(shí)播放的效果也就不能實(shí)現(xiàn)。其中在傳輸?shù)臅r(shí)候，Java函數(shù)的選擇也是很重要的，本系統(tǒng)采用的是inputoustream和outputstream對(duì)應(yīng)的字節(jié)流輸入輸出函數(shù)來保證數(shù)據(jù)傳輸?shù)恼_性。傳輸?shù)耐娇刂坪侠硪彩潜ＷC數(shù)據(jù)傳輸正確性的一個(gè)重要方面。系統(tǒng)重點(diǎn)技術(shù)簡(jiǎn)介本節(jié)主要是針對(duì)本系統(tǒng)的重點(diǎn)一些技術(shù)進(jìn)行簡(jiǎn)介。其中主要涉及的重點(diǎn)技術(shù)有FFmpeg編解碼，Jni運(yùn)用，SDL視頻播放，socket套接字使用。FFmpeg編解碼，這個(gè)三方庫是本系統(tǒng)的核心。使用它來完成了數(shù)據(jù)的獲取，視頻數(shù)據(jù)的編碼壓縮這些核心功能。下面是大致的一個(gè)編解碼步驟：其中數(shù)據(jù)獲取是先使用av_register_all()進(jìn)行初始化（這個(gè)函數(shù)是所有模塊初始化，也可以用對(duì)應(yīng)模塊的函數(shù)進(jìn)行初始化）。使用avformat_find_stream_info函數(shù)獲取對(duì)應(yīng)流媒體的各個(gè)方面的信息（具體會(huì)在下面詳解）。avcodec_open2初始化音視頻編解碼器，再使用av_read_frame讀取幀頻數(shù)據(jù)。并用avcodec_decode_video2()解碼一幀視頻數(shù)據(jù)。輸入一個(gè)壓縮編碼的結(jié)構(gòu)體AVPacket。avcodec_decode_video2函數(shù)返回成功后，我們就可以通過這個(gè)AVPacket結(jié)構(gòu)體獲取對(duì)應(yīng)的視頻數(shù)據(jù)了。FFmpeg的視頻編解碼的庫都主要集中于libavcodec對(duì)應(yīng)的文件夾下，其中包含了大部分對(duì)于音視頻的編解碼函數(shù)。下面是就基本的FFmpeg編解碼的流程圖：圖SEQ圖\*ARABIC7音視頻編解碼流程圖Jni其實(shí)就是一個(gè)橋梁，連接Java和C其中主要的就是一個(gè)動(dòng)態(tài)庫的生成，對(duì)應(yīng)函數(shù)的編寫格式，和傳參方式。其中大致實(shí)現(xiàn)步驟如下：編寫Java類，帶有native的聲明方法。使用Javah命令生成對(duì)應(yīng)的類的頭文件。使用C/C++實(shí)現(xiàn)與之對(duì)應(yīng)的本地方法。使用vs2013將你的C/C++文件編譯生成對(duì)應(yīng)的動(dòng)態(tài)鏈接庫。配置對(duì)應(yīng)的環(huán)境變量，使Java能夠?qū)雽?duì)應(yīng)的動(dòng)態(tài)鏈接庫。在這些方法實(shí)現(xiàn)的過程中，要使用到對(duì)應(yīng)的參數(shù)調(diào)用，和函數(shù)回調(diào)。在后面的詳解中會(huì)詳細(xì)說明。SDL在本系統(tǒng)的主要作用是對(duì)系統(tǒng)攝像頭的驅(qū)動(dòng)監(jiān)測(cè)，和攝像頭啟動(dòng)。主要包括以下幾步：監(jiān)測(cè)攝像頭驅(qū)動(dòng)信息。使用對(duì)應(yīng)的攝像頭驅(qū)動(dòng)啟動(dòng)攝像頭。SDL_CreateWindow函數(shù)創(chuàng)建對(duì)應(yīng)的視頻播放窗口。使用SDL_Texture函數(shù)存儲(chǔ)一幀的像素?cái)?shù)據(jù)。使用SDL_UpdateYUVTexture更新紋理，顯示一幀的視頻數(shù)據(jù)。這里介紹的也是SDL使用的大致的幾個(gè)常用和關(guān)鍵的幾個(gè)函數(shù)和步驟，后面還會(huì)對(duì)其進(jìn)行詳細(xì)的介紹。Socket套接字使用相對(duì)比較簡(jiǎn)單，要很好的控制和利用也要好好學(xué)習(xí)。本系統(tǒng)中的服務(wù)器中的主要步驟如下：服務(wù)器申請(qǐng)端口，創(chuàng)建serversocket對(duì)象。使用accept函數(shù)進(jìn)行客戶端的監(jiān)聽?？蛻舳耸褂胹ocket套接字進(jìn)行連接。建立連接過后，建立一個(gè)實(shí)例化的socket套接字。使用socket類中的inputstream和outputstream進(jìn)行字節(jié)流的傳輸。Socket套接字是基于TCP的通訊協(xié)議，在Java中寫的，對(duì)于底層的具體通訊方式?jīng)]有進(jìn)行詳細(xì)的了解，后面會(huì)對(duì)其具體詳情進(jìn)行介紹。本章小結(jié)本章對(duì)于本系統(tǒng)的大致框架結(jié)構(gòu)，每一部分的框架結(jié)構(gòu)有了一個(gè)大致的了解，對(duì)應(yīng)其相關(guān)的技術(shù)以及其中重點(diǎn)或者關(guān)鍵的部分也有相關(guān)的提及。對(duì)于本系統(tǒng)的數(shù)據(jù)傳輸質(zhì)量、速度方面進(jìn)行了簡(jiǎn)單的介紹，也分析了本系統(tǒng)影響視頻播放的各個(gè)方面做了一些簡(jiǎn)介。本章的目的只是讓讀者了解本系統(tǒng)的大致結(jié)構(gòu)，其中具體的實(shí)現(xiàn)方法以及細(xì)節(jié)，會(huì)在下一章節(jié)進(jìn)行說明。系統(tǒng)詳細(xì)設(shè)計(jì)視頻采集技術(shù)實(shí)現(xiàn)方法這里介紹的是PC端視頻采集技術(shù)的具體實(shí)現(xiàn)方法，以及對(duì)應(yīng)的FFmpeg進(jìn)行編解碼的具體實(shí)現(xiàn)方式。這也是本系統(tǒng)的核心重點(diǎn)所在。攝像頭驅(qū)動(dòng)及FFmpeg平臺(tái)搭建視頻攝像頭視頻獲取，主要是針對(duì)攝像頭的啟動(dòng)，和運(yùn)行進(jìn)行說明。由于視頻獲取和后面的視頻顯示是在一起的，就放在下面講解。本系統(tǒng)基于的PC平臺(tái)是win7的平臺(tái)，win平臺(tái)使用的攝像頭驅(qū)動(dòng)有老版本的vfw（videoforWindows）對(duì)應(yīng)的封裝庫（這個(gè)基本已經(jīng)不用了）。也有現(xiàn)在使用較為廣泛的是基于DirectShow來驅(qū)動(dòng)攝像頭的。而本系統(tǒng)進(jìn)行檢測(cè)是基于DirectShow的攝像頭，因此采用了FFmpeg自帶的攝像頭驅(qū)動(dòng)方式來對(duì)攝像頭進(jìn)行驅(qū)動(dòng)。主要的函數(shù)是av_find_input_format獲取系統(tǒng)攝像頭設(shè)備，其中參數(shù)是對(duì)應(yīng)你攝像頭的驅(qū)動(dòng)類型。而后使用avformat_open_input函數(shù)就能打開對(duì)應(yīng)攝像頭，獲取到里面對(duì)應(yīng)的視頻流數(shù)據(jù)。但是此函數(shù)里的參數(shù)需要你事先獲得你攝像頭使用的設(shè)備驅(qū)動(dòng)名稱，這里獲取攝像頭驅(qū)動(dòng)信息的方式有一下幾種：使用FFmpeg自帶的命令進(jìn)行查看，查看攝像頭設(shè)備信息的命令為：ffmpeg-list_devicestrue-fdshow-idummy使用代碼在控制臺(tái)打印出對(duì)應(yīng)的設(shè)備信息主要使用函數(shù)av_dict_set。使用一些軟件來實(shí)現(xiàn)這個(gè)功能，比如DirectShow的調(diào)試工具GraphEdit。這里使用到的FFmpeg函數(shù)并不多，但是需要事先在win7平臺(tái)下基于vs2013進(jìn)行FFmpeg的平臺(tái)搭建，就在此進(jìn)行介紹。下面只搭建平臺(tái)的步驟：官網(wǎng)上下載對(duì)應(yīng)FFmpeg在win平臺(tái)下編譯的包，根據(jù)你系統(tǒng)的平臺(tái)來選擇。在vs中新建控制臺(tái)工程，并設(shè)置動(dòng)態(tài)鏈接庫路徑（也可以使用代碼來實(shí)現(xiàn)動(dòng)態(tài)庫的連接）。將所需要的dll文件拷貝到你所見工程當(dāng)中。編寫一個(gè)測(cè)試代碼進(jìn)行測(cè)試，成功就完成了。由于后面Android也需要FFmpeg移植，搭建基于Android的FFmpeg平臺(tái)，下面就根據(jù)Android平臺(tái)說明一下搭建步驟：下載對(duì)應(yīng)的FFmpeg源代碼。建立編譯平臺(tái)，一般在Linux下編譯，如果你用的是win平臺(tái)，可以使用模擬Linux平臺(tái)的軟件，如Cygwin。編寫和修改configure文件，和編寫build_Android.sh腳本文件，準(zhǔn)備進(jìn)行編譯（如果平臺(tái)是win平臺(tái)，還要進(jìn)行其他文件的修改）。創(chuàng)建普通的Android工程，將編譯出來的so動(dòng)態(tài)庫加入對(duì)應(yīng)的Jni文件夾創(chuàng)建對(duì)應(yīng)的含有native本地調(diào)用程序的類。創(chuàng)建對(duì)應(yīng)的頭文件，編寫對(duì)應(yīng)的Android.mk文件。運(yùn)行Android.mk文件，編譯生成對(duì)應(yīng)的so文件。加載對(duì)應(yīng)的so動(dòng)態(tài)庫。進(jìn)行基本測(cè)試，成功完成。以上就是針對(duì)攝像頭監(jiān)測(cè)和啟動(dòng)以及FFmpeg的一些平臺(tái)搭建的類容，都是只寫出了核心的內(nèi)容，若要實(shí)踐還需要多多參考其他資源。PC端獲取視頻解碼顯示視頻的獲取工作，主要是由FFmpeg完成，而PC端的視頻數(shù)據(jù)顯示基本由SDL完成。這里就分別進(jìn)行視頻數(shù)據(jù)獲取和視頻數(shù)據(jù)顯示的詳細(xì)介紹。下面是對(duì)應(yīng)的視頻獲取解碼的路程圖：圖SEQ圖\*ARABIC8視頻解碼這里需要說明的是，視頻的獲取中也包含了視頻解碼的過程，從攝像頭中獲取的視頻數(shù)據(jù)通過解碼成一幀幀的YUV數(shù)據(jù)，傳遞給SDL來進(jìn)行播放。這里對(duì)部分函數(shù)進(jìn)行說明：Av_register_all()：對(duì)所有的FFmpeg編解碼器進(jìn)行注冊(cè)。Av_find_stream_info()：新建AVStream的輸入碼流，這里是對(duì)應(yīng)的攝像頭輸入碼流。avcodec_find_encoder()：查找對(duì)應(yīng)的編碼器。avcodec_open2()：打開對(duì)應(yīng)的編碼器。av_read_frame()：讀取一幀的數(shù)據(jù)到對(duì)應(yīng)的packet。avcodec_dencode_video2()：真正解碼碼一幀視頻，將對(duì)應(yīng)的packet里的數(shù)據(jù)解碼到AVFrame里。sws_scale()：對(duì)AVFrame里的一幀圖片進(jìn)行縮放處理。這里最耗時(shí)的兩個(gè)函數(shù)是avcodec_dencode_video2()和sws_scale()，由于獲取的視頻數(shù)據(jù)格式是rawdata數(shù)據(jù)，在進(jìn)行解碼和圖像縮放的時(shí)候，在PC端的耗時(shí)并不長(zhǎng)，兩個(gè)函數(shù)加起來在3ms左右，對(duì)于這里采集視頻使用的是25幀，即40ms采集一幀，在此的影響不大。圖像的縮放函數(shù)并沒有改變?cè)瘮?shù)的長(zhǎng)寬，僅僅是改變了數(shù)據(jù)格式，從rawdata變?yōu)榱薡UV。其中黃色的內(nèi)容是SDL2.0新增加的內(nèi)容。下面就是針對(duì)這一幀幀的數(shù)據(jù)SDL進(jìn)行播放的流程圖：圖SEQ圖\*ARABIC9SDL視頻播放流程圖關(guān)于SDL播放問題，這里主要關(guān)注的是兩個(gè)點(diǎn)：第一，在播放是窗口是否可拖動(dòng)，或者其他操作。第二，視頻播放的流暢度，如果不流暢如何處理。關(guān)于第一點(diǎn)，本系統(tǒng)使用的是消息緩存機(jī)制。即新建一個(gè)線程，對(duì)窗口的操作進(jìn)行消息緩存，并且進(jìn)行40ms的延時(shí)來控制視頻幀數(shù)。而主線程進(jìn)行消息緩存的等待，獲取到對(duì)應(yīng)的緩存消息，介紹等待。這樣處理就能夠有一個(gè)線程處理窗口操作消息，不會(huì)使窗口一直處于忙碌狀態(tài)，而且還能夠更加準(zhǔn)確的控制幀數(shù)。關(guān)于第二點(diǎn)，在視頻播放不流暢的時(shí)候，會(huì)彈出bufferfull的提示，并且將當(dāng)時(shí)的幀進(jìn)行舍棄。以保證視頻能夠正常播放。這種情況在進(jìn)行窗口移動(dòng)的過程中，視頻會(huì)暫停，就會(huì)出現(xiàn)這種情況，但當(dāng)移動(dòng)結(jié)束后又能正常播放。下面是PC端視頻獲取顯示的運(yùn)行截圖：圖SEQ圖\*ARABIC10PC端運(yùn)行截圖視頻編碼存儲(chǔ)視頻編碼的主要目的是對(duì)占用空間很大的視頻數(shù)據(jù)進(jìn)行壓縮，使其方便傳輸。不同的編碼格式有不同的優(yōu)缺點(diǎn)，也有不同的應(yīng)用場(chǎng)景和范圍。下面就是視頻編碼中主要的編碼方案：表格SEQ表格\*ARABIC1主要視頻編碼方案名稱推出機(jī)構(gòu)推出時(shí)間目前使用領(lǐng)域HEVC(H.265)MPEG/IUT-T2013推廣中H.264MPEG/IUT-T2003各個(gè)領(lǐng)域MPEG4MPEG2001不溫不火MPEG2MPEG1994數(shù)字電視VP9Google2013研發(fā)中VP8Google2008不普及CV-1MicrosoftInc.2006微軟平臺(tái)由于本系統(tǒng)并不需要進(jìn)行音頻壓縮處理，所有在進(jìn)行編碼的時(shí)候，僅僅做了視頻編碼處理。如果要加入音頻壓縮處理時(shí)，往往還需要進(jìn)行封裝，進(jìn)行音視頻同步方面的問題。在本系統(tǒng)中并沒有必要加入這些。因此，本系統(tǒng)采用的是使用范圍較為廣泛的H.264的壓縮編碼方案，將得到的YUV數(shù)據(jù)轉(zhuǎn)換成對(duì)應(yīng)的H.264格式，現(xiàn)在就YUV數(shù)據(jù)流和H.264的碼流進(jìn)行一個(gè)簡(jiǎn)單的介紹。YUV數(shù)據(jù)是指視頻像素?cái)?shù)據(jù)，是最為基本的視頻數(shù)據(jù)。其中包括YUV420P、YUV422P和YUV444P。當(dāng)然基本的非壓縮像素?cái)?shù)據(jù)也有RGB格式類型，在本系統(tǒng)中使用的是YUV420P的格式。其中YUV表示的是三個(gè)分量，Y表示的是亮度，也就是灰度值；而U和V表示的是色度，主要功能是描述影像的色彩和飽和度，用來指定像素的顏色。YUV的存儲(chǔ)格式和采樣方式密切相關(guān)，其中后面的420P、422P和444P代表的就是三種不同的采樣方式。具體情況在此就不詳述了。我想重點(diǎn)強(qiáng)調(diào)的就是通過不同的采樣方式，會(huì)有不同的格式，只有通過對(duì)應(yīng)的采樣格式從數(shù)據(jù)碼流中提取像素點(diǎn)的YUV值，才能夠正確的轉(zhuǎn)換成RGB像素點(diǎn)的值，然后顯示出來。H.264碼流，是將對(duì)應(yīng)的YUV像素?cái)?shù)據(jù)格式進(jìn)行壓縮過后得到的數(shù)據(jù)。H.264原始碼流，又稱為“裸流”，是由一個(gè)一個(gè)的NALU組成的。其中每個(gè)NALU之間通過startcode（起始碼）進(jìn)行分割。其中起始碼的類型必須是“0X00000001”或者“0X000001”這兩種類型其中的一種。而如果要進(jìn)行H.264碼流的解析，就要首先從碼流中找到這些起始碼，分離出單個(gè)的NALU，然后再對(duì)單個(gè)的NALU單元進(jìn)行分析。當(dāng)然我們?cè)谶M(jìn)行編碼的時(shí)候，并不需要對(duì)其了解太多，因?yàn)镕Fmpeg已經(jīng)有對(duì)應(yīng)的函數(shù)可以實(shí)現(xiàn)這些壓縮解壓的過程了。這是對(duì)一個(gè)H264碼流的結(jié)構(gòu)進(jìn)行的分析，下面就是對(duì)其編碼方式進(jìn)行分析。H264是以高質(zhì)量高壓縮和支持多種網(wǎng)絡(luò)流媒體協(xié)議而聞名的。其主要是實(shí)現(xiàn)方式就是通過參考，在有一個(gè)完整幀的情況下，后面的相鄰幀圖像差距一般只有不到10%的差距，而H264的編碼就是依靠一個(gè)完整的幀，后面相鄰的幀對(duì)前面完整的幀進(jìn)行參考，如果差距不大，就只需要進(jìn)行變化部分的參考即可，要是變化較大，那么久從新生成一個(gè)新的參考幀。從而大大降低了數(shù)據(jù)量。在H264中定義的三種幀，分別是I幀、P幀、B幀。其中I幀是完整的編碼幀，P幀是參考之前的I幀生成的差異幀，B幀是參考前后編碼的幀。I幀包含完整的圖像數(shù)據(jù)，直接解碼I幀就可以有完整的圖像數(shù)據(jù)，而P幀是表示的這一幀和之前的I幀或者是P幀之間的差別，解碼時(shí)就要實(shí)現(xiàn)緩存之前的幀，再加上本幀定義的差別，才能夠生成最后的畫面。而B幀對(duì)應(yīng)的是前后幀與本幀之間的差別，在進(jìn)行B幀解碼時(shí)，不僅先要取得前面一幀的緩存畫面，而且還要取得后面一幀的緩存畫面，通過前后兩幀和本幀的差別疊加過后取得最終的畫面，由于B幀需求的條件和比較多，而且壓縮率高，在解碼的時(shí)候CPU的耗時(shí)會(huì)很多，這也是B幀和H264編解碼速度之間的關(guān)系。下面就是對(duì)YUV數(shù)據(jù)轉(zhuǎn)化成H.264格式數(shù)據(jù)的一個(gè)流程圖：圖SEQ圖\*ARABIC11視頻編碼路程圖其中綠色的部分是實(shí)際上輸出數(shù)據(jù)的函數(shù)，藍(lán)色部分才是真正意義上的視頻編碼函數(shù)。下面就將上面所有的函數(shù)進(jìn)行相應(yīng)的解釋說明：Av_register_all()：對(duì)所有的FFmpeg編解碼器進(jìn)行注冊(cè)。avformat_alloc_output_context2()：初始化輸出流碼的AVFormatContext，這個(gè)函數(shù)也就可以更加自動(dòng)的選擇編碼方式，可以根據(jù)你的輸出文件后綴名進(jìn)行判斷編碼方式。avio_open()：打開對(duì)應(yīng)輸出文件，雖然本系統(tǒng)緩存在Buffer中，不過也向文件中進(jìn)行本地存儲(chǔ)寫入。av_new_stream()：新建AVStream的輸出碼流。avcodec_find_encoder()：查找對(duì)應(yīng)的編碼器。avcodec_open2()：打開對(duì)應(yīng)的編碼器。avformat_write_header()：寫文件頭，但對(duì)于一些沒有頭文件封裝格式的編碼方式來說，并不需要這個(gè)函數(shù)。avcodec_encode_video2()：真正編碼一幀視頻，將存儲(chǔ)的YUV數(shù)據(jù)編碼為對(duì)應(yīng)的H.264的AVPacket。av_write_frame()：將編碼好的流視頻寫入對(duì)應(yīng)的文件，而本系統(tǒng)還需要把對(duì)應(yīng)的H.264的數(shù)據(jù)同時(shí)緩存到數(shù)據(jù)Buffer中。flush_encoder()：要在YUV像素?cái)?shù)據(jù)讀取完畢過后調(diào)用此函數(shù)，用于輸出編碼器中剩余的AVPacket。這個(gè)函數(shù)是自己編寫的，具體看源碼。av_write_trailer()：寫文件尾，同樣，有些封裝格式不需要寫文件尾，根據(jù)不同的編碼方式來定。視頻緩存?zhèn)鬏敂?shù)據(jù)緩存?zhèn)鬏數(shù)姆椒?，基本是基于Jni的一個(gè)傳參和調(diào)用方法。本系統(tǒng)由于服務(wù)器選用的是Java，加上客戶端也是基于Java的Android平臺(tái)，因此選用的方式就是在Java層進(jìn)行Buffer緩存的實(shí)例化，將其引用傳入C語言層，再將其填充，填充完成過后，再由另外一個(gè)線程將其傳輸?shù)椒?wù)器。這里對(duì)Jni的機(jī)制進(jìn)行簡(jiǎn)單講解，Jni(JavaNativeInterface)其主要功能是進(jìn)行Java和C/C++進(jìn)行通訊。實(shí)際上，Jni是JVM中實(shí)現(xiàn)的一個(gè)部分，由此native語言(C/C++)都對(duì)應(yīng)的運(yùn)行在JVM宿主環(huán)境中（HostEnvironment）。也是這種方式加上Jni是一個(gè)雙向接口，使得開發(fā)者不僅可以在Java中通過Jni訪問Native代碼，也可以在Native中嵌入一個(gè)對(duì)應(yīng)的JVM實(shí)現(xiàn)在Native代碼中對(duì)Java代碼的訪問。也正是通過這種方式，彌補(bǔ)了一些時(shí)候Java開發(fā)中一些缺陷。例如你希望你提高默寫關(guān)鍵的模塊代碼的效率的時(shí)候，你就可以通過C/C++等Native語言來進(jìn)行相關(guān)程序庫的開發(fā)。當(dāng)然是用Jni的時(shí)候，也有其相應(yīng)的缺點(diǎn)：因?yàn)橐褂肗ative模塊的代碼，因此Java會(huì)失去原來的跨平臺(tái)性和其安全性等等的特性。除此之外，Jni的應(yīng)用中，Native代碼和Java代碼都是運(yùn)行在同一宿主的進(jìn)程空間內(nèi)，如果是跨進(jìn)程或者是宿主機(jī)之間的通訊，就只能考慮采用socket、IPC或者是WebService等通訊機(jī)制來進(jìn)行實(shí)現(xiàn)。其具體的數(shù)據(jù)傳輸方式如下結(jié)構(gòu)圖所示：圖SEQ圖\*ARABIC12視頻數(shù)據(jù)傳輸結(jié)構(gòu)圖在數(shù)據(jù)從C語言層里面獲取的時(shí)候，傳輸?shù)絁ava層，這里也有相應(yīng)的數(shù)據(jù)對(duì)應(yīng)關(guān)系，畢竟這兩個(gè)語言所用的基本數(shù)據(jù)單位還是有一定的差別。下面就對(duì)C和Java的基本數(shù)據(jù)對(duì)應(yīng)列出了大致的表格：表格SEQ表格\*ARABIC2Java和C的數(shù)據(jù)對(duì)應(yīng)表Java類型本地類型（JNI）本地類型（C）描述BooleanJbooleanUnsignedchar無符號(hào)8個(gè)字節(jié)ByteJbyteSignedchar有符號(hào)8個(gè)字節(jié)CharJcharUnsignedshort無符號(hào)16個(gè)字節(jié)ShortJshortShort有符號(hào)16個(gè)字節(jié)IntJintLong有符號(hào)32個(gè)字節(jié)LongJlong_int64有符號(hào)64個(gè)字節(jié)FloatJfloatFloat32個(gè)字節(jié)DoubleJdoubleDouble64個(gè)字節(jié)ObjectJobject_jobject自定義結(jié)構(gòu)VoidVoidVoidN/A在JNI的調(diào)用時(shí)，往往還會(huì)使用到Jni的簽名，其實(shí)就是對(duì)應(yīng)的數(shù)據(jù)類型，通常在函數(shù)調(diào)用的時(shí)候會(huì)用到。下面是所有Jni中的變量標(biāo)簽：表格SEQ表格\*ARABIC3Jni變量標(biāo)簽類型相應(yīng)的簽名BooleanZByteBCharCShortSIntILongLFloatFDoubleDVoidVObjectL用/分割包的完整類型名；Ljava/lang/stringArray[簽名[I[Ljava/lang/object;Method(參數(shù)1類型簽名參數(shù)2類型簽名…)返回值類型簽名服務(wù)器傳輸技術(shù)實(shí)現(xiàn)方法本系統(tǒng)的服務(wù)器部分并沒有多么大量的代碼，也只是簡(jiǎn)單的對(duì)socket套接字進(jìn)行運(yùn)用，對(duì)客戶端進(jìn)行監(jiān)聽，以及對(duì)數(shù)據(jù)進(jìn)行同步傳輸。在上一章已經(jīng)對(duì)此模塊的大體框架進(jìn)行了一個(gè)大致的描述。其中有幾個(gè)較為重要的實(shí)現(xiàn)方法，下面就對(duì)其進(jìn)行詳細(xì)的介紹?？蛻舳藬?shù)據(jù)監(jiān)聽使用Java進(jìn)行服務(wù)器編程，稍微要容易一些，畢竟很多東西都進(jìn)行了封裝。Java進(jìn)行客戶端的數(shù)據(jù)監(jiān)聽，主要是在服務(wù)器端新建一個(gè)serversocket套接字。進(jìn)行阻塞監(jiān)聽。Socket和serversocket類都是位于J包中，serversocket位于服務(wù)器端，socket是在客戶端和服務(wù)器端進(jìn)行連接時(shí)兩邊都會(huì)產(chǎn)生的一個(gè)實(shí)例。服務(wù)器或者客戶端都可以通過對(duì)這個(gè)socke實(shí)例進(jìn)行對(duì)這個(gè)網(wǎng)絡(luò)連接進(jìn)行操作。對(duì)于這個(gè)套接字而言，客戶端和服務(wù)器端都是平等的，沒有什么差別。不管是Socket或者ServerSocket它們的實(shí)現(xiàn)方式都是通過SocketImpl類及其子類完成的。服務(wù)器要實(shí)現(xiàn)監(jiān)聽，在新建serversocket套接字以后，要給它進(jìn)行實(shí)例化，其中要分配一個(gè)固定端口進(jìn)行監(jiān)聽。這里要注意不要使用一些常用的接口，這些接口很容易被占用，導(dǎo)致程序無法運(yùn)行。監(jiān)聽方法主要的是accept方法，當(dāng)調(diào)用此方法是，就會(huì)在這里產(chǎn)生阻塞，直到有一個(gè)客戶端進(jìn)行連接，返回一個(gè)實(shí)例化的socket套接字。因此在服務(wù)器進(jìn)行編程的時(shí)候，在產(chǎn)生一個(gè)實(shí)例化的socket套接字過后，應(yīng)新建一個(gè)進(jìn)程對(duì)這個(gè)套接字進(jìn)行處理，而主程序繼續(xù)監(jiān)聽后面即將到來的客戶端連接。由于大多數(shù)的服務(wù)器基本上都是不斷地監(jiān)聽或者處理數(shù)據(jù)，因此多線程的處理也顯得較為重要。數(shù)據(jù)傳輸和緩存處理這里的實(shí)現(xiàn)方法，就是.socket繼承與java.lang.object的幾個(gè)使用最頻繁的兩個(gè)函數(shù)，以及基本的多線程之間同步的實(shí)現(xiàn)方法。數(shù)據(jù)的獲取和傳輸使用的是getinputstream和getoutputstream方法，使用這兩個(gè)方法都會(huì)得到一個(gè)對(duì)應(yīng)的inputstream對(duì)象實(shí)例或者outputstream對(duì)象實(shí)例。這里使用的是getinputstream獲得PC端傳輸過來的視頻數(shù)據(jù)，這里需要強(qiáng)調(diào)的是，getinputstream函數(shù)是一個(gè)阻塞函數(shù)，當(dāng)沒有數(shù)據(jù)來臨時(shí)，它就會(huì)產(chǎn)生阻塞，一直等待數(shù)據(jù)來臨。這也是socket實(shí)現(xiàn)長(zhǎng)連接的一個(gè)重要特性。而getoutputstream并不是一個(gè)阻塞函數(shù)，當(dāng)輸出客戶端連接時(shí)，數(shù)據(jù)存在它就會(huì)將數(shù)據(jù)發(fā)送到客戶端。同樣這兩個(gè)函數(shù)也會(huì)產(chǎn)生一個(gè)ioexception，要必須對(duì)其進(jìn)行捕捉。兩個(gè)客戶端連接過后，都會(huì)新建兩個(gè)線程分別對(duì)其進(jìn)行控制，而這兩個(gè)線程都是要對(duì)同一個(gè)數(shù)據(jù)Buffer進(jìn)行操作，這就涉及到多線程對(duì)于同一資源的互斥訪問。本系統(tǒng)使用的是同步鎖synchronized。在使用同步鎖時(shí)，要加上對(duì)應(yīng)的訪問控制對(duì)象，否則不能實(shí)現(xiàn)你想要的同步控制方法。本系統(tǒng)在讀線程中由于getinputstream是阻塞函數(shù)，在這個(gè)函數(shù)后面進(jìn)行寫完成的等待，以防寫進(jìn)程還沒有完成，又進(jìn)行下一幀的讀取。當(dāng)然這樣也有可能造成掉幀的情況，不過在獲取數(shù)據(jù)的時(shí)候有40毫秒的延遲，一般還是足夠。在寫進(jìn)程的開始進(jìn)行等待，當(dāng)讀進(jìn)程讀取數(shù)據(jù)完成后，釋放寫進(jìn)程的等待。寫進(jìn)程開始工作，完成過后釋放度進(jìn)程的等待。這也是較為基本的同步實(shí)現(xiàn)方法，在此就不給流程圖了。移動(dòng)終端視頻處理技術(shù)實(shí)現(xiàn)方法數(shù)據(jù)接收和存儲(chǔ)數(shù)據(jù)的接受也相對(duì)比較簡(jiǎn)單，由于前面對(duì)socket套接字進(jìn)行過介紹，這里就描述一些客戶端的socket應(yīng)用。客戶端也要新建一個(gè)socket套接字，并對(duì)其進(jìn)行實(shí)例化，在實(shí)例化的時(shí)候，要和你對(duì)應(yīng)的服務(wù)器本地的IP地址和服務(wù)器監(jiān)聽的接口進(jìn)行對(duì)應(yīng)，否則會(huì)產(chǎn)生runtimeException的異常。在移動(dòng)終端客戶端也進(jìn)行了數(shù)據(jù)的本地存儲(chǔ)，在接受到服務(wù)器傳輸?shù)臄?shù)據(jù)后，傳輸?shù)綌?shù)據(jù)Buffer中，同時(shí)也輸出到本地文件夾中。但由于每次啟動(dòng)都會(huì)對(duì)新建一個(gè)文件夾，因此只能保持一次的視頻通訊數(shù)據(jù)。視頻數(shù)據(jù)傳輸?shù)絁ava層，再通過本地動(dòng)態(tài)庫的調(diào)用，在對(duì)應(yīng)的FFmpeg里面進(jìn)行解碼。其運(yùn)用的方式和上面的一致，也是通過Jni，在此不再贅述。視頻數(shù)據(jù)解碼這一模塊和上述PC端的視頻數(shù)據(jù)解碼的方式差距不大，也是使用的FFmpeg進(jìn)行的解碼，僅僅是運(yùn)行的平臺(tái)不一樣，但實(shí)現(xiàn)的方式幾乎一致。這里是通過接收到的buffer數(shù)據(jù)里的H264數(shù)據(jù)包使用avcodec_dencode_video2()函數(shù)進(jìn)行解碼，解碼后的數(shù)據(jù)傳送給顯示控件進(jìn)行顯示。這里需要說明一點(diǎn)，PC端的視頻顯示是基于SDL，而Android移動(dòng)終端上的視頻顯示是在Android對(duì)應(yīng)的surfaceView的控件上進(jìn)行顯示的。界面設(shè)計(jì)及視頻播放移動(dòng)終端的界面設(shè)計(jì)在此進(jìn)行了簡(jiǎn)化，處理一個(gè)連接使用的端口地址輸入框，就是一個(gè)視屏顯示窗口，以及對(duì)應(yīng)的信息顯示窗口。這里使用的不是傳統(tǒng)的mediaplayer，而是surfaceView，這個(gè)控件相對(duì)于前一個(gè)來說有更大的自主性。Mediaplayer控件的使用基本上都是前篇一律，沒有什么可以自己操控的空間，限制比較大。而surfaceView不同，surfaceView空間的使用是和SurfaceHolder配合進(jìn)行操作，可以實(shí)現(xiàn)自己想要的一些特殊的效果。Surfaceview意思就我們可以自己繪制的一塊view，當(dāng)然這只是我自己的一個(gè)見解，當(dāng)然就是們想要的什么畫面，通過內(nèi)存或者硬件將這塊圖形數(shù)據(jù)繪制到屏幕上，而這個(gè)surfaceview正好就是這個(gè)畫布。Surfaceview是對(duì)應(yīng)有內(nèi)存區(qū)域的，有內(nèi)存區(qū)域就自然有生命周期，可以動(dòng)態(tài)的申請(qǐng)和銷毀，也就有了我們對(duì)于surfaceview的一個(gè)基本操作：surfaceCreated/Changed/Destroyed，這三個(gè)操作加在一起就是callback函數(shù)，也就是回調(diào)函數(shù)。而每當(dāng)我們創(chuàng)建一個(gè)surfaceview的時(shí)候，都需要一個(gè)SurfaceHolder來進(jìn)行控制，可以調(diào)用getholder來得到這個(gè)holder。大多數(shù)使用surfaceview時(shí)都會(huì)創(chuàng)建兩個(gè)線程，一個(gè)是UI線程，一個(gè)是負(fù)責(zé)繪圖的線程。這個(gè)模型的好處就是畫圖線程不會(huì)依賴于UI線程，不會(huì)對(duì)UI線程進(jìn)行阻塞，而是單純的依賴UI繪圖線程，對(duì)于本系統(tǒng)這種實(shí)時(shí)更新數(shù)據(jù)來顯示的情況來說，這種方式更為合理，當(dāng)然由于本系統(tǒng)的UI界面本來就不復(fù)雜，也不太考慮阻塞的問題。下面是surfaceView實(shí)現(xiàn)視頻播放的一個(gè)結(jié)構(gòu)框架圖：圖SEQ圖\*ARABIC13surfaceview結(jié)構(gòu)框圖本章小結(jié)本章是全文的重點(diǎn)，對(duì)所有核心的技術(shù)進(jìn)行了一個(gè)較為全面的講解和說明。其中對(duì)SDL顯示進(jìn)行了大致的講解，對(duì)服務(wù)器的搭建和數(shù)據(jù)同步傳輸進(jìn)行簡(jiǎn)單的介紹，其重點(diǎn)還是對(duì)FFmpeg編解碼一塊進(jìn)行了深入的講解和解析。相對(duì)而言，在移動(dòng)終端的介紹上就沒有那么詳細(xì)，移動(dòng)終端的實(shí)現(xiàn)方式基本和PC端差距不大，存在的區(qū)別就是顯示方式，和FFmpeg的環(huán)境平臺(tái)搭建而已。特殊問題及解決方法這一章介紹了一些本系統(tǒng)在編寫中遇見的一些較為關(guān)鍵性的問題，解決的方法有些或許就是一些小小的設(shè)置問題，當(dāng)然還有些未完全解決的問題，在此列出，方便讀者遇到后好對(duì)應(yīng)嘗試、解決。動(dòng)態(tài)庫運(yùn)用問題動(dòng)態(tài)庫運(yùn)行問題，其一，當(dāng)你寫好程序，生成動(dòng)態(tài)庫后，Java程序無法調(diào)用，找不到對(duì)應(yīng)的動(dòng)態(tài)庫。解決方案：更改系統(tǒng)環(huán)境變量，將動(dòng)態(tài)庫的路徑添加到系統(tǒng)環(huán)境變量中，再重啟eclipse。其中注意，在你的Java程序在使用動(dòng)態(tài)庫的時(shí)候，其他的程序不能占用此動(dòng)態(tài)庫。問題二，你生成的不是有效的win32程序。 解決方案：一看這個(gè)問題你貌似就知道了是環(huán)境位數(shù)問題，但是這里的位數(shù)全部都要調(diào)成統(tǒng)一的，很有可能你就遺漏了一個(gè)小點(diǎn)。需要統(tǒng)一的環(huán)境有，系統(tǒng)環(huán)境，vs環(huán)境（即使是64位的電腦上，默認(rèn)的也是win32平臺(tái)），jdk環(huán)境，你引用的三方庫環(huán)境，eclipse環(huán)境。C與Java數(shù)據(jù)通信問題C與Java的通訊問題，主要是對(duì)Java和C的基本數(shù)據(jù)的理解，要正確理解對(duì)應(yīng)的數(shù)據(jù)，才能夠通過Jni正確的傳送參數(shù)。這里常常遇到的問題就是數(shù)據(jù)傳輸不正確。解決方法：更具上面給的數(shù)據(jù)對(duì)應(yīng)圖，以及Jni對(duì)應(yīng)的變量標(biāo)簽列表進(jìn)行函數(shù)調(diào)用和數(shù)據(jù)傳參，根據(jù)里面的數(shù)據(jù)對(duì)應(yīng)進(jìn)行相應(yīng)的數(shù)據(jù)傳輸。其次就是理解Java里面的類和對(duì)象關(guān)系，引用和域的意義。由于Java里面沒有指針，而C里面有，所以在使用時(shí)一定要弄清楚這些基本概念。數(shù)據(jù)傳輸同步問題這里主要對(duì)Java的幾種流式傳輸方式進(jìn)行一個(gè)簡(jiǎn)介，因?yàn)樵谙到y(tǒng)編寫過程中遇到的很多數(shù)據(jù)傳輸正確性的問題，和同步處理不當(dāng)?shù)膯栴}都與這有關(guān)。下面就對(duì)Java中主要的流式操作和相關(guān)的IO操作類進(jìn)行簡(jiǎn)介：File（文件特征和管理）：用于文件或目錄的描述信息?？梢赃M(jìn)行修改文件，增刪文件，判斷路徑等等操作。Inputstream（二進(jìn)制格式操作）：基于字節(jié)流的輸入操作，幾乎其他的輸入字節(jié)流操作都是繼承這個(gè)類，此抽象類定義了所有的輸入流具有的共同特征。Outputstream（二進(jìn)制格式操作）：基于字節(jié)流的輸出操作，幾乎其他的輸出字節(jié)流操作都是繼承這個(gè)類，此抽象類定義了所有的輸出流具有的共同特征。Reader（文件格式操作）：基于字符的輸入操作，是個(gè)抽象類。Writer（文件格式操作）：基于字符的輸出操作，是個(gè)抽象類。RandomAccessFile（隨機(jī)文件操作）：可以對(duì)文件進(jìn)行任意位置的隨機(jī)存儲(chǔ)操作，功能豐富。以下就關(guān)于這幾個(gè)主要IO操作的一個(gè)關(guān)系圖：圖SEQ圖\*ARABIC14IO操作類關(guān)系圖編碼幀頻和參數(shù)設(shè)置問題編碼幀頻問題是一個(gè)很復(fù)雜的問題，雖然說使用采集的定時(shí)延遲可以大致控制視頻幀頻數(shù)，在進(jìn)行轉(zhuǎn)碼的時(shí)候，根據(jù)你采集時(shí)的延遲給定固定幀頻。不僅如此，在進(jìn)行編碼的時(shí)候還許多參數(shù)進(jìn)行設(shè)置這里包含了幾乎你編碼想要使用的所有參數(shù)方式。下圖就是一些有關(guān)編解碼時(shí)AVCodecContext結(jié)構(gòu)體中一些常見參數(shù)的含義：表格SEQ表格\*ARABIC4編解碼AVCodecContext參數(shù)變量含義enumAVMediaTypecodec_type編解碼器的類型structAVCodec*codec采用的解碼器AVCodecintbit_rate平均比特率，就是碼率uint8_t*extradata針對(duì)特定編碼器包含的附加信息intextradata_size針對(duì)特定編碼器包含的附加信息AVRationaltime_base可以把PTS轉(zhuǎn)化成實(shí)際的時(shí)間（秒）intwidth,height視頻數(shù)據(jù)，代表寬高Intrefs運(yùn)動(dòng)估計(jì)參考幀的個(gè)數(shù)intsample_rate采樣率（針對(duì)音頻）intchannels聲道數(shù)（針對(duì)音頻）enumAVSampleFormatsample_fmt采樣格式intprofile型intlevel級(jí)（和profile有些相似）本章小結(jié)本章主要是針對(duì)一些較為常見的問題，或者說筆者認(rèn)為有必要提出的較為重要的一些問題進(jìn)行了一些講解，當(dāng)然沒有說出具體的方法，只是給了一些解決的參考資