【正文】 需要幾個產(chǎn)業(yè)鏈來支撐 [2]：內(nèi)容制作商、內(nèi)容集成商、網(wǎng)絡(luò) 運營商。國家從 20xx年 5月開始整頓國內(nèi) IPTV市場。韓國第 二大網(wǎng)絡(luò)門戶 Daum通信在 20xx年也宣布進入 IPTV市場 [3]。 由于 IPTV巨大的潛在價值和商業(yè)空間，各個國家紛紛發(fā)展 IPTV[2]。 國內(nèi)外研究現(xiàn)狀 1）國內(nèi)外 IPTV發(fā)展研究現(xiàn)狀 隨著科技發(fā)展，用戶已不再滿足于電視業(yè)務(wù)的單向廣播模式，希望在電視上實現(xiàn)雙向 交互功能。 因此，開展 IPTV播放器的研究，提供一種價格低廉的高性能 IPTV播放器，對國內(nèi) IPTV 行業(yè)發(fā)展有著積極的推動作用。 IPTV 播放器作為 IPTV系統(tǒng)中的核心應(yīng)用軟件，也是與硬件平臺緊密相關(guān)的。在機頂盒這種專門的播放設(shè)備上，在播放一個電影前一般要插播一段廣 告，另外，同一部電影往往由多個分片存儲的節(jié) 目文件組成，為了讓用戶查覺不到媒體文 件切換導(dǎo)致的停頓感，在對多個分片進行連續(xù)播放時，需要實現(xiàn)無縫的連續(xù)播放。 3)能同時適應(yīng)本地媒體文件播放和網(wǎng)絡(luò)媒體文件播放 播放器 除了可以播放本地的視頻節(jié)目外也可播放網(wǎng)絡(luò)點播或直播節(jié)目。 基于以上特點，通常廠家對 IPTV播放器有以下需求： 1)全格式支持 要求支持常見的主流文件格式，并同時具備添加新格式支持的能力。 通常而言 IPTV系統(tǒng)是以視音頻服務(wù)為主要業(yè)務(wù)，同時提供游戲、股票等增值服務(wù)的系統(tǒng)業(yè) 務(wù)的綜合體，而視頻播放是 IPTV的核心業(yè)務(wù)，視頻播放器是 IPTV的核心模塊。 ，實現(xiàn)了播放器內(nèi)核與內(nèi)核接口庫并進行了測試。借鑒 微軟 DirectShow架構(gòu)和操作系統(tǒng)的微內(nèi)核思想，提出了 基于分層結(jié)構(gòu)和流水線理念的 IPTV播放器內(nèi)核設(shè)計思路：內(nèi)核按照服務(wù)層級來劃分模塊， 內(nèi)層模塊完成實際工作任務(wù)，外層模塊完成邏輯控制，內(nèi)層為外層提供服務(wù)；播放器內(nèi)核 同時采用組件化、鏈路化的方式，完成流媒體的解析和解碼，從而實現(xiàn)對新增媒體格式的 擴展支持。依據(jù)該思路，設(shè)計了一個易擴展、可復(fù)用程度高的 先進框架。因此，開 展 IPTV播放器關(guān)鍵技術(shù)研究有意義。 IPTV通?；谇度胧较到y(tǒng)開 發(fā)，由于硬件平臺的多樣性導(dǎo)致業(yè)界尚無標準可循，而常見的開源播放器又無法滿足不同 廠家的功能需求?；诓シ牌鞯幕驹砗头謱咏Y(jié)構(gòu)的優(yōu)勢，提出了基于層次 結(jié)構(gòu)的 IPTV播放器框架的設(shè)計思路。 。接口庫本身與播放邏輯無關(guān)， 播放邏輯及具體業(yè)務(wù)的處理，由業(yè)務(wù)層及應(yīng) 用層實現(xiàn)，其通過 TCP連接與內(nèi)核進行通訊， 實現(xiàn)對內(nèi)核的控制及狀態(tài)查詢，并接收內(nèi)核發(fā)送的事件通知。And,Playerkerneladoptsthewayofmodularization,link,the pletestreamingparseanddecode,enablingsupportfortheexpansionofthenewmedia format. logicandaffecttheuniversalproblemsinitsbusinessintheupper,definesasetofapis,calling ,logicandthe h theTCPconnectionwiththekernelofmunication,Itrealizedthecontrolsystemforthe kernelandstatusquery,receiveeventnotificationssentbythekernel. ,realizetheplayerkernelandthekernel interfacelibrary,andachievethecorefunctionalityofIPTVplayersrequired,andtheplayer canmeetthedemandoftheapplicationsystemfunction. Keywords:IPTV,InterTV,streamingmedia,player,Videoandaudiodecoding 第一章緒論 第 1頁 第一章緒論 課題的目的和意義 IPTV（ InterProtocolTelevision）交互式互聯(lián)網(wǎng)電視，以其特有的互動性、內(nèi)容豐富 性、及時性吸引了眾多用戶，成為電信及廣電部門、電子及 軟件企業(yè)爭相搶奪的新興市場。播放器在 IPTV上的 應(yīng)用特點是：媒體格式多種多樣、數(shù)據(jù)源日益增多（如本地文件、各種不同的網(wǎng)絡(luò)協(xié)議） 以及硬件平臺的多樣性。播放器要支持提供全 VCR 操作的能力、允許各 VCR操作狀態(tài)之間的自由切換，使視頻應(yīng)用業(yè)務(wù)可以提供給用戶友好 的人機交互。 4)無縫連續(xù)播放支持 一般的播放器在連續(xù)播放多個媒體文件時，媒體文件切換過程會有短暫停頓，或畫面 靜止或聲音停頓。 IPTV通常是嵌入式系統(tǒng) [1]， 與通用計算機系統(tǒng)不同，其軟件與硬件是緊密關(guān)聯(lián)的。目前國內(nèi)自主研發(fā)的嵌入式播放器分辨率 低，流暢度 差；而國外 IT公司能提供的嵌入式播放器雖然在分辨率和流暢度上有很大優(yōu)勢， 但是價格偏高。 在這個框架下，通過添加支持不同格式的解析模塊，就能為終端機頂盒提供新的媒體格式 的播放支持，利用其提供的一系統(tǒng)列接口，也能在其上構(gòu)建各種不同業(yè) 務(wù)的應(yīng)用模塊，以 提高軟件模塊的可復(fù)用性，可極大地縮短開發(fā)各種不同多媒體應(yīng)用的開發(fā)周期，降低開發(fā) 成本，為企業(yè)帶來長久效益。播放器是 IPTV 終端機頂盒的關(guān)鍵模塊，主要完成 IPTV的流媒體業(yè)務(wù)和其他業(yè)務(wù)的圖形及伴音展示 [2]。韓國電信在 20xx年 7月推出 IPTV以來，到當年 9月底已發(fā)展了 [3]。 我國 IPTV的發(fā)展始于 20xx年 [4]。 20xx年年底，互聯(lián)網(wǎng)電視獲 得廣電總局的 “ 解禁 ” ，中國電信和廣地廣電運營商紛紛加入試點，試圖奪取主動權(quán) [4]。微軟公司的 WindowsMediaPlayer和 Real公司的 RealPlayer 是這一階段的典型代表。在本課題的 IPTV系統(tǒng)開發(fā)中無 法使用。 這個階段的播放器支持格式多，并且開源可擴展，但是都是基于 PC設(shè)備的，無法在特 定硬件平臺的嵌入式設(shè)備中擴展使用。 這個階段的播放器為我們提供了很多播放器框架開發(fā)的 思路，但是框架本身都是基于 一定平臺的，無法滿足在任意平臺上的擴展使用。 當前各個廠家對 IPTV播放器的研究，都停留在所選用設(shè)備架構(gòu)和硬件平臺基礎(chǔ)上的播 放器研究與開發(fā)，以滿足自身 IPTV系統(tǒng)所用機頂盒產(chǎn)品的需求。 硬件適配層：該層針對不同的硬解碼芯片制造商的硬件平臺提供適配功能，為 上層提 供統(tǒng)一的接口。接口庫本 身無任何關(guān)于播放邏輯的控制，播放邏輯及各種與具體應(yīng)用需求相關(guān)的處理，由業(yè)務(wù)層及 業(yè)務(wù)層之上的應(yīng)用層實現(xiàn)。比如： 需要使用 HTTP、 MMS（ MembershipManagementSystem）、 RTSP（ RealTimeStreaming Protocol） [5][6][7]、 P2P（ peertopeerwork）等協(xié)議從網(wǎng)絡(luò)上獲取數(shù)據(jù)時，只需要開發(fā)出 相應(yīng)的功能模塊掛接上即可，而不需要對播放器內(nèi)核做任何修改；另外，需要增加對新媒 體格式的支持時，只需要按照定義好的接口，開發(fā)針對該媒體格式的解復(fù)用組件 DemuxFilter等模塊，然后加入播放器內(nèi)核中即可，不需要對播放器框架做任何修改。 其實質(zhì)是一套網(wǎng)絡(luò)通訊的客戶端發(fā)包工具，將播 放指令按照和播放器內(nèi)核約定的指令數(shù)據(jù)結(jié)構(gòu)發(fā)送數(shù)據(jù)包給播放器內(nèi)核進程。 第二章： IPTV播放器框架設(shè)計。借鑒微軟 DirectShow架構(gòu)和操作系統(tǒng)的微內(nèi)核 思想，提出了 IPTV播放器內(nèi)核設(shè)計的思路：讓播放器內(nèi)核專一做與音視頻流播放相關(guān)的工 作，不再直接參與數(shù)據(jù)的獲取等工作。然后定 義出一套 API接口，該接口供業(yè)務(wù)層調(diào)用。 第六章：總結(jié)與前景。 對于音視頻播放，一般可有以下四個基本步驟：數(shù)據(jù)源讀?。?Sourcereader）、解復(fù) 用（ Demux,Demultiplexer的縮寫）、解碼（ Decoder）、輸出（ Render），如圖 1所示。 解復(fù)用 每種多媒體文件都有其特有的封裝格式。常見的編碼格式有 MPEGI[8]、 MP MPEGII[8]、 、 MPEG4[8][9] 等。 RGB是一種基于三基色原里的色彩表示法。 對連續(xù)變化的模擬信號進行抽樣、量化、編碼 ,最終生成數(shù)字信號的過程就是脈沖編碼 調(diào)制，簡稱為 PCM. 經(jīng)過數(shù)據(jù)源讀取、解復(fù)用、解碼、輸出四個 步驟之后，就完成了多媒體文件的播放。 IPTV播放器的研究與設(shè)計，就是對數(shù)據(jù)源讀取和解復(fù)用這兩部分的實現(xiàn)進行研究與設(shè) 計。 IPTV 播放器框架設(shè)計思路 在一般的系統(tǒng)框架設(shè)計中，往往都采用分層式結(jié)構(gòu)，因為分層式結(jié)構(gòu)具有以下優(yōu)勢： 1)有利于各層邏輯的復(fù)用； 2)易于替換原有層次內(nèi)的實現(xiàn)； 3)能夠降低層次與層次的依賴度； 4)可以使不同級別的開發(fā)人員只關(guān)注整個結(jié)構(gòu)中的某一層； 5)有利于標準化。 UI不用關(guān)心播放器功能、軟件工程師不用考慮界面應(yīng)該如何布局，每個崗位的職責都很專 一，如此一來，開發(fā)進度自然能夠保證。 不同層次的功能定位、層間通訊方式，嚴重的影響了系統(tǒng)的可擴展性、可替換性。 媒體業(yè)務(wù)層將種類繁多的播放業(yè)務(wù)抽象為控制調(diào)用和功能調(diào)用兩大類接口。 視頻業(yè)務(wù)應(yīng)用層 根據(jù)多媒體業(yè)務(wù)的用戶需求、多媒體格式，視頻業(yè)務(wù)應(yīng)用層有許多種變現(xiàn)形式和側(cè)重 點。例如，以播放本地文件為主要業(yè)務(wù)的 “ 我的影庫 ” ，如 果發(fā)現(xiàn)與視頻文件匹配的字幕文件，在播放視頻時，應(yīng)用層將嘗試解析并顯示字幕。隨著開發(fā)的深入，累積一定量的視頻服務(wù)后，當 出現(xiàn)與以往視頻應(yīng)用業(yè)務(wù)需求相同或相近的新業(yè)務(wù)時，可以直接復(fù)用現(xiàn)有的視屏業(yè)務(wù)服 務(wù)。 第二章 IPTV播放器框架設(shè)計 第 11頁 圖 4業(yè)務(wù)層與其它各模塊的關(guān)系 1頁面調(diào)用 JS（ JavaScript）插件 頁面通過調(diào)用 JS插件開發(fā)各種不同的面向頁面的流媒體業(yè)務(wù)。 用戶向業(yè)務(wù)進程發(fā)出一條控制命令后，接口層立即向業(yè)務(wù)層的共享內(nèi)存查詢權(quán)限信 息，裁決是否允許該用戶進行本向操作。業(yè)務(wù)進程使用面向?qū)ο蟮?C++語言編寫， 并且廣泛的使 用了面向?qū)ο蟮呐缮?、多態(tài)、重載等機制。主函數(shù)處 于總體協(xié)調(diào)的位置之上，根據(jù)業(yè)務(wù)需要創(chuàng)建具體的類對象，循環(huán)接受消息，并且調(diào)用各個 子類提供的具體的消息處理方法。播放器通訊控制層處 于視音頻業(yè)務(wù)應(yīng)用程序與播放器內(nèi)核之間，在二者之間傳遞播控指令并反饋播放狀態(tài)。利用 TCP協(xié)議能夠確保播控指令和播放狀態(tài)，按照事件發(fā)生的 先后順序到達內(nèi)核或者上層應(yīng)用。 TCP連接本來是可以雙向通訊的，為了能夠快速響應(yīng)播控指 令、及時反饋播放狀態(tài)，使兩類數(shù)據(jù)分別有各自的通道，互不干擾。 JumpForword指令至少需要包含 第二章 IPTV播放器框架設(shè)計 第 13頁 跳躍的起點和跨度，這樣內(nèi)核就可以實現(xiàn)一個跳躍播放。 播放器內(nèi)核層就是以進程形式形式存 在的最基本最核心的視音頻播控功能，有時也被 稱為播放器內(nèi)進程。 播放器內(nèi)核進程就是一個處于伺服狀態(tài)的后臺進程，上層應(yīng)用通過調(diào)用通訊控制層中 的接口，向內(nèi)核傳遞一個網(wǎng)絡(luò)格式的操控指令包，內(nèi)核收到該指令包后進行必要的解析和 驗證處理之后，執(zhí)行指令相應(yīng)的動作。這些 芯片雖然管腳排列、封裝形式不盡相同，但是都是為了支持某種特定的視音頻編碼格式。 各個芯片廠商提供的 SDK包雖然風格迥異，但是基本原理是相同的。適配功能需 要實現(xiàn)，各個 SDK開發(fā)包都可能用到的那些功能。音頻方法主要包括：打開 /關(guān)閉解碼器、初始 化音頻編碼格式、開始播放、寫入數(shù)據(jù)、調(diào)節(jié)音量、設(shè)置聲道、開始播放、暫停、快進等。 “ 媒體格式說明 ” 內(nèi)的眾多信息，是解碼器進行解碼工作必不可少的指導(dǎo)參數(shù)。是一幀的開始還是一幀的結(jié)束，還是完整的 一幀。 Meta信息必須與 ESData匹配，否則要么無 法播放，要么播放期間異常終止。包括視頻業(yè)務(wù)服務(wù)層和視頻業(yè)務(wù)應(yīng)用層。接口層只是傳 遞通道，沒有絲毫播放功能。 用于不定時接收播放器返回的事件通知。內(nèi)核接口庫再將結(jié)果返回給業(yè)務(wù)應(yīng)用層。 支持多播放引擎 “ 播放引擎 ” 其實就是對視音頻進行播放時完成的一條流水線。一般情況下，創(chuàng)建一個唯一的引擎，即可滿足視音頻 播放 需要。 2）無縫連播：在只有一個播放引擎的情況下，必須在 Demux模塊內(nèi)進行復(fù)雜的處理才 可能實現(xiàn)無縫連播。媒體服務(wù)模塊 MSP（ MediaServiceProvider）根據(jù)引擎句柄很容易識別操控命令應(yīng)該 由那個引擎執(zhí)行。 demux模塊的 CanHandleFile函數(shù)中會解析文件內(nèi)容去判斷是否支持。本文設(shè)計的播放器通過對文件 內(nèi)容中這些標志進行遍歷判斷，來提高文件類型判別的準確性。 通過擴展名方式進行文件類型識別，快速高效，但是以文件內(nèi)容進行判別，更加準確。刪除不再有用的 Filter組件，并釋放相關(guān)資源的過程，就是拆卸。 Filter組件之間傳遞數(shù)據(jù)時，都以指針的 形式 進行，避免了大量的內(nèi)存拷貝，降低了 CPU占用率。 支持 VCR操作之間的自由切換 本地視音頻播放提供的操作有：播放、停止、暫停、快退、快進、選時、 調(diào)節(jié)音量、 切換聲道、靜音等，用戶可在任意兩個允許的狀態(tài)之間切換。最后給出了基于該框架設(shè)計的 IPTV播放 器能夠支持 的技術(shù)特性。 微軟公司的 DirectShow系統(tǒng)，為解決這些挑戰(zhàn)提供了一種可