【正文】 進(jìn)行阻塞監(jiān)聽。 客戶端數(shù)據(jù)監(jiān)聽 使用 Java 進(jìn)行服務(wù)器編程，稍微要容易一些，畢竟很多東西都進(jìn)行了封裝。 在上一章已經(jīng)對此模塊的大體框架進(jìn)行了一個(gè)大致的描述。 下面是所有 Jni 中的變量標(biāo)簽： 表格 3 Jni變量標(biāo)簽 類型 相應(yīng)的簽名 Boolean Z Byte B Char C Short S Int I Long L Float F Double D Void V Object L 用 /分割包的完整類型名； Ljava/lang/string Array [簽名 [I [Ljava/lang/object。 其具體的數(shù)據(jù)傳輸方式如下結(jié)構(gòu)圖所示： 第 21 頁 共 39 頁 數(shù) 據(jù) B u f f e r 初 始 化B u f f e r F u l l 初 始 化開 始J n i 調(diào) 用 本 地 視 頻獲 取 代 碼連 接 服 務(wù) 器填 充 數(shù) 據(jù) B u f f e r 緩 存B u f f e r F u l l 標(biāo) 志 位標(biāo) 志 位 的 值將 標(biāo) 志 位 置 為 T u r e讀 取 B u f f e r 緩 存 數(shù)據(jù)將 標(biāo) 志 位 置 為F a l s e獲 取 視 頻 數(shù) 據(jù)T r u e數(shù) 據(jù) B u f f e rF a l s e 圖 11視頻數(shù)據(jù)傳輸結(jié)構(gòu)圖 在數(shù)據(jù)從 C 語言層里面獲取的時(shí)候，傳輸?shù)?Java 層，這里也有相應(yīng)的數(shù)據(jù)對應(yīng)關(guān)系，畢竟這兩個(gè)語言所用的基本數(shù)據(jù)單位還是 有一定的差別。當(dāng)然是用 Jni 的時(shí)候，也有其相應(yīng)的缺點(diǎn)：因?yàn)橐褂?Native 模塊的代碼，因此 Java 會失去原來的跨平臺性 和其安全性等等的特性。也正是通過這種方式，彌補(bǔ)了一些時(shí)候 Java 開發(fā)中一些缺陷。實(shí)際上， Jni 是 JVM中實(shí)現(xiàn)的一個(gè)部分，由此 native語言 (C/C++)都對應(yīng)的運(yùn)行在 JVM 宿主環(huán)境中（ Host Environment）。本系統(tǒng)由于服務(wù)器選用的是 Java，加上客戶端也是基于 Java 的 Android 平臺，因此選用的方式就是在 Java 層進(jìn)行 Buffer 緩存的實(shí)例化，將其引用傳入 C 語言層，再將其填充，填充完成過后，再由另外一個(gè)線程將其傳輸?shù)椒?wù)器。 18. av_write_trailer()：寫文件尾，同樣，有些封裝格式不需要寫文件尾，根據(jù)不同的編碼方式來定。 17. flush_encoder()：要在 YUV 像素?cái)?shù)據(jù)讀取完畢過后調(diào)用此函數(shù)，用于輸出編碼器中剩余的 AVPacket。 15. avcodec_encode_video2()：真正編碼一幀視頻，將存儲的 YUV 數(shù)據(jù)編碼為對應(yīng)的 的 AVPacket。 第 20 頁 共 39 頁 13. avcodec_open2()：打開對應(yīng)的編碼器。 11. av_new_stream()：新建 AVStream 的輸出碼流。 9. avformat_alloc_output_context2() ： 初 始 化 輸 出 流 碼 的AVFormatContext，這個(gè)函數(shù) 也就可以更加自動的選擇編碼方式， 可以根據(jù)你的輸出文件后綴名進(jìn)行判斷編碼方式。 下面就是對 YUV 數(shù)據(jù)轉(zhuǎn)化成 格式數(shù)據(jù)的一個(gè)流程圖： 第 19 頁 共 39 頁 A v f o r m a t _ a l l o c _ o u t p u t _ c o n t e x t 2 ( )A v _ r e g i s t e r _ a l l ( )A v i o _ o p e n 2 ( )A v _ n e w _ s t r e a m ( )A v c o d e c _ f i n d _ e n c o d e r ( )A v c o n d e c _ o p e n 2 ( )A v f o r m a t _ w r i t e _ h e a d e r ( )F l u s h _ e n c o d e r ( )A v _ w r i t e _ t r a i l e r ( )C l o s eA V F r a m eA v c o d e c _ e n c o d e _ v i d e o 2 ( )A V P a c k e tA v _ w r i t e _ f r a m e ( )R e a d D a t aF a l s eT r u e 圖 10視頻編碼路程圖 其中綠色的部分是實(shí)際上輸出數(shù)據(jù)的函數(shù)，藍(lán)色部分才是真正意義上的視頻編碼函數(shù)。 I 幀包含完整的圖像數(shù)據(jù)，直接解碼 I 幀就可以有完整的圖像數(shù)據(jù)，而 P 幀是表示的這一幀和之前的 I 幀或者是 P 幀之間的差別，解碼時(shí)就要實(shí)現(xiàn)緩存之前的幀，再加上本幀定義的差別，才能夠生成最后的畫面。在H264 中定義的三種幀，分別是 I 幀、 P 幀、 B 幀。其主要是實(shí)現(xiàn)方式就是通過參考，在有一個(gè)完整幀的情況下，后面的相鄰幀圖像差距一般只有不到 10%的差距，而 H264 的編碼就是依靠一個(gè)完整的幀，后面相鄰的幀對前面完整的幀進(jìn)行參考，如果差距不大，就只需要進(jìn)行變化部分的參考即可，要是變化較大，那么久從新生成一個(gè)新的參考幀。 這是對一個(gè) H264 碼流的結(jié)構(gòu)進(jìn)行的分析，下面就是對其編碼方式進(jìn)行分析。而如果要進(jìn)行 第 18 頁 共 39 頁 碼流的解析，就要首先從碼流中找到這些起始碼，分離出單個(gè)的 NALU，然后再對單個(gè)的 NALU 單元進(jìn)行分析。其中每個(gè)NALU 之間通過 startcode（起始碼）進(jìn)行分割。 碼流，是將對應(yīng)的 YUV 像素?cái)?shù)據(jù)格式進(jìn)行壓縮過后得到的數(shù)據(jù) 。具體情況在此就不詳述了。其中 YUV表示的是三個(gè)分量， Y表示的是亮度，也就是灰度值；而 U 和 V 表示的是色度，主要功能是描述影像的色彩和飽和度，用來指定像素的顏色。其中包括YUV420P、 YUV422P 和 YUV444P。因此，本系統(tǒng)采用的是使用范圍較為廣泛的 的壓縮編碼方案，將得到的 YUV 數(shù)據(jù)轉(zhuǎn)換成對應(yīng)的 格式，現(xiàn)在就 YUV 數(shù)據(jù)流和 的碼流進(jìn)行一個(gè)簡單的介紹。如果要加入音頻壓縮處理時(shí)，往往還需要進(jìn)行封裝，進(jìn)行音視頻同步方面的問題。不同的編碼格式有不同的優(yōu)缺點(diǎn)，也有不同的應(yīng)用場景和范圍。這種情況在進(jìn)行窗口移動的過程中，視頻會暫停，就會出現(xiàn)這種情況，但當(dāng)移動結(jié)束后又能正常播放。 關(guān)于第二點(diǎn)，在視頻播放不流暢的時(shí)候，會彈出 buffer full 的提示，并且將當(dāng)時(shí)的幀進(jìn)行舍棄。而主線程進(jìn)行消息緩存的等待 ， 獲取到對應(yīng)的緩存消息，介紹等待。關(guān)于第一點(diǎn)，本系統(tǒng)使用的是消息緩存機(jī)制。 下面就是針對這一幀幀的數(shù)據(jù)SDL 進(jìn)行播放的流程圖： 圖 8SDL視頻播放流程圖 關(guān)于 SDL 播放問題，這里主要關(guān)注的是兩個(gè)點(diǎn)：第一，在播放是窗口是否可拖動，或者其他操作。 圖像的縮放函數(shù)并沒有改變原函數(shù)的長寬，僅僅是改變了數(shù)據(jù)格式，從 rawdata 變?yōu)榱?YUV。 7. sws_scale()：對 AVFrame 里的一幀圖片進(jìn)行縮放處理。 5. av_read_frame()：讀取一幀的數(shù)據(jù)到對應(yīng)的 packet。 3. avcodec_find_encoder()：查找對應(yīng)的編碼器。 這里對部分函數(shù)進(jìn)行說明： 1. Av_register_all()：對所有的 FFmpeg 編解碼器進(jìn)行注冊。這里就分別進(jìn)行視頻數(shù)據(jù)獲取和視頻數(shù)據(jù)顯示的詳細(xì)介紹。 以上就是針對攝像頭監(jiān)測和啟動以及 FFmpeg的一些平臺搭建的類容，都是只寫出了核心的內(nèi)容，若要實(shí)踐還需要多多參考其他資源。 8. 加載對應(yīng)的 so 動態(tài)庫。 6. 創(chuàng)建對應(yīng)的頭文件，編寫對應(yīng)的 文件。 3. 編寫和修改 configure 文件，和編寫 腳本文件，準(zhǔn)備進(jìn)行編譯（如果平臺是 win 平臺，還要進(jìn)行其他文件的修改）。 由于后面 Android也需要 FFmpeg移植，搭建基于 Android的 FFmpeg平臺，下面就根據(jù) Android 平臺說明一下搭建步驟： 1. 下載對應(yīng)的 FFmpeg 源代碼。 3. 將所需要的 dll 文件拷貝到你所見工程當(dāng)中。 下面只搭建平臺的步驟： 1. 官網(wǎng)上下載對應(yīng) FFmpeg 在 win 平臺下編譯的包，根據(jù)你系統(tǒng)的平臺來選擇。 3. 使用一些軟件來實(shí)現(xiàn)這個(gè)功能，比如 DirectShow 的調(diào)試工具GraphEdit。而后使用 avformat_open_input 函數(shù)就能打開對應(yīng)攝像頭，獲取到里面對應(yīng)的視頻流數(shù)據(jù)。而本系統(tǒng)進(jìn)行檢測是基于DirectShow 的攝像頭，因此采用了 FFmpeg自帶的攝像頭驅(qū)動方式來對攝像頭進(jìn)行驅(qū)動。 本系統(tǒng)基于的 PC 平臺是 win7 的平臺， win平臺使用的攝像頭驅(qū)動有老版本的 vfw（ video for Windows）對應(yīng)的封裝庫（這個(gè)基本已經(jīng)不用了）。 攝像頭 驅(qū)動及 FFmpeg 平臺搭建 視頻攝像頭視頻獲取 ，主要是針對 攝像頭的啟動，和運(yùn)行進(jìn)行說明。 3 系統(tǒng)詳細(xì)設(shè)計(jì) 視頻采集技術(shù)實(shí)現(xiàn)方法 這里介紹的是 PC 端視頻采集技術(shù)的具體實(shí)現(xiàn)方法，以及對應(yīng)的 FFmpeg 進(jìn)行編解碼的具體實(shí)現(xiàn)方式。 對于本系統(tǒng)的數(shù)據(jù)傳輸質(zhì)量、速度方面進(jìn)行了簡單的介紹，也分析了本系統(tǒng)影響視頻播放的各個(gè)方面做了一些簡介。 Socket 套接字是基于 TCP 的通訊協(xié)議，在 Java 中寫的，對于底層的具體通訊方式?jīng)]有進(jìn)行詳細(xì)的了解，后面會對其具體詳情進(jìn)行介紹。 4. 建立連接過后，建立一個(gè)實(shí)例化的 socket 套接字。 2. 使用 accept 函數(shù)進(jìn)行客戶端的監(jiān)聽。 Socket 套接字使用相對比較簡單，要很好 的控制和利用也要好好學(xué)習(xí)。 5. 使用 SDL_UpdateYUVTexture 更新紋理，顯示一幀的視頻數(shù)據(jù)。 第 13 頁 共 39 頁 3. SDL_CreateWindow 函數(shù)創(chuàng)建對應(yīng)的視頻播放窗口。主要包括以下幾步： 1. 監(jiān)測攝像頭驅(qū)動信息。在后面的詳解中 會詳細(xì)說明。 5. 配置對應(yīng)的環(huán)境變量，使 Java 能夠?qū)雽?yīng)的動態(tài)鏈接庫。 3. 使用 C/C++實(shí)現(xiàn)與之對應(yīng)的本地方法。其中大致實(shí)現(xiàn)步驟如下： 1. 編寫 Java 類，帶有 native 的聲明方法。 FFmpeg 的視頻編解碼的庫都主要集中于 libavcodec 對應(yīng)的文件夾下 ，其中包含了大部分對于音視頻的編解碼函數(shù)。輸入一個(gè)壓縮編碼的結(jié)構(gòu)體 AVPacket。 3. avcodec_open2 初始化音視頻編解碼器，再使用 av_read_frame 讀取幀頻數(shù)據(jù) 。 下面是大致的一個(gè)編解碼步驟： 1. 其中數(shù)據(jù)獲取是先使用 av_register_all()進(jìn)行初始化（這個(gè)函數(shù)是所有模塊初始化，也可以用對應(yīng)模塊的函數(shù)進(jìn)行初始化） 。 FFmpeg 編解碼，這個(gè)三方庫是本系統(tǒng)的核心。 系統(tǒng)重點(diǎn)技術(shù)簡介 本節(jié)主要是針對本系統(tǒng)的重點(diǎn)一些技術(shù)進(jìn)行簡介。其中在傳輸?shù)臅r(shí)候， Java 函數(shù)的選擇也是很重要的，本系統(tǒng)采用的是 inputoustream和 outputstream對應(yīng)的字節(jié)流輸入輸出函 數(shù)來保證數(shù)據(jù)傳輸?shù)恼_性。要不就會出現(xiàn)編碼過后與原來的幀頻不能有效的對應(yīng)，使得播放過快或者過慢。由于視頻采集的時(shí)候，得到的是 YUV 數(shù)據(jù)，要轉(zhuǎn)碼成為 H264 編碼的格式，進(jìn)行壓縮方便傳輸和播放。 在第三章中會對 H264 的編碼結(jié)構(gòu)和其中的 I， P 幀進(jìn)行詳解。 由于從視頻獲取、解碼、編碼、傳輸、數(shù)據(jù)獲取、解碼播放都是一個(gè)線性操作， 加上網(wǎng)絡(luò)的傳輸不穩(wěn)定因素。因此只能采用 H264的壓縮方式來進(jìn)行壓 縮，一般的 H264 的壓縮比在 100:1 左右，折算下來每秒鐘傳輸?shù)臄?shù)據(jù)為 100kb 左右，這樣的數(shù)據(jù)量在一般的網(wǎng)絡(luò)寬帶都能夠有效的支持。每幀的數(shù)據(jù)在沒有壓縮的時(shí)候是 460800個(gè)字節(jié)，也就是 450kb。 系統(tǒng)性能 需求 系統(tǒng)性能需求主要集中的方面是數(shù)據(jù)傳輸?shù)乃俣?，和視頻播放的效果。 在移動終端數(shù)據(jù)接收時(shí)，新建一個(gè)線程進(jìn)行服務(wù)器連接，獲取視頻數(shù)據(jù)Buffer，當(dāng)數(shù)據(jù)緩沖完成過后 ，傳輸?shù)?FFmpeg 對應(yīng)的動態(tài)庫中進(jìn)行解碼，由相應(yīng)的視頻控件來進(jìn)行播放。當(dāng) PC端數(shù)據(jù)傳輸?shù)椒?wù)器后，存儲到建立的數(shù)據(jù) Buffer 中，解除寫進(jìn)程等待，讓讀進(jìn)程進(jìn)行等待。以此來通知 Java 代碼里的數(shù)據(jù)傳輸線程，可以讀取數(shù)據(jù) Buffer 里的數(shù)據(jù)來進(jìn)行傳輸。 數(shù)據(jù)獲取階段， Buffer 的創(chuàng)建是在 Java 代碼里面完成的，通過 Jni 的調(diào)用，將其對象的引用傳輸?shù)?C 代碼里，用于存儲從攝像頭你獲取的視頻數(shù)據(jù)。 在此分別給出三個(gè)大模塊對應(yīng)的結(jié)構(gòu)框架圖： 第 9 頁 共 39 頁 顯 示 器P C 主 機(jī)獲 取 b u f f e r 數(shù) 據(jù)傳 輸 到 服 務(wù) 器與 服 務(wù) 器 建 立 連接服 務(wù) 器監(jiān) 測 攝 像 頭型 號 ， 啟 動攝 像 頭數(shù) 據(jù) B u f f e r獲 取 視 頻 數(shù) 據(jù)進(jìn) 行 編 碼 緩 存對 于 視 頻 數(shù)據(jù) 進(jìn) 行 播 放線 程 二線 程 一 圖 3 PC端結(jié)構(gòu)框架圖 啟 動 服 務(wù) 器并 初 始 化P C 端移 動 終 端等 待