【正文】 編碼圖像。一般來說，視頻幀可分為兩種類型：逐行和隔行視頻的。在傳統(tǒng)的模擬電視中，為了減少大面積的閃爍現(xiàn)象，我們把一完整的逐行幀分成兩個隔行的場?？梢钥匆?，這時幀內(nèi)相鄰行之間的空間相關(guān)性較強，因此運動較小或靜止的圖像宜采用幀編碼方式，對運動量較大的運動圖像則宜采用場編碼的方式。一個編碼圖像通常劃分成若干個宏塊，一個宏塊由一個 16x16 亮度像素值和一個8x8 的 Cb 和一個 8x8 的 Cr 彩色像素值塊組成（YUV420 采樣格式） 。每個圖像中，這些宏塊被排列成片的形式。I 片只包含 I 宏塊，P 片可包含 P 和 I 宏塊，而 B 片可包含 B 和I 宏塊。 I 宏塊利用當(dāng)前片中已解碼的像素作為參考進行幀內(nèi)預(yù)測（不能取其它片中的已解碼像素作為參考進行幀內(nèi)預(yù)測） 。P 宏塊利用前面已編碼圖象作為參考進行幀內(nèi)預(yù)測，一個幀內(nèi)編碼的宏塊可進一步作宏塊的分割：即 16x116x8x16 或 8x8 亮度像素值塊（以及附帶的彩色像素值） ；如果選了 8x8 的子宏塊，則還可以再分割成各種子宏塊，尺寸可為 8x8x4x8 或 4x4 亮度像素塊（以及附帶的彩色像素） 。B 宏塊則利用雙向南京郵電大學(xué)碩士研究生學(xué)位論文 第三章 視頻編解碼技術(shù)綜述13的即過去的和將來的已編碼圖像作為參考進行幀內(nèi)預(yù)測。，每個檔次支持一組特定的編碼功能，并支持一類特定的應(yīng)用?；緦哟危˙aseline Profile）：主要利用了 I 片和 P 片，支持幀內(nèi)和幀間編碼，支持基于上下文的自適應(yīng)變長編碼進行的（CAVLC） 。主要應(yīng)用于視頻電話、電視會議、無線通信等要求實時性、低延遲的場合。主要層次(Main Profile)：支持隔行視頻，可采用 B 片的幀間編碼和采用加權(quán)預(yù)測的幀內(nèi)編碼。其支持基于上下文的自適應(yīng)的算術(shù)編碼（CABAC） 。主要應(yīng)用于數(shù)字廣播電視與數(shù)字視頻存儲。擴展層次(Extended Profile)：支持碼流之間有效的切換（SP 和 SI 片） 、通過數(shù)據(jù)分割改進誤碼性能，但不支持隔行視頻和基于上下文的自適應(yīng)的算術(shù)編碼（CABAC） 。南京郵電大學(xué)碩士研究生學(xué)位論文 第三章 視頻編解碼技術(shù)綜述14南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計15第四章 系統(tǒng)框架設(shè)計及實現(xiàn)隨著 3G 時代的到來和手機硬件配置的大幅提高，例如高分辨率顯示屏、高速 CPU、大容量存儲，甚至配備獨立的 GPU 等，手機將逐漸從簡單的語音通信工具發(fā)展成支持互聯(lián)網(wǎng)瀏覽、移動電子商務(wù)、多媒體娛樂等以信息為中心的移動個人信息設(shè)備。因此，越來越多的人使用手機去觀看在線電影、視頻，收聽廣播等。由于手機的軟硬件環(huán)境千差萬別，加上網(wǎng)絡(luò)傳輸條件受限，所以傳統(tǒng)的基于個人電腦的流媒體系結(jié)構(gòu)并不完全適用于手機系統(tǒng)。因此，本章設(shè)計了適用于手機設(shè)備及其網(wǎng)絡(luò)環(huán)境的系統(tǒng)框架，并且同時兼容現(xiàn)有的桌面流媒體系統(tǒng)。 系統(tǒng)需求移動流媒體系統(tǒng)主要的應(yīng)用是在無限互聯(lián)網(wǎng)上分享多媒體數(shù)據(jù)，像視頻短片、流行音樂、個人照片等，因此，在手機客戶端上能夠流暢觀看 VOD 節(jié)目及直播節(jié)目（Live Broadcast）是系統(tǒng)的基本功能需求。且應(yīng)為手機操作系統(tǒng)較為繁多，所以也要求系統(tǒng)中的客戶端軟件具有良好的跨平臺性。在此基礎(chǔ)上，對用戶體驗有著比以往更高的要求，現(xiàn)有的手機流媒體系統(tǒng)大部分所支持的最高分辨率為 QCIF（176x144 像素） ，而當(dāng)前主流智能手機的屏幕分辨率均已達到QVGA（320x240 像素）級別，當(dāng)用戶全屏觀看節(jié)目時，圖像會產(chǎn)生拉伸。雖然這些系統(tǒng)中均使用了一些平滑算法來處理拉伸后的圖像，使畫面看上去鋸齒較少，但是我們知道，在液晶屏幕上像素點對點（PixeltoPixel）顯示才能獲得最佳顯示效果，所以，在本文設(shè)計的系統(tǒng)中，我們最高支持 QVGA 分辨率的節(jié)目，且要保持較為流暢的幀率（15 幀/ 秒） ，這就對解碼器的性能提出了挑戰(zhàn)。與此同時，絢麗易用的 UI（User Interface）對用戶體驗來說也是至關(guān)重要的，它往往決定了用戶對軟件的第一印象。設(shè)計并實現(xiàn)一套完整的跨平臺的 UI 系統(tǒng)是十分消耗人力和資源的，因此，我們將跨平臺 UI 設(shè)計這部分工作放在了今后，文中并未涉及這部分，但使用了 ADK（Application Development Kit）的概念，將 UI 層與應(yīng)用邏輯層（節(jié)目播放，錄制，節(jié)目菜單瀏覽等）相分離，為將來更換 UI 層做好準(zhǔn)備工作。流暢的用戶體驗同樣要求高效的數(shù)據(jù)傳輸，尤其在網(wǎng)絡(luò)帶寬有限且抖動較大的無限網(wǎng)南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計16絡(luò)環(huán)境中。目前，大多數(shù)桌面流媒體系統(tǒng)均采用了 P2P（PeertoPeer）即點對點的架構(gòu)。相比傳統(tǒng)的 Client/Server（客戶端 /服務(wù)器）架構(gòu)，P2P 擁有不少先天的優(yōu)越性，主要為網(wǎng)絡(luò)資源利用率高、節(jié)點越多網(wǎng)絡(luò)越穩(wěn)定等。但是，運營商現(xiàn)有的網(wǎng)絡(luò)帶寬條件及按流量計費的模式并不適合大流量的 P2P 應(yīng)用，所以，文中的流媒體系統(tǒng)采用了傳統(tǒng)的 C/S 框架。同時，為了適應(yīng)將來可能出現(xiàn)的需求，要求我們的系統(tǒng)可以從 C/S 框架平穩(wěn)的升級到 P2P 框架，這就要從協(xié)議的設(shè)計上出發(fā)，為以后的升級做好準(zhǔn)備。文中的系統(tǒng)中所使用的會話建立協(xié)議 SEP（ Setup）已由先前的工作完成，在文中有著較為詳細的闡述。 系統(tǒng)方案選擇在無線網(wǎng)絡(luò)環(huán)境中構(gòu)建 VOD/Live Streaming 這樣的典型視頻應(yīng)用，客戶端與服務(wù)器端是兩個最重要的組成部分。在服務(wù)器端的選擇上，由于先前的工作中已經(jīng)完成了一個成熟度較高的針對桌面流媒體系統(tǒng)的服務(wù)器組，已經(jīng)過較長時間的測試，能夠達到長時間無間隙運行的要求。并且，此服務(wù)器組可以適應(yīng)不同架構(gòu)的傳輸模式，在桌面流媒體系統(tǒng)中采用了 P2P 架構(gòu)，而針對移動流媒體系統(tǒng)，可以方便的切換為 C/S 架構(gòu)，也是為將來移動 P2P 的研究與實現(xiàn)留有了可能。所以，本文中的系統(tǒng)服務(wù)器選擇了這套方案。有了服務(wù)器端后，要討論的自然就是手機等移動設(shè)備上運行的客戶端了，這也是本文研究的重點。我們知道，移動平臺的操作系統(tǒng)非常豐富，主要有 Symbian、Windows Mobile、Linux、MacOS 等等，它們之間的競爭也很激烈，并不像桌面家用平臺上Windows 一統(tǒng)江山，因此，怎樣開發(fā)一個跨平臺的，也就是說具有良好移植性的客戶端軟件成了我們討論的主題。一個軟件要具有良好的跨平臺性，從它的設(shè)計之初就要考慮盡可能的將平臺相關(guān)的部分與應(yīng)用邏輯部分相分離，使軟件應(yīng)用邏輯部分的代碼可以運行在任何平臺上。不管在何種平臺上構(gòu)建視頻應(yīng)用，都需要一套多媒體框架（Multimedia Framework，以下簡稱 MMF） ，而 MMF 往往與平臺的結(jié)合很緊密，所以幾乎每一個移動平臺都有自己的 MMF，像 Symbian 的 MMF、Windows Mobile 的 DirectShow、Linux 的GStreamer 等等。如果基于這些 MMF 去設(shè)計客戶端軟件將不能擁有良好的移植性，所以，我們選擇了 FFmpeg 結(jié)合 SDL 這套緊湊且具有良好跨平臺特性的框架方案。 FFmpeg 是著名的開源跨平臺編解碼函數(shù)庫，功能非常全面，可以根據(jù)具體的需要進行量體裁衣；而SDL 則是封裝了多種平臺的底層圖像、聲音呈現(xiàn)等功能的函數(shù)庫，在下文函數(shù)庫移植的章節(jié)中有著具體的闡述。南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計17 系統(tǒng)框架設(shè)計本課題所研發(fā)的移動客戶端軟件基于現(xiàn)有的服務(wù)器系統(tǒng)，此服務(wù)器系統(tǒng)原先為配合桌面 P2P 點播客戶端所開發(fā)，具有高度的成熟度及健壯性。移動客戶端與固定客戶端使用同樣的會話協(xié)議，也就是 SEP 協(xié)議，SEP 為英文單詞 setup 的簡寫，意為會話建立的意思，下面兩節(jié)主要介紹了系統(tǒng)中的服務(wù)器及客戶端部署框架，并且描述了 SEP 協(xié)議的主要特征與會話流程。1. Portal Server（導(dǎo)航服務(wù)器）：用戶導(dǎo)航服務(wù)器，物理上是一臺服務(wù)器加操作系統(tǒng)，再加上應(yīng)用服務(wù)器軟件，合稱Portal服務(wù)器。Portal實現(xiàn)了HTTP協(xié)議服務(wù)器端，可在終端請求時為用戶返回導(dǎo)航頁面。2. Bootstrap Server（接入服務(wù)器）：是系統(tǒng)中直接被用戶訪問的網(wǎng)絡(luò)節(jié)點，用戶只有通過系統(tǒng)的Bootstrap Server才可能接入系統(tǒng)，是一個物理實體；其基本功能是用戶管理，共享資源管理，接入認證；可能具有一定的調(diào)度功能和計費功能。3. Media Server（媒體服務(wù)器）：系統(tǒng)提供一些集中的服務(wù)器來為終端用戶提供內(nèi)容服務(wù)；這些內(nèi)容服務(wù)器的內(nèi)容通常是通過pull或者push的方式從內(nèi)容源獲取的；按照業(yè)務(wù)類型，可以分為直播媒體內(nèi)容服務(wù)器和點播媒體內(nèi)容服務(wù)器。4. 手持終端：指利用移動網(wǎng)絡(luò)接入流媒體系統(tǒng)的手持終端，主要代表是手機。其特點是處理器運算能力有限、內(nèi)存較少，其上運行的軟件要充分考慮省電性。南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計18M e d i a S e r v e rP o r t a l S e r v e rB o o t s t r a p S e r v e rA P圖 流媒體系統(tǒng)部署1. 與 Portal Server 的交互流程：a) 新用戶通過和 Portal 服務(wù)器交互，輸入用戶名/ 密碼等信息，可以實現(xiàn)用戶登陸；初次訪問的用戶亦可以注冊新的賬戶；b) 用戶通過運行在手機上客戶端，輸入用戶名/密碼，和 Portal 服務(wù)器交互，實現(xiàn)訪問系統(tǒng)的認證；Portal 返回手機終端下一步訪問的 Bootstrap 服務(wù)器地址及EPG（Electronic Program Guide）信息等；2. 與 Bootstrap Server 的交互a) 用戶從節(jié)目菜單中選擇希望觀看的節(jié)目，選取后客戶端會發(fā)送相應(yīng)的請求給Bootstrap 服務(wù)器；b) Bootstrap 服務(wù)器返回能夠提供被選擇節(jié)目的媒體服務(wù)器給用戶。3. 與媒體服務(wù)器的交互a) 用戶從 Bootstrap Server 獲取到媒體服務(wù)器地址后，發(fā)送播放請求給 Bootstrap 服務(wù)器，再由它將請求轉(zhuǎn)發(fā)給媒體服務(wù)器，媒體服務(wù)器接受請求后將媒體數(shù)據(jù)分割成固定大小的塊（Chunk） ，封裝成 RTP 流后推向手機終端；b) 媒體服務(wù)器接收請求后，建立會話，將用戶需求的媒體數(shù)據(jù)（Media Clip）分割成固定大小的塊（Chunk） ，封裝成 RTP 流后推向手機終端。南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計19圖 系統(tǒng)基本流程在這一節(jié)里對系統(tǒng)基本會話過程中的幾個關(guān)鍵報文作了詳細解析。這里要先解釋兩個名詞，由于流媒體系統(tǒng)依賴服務(wù)器下載的特點，對媒體內(nèi)容需要采用一定方式的分割。因此將一部完整的視頻分割成內(nèi)容塊（Chunk）和內(nèi)容片（Piece） ，Chunk和Piece 的主要區(qū)別是：1. Chunk比 Piece要大，如chunk是Piece的3倍大?。籧hunk級，而無法感知 Piece。Piece的感知是在系統(tǒng)的調(diào)度功能和終端。另外，SEP協(xié)議中所有的報文種類都會含有SEP_HEADER報文首部，為了使程序具有較好的移植性，所使用的基本數(shù)據(jù)類型均為重新宏定義過的，它們均加上了VOS前綴。1. Join 報文Join 消息需要攜帶用戶的 ID 、用戶名、用戶類型（手機終端、固定終端） 、本地的IP 和 port 等用戶屬性參數(shù)。當(dāng)手機客戶端需要登入系統(tǒng)時，首先就要像 Portal 服務(wù)器發(fā)出 Join 消息，然后等待響應(yīng)，這里在設(shè)計時需要考慮網(wǎng)絡(luò)丟包引起的超時因素，當(dāng)嘗試發(fā)送幾次都得不到響應(yīng)時，需要進行相應(yīng)的超時處理；具體如下面的結(jié)構(gòu)體所示：南京郵電大學(xué)碩士研究生學(xué)位論文 第四章 系統(tǒng)框架實現(xiàn)及設(shè)計20typedef struct CLIENT_ATTR_STRU{ VOS_UINT8 ucTrans。 /*傳輸協(xié)議類型, 0x06 為TCP, 0x11為UDP*/ VOS_UINT8 ucRsv1。 VOS_UINT16 uwPort。 /*端口號*/ struct in_addr tIPAddr。 /*IP 地址*/ VOS_UINT8 ucUserType。 VOS_UINT8 ucUserNameLen。 VOS_UINT8 aucUserName[DSN_USER_NAME_MAX_LEN + 1]。 VOS_UINT8 ucRsv2。}