<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 消費(fèi)電子 > 學(xué)習(xí)方法與實(shí)踐 > 數(shù)字機(jī)頂盒的架構(gòu)與設(shè)計(jì)關(guān)鍵

          數(shù)字機(jī)頂盒的架構(gòu)與設(shè)計(jì)關(guān)鍵

          ——
          作者: 時(shí)間:2008-01-16 來源:電子產(chǎn)品世界 收藏

            可說是手機(jī)之外的另一波殺手級(jí)應(yīng)用,它以客廳為核心,不斷地整合家庭中的其它視聽及信息設(shè)備,形成多元應(yīng)用的家庭網(wǎng)絡(luò);不僅如此,與手機(jī)也向整合之路發(fā)展,移動(dòng)電視(Mobile TV)已在全球各地如火如荼的推動(dòng)當(dāng)中。當(dāng)電視廣播系統(tǒng)與網(wǎng)絡(luò)、甚至是移動(dòng)蜂窩系統(tǒng)結(jié)合時(shí),包括視頻、語音與數(shù)據(jù)的服務(wù)自然走向多元匯流的趨勢(shì),這是一個(gè)比過去獨(dú)立形式復(fù)雜許多的應(yīng)用環(huán)境,而數(shù)字機(jī)上盒(Set-top-box)正位于此架構(gòu)的核心位置,其面臨的設(shè)計(jì)挑戰(zhàn)確實(shí)繁重。

              根據(jù)電視節(jié)目發(fā)送管道的不同,又可分為數(shù)字地面(Terrestrial)機(jī)頂盒、數(shù)字衛(wèi)星(Satellite)機(jī)頂盒、數(shù)字有線(Cable)機(jī)頂盒,以及通過網(wǎng)絡(luò)(xDSL、Cable Modem、光纖)的IP 機(jī)頂盒等形式。整體而言,的技術(shù)主軸朝向支持HDTV(High Definition TV)及互動(dòng)性(Interactive)發(fā)展,但不同市場(chǎng)區(qū)塊仍有技術(shù)及應(yīng)用上的偏重。為了達(dá)到產(chǎn)品的差異化定位,加入硬盤的數(shù)字視頻錄像機(jī)(DVR)及整合家庭網(wǎng)絡(luò)功能的家庭網(wǎng)絡(luò)網(wǎng)關(guān)器(Residential Gateway, RG),也是的重要設(shè)計(jì)方向。

          系統(tǒng)架構(gòu)

              一個(gè)數(shù)字機(jī)頂盒是由軟、硬件所組成,在硬件方面的主要單元可分為接收廣播信號(hào),并將其轉(zhuǎn)換為數(shù)字傳輸串流的前端(front-end, FE)芯片,即諧調(diào)器(tuner)和調(diào)節(jié)/解調(diào)器(modulator/demodulator);后端芯片包括電視解碼器/編碼器(NTSC/PAL decoder/encoder)、MPEG-2 Transport、MPEG-2 MP@ML或HL解碼器、微處理器、圖形芯片、音頻處理器、音頻DAC、視頻DAC;以及DRAM/SDRAM、Flash等內(nèi)存、電源組件及其它標(biāo)準(zhǔn)離散組件。更高級(jí)產(chǎn)品還會(huì)整合安全芯片、調(diào)制解調(diào)器(modem)或家庭網(wǎng)絡(luò)芯片,以及可錄像的硬盤(HDD)。(圖1)為支持DVR功能的機(jī)頂盒解碼芯片方塊圖。

            圖1  具有DVR功能的機(jī)頂盒解碼器方塊圖(以STx5100為例){{分頁}}

            資料來源:ST

              更強(qiáng)大及多元的功能及更高的整合度是數(shù)字機(jī)頂盒在硬件部分的發(fā)展趨勢(shì)。在功能上,電視解碼器強(qiáng)調(diào)要能做到dual-TV和dual-DVR,也就是除了能解碼并顯示數(shù)字和模擬兩種電視廣播信號(hào)外,還要能解碼兩個(gè)同步標(biāo)準(zhǔn)解析電視頻號(hào),再送到多臺(tái)不同的電視機(jī)播放,或錄制節(jié)目到硬盤中。此外還有所謂的PAP(高解析雙畫面)和PIP(子母畫面)功能,能夠在同一個(gè)屏幕上顯示兩個(gè)不同的高解析電視畫面,可以分別并列或上下排列。

              在整合性上,為了保持設(shè)計(jì)彈性,一般在系統(tǒng)中前端及后端芯片是分離的配置,但也能將兩者整合為單一封裝,進(jìn)而為大量生產(chǎn)的應(yīng)用提供更佳的成本效益。芯片本身則朝SoC的方向發(fā)展,尤其是位居核心的解碼器芯片,此類芯片會(huì)采用90納米等高級(jí)制程,在一顆芯片上整合各種主要功能,包括高性能的CPU、視頻解碼電路和各種外圍設(shè)備,請(qǐng)參考(圖2)。

            圖2  機(jī)頂盒單芯片iDTV處理器硬件架構(gòu)方塊圖(以STD2000為例)

            資料來源:ST

              在軟件部分則包括操作系統(tǒng)和實(shí)時(shí)操作系統(tǒng)(RTOS)、提供互動(dòng)功能的MHP 等中介軟件(Middleware)及應(yīng)用程序接口(API),以及電子節(jié)目表(EPG)等應(yīng)用軟件或條件式接取(Conditional Access, CA)安全功能。接口上則需要支持安全性模塊(POD module)、共同接口(CI)、智能卡(smart card/reader)、高速界面(USB、IEEE 1394及序列ATA)等。CA、CI、POD等技術(shù)難度較高,也是設(shè)備商在選用視頻處理芯片解決方案后,仍需進(jìn)一步整合開發(fā)的議題。

          設(shè)計(jì)關(guān)鍵:視頻轉(zhuǎn)換處理

              視頻轉(zhuǎn)換處理無疑是機(jī)頂盒最主要的功能,因此編碼/解碼器(CODEC)猶如機(jī)頂盒的心臟。目前電視廣播界仍以MPEG-2為基本視頻壓縮規(guī)格,但已積極轉(zhuǎn)向MPEG-4、H.264/AVC(即MPEG-4 Part 10)及VC-1等新一代編解碼規(guī)格。采用新的規(guī)格對(duì)業(yè)者來說具有許多好處,最明顯的例子在于他們能通過有限的頻寬傳送更多的節(jié)目頻道,或提供高畫質(zhì)的電視節(jié)目。

              以MPEG-2和H.264來比較,在傳輸HDTV內(nèi)容時(shí),前者需要20Mbps頻寬,后者只需8Mbps頻寬就能提供相同的畫質(zhì),兩者差了2.5至3倍。除了頻寬的考慮外,采用新的視頻壓縮規(guī)格也能帶來其它的優(yōu)勢(shì),例如在具備節(jié)目錄制PVR /DVR功能的機(jī)頂盒中,更大的壓縮比意味著能儲(chǔ)存更多的容量;此外,新的規(guī)格也提供了對(duì)象導(dǎo)向的互動(dòng)功能,以及子母分割畫面等加值功能。{{分頁}}

              目前市場(chǎng)上并未明確的往特定的新一代規(guī)格靠攏,處在這個(gè)過渡期中,機(jī)頂盒只得同時(shí)支持多種規(guī)格。MPEG-4雖然問世較久,也有不少廠商大力支持,但它先天上存在著一些難以克服的瓶頸,讓它在推展上顯著舉步維艱。

              MPEG-4最大的問題在于規(guī)格過于龐雜,視頻只是MPEG-4定義中的一個(gè)部分(lS014496-2 MPEG-4 Part 2)。這種龐雜性就產(chǎn)生各部分兼容性的定問題:有些內(nèi)容不夠清楚,或不夠開放;有些做了折衷處理,反而造成互操作性的難題。舉例來說,由于MPEG-4允許自訂輸出規(guī)格,因此造成各種規(guī)格并存的現(xiàn)象,例如較知名的Divx規(guī)格及微軟的wmv規(guī)格,但過多規(guī)格也讓服務(wù)業(yè)者望之卻步。另一個(gè)令人詬病的原因,則在于要取得MPEG-4的商用取可證曠日廢時(shí),而且得負(fù)擔(dān)高昂的使用費(fèi)用。

              相較之下,H.264雖然也是一個(gè)復(fù)雜的標(biāo)準(zhǔn),但它只針對(duì)視頻做制定,也已獲得MPEG/lS0和ITU兩大國(guó)際標(biāo)準(zhǔn)組織的支持,加上它是當(dāng)前能提供最佳視頻壓縮效能的規(guī)格,也不存在使用費(fèi)的問題,所以自2003年標(biāo)準(zhǔn)推出后,即對(duì)HDTV、HD-DVD、手機(jī)及視頻串流等業(yè)者產(chǎn)生莫大的吸引力。不僅如此,H.264在制定時(shí)即考慮了與MPEG-2既有系統(tǒng)的通用性問題,因此,在今日的基礎(chǔ)建設(shè)中就能將H.264嵌入MPEG-2傳送流(TS)中發(fā)送出去。H.264的應(yīng)用情況與取樣速率請(qǐng)參考(表1)。

              不過,在提升壓縮效能的同時(shí),H.264也存在編碼計(jì)算復(fù)雜度大增的問題,因此需要消耗更大的運(yùn)算資源。在此情況下,機(jī)頂盒必須采用更高效能的處理器,或以專屬的CODEC加速器硬件來完成任務(wù)。此外,高質(zhì)量、低復(fù)雜性算法對(duì)于H.264的編解碼也有很大的幫助,以ST來說,就已提出運(yùn)動(dòng)估算與速率控制算法,以及用于H.264解碼的錯(cuò)誤檢測(cè)與隱藏算法,能讓解碼器承擔(dān)并隱藏?cái)?shù)據(jù)封包損失,在無線封包網(wǎng)絡(luò)上實(shí)現(xiàn)IP網(wǎng)絡(luò)的最佳效能。

          視頻編碼轉(zhuǎn)換(Transcoding)


              身為數(shù)字家庭網(wǎng)絡(luò)核心位置的機(jī)頂盒,除了提供電視節(jié)目的視頻轉(zhuǎn)換播放之外,目前也成為家庭中如DVD、PMP、數(shù)字相機(jī)等各種不同設(shè)備的互連中心。為了讓視頻內(nèi)容能在不同設(shè)備間進(jìn)行播放及存取,機(jī)頂盒還得具有視頻編碼轉(zhuǎn)換的能力,也就是調(diào)整位位速率以符合特殊的信道速率或儲(chǔ)存格式;或是用來改變分辨率,如將高分辨率(HD)視頻串流傳送給標(biāo)準(zhǔn)分辨率(SD)電視,或是在CIF移動(dòng)終端上顯示SD視頻等。

            圖3  DBS MPEG-2轉(zhuǎn)H.264編碼轉(zhuǎn)換技術(shù)

            資料來源:ST Journal of Research- Vol 2, No. 1

              ST先進(jìn)系統(tǒng)技術(shù)(AST)小組所開發(fā)的動(dòng)態(tài)位串流規(guī)劃(Dynamic Bitstream Shaper,DBS)技術(shù),即采取最佳化的算法來支持MPEG-2與H.264之間的位速率、訊框速率、訊框大小與編碼標(biāo)準(zhǔn)變化。它的開發(fā)目的在于降低視頻編碼轉(zhuǎn)換的架構(gòu)復(fù)雜性、運(yùn)算耗能、內(nèi)存需求,以及運(yùn)算延遲等,讓視頻內(nèi)容不需經(jīng)過再編碼(re-encoding)而能獲得相同或更佳的質(zhì)量。{{分頁}}

          設(shè)計(jì)關(guān)鍵:數(shù)字內(nèi)容管理技術(shù)

              進(jìn)入數(shù)字內(nèi)容的時(shí)代,復(fù)制盜版的難度大減,這也成了電視服務(wù)業(yè)者邁向或IPTV時(shí)最關(guān)心的問題之一,負(fù)責(zé)接收轉(zhuǎn)換數(shù)字內(nèi)容的機(jī)頂盒,自然就被賦與了版權(quán)管控的任務(wù)。目前對(duì)于數(shù)字電視內(nèi)容管理的技術(shù)作法不少,其中以條件式接取(CA)和數(shù)字版權(quán)管理(DRM)被視為基本的保護(hù)機(jī)制,新興的標(biāo)準(zhǔn)中較受重視的是安全視頻處理器聯(lián)盟(Secure Video Processor Alliance, SVPA)推出的SVP標(biāo)準(zhǔn)。以下將分別進(jìn)行探討:

          條件式接取(CA)


              CA是系統(tǒng)服務(wù)業(yè)者經(jīng)營(yíng)數(shù)字電視業(yè)務(wù)的一項(xiàng)關(guān)鍵性機(jī)制,它能為廣播式網(wǎng)絡(luò)提供“尋址化管理”(Addressability),其關(guān)注的重點(diǎn)是電視頻道與用戶的權(quán)限。用戶需通過專屬機(jī)頂盒或智慧卡來取得授權(quán),才能解開擾碼(Scrambling)。除了加解擾外,CA也能接收控制用戶的管理信息,包括用戶名稱、地址、智能卡號(hào)、賬單等等,并搭配后端客戶管理及收費(fèi)系統(tǒng)來提供更個(gè)人化的增值服務(wù)。

              由于CA得處理復(fù)雜的加解擾等演算問題,是機(jī)頂盒制造商較難跨越的一道門坎,也是掌握此技術(shù)公司的極大優(yōu)勢(shì)。過去CA往往與特定的系統(tǒng)設(shè)計(jì)公司的專屬機(jī)頂盒綁在一起,用戶一旦要換系統(tǒng),就得連機(jī)頂盒一同更換。這種情況除了造成系統(tǒng)公司與用戶的困擾外,也讓機(jī)頂盒因通用性低而受到局限,因此相關(guān)的組織或政府政策上都致力于推動(dòng)CA從機(jī)頂盒中獨(dú)立出來的機(jī)卡分離作法。

              以DVB來說,系統(tǒng)原先只就CA做了共同擾碼(DVB Common Scrambling)的定義,操作(Operation)及管理(Management)則開放讓系統(tǒng)設(shè)計(jì)公司可以自行開發(fā)。目前DVB已針對(duì)局端與客戶端分別提出了同步加密 (Simulcrypt) 與多重解密 (Multicrypt) 的方案,以解決互通操作上的問題。

              此外,美國(guó)、歐洲及亞洲多國(guó)都已將機(jī)卡分離視為電視產(chǎn)業(yè)發(fā)展的既定政策。目前將CAM(CA模塊)獨(dú)立設(shè)計(jì)的作法有三種,分別是采PCMCIA、USB或智能卡的方式,其中又以PCMCIA為市場(chǎng)主流,包括美國(guó)的POD標(biāo)準(zhǔn)及歐洲的DVB-C標(biāo)準(zhǔn),都以PCMCIA為其基本的物理接口。

          DRM


              CA的尋址化功能雖能對(duì)頻道及用戶做收視控管,但對(duì)于個(gè)別節(jié)目的內(nèi)容保護(hù)與授權(quán)就力有未逮,在此情況下,有必要進(jìn)一步采用DRM機(jī)制來提供內(nèi)容管理。這兩者是相輔相成的,CA是系統(tǒng)業(yè)者的收視管理及營(yíng)運(yùn)工具,而DRM則是內(nèi)容發(fā)行商的自我保護(hù)機(jī)制。

              DRM 采取的是許可證管理(License Management)策略,也就是由數(shù)字內(nèi)容發(fā)行商對(duì)原始檔進(jìn)行加密(一般采用128位或156位對(duì)稱算法),同時(shí)在添加的標(biāo)頭中加入作者、版本號(hào)、發(fā)行日期等版權(quán)信息。當(dāng)用戶想通過網(wǎng)絡(luò)或直接從光盤中取得內(nèi)容時(shí),系統(tǒng)會(huì)自動(dòng)檢查有沒有相應(yīng)的許可證(LICENSE),認(rèn)證的方式包括插入IC卡、IKEY(一種USB接口的身份認(rèn)證令牌),或經(jīng)由網(wǎng)絡(luò)認(rèn)證服務(wù)器來認(rèn)證其賬號(hào)、密碼。

              整個(gè) DRM 的建置架構(gòu)共分為 3 層:使用者接口應(yīng)用軟件、DRM 用戶認(rèn)證子系統(tǒng),以及最基本的加密引擎。其中用戶認(rèn)證子系統(tǒng)是IPTV業(yè)務(wù)推行的關(guān)鍵,目前有許多認(rèn)證系統(tǒng),兩種較典型的IPTV DRM系統(tǒng)分別采用Kerberos和PKI認(rèn)證機(jī)制。

              此外,就DRM的規(guī)格來說,目前市場(chǎng)上的規(guī)格相當(dāng)分歧,最受重視的無疑是Windows Media的DRM及開放移動(dòng)聯(lián)盟OMA推出的DRM 1.0/2.0規(guī)格,但仍有包括UT-DRM、NDS、SecureMe dia、WideVine、BesDRM等規(guī)格并存。為了讓用戶能收看不同來源的視頻內(nèi)容,今日的機(jī)頂盒只得盡量支持市場(chǎng)上的DRM規(guī)格。

            圖4  不同DRM規(guī)格的互通問題

            資料來源:Coral聯(lián)盟{(lán){分頁}}

              DRM保護(hù)內(nèi)容的立意雖好,但規(guī)格林立反而造成市場(chǎng)發(fā)展的阻礙,請(qǐng)參考(圖4)。為了使各種DRM規(guī)格能夠互通,包括惠普、飛利浦電子、ST、三星電子、索尼和20世紀(jì)??怂闺娪肮镜?0個(gè)公司組成了Coral聯(lián)盟,即致力于為基于WEB和家庭網(wǎng)絡(luò)的設(shè)備安全傳送內(nèi)容提供互操作性。目前該組織已公布一種互操作層,能支持多種DRM方案,其架構(gòu)請(qǐng)參考( 圖5),不過,微軟及Apple兩大公司的規(guī)格仍是例外。

            圖5  Coral聯(lián)盟提出的DRM互操作層節(jié)點(diǎn)作法

            資料來源:Coral聯(lián)盟

          安全視頻處理器(SVP)


              SVP標(biāo)準(zhǔn)主要由SVP聯(lián)盟推廣,目前已獲得20多家主要媒體與技術(shù)廠商支持,ST是該標(biāo)準(zhǔn)的發(fā)起會(huì)員之一。SVP聯(lián)盟的主要工作是在數(shù)字家庭網(wǎng)絡(luò),以及數(shù)字電視、機(jī)頂盒、DVR、可攜式媒體播放器等消費(fèi)性電子應(yīng)用中推廣其SVP內(nèi)容保護(hù)技術(shù)。

              SVP能與CA及DRM形成互補(bǔ)的機(jī)制,為數(shù)字內(nèi)容提供更完善的保護(hù)管理。通過SVP技術(shù),媒體公司可以自行設(shè)置其DRM規(guī)范來對(duì)其作品內(nèi)容加以保護(hù),并將來自CA系統(tǒng)的規(guī)則映像到SVP格式之中,最后再通過支持SVP功能的個(gè)人錄像機(jī)、DVD錄像機(jī)或PMP等設(shè)備解密還原為原始內(nèi)容呈現(xiàn)給觀眾。

              基本上,SVP技術(shù)是一種以硬件為基礎(chǔ)的安全方案,提供加密、傳輸和接收內(nèi)容及關(guān)于如何通過安全信道使用內(nèi)容的規(guī)則。其硬件核心只需不到20萬門電路閘,并在其上運(yùn)行一個(gè)安全軟件堆棧。這可以說是一種低成本、適合未來應(yīng)用的解決方案,因此ST的數(shù)字視頻處理器及解碼器已普遍支持SVP標(biāo)準(zhǔn)。

          結(jié)語


              為了應(yīng)對(duì)市場(chǎng)的變化,數(shù)字機(jī)頂盒必須具備提供產(chǎn)品開發(fā)的便利性及升級(jí)上的彈性,這包括設(shè)備開發(fā)層面及終端用戶的使用層面。在開發(fā)層面,目前關(guān)鍵零組件的廠商會(huì)提供完善的設(shè)計(jì)參考平臺(tái),讓設(shè)備商能夠加速開發(fā)時(shí)程,而且能在既有的設(shè)計(jì)基礎(chǔ)上,彈性地加入新的功能以推出差異化或升級(jí)的產(chǎn)品。在終端部分,機(jī)頂盒也需具有軟件升級(jí)的功能,也就是只需通過遠(yuǎn)程網(wǎng)絡(luò)的下載更新,就能升級(jí)其軟件或韌體。

              由于數(shù)字機(jī)頂盒是一個(gè)集合各種功能于一身的Hub,加上這一市場(chǎng)上的技術(shù)、標(biāo)準(zhǔn)與應(yīng)用需求變化極快,要想推出滿足各方需求且使用壽命長(zhǎng)的通用型機(jī)頂盒,是一件很不容易的事。除了上述的視頻轉(zhuǎn)換處理及內(nèi)容管理的設(shè)計(jì)關(guān)鍵外,在數(shù)字衛(wèi)星、地面及有線電視的服務(wù)上,信號(hào)回傳的互動(dòng)性是整體系統(tǒng)上的重要瓶頸;在 IPTV的部分,雖以互動(dòng)性見長(zhǎng),但如何保證串流視頻的服務(wù)質(zhì)量(QoS),并能提供HDTV的服務(wù),也是很大的挑戰(zhàn)。當(dāng)然,還有更多的挑戰(zhàn)及商機(jī)擺在眼前,例如數(shù)字電視與有線/移動(dòng)電話的整合等,是值得我們不斷去投入觀察的。


          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();