多媒体家庭平台，是由DVB联盟制定的一种标准，开始于1997年，DVB-MHP的工作不仅覆盖应用程序接口API，而且还包括家庭数字网络（IHDN）和本地集群，其目的是标准化家庭平台，这对于未来成功应用交互式多媒体是很关键的。它同时也可以看作是DVB纯广播工作到交互式TV应用的自然升级，推动了电视业务从模拟电视到数字化电视的过渡。

多媒体家庭平台（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的操作系统/运行环境为交互数字电视提供了较为完整的系统解决方案。