1、前言

数字电视自从1995年投入运营以来，中间件业务平台就一直是人们研究和讨论的课题。以欧洲为代表的数字电视运营商，一直认为开展数字电视增值业务是其发展的最终目的，数字电视需要中间件平台，对互联网应用需要进行有限度的兼容和采取围墙式的管理（Walled Garden）。这是一种从“电视”向“互联网（或计算机）”靠拢的观点。以美国人为代表的观点认为，数字电视接收设备就是一个互联网终端，植入浏览器软件，运行网页浏览，就可以实现数字电视娱乐。这是一种从“互联网（或计算机）”向“电视”靠拢的观点。由此可以看出，欧洲人考虑的是怎样从数字电视运营中发展增值业务、获取收益；而美国人更多的是积极寻求将家庭设备也互联起来，让互联网的丰富内容走入家庭的客厅终端。

不同的思想产生不同的技术路线。于是，以规范中间件平台架构、接入协议和应用开发为核心的中间件平台标准——MHP（媒体家庭平台）——从欧洲诞生。美国人将互联网植入数字电视机顶盒的努力，一直都不曾中断过。美国的ATVEF（Advanced Television Enhancement Forum，先进电视发展论坛）早在1999年就发布了基于互联网HTML的交互应用规范。微软公司自1998年就推出了WebTV，直到近几年的Mediaroom，为微软操作系统入主消费电子花费了巨大财力、物力，行业内人士可能都不会忘记“维纳斯”计划。美国还产生过知名的数字电视浏览器技术公司——Liberate。以增值业务为目标的各式中间件平台以及以MHP为基础的不同中间件规范（如美国有线电视联盟的OCAP、中国标准草案DTVM、日本ARIB、巴西Ginga-J等），还有众多的中间件业务平台在全球各地不同数字电视运营商的运营中发挥着作用；而希望将将互联网搬到电视的努力却显得非常艰难：ATVEF标准基本被人遗忘，微软公司的WebTV平台和维纳斯计划无疾而终，Liberate也是早就宣告破产了。2006年，Apple公司推出了AppleTV，其优美的设计和良好的用户体验曾经让很多人喜爱，但是，真正的市场效果却并不理想，直到目前都还没有具有商业意义的市场部署。

然而，互联网技术与网络宽带的不断发展、信息与视频内容越来越丰富，尤其是近年出现的社交网络、云计算等概念与系统、移动互联网等，使得“电视”与“互联网”之间的融合成为不可阻挡的趋势。但是，这两者之间究竟如何“相会”，欧洲人与美国人又有不同的理解：欧洲的数字电视业界推出了基于中间件平台兼容互联网（宽带）的双模业务系统——HbbTV；而美国人持续在互联网浏览器架构上努力，在其Android系统在移动领域（手机）上成功的基础上，Google公司将它推向了数字电视领域，形成了GoogleTV。

当前，有一种观点认为，由于其源代码的免费开放，GoogleTV会迅速取代中间件系统，成为一统天下业务平台。本文试图从技术和运营商业务需求的角度，阐述这两个系统的发展前景。本文的观点纯属个人观点，欢迎业界同仁批评指正。

2　HbbTV与GoogleTV平台的技术特征

2.1　HbbTV平台的技术简介

HbbTV（Hybrid Broadcast and Broadband Television）是在MHP标准平台的基础上演进与发展起来的。严格意义上将，MHP标准也定义了对互联网协议（TCP/IP, HTTP等）的支持，但标准的大部分规范还是只对广播环境的应用下载与管理、应用生命周期管理、应用编程接口等进行了详细的规定，对采用互联网技术（HTML、JavaScript等）进行应用的开发与管理定义不是具体。HbbTV弥补了MHP中间件平台这些方面的不足，对互联网技术如何与广播通道的协调进行了细致的规范。由DVB提交的ETSI标准（ETSI 102 796 V1.1.1 2009-12和ETSI 102 809 V1.1.1 2010-01）对HbbTV的技术架构与应用管理进行了明晰的规范。

2.1.1　HbbTV平台的架构与功能

HbbTV定义的是一种双模终端（Hybrid Terminal），可以在没有宽带连接时，总是与广播电视网络连接着，以便不间断地接收音视频节目和相关应用，也可以同时支持广播与宽带网络的连接。下图显示了HbbTV的业务（应用、视频等）的通道来源。

图为：HbbTV业务的通道来源

下图描绘了HbbTV系统架构和主要功能组件，主要组件的功能在图后进行了简单说明。

图为：双模终端软件系统功能组件示意图

通过广播电视通道（Broadcast Interface），双模终端接收AIT数据、线性音视频节目、应用数据和流事件（Stream Event）。后两者数据采用DSM-CC对象轮播协议（DSM-CC Object　Carousel）传送。因此，DSM-CC客户端（DSM-CC Client）需要嵌入以便接收数据传送到运行环境（Runtime Environment）。运行环境可以看成是非常抽象的组件，执行应用、显示界面。浏览器（Browser）和应用管理器（Application Manager）是这个应用运行环境的组成部分。应用管理器解析AIT数据以便控制应用的生命周期；浏览器执行和呈现应用。

线性的音视频内容的处理与广播电视终端（或只支持卫星、地面或有线数字电视的终端）完全一样，所有与DVB相关的功能也都完全支持（如频道列表、EIT信息处理、选择业务与调频等），由广播处理器（Broadcast Processing）组件处理，音视频等媒体内容的播放由媒体播放器（Media Player）组件负责。

通过宽带通道（Broadband Interface），双模终端能够连接到互联网或其它的IP网络。它提供了应用数据接收的第二个通道，以便与应用提供商的服务器连接。这个连接用于接收非线性音视频内容（如内容点播业务）。互联网协议处理器（Internet Protocol Processing）组件包含了处理来源于互联网等IP网络数据的功能，通过这个组件，应用数据提供给运行环境，非线性音视频内容传送到媒体播放器（Media Player），包含在应用中解析、呈现与播放。

2.1.2　HbbTV平台的业务与应用模型

HbbTV支持两种类型的应用：1）广播电视相关的应用，通过广播电视通道传送；2）独立于广播电视的应用，它们不通过广播电视通道传送。

根据应用与广播频道（Service）绑定或网络连接的不同情况，还可以有如下不同的应用模型，下面从简单到复杂列出了几种：

只与一个广播频道相绑定的应用：在频道选择时，应用启动；在频道切换走时，应用终止；

与多个频道相绑定的应用：在其中的任何一个频道选择时，应用启动；在此频道切换走时，应用终止，即使新频道也有此应用与其绑定；

在频道切换时保持运行的应用：这种应用与多个广播频道绑定，在任何一个相关频道选择时，应用启动；而当切换到新的也与此应用绑定的频道时，应用不终止、继续保持运行；只有当选择的频道上不再有此应用与其绑定时，应用终止；

与广播频道的部分内容绑定的应用（例如，与单个的节目或广告内容绑定）：在相关内容启动时，应用启动；当相关内容终止时，应用终止；

与点播的内容绑定的应用：其控制，要么与广播频道部分内容绑定的应用一致，要么，在整个的点播过程中都保持有效；与网络运营商或与服务提供商相连接的应用：在某些部署中，这种应用连接可以是永久的（permanent）。

HbbTV标准对通过广播通道、宽带通道进行传送应用的启动、终止等生命周期管理，都进行了详细的规定。下图显示了应用生命周期状态转换的过程。

图为：应用生命周期和状态转换示例

终端用户可以通过下面的方式访问互动应用（Interactive Application）：

通过启动一个广播频道相关的自启动应用（Autostart Application）上的红键（Red Button）；

通过TEXT键（TEXT Button）启动一个数字字幕应用（Digital Teletext Application）；

通过互联网电视门户启动一个厂商设置的非广播应用；

通过启动正在运行应用上的一个超级链接；

通过选择一个广播频道，其上有一个全屏的自启动应用。

2.1.3　广播相关自启动应用的访问

广播相关自启动应用通常与广播频道或其上的节目与事件相关联，在第一种情况下，此自启动应用应该立即启动；在第二种情况下，会有下列情形：

显示一个红键（Red Button），指示有应用可以启动；

不显示用户界面；

显示一个全屏（如在音频应用和数据应用时）

一般情况下，自启动应用不显示全屏。当有一个红键（Red Button）指示有应用时，用户按红键（Red Button）将会全屏显示；如果没有广播相关的自启动应用，按住红键（Red Button）则无任何反应。

图为：红键（Red Button）指示有应用，按红键（Red Button）全屏显示应用

上图显示了广播相关自启动应用通过红键（Red Button）启动的情形。

2.1.4　非广播相关应用的访问

非广播相关的应用是指独立、不通过广播通道传送的应用，它一般是通过电视门户（TV Portal）来访问的，互联网电视门户是一个应用，它提供一种起始网页，其中的非广播应用进行一定的排列和展现，使得用户能够很方便地浏览和访问其设置和关联的应用（非广播相关的应用）。

图为：互联网电视门户的启动

应用的退出一般采用退出键（Exit Button），或应用指示的方式。

我们可以看到，HbbTV定义的是既支持广播业务，又支持宽带业务的数字电视中间件技术架构，能够并行地支持与两个网络连接：一方面，它能够连接广播电视的DVB网络（如DVB-T、DVB-S或DVB-C），通过广播电视网络，双模终端能够接收标准的广播电视节目，这是一种线性方式的音视频内容、应用数据和应用信令信息；另一方面，双模终端能够通过宽带与互联网（IP网络）连接，支持与应用服务器的双向通讯，这种方式使得终端能够接收非线性的音视频内容和应用数据，还可以下载非实时的音视频内容。

2.2　GoogleTV平台的技术简介

Google公司在互联网搜索领域取得巨大成功以后，也在努力进入消费电子领域。他们巨资开发的Android平台，在手机领域开始崭露头角，接着又将其推广到数字电视领域。下面我们着重介绍和探讨GoogleTV设计理念和技术框架。

2.2.1　GoogleTV平台的设计理念

Google TV是一个整合计算机系统、媒体播放与网络应用的概念型电视平台，由Google公司主导研发，并且免费开源发布。Google TV的应用涵盖下列领域：

图为：GoogleTV设计的理念

通过上图可以看出，就硬件而言，除了在实际操作环境可以搭配多样化的周边设备外，Google TV在规格表现上也有诸多要求；在软件方面，GoogleTV将其搜索引擎及Android系统加进了GoogleTV的平台之中；在应用提供上，与内容提供商合作开发，以便具有广阔应用与业务开发群体，形成Android应用商店。

2.2.2　GoogleTV平台的技术架构

GoogleTV的核心软件系统是Android平台，其架构见下示意图。

图为：GoogleTV软件核心Android架构

Android是一个模块化与层次性的架构设计，这也是平台化软件设计通用的设计理念与架构模式。Android主要有5个层次：

1）应用程序层

Android 会同一系列核心应用程序包一起发布，该应用程序包有 email客户端、SMS 语言编写的。?短消息程序、日历、地图、浏览器、联系人管理程序等。所有的应用程序都可以使用Java

2）应用程序框架层

开发人员也可以访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用；任何一个应用程序都可以发布它的功能块并且任何其它的应用程序都可以使用其所发布的功能块（其实，软件在一起是很难控制不被调用的）。同样，该应用程序重用机制也使用户可以方便的替换程序组件。

隐藏在每个应用后面的是一系列的服务和系统, 其中包括；

可扩展的视图（Views），可以用来构建应用程序，它包括列表（lists）、网格（grids）、文本框（text boxes）、按钮（buttons）等，甚至可嵌入的Web 浏览器；

内容提供器（Content Provider）使得应用程序可以访问另一个应用程序的数据（如联系人数据库），或者共享它们自己的数据；

资源管理器（Resource Manager）提供非代码资源的访问，如本地字符串、图形、和布局文件（layout files）；

通知管理器 （Notification Manager）使得应用程序可以在状态栏中显示自定义的提示信息；

活动管理器（Activity Manager）用来管理应用程序生命周期并提供常用的导航回退功能。

3）程序库层

Android包含一些C/C++库，这些库能被Android系统中不同的组件使用。它们通过Android应用程序框架为开发者提供服务。以下是一些核心库：

系统C库：从BSD继承来的标准C系统函数库（libc），它是专门为基于嵌入式Linux（Embedded Linux）的设备优化了的；

媒体库：基于PacketVideo/OpenCORE。该库支持多种常用的音频、视频格式回放和录制，同时支持静态图像文件。支持的编码格式包括MPEG-4、H.264、MP3、AAC、AMR、JPG、PNG等；

显示管理器（Surface Manager）：对显示子系统的管理，并且为多个应用程序提供2D和3D图层的无缝融合；

浏览器引擎（LibWebCore）：最新的Web 浏览器引擎用，支持Android 浏览器和可嵌入的Web 视图；

图性引擎（SGL）：底层的2D图形引擎；

3D图形库（3D libraries）：基于OpenGL ES 1.0 APIs 实现；该库可以使用硬件3D加速（如果可用）或者使用高度优化的3D软加速；

字体引擎（FreeType）：点阵（Bitmap）和矢量（Vector）字体显示；

SQLite：一个对于所有应用程序可用，功能强劲的轻型关系型数据库引擎。

4）Android运行库（Runtime libraries）

编程语言核心库的大多数功能。 Android包括了一个核心库，它提供了Java

每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机（Dalvik VM）实例。Dalvik被设计成可以同时高效地运行多个虚拟系统。

程序的虚拟机，其可执行文件（Dalvik Dalvik虚拟机是由Google公司主导开发的用来解释执行Java executable 编译器编译，然后通过SDK?format）格式文件（.dex）针对小内存使用做了优化。同时Dalvik虚拟机是基于寄存器的，所有类都经由Java 中的"dx"工具转化成“.dex”格式由虚拟机执行。Dalvik虚拟机依赖Linux内核的一些功能，比如线程机制和底层内存管理机制。

5）Linux 内核

Android的核心系统服务依赖于Linux 2.6 内核，如安全性、内存管理、进程管理、网络协议栈和驱动模型。Linux内核也同时作为硬件和软件栈之间的抽象层。

Android媒体库系统OpenCORE的架构如下图所示：

图为：Android媒体库软件的组成

OpenCore的代码非常庞大，它是基于C++的实现，定义了全功能的操作系统移植层，各种基本的功能均被封装成类（Class）的形式，各层次之间的接口多使用继承等方式。

在Android 2.1及以前的版本中，是不支持JIT的。2010年5月21日的Google I/O大会上，Google发布了Android 2.2版本，主要的新功能包括：

支持JIT，性能也有提高；

支持Adobe Flash 10.1及AIR（Apollo Integrated Runtime）技术；

支援全新的API应用，例如语音辨识功能，可以快速将话语转成文字讯息，进行资料搜寻，甚至用来启动Google Maps等；

在企业应用上也有相当程度的支持，例如微软的Exchange、Security Policies与GAL lookup（全地址搜索）等，方便在接收即时讯息与内容快速传送之类的运用。

2.3　HbbTV与GoogleTV平台的技术比较分析

从上面的分析我们可以看到，HbbTV是MHP模式的中间件平台向互联网（基于IP传输的网络）的延伸，其细致的基于IP网络通道应用管理的协议规范，可以有效地将广播通道的应用管理融于一体，使得HbbTV平台（简单地说就是中间件平台）可以支持DVB、IP多媒体应用。而GoogleTV的技术平台，是将基于Linux的开放软件包集成在一起，采用开源的媒体播放器来播放音视频流媒体。在GoogleTV的核心Android系统中，并没有支持广播通道（DVB-C/S/T）的数字电视协议（至少到目前为止还没有），因此，它是不可以被数字电视运营商用来开展增值业务的。这可以说是GoogleTV平台目前的一个重要的缺陷。

一般情况下，数字电视中间件平台（即使是基于MHP规范的），都是与平台的操作系统（RTOS）无关的，例如中间件系统中的文件系统、TCP/IP协议栈等是可以移植到不同的系统中的，这样基于中间件的业务平台对系统的内存和存储（如Flash等）的要求就会低许多；而Android系统是基于Linux的，尽管实时Linux操作系统进行了许多的优化，但每个应用需要在一个不同的进程中运行，其需要的存储等都还是比标准的中间件平台要大许多。尤其是Android系统中的图形与图像处理模块、媒体播放器模块、浏览器引擎等都是Google公司从其它的开源代码中集成起来的，是一个GPL软件包的组合与大杂烩。

程序的执行方式：Dalvik语言进行应用程序的编写，DalvikVM采用了与JavaVM不同的bytecode格式和Java尽管都是采用Java程序的执行进行了优化。然而，Dalvik虚拟机与传统的Java虚拟机相比的性能提高，还没有权威机构给出数据。在Android2.1版本以前，Google号称其性能优异，无需JIT（Just-In-Time）技术，可是，在最近发布的Android2.2中，JIT技术还是采用了。知识产权问题，当然也对Java?VM是基于寄存器的；JavaVM是基于堆栈的。此举的目的是为了避开Sun公司的Java。

基于HbbTV的中间件平台，是由不同的技术厂商自行开发和提供的，在符合标准规范（HbbTV、MHP或其它专有中间件规范）的情况下，可以添加运营商需要的功能、从而适合个性化与交互性的应用需要；GoogleTV采用的是开源软件包，是免费的。这成为众多终端整机厂商趋之若鹜的重要原因。

3、数字电视运营对中间件技术平台的要求

在网络功能趋同、业务融合的今天，数字电视运营已经发生了很大的变化，通过宽带网络、基于IP协议传递视频的业务和多媒体终端已经在大量涌现。在IP网络上进行点播、时移以及录制等都是很普通的功能，而且，应用本身和其数据已经混为一体、不可区分。由于信息量大和及时性要求，这些应用以及越来越多地以HTML网页的形式展现，根据需要及时下载，或者相关信息通过Ajax、RSS等协议自动更新。

对运营商而言，数字电视数据业务可能来源于广播信道（卫星、有线或无线等）和/或宽带信道（互联网、或其它的IP通道）的信号，音视频与数据可以不加区分地由这两个通道分别接入，在带宽限制的情况下，广播通道可以用来播送高清节目，而宽带的使用形式就会有很广，如视频点播、时移、信息浏览、电子商务等。

运营商对数字电视的诉求是要通过提供音视频内容、娱乐信息等，来进行增值业务和互动应用的运营。因此，运营商需要一个能够完全掌控的“封闭”环境，形成一个“围墙花园”（Walled Garden），将音视频节目、娱乐信息、增值业务与应用都搬到运营商控制的平台上向用户提供，并对所有业务的运行进行监控。同时，运营商也需要能够有开放系统的可能，允许终端用户访问开放的互联网信息，甚至可以访问互联网音视频内容，如YouTube、优酷网、土豆网等视频网站的内容。当然，从内容安全的角度来看，这些互联网内容需要在服务器端进行过滤与监控。同时，运营商需要一个稳定、可靠的中间件业务平台，根据市场和业务的发展进行功能的更新与改进，他们需要专业的中间件平台技术厂商为其进行针对性和专业化的服务，这势必使得中间件平台逐步个性化和根据运营商的需要进行定制化，即使是基于HbbTV平台的中间件，在不同的运营商市场，会显示出有运营商烙印的特征功能，这将会促进运营商在激烈的竞争中不断推陈出新、发展用户、赢得竞争。

数字电视行业正在经历着深刻的变化，多媒体视频业务通过多种渠道不断涌现。从老百姓的角度来讲，过去被动地看电视就够了，现在需要越来越多的交互性内容，比如在体育赛事播出时提供增值业务等，观众对数字手段带来好处的要求也越来越多，短信、电子邮件、天气预报也可以搬到电视屏幕上来，除此以外，还有一些个性化的社区服务和社会化电视。

4、未来的技术平台谁会胜出？

从业务的角度上来看，数字电视有两类市场：运营商市场和零售市场。数字电视运营商（包括广电运营商和电信运营商）需要在他们的“封闭”网络（“围墙花园”—Walled Garden）中进行经营与发展、创造用户、增加收入。在封闭的网络中，运营商能够丰富他们的业务，提供开放的互联网无法比拟的应用内涵和服务质量。以HbbTV为基础的中间件融合业务平台，既可以满足运营商采用广播和（或）宽带通道进行增值业务开展的需要，而且又可以支持运营商对应用进行管理和控制。因此，HbbTV中间件平台更能够符合运营商的需要，必将成为运营商的不可或缺的业务运营平台。

从技术的角度来看，GoogleTV并没有脱离微软公司的WebTV、Apple公司的AppleTV的框架与功能，是WebTV或AppleTV在互联网电视上的又一次努力，是互联网技术移植到流媒体视频处理领域的技术思路的延续。毫无疑问，采用它去浏览Hulu、YouTube等视频网站的内容以及网上新闻是没有问题的，但对有大量覆盖的有线电视、卫星电视和（或）IPTV电视用户的数字电视运营商来说，我们认为，它是不便于用来进行增值业务运营的。

GoogleTV当前引起了业界的广泛关注，主要原因是Google公司将Android平台全部开放其源代码，容许Android在终端上的移植层的源代码为各厂家所拥有（各厂家自己进行移植）。我们认为，GoogleTV平台可能适合于数字电视厂家将其移植到零售市场的终端设备上，用来支持互联网流媒体的播放与浏览、增加其终端设备的功能和卖点。运营商市场是不可能使用原封不动的GoogleTV平台的。即使有厂家将GoogleTV系统用于运营商市场，那他们也需要花费巨大的精力将原有Android系统进行技术改造、增加运营商需要的功能。那这样，它也就不成为GoogleTV平台，而只是开源代码为技术厂商所用而已，就象其它的开源代码（如WebKit、OpenGL等）一样。

总之，Google公司将GoogleTV平台完全开放源代码，其本质目的是使GoogleTV终端能够访问他们的Android应用商店，他们通过此应用商店获取利益，而并非真正是为了数字电视业界有一个普遍适用的技术平台而无利益的考量。不管怎样，GoogleTV是互联网领域向数字电视领域融合的又一次尝试，它为家电厂家的终端研发提供了软件系统的参考，必将对数字电视和互联网视频流媒体业务的未来发展产生深远影响。