MHP

多媒體家庭平台（MHP）是由一個叫UNITEL的歐洲組織提出的，其目標是開發一個可接入多種數字多媒體服務的通用平台。

1993年，在數字電視的交互平台上提出該方案；

1997年，被列入DVB計劃中；

1998年7月，Sun Java虛擬機技術被加到MHP內核中；

2000年2月，Steering Board(EIGT指導委員會)第28屆大會批准在DVB中加入MHP1.0標準；

2000年7月，MHP1.0成為ETSI標準系列中的TS101 812；

2001年4月，DVB發佈MHP1.0.1一致性測試和版本文檔，DVB和ETSI中心達成MHP管理協議。MHP專家組着手開發MHP Test Suite;

2001年10月，ETSI發佈MHP1.0.1為TS101 812 V1.1.2；

2001年11月，ETSI發佈MHP1. 1為TS101 812 V1.1.1；

2002年4月，芬蘭成為世界上第一個通過使用MHP來實現無線實況轉播互動服務的國家；

2002年11月，Streering Board通過根據CableLabs OCAP（美國有線電視實驗室交互式服務的有線電視產業軟件標準）而制訂的GEM（Globally Executable MHP）第一個版本;

2002年12月，DVB通過MHP Test Suite 1.0.2b――第一個完整的MHP測試包；

2003年1月，ETS發佈GEM為標準TS102 819；

2003年4月，DVB批准MHP1.0.3,MHP1.1.1，並遞交給ETSI，分別進行作為標準TS101 812V1.3.1和標準TS102 812V1.2.1標準化工作；

2003年6月，ARIB（日本DTV標準）宣告在日本的數據廣播中接受基於GEM的應用環境；

2003年7月，ETSI就批准發佈標準ES201 812 V1.1.1(一個ETSI的MHP標準版本)徵詢意見。

多媒體家用平台(MHP，Multimedia Home Platform) 項目定義了交互數字應用程序和運行這些應用程序的終端之間的通用接口。它是由DVB組織於1997年提出的。它的目標是在家用平台建立標準的交互多媒體應用程序，實現從純數字電視廣播向交互電視應用的平穩過渡，徹底取代模擬電視廣播。整個項目不僅包括應用程序編程接口(API)，還涉及用户數字接入網等各個方面。2000年2月，DVB組織通過了MHP標準(MHP1.0)，2000年7月，歐洲電信標準化研究所(ETSI，European Telecommunications Standards Institute)正式接受了這一標準，編號TS 101 182，為正式部署標準鋪平了道路，更新的MHP1.1標準正在討論中。MHP項目的實施將有利於廣播、電信和計算機技術的進一步融合，併為運營商提供更全面、更強大、更靈活的技術解決方案。

DVB組織是由全世界30多個國家超過260個成員組成的合作組織，核心機構是DVB指導委員會(the DVB Steering Board)，對所有DVB標準和技術規範進行最後認證。MHP項目遵循DVB的慣例，將項目分解成兩個模塊即技術模塊和商業模塊。分別制定技術解決方案和商業解決方案。

MHP項目組針對兩個模塊建立了兩個工作組：

① 面向市場的工作組，主要定義基於本地網進行增強和交互電視廣播的用户和市場需求(包括互聯網訪問等)。

② 面向技術的工作組—DVB-TAM(Technical

Issues Associated with MHP)，解決DVB編程接口(API，Application Programming Interface)的規範等問題。

數字電視軟件平台—中間件由於各個廠家提出互不兼容的解決方案，尚無統一的定義和標準。一般認為：中間件指居於數字電視機頂盒內部實時操作系統與應用程序中間的軟件部分，它以應用程序接口API的形式存在，整個API集合被存儲在機頂盒的閃存FLASH中。MHP項目組就是致力於出台統一的中間件標準。表1列出一些典型數字電視系統和中間件提供商，其中的數據統計至2001年初。

表1 部分公司中間件情況比較

MHP項目組考慮以下幾個參考API候選方案：

· MHEG-5

· Mediahighway+

· OpenTV

· HTML/Java

· JavaTV

多媒體和超媒體專家系統(MHEG-5)是進行增強廣播服務的一種格式，能在擁有有限資源的終端上運行基本類型應用程序，它採用開放態度描繪編程對象，以便這些對象既能應用於標準化編程又能滿足特定的編程需求。

Mediahighway+和OpenTV系統在本文應用實例部分中將有詳細介紹，這裏不再重複。

HTML是互聯網上通用的標準語言。它是一種純解釋性語言，需要在本機上運行解釋器。

ava是由SUN公司開發的新一代編程語言，本來是想應用於智能型家電產品，但目前卻成為互聯網編程語言的主流。它是面向對象的程序語言，類似於C++，但摒棄了C++語言中少用且不好用的部分，它的特徵有跨平台、多線程、分佈式等，使用它可在各式各樣不同種機器、不同種操作平台的網絡環境中開發軟件 “一次編譯，到處運行”。它徹底改變應用程序的開發模式，帶來了自PC機以來又一次技術革命。

Java應用程序必須通過與操作系統密切相關的Java虛擬機，才能實現其功能。針對實時操作系統(例如HOPEN 、VXWORKS、PSOS)開發的嵌入式Java虛擬機可以為Java程序提供支持環境。實時操作系統支持面向消費類電子產品的Personal Java應用環境。這意味着不論在家庭、辦公室，還是在旅行途中，普通消費者能通過Java虛擬機技術，在實時操作系統和Java API上體會交互式電視機、電冰箱、烤麪包箱、防盜設備等方面豐富多彩的生活模式，通過TCP/IP進行信息的交流，實現家庭信息化、智能化。

Java TV API是由SUN公司和各大數字電視公司通過開放式研究在Java平台的基礎上開放的產品，是計算機界的巨頭之一。SUN公司進軍數字電視廣播領域的拳頭產品。它藉助Java這一跨平台語言，針對增強電視和交互電視進行加強和優化，主要電子消費型產品生產廠家已公開聲明他們的產品將支持 Java TV API並將其作為全球數字電視軟件平台標準。

Java TV API 是針對數字電視接收機獨有的功能而設計的，這些功能有：

·音頻/視頻媒體控制

· 廣播數據訪問

· 服務信息數據訪問

· 調諧器和譯碼器控制

· 屏幕圖形處理

DVB組織在考慮API候選方案時採用開放的態度，能適應不同層次運營商(稱為水平市場)的要求，API的選擇是與條件接收系統無關的，但同時能支持多密應用。

MHP主要定義了機頂盒中間件的整體結構、傳送協議、內容格式、Java虛擬機和DVB-J APIs、安全性、各層的細節、應用狀態和表現、應用的自動啓動等，還定義了專用的應用信令。

MHP被定義成三層：資源層，系統軟件層和應用層。典型的資源層包括：MPEG處理，I/O設備，CPU，存儲和圖形系統。系統軟件層給應用層提供一個抽象的可視的平台，通過執行一個應用管理器（亦被稱作navigator）來管理MHP和MHP上的應用。

現有的每個MHP系統都提出了不同的參考模型。DVB-TAM工作組運用面向對象，工具定義了應用程序類和函數，結合MHP系統需求的軟硬件資源(模型見圖1) 最終建立了一個整體參考模型，如圖2所示。整體參考模型包括5個層次(見圖3)：

應用程序(內容、腳本)和多媒體部件(視頻、音頻、字幕)；

· 編程接口API。

· 平台/系統軟件或中間件，包括交互式應用引擎、實時引擎或虛擬機，應用程序管理器等。

軟硬件資源和相關軟件。

主要系統功能有。

· 應用程序發送和控制功能、事件管理功能。

· 條件接收功能。

· 內容下載功能。

· 導航功能。

· 內容顯示控制功能

· 通信和I/O控制功能。

· 底層驅動管理功能。

根據這一參考模型，用户能夠獲得以下服務。

· 增強的廣播服務。

· 交互式廣播服務。

· 互聯網服務。

MHP的核心部分——系統軟件的本質就是一箇中間件。與其它的中間件不同的是，MHP中間件不是一個私有的中間件，它是一個開放的、統一的中間件。MHP標準只是定義了一些API接口，它沒有給出實現MHP的方法，因此，實現MHP的具體方案主要由中間件廠商和機頂盒廠商給出。

許多軟件包提供了該平台的常用API。MHP應用只需通過這些指定的API訪問平台。在指定API跟底層資源和系統軟件之間需要一個映射。

MHP建立在DVB－J的基礎上。DVB－J包括Sum Mircosystems公司的Java虛擬機。

（1）應用程序（Application）

由參考模型提供的環境能很方便地對應用程序進行測試和認證，完全依照參考模型設計的應用程序一般能順利運行。而對應用程序提供商來説，他們的權益也受到保護。因為他們能設計出靈活的應用程序，可以廣泛應用於不同的平台，而不受機頂盒底層的限制。

DVB-TAM對應用程序的定義是：能用軟件模塊實現交互式服務的功能性應用。一個應用程序也可以看作是一系列能激活MHP軟硬件資源的函數。

一個交互式的應用程序由以下兩大基本部分組成：

· 應用程序腳本(解釋型的或過程型的)；

· 內容/場景(用户圖形接口和媒體流)。

用户圖形接口(GUI)是用户與機頂盒交互的接口，包括場景設計、選擇按鈕、靜止圖像、文本等。整個用户圖形接口可以説由許多幕場景組成，每幕場景又是由一系列小部件、編程對象和屬性構成。而各場景之間、各個編程對象的聯繫則由特別的機制完成。

過程型的應用程序，是基於低端函數和類庫的程序，通常用於需要對主機資源進行優化時(如對傳輸網絡資源進行最大化利用等)。它一般是平台相關性的，因此當移植到不同的主機平台時需要進行相應的變化。

解釋型應用程序由高端函數和類庫組成。這就允許我們能用平台無關性的參考模型來檢驗應用程序是否具有平台兼容性。

實際上，應用程序不一定全是解釋型的或全是過程型的。例如，我們可以在解釋型應用程序中嵌入過程型的代碼，這樣可以極大地減少代碼長度和程序執行效率。而平台無關性的問題則由主機內嵌的實時引擎、虛擬機來解決。當然如果在平台設計時沒有考慮兼容性的問題，那麼要想實現不同平台的良好移植性是很困難的。

應用程序是可標識的，它可以自動運行或在受請求後運行。應用程序的顯示模式是大小可調的，或在後台運行。對應用程序的管理包括：中斷、錯誤處理、優先級模式、動態資源管理。在退出應用程序時，應該釋放系統資源。

（2）應用程序發送機制（Application delivery mechanisms）

程序腳本和相關內容打包成應用程序對象後，轉換成DSM-CC對象。DSM-CC標準是由MPEG組織制定的，與網絡通信協議類似，數據廣播的前端和數據廣播接收裝置之間必須有一套通信協議來保證數據的傳輸和解碼，MPEG-2標準的第6部分DSMCC就是這樣的一種開放協議。與其他協議相比較，DSMCC主要考慮的是在接收端設備資源有限的情況下如何實現快速的數據傳輸。DSM-CC UU是一種接口，允許我們從廣播流中或從遠端服務器中獲取DSM-CC格式的對象。

DSM-CC對象允許一個數據環模塊攜帶一個或多個程序對象。對象是模塊化的，這樣可以優化內存使用性能。DSM-CC也提供壓縮工具來格式化程序對象和數據環對象，發送機制還確保數據環對象下載的安全性。

（3）編程接口定義（API）

DVB-TAM對API的定義是：它是一系列高端函數、數據結構和協議，用來表示有關平台獨立性軟件的標準接口。它應用面向對象的語言，並能靈活地再複用已有的函數。

一個應用程序根據高端API的定義描述一系列的對象。它定義了應用程序與本機硬件資源、軟件資源之間的接口。

對API定義了以下的要求。

· 繼承性：它是可複用的。對於面向對象的語言來説，可繼承性是一個很重要的特性，父類(super class)中的數據或方法其子類(subclass)可繼承使用，子類的子類也可繼承使用，從而實現數據重複使用(reuse)，極大的提高了編程效率。

· 開放性：它能被其他接口實例引用。

· 抽象性：利用抽象數據類型將低端的特性封裝起來，不能被直接運用。只有通過授權的行為才能與外部交互，從而保證源代碼的完整性和安全性。

· 靈活性：它是硬件獨立的，在將來由於硬件升級和換用不同的硬件系統時，API也能升級。如可以通過下載增加新的類庫等。

根據應用程序的不同格式，低端API用來處理進程型函數，同時高端API用來處理解釋型函數。

· 低端API對應於進程型程序。此類API不僅需要闡明應用函數，還要關心資源的情況。

· 高端API對應於解釋型程序。用於抽象解釋層的級別越高，系統的獨立性就越強。API只需要闡明應用函數，不需要關心資源是否被激活。開放API定義的制定將保證DVB機頂盒實現硬件無關性功能。

DVB-MHP對API的功能表述如下。

· 支持本機存儲的或實時下載的應用程序。

· 支持所見即所得。

· 支持對數據庫的訪問(如DVB-SI表單)。

· 兼容性。

作為MHP項目的核心部分，一個開放的、有發展前途的API標準應該是模塊化的、可移植的、靈活的、可擴展的。它允許內容和服務提供商應用不同的但相互兼容的平台提供服務。

（4）導航系統（Navigation/Selection）

當機頂盒啓動後，內嵌的導航函數通過調用相應的API運行第一層的導航程序。API也能用來對TS流進行控制，如瀏覽頻道和節目。

導航也能直接由可執行代碼運行，而不需要運用API和相關解釋器。在DVB-TAM推薦的模型中，導航系統模塊與API位於在同一層次，以便能方便的從數據管道和TS流取得數據。

基本的導航系統包括以下兩個功能。

· 列出全部可用的節目清單。

· 提供快捷鍵方便用户訪問節目內容。

增強型的導航系統由電子節目指南(EPG)實現，增強功能包括用户文件夾和書籤等。

（5）應用程序啓動和控制（Application Launch and Control）

一個應用程序的運行包括啓動、應用和表現幾個部分。程序代碼可駐留在機頂盒中或從遠端服務器中下載。如果是從遠端服務器中下載的，應用程序能自動升級。

應用程序管理器的功能是。

· 獲取和釋放系統資源。

· 錯誤管理和例外處理。

· 初始和中斷會話(Session)。

· 檢驗代碼和數據的完整性。

· 同步指令和信息。

· 調整顯示圖形格式以適應不同平台的要求。

· 允許對內容和變量的共享。

· 擁有有序和整潔的表現式樣。

（6）加密功能（Security Functions）

雖然加密模塊的定義尚未完成，DVB還是定義了涉及加密的API的要求。

· 應該使用通用的加密模塊，以保證不同廣播運營商和內容提供商在交換節目時的兼容性。

· 涉及加密的API應該是與條件接收系統無關的。如果有必要的話，MHP 的API應該對CA相關函數開放。

重要的安全方面的考慮還涉及：

· 對系統資源的保護以防濫用，如對內存的過量訪問。

· 對專用數據的保護以防未授權的訪問。

（7）中間件（Middleware）

節目服務商將各種服務項目以應用程序的形式通過傳輸信道(例如，寬帶多媒體數據網，有線電視網絡)發佈(如，EPG)，用户打開電視機通過機頂盒瀏覽。用户的需求信息(例如，視頻點播VOD)通過上傳信道(例如，電話線Modem或有線電視電纜)傳輸到視頻服務器，並根據請求選擇相應的服務項目以應用程序的形式通過傳輸信道下載到用户終端－機頂盒的閃存Flash中。應用程序調用機頂盒Flash內的中間件所包含的API，執行應用程序，完成用户請求的功能。

中間件的目的是使機頂盒基本的和通用的功能以API的形式提供給機頂盒生產廠家，以實現數字電視交互式功能的標準化，同時使服務項目(以應用程序的形式通過傳輸信道)下載到用户終端－機頂盒的數據量減小到最低限度。中間件產品一般由非節目提供商和非機頂盒廠家的第三方提供，對於使節目提供商製作節目和廠家生產機頂盒的進一步簡化和標準化都是非常有利的。這正是知識經濟時代市場更加細分的具體表現。

中間件的實現直接取決於應用程序的格式(是解釋型的還是進程型的)以及應用高端還是低端的API。每個成功的中間件實現都是根據本機平台的特點量體裁衣。

實現交互和實時引擎有不同的方法，但通常需要有以下幾大模塊。

· 庫函數；

· 腳本和內容解釋器；

· 事件管理器(處理遙控器和其他設備、用户響應、標識、定時、錯誤處理)；

· 自舉(Loader)。

依靠使用API，實時引擎提供與系統硬件和軟件低層接口。實時引擎能喚醒駐留在本機內的程序，而駐留本機程序則可以是與平台相關的，從而在解釋性應用程序層面提高系統性能和減少操作性的限制(如壓縮下載應用程序對象的大小) 。實時引擎是可執行代碼，參照參考模型並根據各個平台特點優化。

虛擬機通常用來運行過程型函數(例如複雜的計算、信息和文本處理、數據壓縮)或駐留程序，以加強解釋性應用程序的性能。

由於實時引擎和虛擬機的應用，使得API能實現與平台無關性的應用程序。

（8）軟硬件資源（Hardware and Software Resources）

MHP應該是有友好的用户界面的。對於周邊設備來説，顯示設備、輸入設備如(遙控器)是必須的，另外可以選擇使用鍵盤，本地的內置或外置的存儲設備。而這些周邊設備的連接應該是“即插即用”的。

對於一台基於MHP的機頂盒來説，內部硬件資源包括：前端、解複用、解碼、濾波、通用接口、通訊接口、CA系統、內存和相關的驅動等。

要實現目前DVB的標準功能，需要機頂盒有至少1MB閃存和1MB內存，同時需要CPU的速度達到20MIPS。如果有16MB閃存和32MB內存及100MIPS的CPU的話，就能做到遊刃有餘。硬件資源可特別分配，如指定70%的CPU處理時間用於運行應用程序，而餘下的30%的時間用於系統管理。

在內存中存儲瞭如下內容：

· API的解釋器；

· 庫函數；

· 實時引擎和虛擬器；

· 自舉(Loader)；

· 系統工具；

· 文件系統；

· 固件(firmware)；

· 操作系統(包括啓動、內存管理、任務管理、資源管理、時針等)；

· 驅動；

· 導航系統。

在閃存中允許下載多個版本的應用程序。同時對內存的管理也是相當靈活的，採用分塊管理，用於不同程序的內存段有不同的標識，可以只對某一內存段的程序進行刷新。

由DSM-CC循環發送下來的應用程序存儲在RAM中，同時RAM可用於存儲視音頻解碼的數據緩衝，用於動態平台管理(如堆棧、過程排隊等)，用於存儲應用程序中用到的變量。

最基本的系統設置和出廠設置通常存儲在EEPROM中(一般不超過10KB)。

MHP把所有的交互作用按照應用領域劃分成三個層次：增強廣播，交互廣播和Internet訪問。

（1）Internet訪問

該層次是交互廣播的超集，它提供了互聯網服務（E-mail,Web瀏覽和chat等）。

（2）增強廣播

該層次的應用不需要回傳信道，只需下載應用後，在本地與視音頻實現交互；

（3）交互廣播

該層次是增強廣播的超集，應用需要回傳信道，能夠實現真正的交互；

（1）傳輸協議（DSM-CC Object Carousel, DVB Object Carousel 和IP等）；

（2）內容格式

圖形格式: PNG、GIF、JPEG、MPEG-2　I幀或P幀、MPEG-1/2音頻、DVB字幕、UTF－8；

碼流格式: MPEG－2視頻、MPEG－1/2音頻、DVB字幕、DVB圖文電視、駐留字符、下載字符、HTML和XML；DVB-HTML(HTML4.0,ECMAScript,CSS2和DOM2);應用模式和信號機制；DVB-J平台（DVB API,Java API,Java TV）;安全加密；層次定義；互聯網訪問。

Java TV API是基於Personal Java應用環境的應用程序接口，是Java平台面向 MHP終端的擴展，它提供了對MHP終端特有功能的控制，包括對業務信息數據庫的訪問、業務選擇、TV上的媒體播放器控制等。Java TV API是針對終端媒體及接收功能的，不包括其他電子設備共有的API。由於Java TV API是獨立於硬件和物理線纜傳輸協議的更抽象的高層協議，因此也可以在一些現存的標準中使用。此外，MHP終端中各種應用的生命週期由Java TV API的Xlet應用模型定義。Xlet運行時可以進行資源的申請和釋放，顯示內容的存取、發現和選擇業務。

在MHP中，幾種不同類型的程序包交織在一起成為一個混合體，主要的程序包有pJava、 DAVIC、DVB、 JavaTV和Havi等。Personal Java標準包是由Sun公司定義的基於pJava 1.1.8的標準包。DVB是由DVB/MHP技術委員會提供的程序包，它主要是對DAVIC 程序包及一些Java標準包的補充。在這些程序包中，有不少存在着嚴重的設計缺陷。例如，相對於 DAVIC/DVB程序包而言，JavaTV程序包的作用並不大。JavaTV程序包主要由JavaTV Consortium提供，Sun系統公司掌握着其知識產權，其內容幾乎含蓋所有的DAVIC和DVB程序包，但它並沒有一個明顯的資源管理模式，如果幾個應用程序同時需要同一個資源時，不同的實現模型便會有不同的結果。

Havi圖形包也有其缺陷，它建立在java.awt基礎之上，可利用AWT的 lightweight component重建一套與AWT一樣的二維圖形widget體系。但由於它不能完全取代AWT，因而造成了兩種圖形包共存的局面。另外，DVB-HTML標準也不是很成功。在MHP標準的形成過程中，對HTML的定義也一直存在着激烈的爭論。

在MHP中存在的種種問題已為人們所認識，它的1.0更正版（1.0.1）就提出1000多條修改和重建程序包的意見，而且其測試程序包也遲遲不能完成，這些都説明了其繁雜的程度 。

當然，DVB/MHP也有不少可取之處，主要有兩點：一是應用程序下載後的標識和運行模式；二是應用數據認證，以及機頂盒內部資源的權限管理和X.509認證書的應用，這使得它與目前互聯網傳輸數據的認證取得一致。

向MHP遷移的過程是整個機頂盒軟件系統向通用MHP系統遷移的過程，重點在於API。DVB-MHP的説法是：“只有當服務商開始提供與MHP兼容的解決方案時，移植過程才算正式開始。”

DVB標準機頂盒已經採用了許多通用標準，包括調製、複用、MPEG-2視音頻、DSM-CC UU接口和協議、通用接口(用於針對條件接收和其他應用)，以及DVB-SI。

然而，不同的系統在很多地方存在不同的格式：

· 組合應用程序腳本和源碼、數據和內容的方式；

· 解壓縮工具；

· 內存分配和管理(應用程序排隊機制和垃圾收集機制)；

· 進程型函數格式；

· 庫函數(進程型函數擴展、圖形)；

· 數據環或其他循環數據發送機制；

· 下載過程和工具；

· 交互機制；

· 變量格式；

· 加密格式。

DVB要求在多服務提供商或多應用程序環境中，基於MHP的解決方案應該是數據可分離的。這就保證只要是通過認證的應用程序，採用通用數據格式，它們之間能利用相同的數據，特別是運用不同的應用程序完成相同任務，而為特定的應用程序保存部分數據也是能夠實現的。

從系統層面上看，應該仔細考慮如何實施遷移以便充分利用DVB-TAM的API。這將有助於機頂盒的可移植性和機動性。特別是對於數字地面廣播來説，面對水平零售市場，如果增加內容是有限的，用户不願意投資購買多個機頂盒。

遷移的過程可能不會一帆風順，需要處理好與現有使用平台兼容性的關係。

通用API的廣泛使用將帶來廣闊的前景，給服務提供商的經營和運作帶來顯著的變化。為了適應不同的平台應用，在運用通用API時，一般應遵循以下規則：

· 應該採用相同的數據環對象格式，在廣播流中傳輸這些對象也應該應用相同的機制。

· 應該採用通用的壓縮方式。

· 應用程序必須是可下載的，在應用程序未被激活時，不需要依靠永久存儲設備。

· 通用庫函數(進程型擴展、圖形等)和駐留程序應該是內嵌的以縮減程序的大小。

· 應用程序、數據和解釋接口應該根據通用方案組織。

· 應該採用相同的啓動和結束應用程序進程的方式。

MHP平台將不停發展，來支持越來越多靈活的、複雜的應用程序。這就需要對API進行更多的擴展。未來的方向是加大這些系統部件和進程的通用性，這將提高系統的性價比，並能有效延長設備的使用週期。

目前，世界上流行的數字電視中間件產品主要有: Canal+ MediaHighway ；OpenTV；NDS等。而國內從事數字電視開發的公司也積極推出自己的產品，如深圳迪科是國內較早進入交互電視領域的公司，目前在市場上已有一席之地；天柏寬網與國外廠商合作，推出了基於Java的中間件產品，其技術水平同步於國外先進水平。現試取較典型的產品進行分析。

（1）Canal+ MediaHighway

Canal+ Technologies的定位既是運營商又是系統集成商，提供除前端設備以外的軟件產品，包括：CA(MediaGuard)；中間件(MediaHighway)以及應用軟件，包括機頂盒開機界面(Mediastart)、頻道列表、遊戲、EPG、股票信息、HTML廣播等；開發工具(Studio+)。由於作為運營商，積累了大量經驗，這對解決系統在涉及運行中出現的問題很有幫助。

Canal+有20多個網絡，但由於系統全線採用自己的產品，開放性較差。

（2）OpenTV系統

OpenTV是世界上運用最多的交互電視解決方案之一，銷售到世界各地的數字電視接收機中有930多萬台安裝了OpenTV的系統軟件。到目前為止，OpenTV的軟件方案已經被世界上的30家電視網絡所使用。其中包括英國空中廣播(BSkyB)、法國的TPS、美國的EchoStar的DISH網絡。OpenTV是數字視頻廣播(DVB)項目組的成員，並且擁有Sun公司的Personal Java™ 的使用許可。

OpenTV系統為創作和發送可下載的交互式應用提供了工具，這些交互式應用包括電子節目嚮導(EPG)，家庭購物、家庭銀行、股市行情、電子郵件、交互式廣告和遊戲。使用OpenTV軟件，觀看現場直播體育比賽的電視觀眾能及時獲取其他賽場上當時的統計數字和得分情況，而不需要等待電視台來向觀眾提供這些信息。這些應用都可以通過遙控來實現，而並不需要鍵盤。

OpenTV也提供了用於創建、廣播和接受交互式電視業務的端到端的產品系列，包括軟件開發包(SDK) 是一個強有力的創作工具包，讓掌握C編程的開發人員可以在NT或者Solaris系統下使用包括編譯器、流調試器、編輯器在內的一整套開發工具來開發電子節目單程序或其他的交互電視應用程序。OpenAuthor針對非編程人員。它是一種基於GUI(圖形用户界面)的拖曳式開發環境，給交互式工具和應用的開發提供了模板及可擴展的結構。OpenTV STUDIO是集成的交互式應用開發工具，包括OpenAuthor和SDK。在廣播前端系統中，OpenStreamer能實現實時廣播數據流的更新，使得股市行情、體育比賽及時報道以及類似的一些應用可以在次秒量級上更新數據。可以説OpenTV的操作系統/運行環境為交互數字電視提供了較為完整的系統解決方案。