【正文】 要基于 平臺以上，能夠正常工作的手機(jī)。 系統(tǒng)功能模塊 本系統(tǒng)的功能需求，是實(shí)現(xiàn)在 PC 端的數(shù)據(jù)采集和數(shù)據(jù)編解碼 ，并且在客戶端進(jìn)行顯示。在移動終端接收到數(shù)據(jù)過后進(jìn)行解碼，而后由手機(jī)端進(jìn)行同步播放。 從數(shù)據(jù)的獲取到數(shù)據(jù)最終的播放，都盡量做到數(shù)據(jù)的正確和同步。如 果存儲完成，則對標(biāo)志位置位。 在數(shù)據(jù)傳輸階段，在服務(wù)器與 PC 客戶端以及移動終端的客戶端建立連接完成以后， 服務(wù)器讀線程監(jiān)聽 PC 端傳輸過來的數(shù)據(jù)，并且讓寫進(jìn)程等待。此時(shí)寫進(jìn)程開始講數(shù)據(jù) Buffer 中的數(shù)據(jù)寫入到移動終端，完成后解除讀進(jìn)程等待。同樣，在數(shù)據(jù) Buffer 不同的讀寫操作時(shí)，要保證進(jìn)程間的互斥 。 第 11 頁 共 39 頁 在數(shù)據(jù)傳輸方面， 由于在采集的時(shí)候采用的是延遲 40 毫秒采集一次視頻數(shù)據(jù)，也就是得到的視頻數(shù)據(jù)為 25 幀頻。若不進(jìn)行壓縮就傳輸數(shù)據(jù)，那么一秒鐘傳輸?shù)臄?shù)據(jù)在10M左右，一般的帶寬都無法承受這樣的數(shù)據(jù)量。 而在這40 秒獲取到數(shù)據(jù)時(shí)，要同步傳輸?shù)綄?yīng)的手機(jī)端并且能夠播放出來，其中包括視頻數(shù)據(jù)解碼，傳輸，在服務(wù)器中進(jìn)行讀取各個(gè)方面的操作。 因此 要保證在通訊連接建立過后不掉幀的難度很大， 但是在范圍程度內(nèi)的掉幀不影響播放效果是可以接受的。 視頻播放效果質(zhì)量主要是在數(shù)據(jù)編碼和數(shù)據(jù)傳輸?shù)恼_性方面。但是在編碼時(shí)，要注意時(shí)間的控制，以及編碼方式的控制。同樣，視頻播放的速度也取決于數(shù)據(jù)傳輸?shù)乃俣?，?shù)據(jù)傳輸?shù)乃俣炔荒苡行M足 ，實(shí)時(shí)播放的效果也就不能實(shí)現(xiàn)。 傳輸?shù)耐娇刂坪侠硪彩潜ＷC數(shù)據(jù)傳輸正確性的一個(gè)重要方面。其中主要涉及的重點(diǎn)技術(shù)有 FFmpeg 編解碼， Jni 運(yùn)用， SDL 視頻播放， socket 套接字使用。使用它來完成了數(shù)據(jù)的獲取，視頻數(shù)據(jù)的編碼壓縮這些核心功能。 2. 使用 avformat_find_stream_info 函數(shù)獲取對應(yīng)流媒體的各個(gè)方面的信息（具體會在下面詳解） 。 4. 并用 avcodec_decode_video2()解碼一幀視頻數(shù)據(jù)。 第 12 頁 共 39 頁 5. avcodec_decode_video2 函數(shù)返回成功后， 我們就可以通過這個(gè) AVPacket結(jié)構(gòu)體獲取對應(yīng)的視頻數(shù)據(jù)了。 下面是就基本的 FFmpeg編解碼的流程圖： 圖 6音視頻編解碼流程圖 Jni 其實(shí)就是一個(gè)橋梁，連接 Java 和 C 其中主要的就是一個(gè)動態(tài)庫的生成，對應(yīng)函數(shù)的編寫格式，和傳參方式。 2. 使用 Javah 命令生成對應(yīng)的類的頭文件。 4. 使用 vs2021 將你的 C/C++文件編譯生成對應(yīng)的動態(tài)鏈接庫。 在這些方法實(shí)現(xiàn)的過程中，要使用到對應(yīng)的參數(shù) 調(diào)用，和函數(shù)回調(diào)。 SDL 在本系統(tǒng)的主要作用是對系統(tǒng)攝像頭的驅(qū)動監(jiān)測，和攝像頭啟動。 2. 使用對應(yīng)的攝像頭驅(qū)動啟動攝像頭。 4. 使用 SDL_Texture 函數(shù)存儲一幀的像素?cái)?shù)據(jù)。 這里介紹的也是 SDL 使用的大致的幾個(gè)常用和關(guān)鍵的幾個(gè)函數(shù)和步驟，后面還會對其進(jìn)行詳細(xì)的介紹。本系統(tǒng)中的服務(wù)器中的主要步驟如下： 1. 服務(wù)器申請端口，創(chuàng)建 serversocket 對象。 3. 客戶端使用 socket 套接字進(jìn)行連接。 5. 使用 socket 類中的 inputstream 和 outputstream 進(jìn)行字節(jié)流的傳輸。 本章小結(jié) 本章對于本系統(tǒng)的大致框架結(jié)構(gòu)，每一 部分的框架結(jié)構(gòu)有了一個(gè)大致的了解，對應(yīng)其相關(guān)的技術(shù)以及其中重點(diǎn)或者關(guān)鍵的部分也有相關(guān)的提及。 本章的目的只是讓讀者了解本系統(tǒng)的大致結(jié)構(gòu)，其中具體的實(shí)現(xiàn)方法以及細(xì)節(jié)，會在下一章節(jié)進(jìn)行說明。這也是本系統(tǒng)的核心重點(diǎn)所在。由于視頻獲取和后面的視頻顯示是在一起的，就放在下面講解。也有現(xiàn)在使用較為廣泛的是基于 DirectShow 來驅(qū)動攝像頭的。 主要的函數(shù)是 av_find_input_format 獲取系統(tǒng)攝像頭設(shè)備，其中參數(shù)是對應(yīng)你攝像頭 的驅(qū)動類型。但是此函數(shù)里的參數(shù)需要你事先獲得你 第 14 頁 共 39 頁 攝像頭使用的設(shè)備驅(qū)動名稱，這里獲取攝像頭驅(qū)動信息的方式有一下幾種： 1. 使用 FFmpeg 自帶的命令進(jìn)行查看，查看攝像頭設(shè)備信息的命令為：ffmpeg list_devices true f dshow i dummy 2. 使用代碼在控制臺打印出對應(yīng)的 設(shè)備信息主要使用函數(shù) av_dict_set。 這里使用到的 FFmpeg 函數(shù)并不多，但是需要事先在 win7 平臺下基于vs2021 進(jìn)行 FFmpeg 的平臺搭建， 就在此 進(jìn)行介紹。 2. 在 vs 中新建控制臺工程，并設(shè)置動態(tài)鏈接庫路徑（也可以使用代碼來實(shí)現(xiàn)動態(tài)庫的連接）。 4. 編寫一個(gè)測試代碼進(jìn)行測試，成功就完成了。 2. 建立編譯平臺，一般在 Linux 下編譯，如果你用的是 win 平臺，可以使用模擬 Linux 平臺的軟件，如 Cygwin。 4. 創(chuàng)建普通的 Android 工程，將編譯出來的 so 動態(tài)庫加入對應(yīng)的 Jni 文件夾 5. 創(chuàng)建對應(yīng)的含有 native 本地調(diào)用程序的類。 7. 運(yùn)行 文件，編譯生成對應(yīng)的 so 文件。 9. 進(jìn)行基本測試，成功完成。 PC 端獲取視頻 解碼 顯示 視頻的獲取工作，主要是由 FFmpeg 完成，而 PC 端的視頻數(shù)據(jù)顯示基本由SDL 完成。 下面是對應(yīng)的視頻獲取解碼的路程圖： 第 15 頁 共 39 頁 S t a r tA v _ r e g i s t e r _ a l l ( )A v _ f i n d _ s t r e a m _ i n f o ( )A v f o r m a t _ o p e n _ i n p u t ()A v c o d e c _ f i n d _ d e c o d e r ( )A v c o d e c _ o p e n 2 ( )A v _ r e a d _ f r a m e ( )G e t P a c k e t ?E n dA v d o d e c _ d e c od e _ v i d e o 2 ( )V i d e o P a c k e t ?T r u e T r u eF a l s eF a l s eS w s _ s c a l e 圖 7視頻解碼 這里需要說明的是，視頻的獲取中也包含了視頻解碼的過程，從攝像頭中獲取的視頻數(shù)據(jù)通過解碼成一幀幀的 YUV數(shù)據(jù)，傳遞給 SDL來進(jìn)行播放。 2. Av_find_stream_info()：新建 AVStream 的輸入碼流，這里是對應(yīng)的攝像頭輸入碼流。 4. avcodec_open2()：打開對應(yīng)的編碼器 。 6. avcodec_dencode_video2()：真正解碼 碼一幀視頻， 將對應(yīng)的 packet 里的數(shù)據(jù)解碼到 AVFrame 里。 這里最耗時(shí)的兩個(gè)函數(shù)是 avcodec_dencode_video2()和 sws_scale()， 由于獲取的視頻數(shù)據(jù)格式是 rawdata 數(shù)據(jù) ，在進(jìn)行解碼和圖像縮放的時(shí)候，在 PC 端的耗時(shí)并不長，兩個(gè)函數(shù)加起來在 3ms 左右，對于這里采集視頻使用的是 25 幀，即 第 16 頁 共 39 頁 40ms 采集一幀，在此的影響不大。 其中黃色的內(nèi)容是 新增加的內(nèi)容。第二，視頻播放的流暢度，如果不流暢如何處理。即新建一個(gè)線程，對窗口的操作進(jìn)行消息緩存，并且進(jìn)行 40ms 的延時(shí)來控制視頻幀數(shù)。這樣處理就能夠有一個(gè)線程處理窗口操作消息，不會使窗口一直處于忙碌狀態(tài)，而且還能夠更加準(zhǔn)確的控制幀數(shù)。以保證視頻能夠正常播放。 第 17 頁 共 39 頁 下面是 PC 端視頻獲取顯示的運(yùn)行截圖： 圖 9PC端運(yùn)行截圖 視頻編碼存儲 視頻編碼的主要目的是對占用空間很大的視頻數(shù)據(jù)進(jìn)行 壓縮，使其方便傳輸。下面就是視頻編碼中主要的編碼方案： 表格 1主要視頻編碼方案 名稱 推出機(jī)構(gòu) 推出時(shí)間 目前使用領(lǐng)域 HEVC() MPEG/IUTT 2021 推廣中 MPEG/IUTT 2021 各個(gè)領(lǐng)域 MPEG4 MPEG 2021 不溫不火 MPEG2 MPEG 1994 數(shù)字電視 VP9 Google 2021 研發(fā)中 VP8 Google 2021 不普及 CV1 Microsoft Inc. 2021 微軟平臺 由于本系統(tǒng)并不需要進(jìn)行音頻壓縮處理，所有在進(jìn)行編碼的時(shí)候，僅僅做了視頻編碼處理。在本系統(tǒng)中并沒有必要加入這些。 YUV 數(shù)據(jù)是指視頻像素?cái)?shù)據(jù)，是最為基本的視頻數(shù)據(jù)。當(dāng)然基本的非壓縮像素?cái)?shù)據(jù)也有 RGB 格式類型，在本系統(tǒng)中使用的是 YUV420P的格式。 YUV 的存儲格式和采樣方式密切相關(guān)，其中后面的 420P、 422P 和 444P 代表的就是三種不同的采樣方式。我想重點(diǎn)強(qiáng)調(diào)的就是通過不同的采樣方式，會有不同的格式，只有通過對應(yīng)的采樣格式從數(shù)據(jù)碼流中提取像素點(diǎn)的 YUV 值，才能夠 正確的轉(zhuǎn)換成 RGB 像素點(diǎn)的值，然后顯示出 來。 原始碼流，又稱為“裸流”，是由一個(gè)一個(gè)的 NALU 組成的。其中起始碼的類型必須是“ 0X00000001”或者“ 0X000001”這兩種類型其中的一種。當(dāng)然我們在進(jìn)行編碼的時(shí)候，并不需要對其了解太多，因?yàn)?FFmpeg 已經(jīng)有對應(yīng)的函數(shù)可以實(shí)現(xiàn)這些壓 縮解壓的過程了。 H264 是以高質(zhì)量高壓縮和支持多種網(wǎng)絡(luò)流媒體協(xié)議而聞名的。從而大大降低了數(shù)據(jù)量。其中 I 幀是完整的編碼幀， P幀是參 考之前的 I 幀生成的差異幀， B 幀是參考前后編碼的幀。而 B 幀對應(yīng)的是前后幀與本幀之間的差別，在進(jìn)行 B 幀解碼時(shí)，不僅先要取得前面一幀的緩存畫面，而且還要取得后面一幀的緩存畫面，通過前后兩幀和本幀的差別疊加過后取得最終的畫面，由于 B 幀需求的條件和比較多，而且壓縮率高，在解碼的時(shí)候 CPU 的耗時(shí)會很多，這也是 B 幀和 H264 編解碼速度之間 的關(guān)系。下面就將上面所有的函數(shù)進(jìn)行相應(yīng)的解釋說明： 8. Av_register_all()：對所有的 FFmpeg 編解碼器進(jìn)行注冊。 10. avio_open()：打開對應(yīng)輸出文件，雖然本系統(tǒng)緩存在 Buffer 中，不過也向文件中進(jìn)行本地存儲寫入。 12. avcodec_find_encoder()：查找對應(yīng)的編碼器。 14. avformat_write_header()：寫文件頭，但對于一些沒有頭文件封裝格式的編碼方式來說，并不需要這個(gè)函數(shù)。 16. av_write_frame()：將編碼好的流視頻寫入對應(yīng)的文件，而本系統(tǒng)還需要把對應(yīng)的 的數(shù)據(jù)同時(shí)緩存到數(shù)據(jù) Buffer 中。這個(gè)函數(shù)是自己編寫的，具體看源碼。 視頻緩存?zhèn)?輸 數(shù)據(jù)緩存?zhèn)鬏數(shù)姆椒?，基本是基?Jni 的一個(gè)傳參和調(diào)用方法。 這里對 Jni 的機(jī)制進(jìn)行簡單講解， Jni(Java Native Interface)其主要功能是 進(jìn)行 Java 和 C/C++進(jìn)行通訊。也是這種方式 加上 Jni 是一個(gè)雙向接口 ， 使得開發(fā)者不僅可以在 Java 中通過 Jni 訪問Native 代碼，也可以在 Native 中嵌入一個(gè)對應(yīng)的 JVM 實(shí)現(xiàn)在 Native 代碼中對Java 代碼的訪問 。例如你希望你提高默寫關(guān)鍵的模塊代碼的效率的時(shí)候，你就可以通過C/C++等 Native 語言來進(jìn)行相關(guān)程序庫的開發(fā)。除此之外， Jni 的應(yīng)用中， Native 代碼和 Java 代碼都是運(yùn)行在同一宿主的進(jìn)程空間內(nèi)，如果是跨進(jìn)程或者是宿主機(jī)之間的通訊，就只能考慮采用 socket、 IPC 或者是 Web Service 等通訊機(jī)制來進(jìn)行實(shí)現(xiàn)。下面就對C 和 Java 的基本數(shù)據(jù)對應(yīng)列出了大致的表格： 表格 2 Java和 C 的數(shù)據(jù)對應(yīng)表 JAVA 類型 本地類型（ JNI） 本地類型（ C） 描述 Boolean Jboolean Unsigned char 無符號 8 個(gè)字節(jié) Byte Jbyte Signed char 有符號 8 個(gè)字節(jié) Char Jchar Unsigned short 無符號 16 個(gè)字節(jié) Short Jshort Short 有符號 16 個(gè)字節(jié) Int Jint Long 有符號 32 個(gè)字節(jié) Long Jlong _int64 有符號 64 個(gè)字節(jié) Float Jfloat Float 32 個(gè)字節(jié) Double Jdouble Double 64 個(gè)字節(jié) Object Jobject _jobject 自定義結(jié)構(gòu) Void Void Void N/A 第 22 頁 共 39 頁 在 JNI 的調(diào)用時(shí)，往往還會使用到 Jni 的簽名，其實(shí)就是對應(yīng)的數(shù)據(jù)類型，通常在函數(shù)調(diào)用的時(shí)候會用到。 Method (參數(shù) 1 類型簽名 參數(shù) 2 類型簽名 … )返回值類型簽名 服務(wù)器傳輸技術(shù)實(shí)現(xiàn)方法 本系統(tǒng)的服務(wù)器部分并沒有多么大量的代碼，也只是簡單的對 socket 套接字進(jìn)行運(yùn)用，對客戶端進(jìn)行監(jiān)聽，以及對數(shù)據(jù)進(jìn)行 同步傳輸。 其中有幾個(gè)較為重要的 實(shí)現(xiàn) 方法 ，下面就對其進(jìn)行 詳細(xì)的 介紹。 Java 進(jìn)行客戶端的數(shù)據(jù)監(jiān)聽，主要是在服務(wù)器端新建一個(gè) serversocket 套接字。 Socket