【流媒体网】摘要：本文将首先介绍HBBTV的由来和背景，然后，着重就HBBTV需求做深入的讨论，希望通过了解HBBTV的需求，让读者对它的产品及方案应该具备的功能和特点有个清晰的认识。

    最近一段时间HBBTV变得非常热门，尤其是在欧洲一些国家和地区。那么HBBTV究竟是什么？HBBTV对于广播电视产业链的各个参与方意味着什么：机会还是挑战？本文将首先介绍HBBTV的由来和背景，然后，着重就HBBTV需求做深入的讨论，希望通过了解HBBTV的需求，让读者对它的产品及方案应该具备的功能和特点有个清晰的认识。接着，就HBBTV的技术、系统架构及与其它标准之间的关系做一概述，以帮助读者理解其技术背景及其适用的范围。最后，给出了几个在欧洲市场上正在运行的例子。对于HBBTV具体的业务、商业模式、面临的挑战和争论，本文不作讨论，留待后续的文章进行探讨。

    关键词和术语：

    1. 引言
    混合终端、机顶盒的概念包括设备其实多年前就有了，问题是为什么在欧洲，电视广播行业突然间对HBBTV设备和服务的前景感到非常乐观和兴奋？以下几个因素是混合解决方案重新获得行业青睐的原因：
    •首先是消费终端已经变得很先进。事实上，许多机顶盒都带有图形加速器，因此能够在当今最流行的平板电视上输出质量很好的视频和图像。
    •其次，广播电视公司已开始在其网站上提供“Catch-up TV” 和实况流媒体业务。目前，网络流媒体的业务主要是面向个人电脑用户（在英国例外），而且采用的播发器是Adobe Flash或是微软的Windows Media。
    •此外，随着家庭接入网速度的提高和信号质量的改善，基于互联网的宽带媒体也变得越来越可靠。因此，把通过电脑屏幕上观看宽带媒体的方式切换到电视机屏幕的时机已经成熟。
    因此，对应地，就需要有相应的技术方案。技术方案有很多如IPTV、DVB-GEM和Tru2way等，问题是哪种方案最适合？欧洲已经有两个运用的较为广泛的平台：MHEG-5（提供复杂先进的数字电视文本）和MHP/GEM（在机顶盒中运行Java应用程序）。为什么还要重起炉灶制订HBBTV规范？下面就先来看一下HBBTV成立的背景。

[NextPage]

    1.1 HBBTV成立的背景[1]
    关于HBBTV成立的背景，最权威的诠释莫过于来自欧洲广播联盟（EBU）的官方建议R127- “在广播/宽带混合环境下的电视”，这项建议的目的是鼓励在发展广播/宽带混合电视接收机的过程中鼓励互操作性和一致性。本小节就根据建议R127编译，和读者一起分享。
    各国宽带市场上不断增加的IPTV业务以及开放互联网中不断普及的“网络电视”服务正在改变媒体交付的领域。虽然在欧洲不同的国家发展的速度不同，但是需要采取共同的方法以促进服务之间和设备之间的互联互通。
    欧洲广播联盟各成员认识到他们可以通过宽带网络为客户提供内容丰富的多媒体内容，通过整合宽带和广播媒体内容（混合广播/宽带）可以更进一步地服务公众。整合带来的新机会包括：更加丰富多彩的电子节目指南（EPG）、“追赶电视”（Catch-up TV，指可以通过时移电视或者网络PVR等功能点播观看过去的老节目）、访问存档内容、互动节目、社区和网络接入等功能。对于那些提供广告的PSB（公共服务广播机构/公司），则可以采用新形式的广告。
    新的数字电视接收机和其它消费电子产品（CE），可以在基于订阅受管理（Walled Garden）的业务架构下，或在由制造商控制的门户架构中，通过宽带网络访问互联网。但是在这些受管理的业务或门户架构下，用户可能无法获得最好的服务及最想要的节目内容。
    欧洲的许多广播机构/公司都参与了专有的或只适用于特定国家的技术平台的开发（各种混合广播/宽带方案），但是这些方案都存在着彼此互不兼容的风险。互联互通的系统是保护欧洲公众利益的最好方法。在数字广播电视频道中提供互动电视服务并没有按照最初设想的那样为广播机构和公众所广泛接受。其原因也许是因为欧洲不同的国家采用了互不兼容的系统而造成的。因此HBB系统中应当设法避免出现类似的情况。
    HBB系统应该是公平和合理的，消费者应该能够和消费纯广播节目一样的方式享受PSB在混合广播宽带网络中传送的丰富精彩的节目内容。
    欧洲广播联盟及其成员需要分析欧洲和各国的规章制度，采取适当的行动，以确保只有在授权情形下，第三方才能把他们的宽带服务和欧洲广播联盟成员的节目相关联。例如，PSB应保留与他们节目相关联的所有内容的编辑控制权（如节目单、画面周围的文字和各种多媒体、 广告、画中画和互动应用等），这也就是所谓的编辑完整性。
    最后，欧洲广播联盟建议其成员必须加强与业界及标准化机构的合作，开发广播/宽带混合的技术平台使其具有必要的技术共性以确保其在欧洲消费市场的发展，从而可以为欧洲消费者带来成本最低和质量最优的系统。为实现这一目标，欧洲广播联盟将设立相关工作组，其中包括了相关行业代表。
    1.2 HBBTV的定义
    目前欧洲的PSB（公共服务广播电视机构/公司）和终端设备制造商以及中间件厂商正在致力于新一代被称为HBB（混合广播/宽带）的互动电视系统的标准化工作。HBB是一种端到端的系统，它涵盖了广播（如地面、有线和卫星）和宽带（开放互联网）两个领域，使用有宽带连接的CE（消费电子设备），如机顶盒或内嵌接收功能的电视机作为服务的接受设备。HBB本质上是一种增强型的广播系统，但它包括了点播业务、互动应用和其它一些在传统的线性广播（单向）环境中很难实现的功能和特性。
    HBB更为准确的定义是：“HBB是一种与DVB兼容的内容发布平台，可以为增强和互动的电视业务提供信令、传输和呈现机制。基于HBB的相关应用同时针对广播和互联网领域而设计，并可以在同时具有广播和互联网混合连接的终端上运行。”
    2. HBBTV的需求分析[2]
    HBBTV一共定义了下面七大类的需求，分别是：
    1.一般性需求
    2.系统相关的需求
    3.内容相关的需求
    4.服务相关的需求
    5.交付相关的需求
    6.消费电子终端相关的需求
    7.终端用户相关的需求
    下面将分别介绍这些需求。在讨论之前，必须注意的是，
    •“HBB”表示一般的意义，并不意味着某个特定具体的技术解决方案。讨论的需求不涉及具体的技术问题如编解码器和传输机制等等，换句话说，这里的需求是技术不可知的。
    •只讨论“高层次”的技术需求，详细的技术或业务问题不在讨论的范围，另外 HBBTV需求部分没有考虑其背后的商业模式。 
    •需求包括了广播电视产业链上所有的组成部分：如内容、服务、网络和终端设备等等。
    •只讨论了和开放横向市场相关的需求，没有涉及供应商特定或纵向专有市场的需求。
    •讨论了一组PSB（公共服务广播电视机构/公司）商定的价值和利益。
    •考虑了欧洲电视和网络媒体领域现实的市场环境。
    •要求在不同的电视传输平台之间提供编辑的完整性和呈现的一致性。
    •为PSB的系统和服务提供有保障的未来是HBB的一个基本目标。
    2.1. 一般性需求
    1.HBB系统应当是一个开放的（非专有）标准并由国际标准化机构如ETSI接受并采纳。
    2.知识产权（IPR）及相关的专利问题应该在HBB业务推出之前得到解决。
    3.在欧洲视听媒体服务指令中设定的法令和法规应能继续保持适用。
    4.欧洲广播机构和CE制造商应共同商定在第一代及其后续HBB设备中所需实现的功能和特性。当有需要时，应该吸纳内容汇聚商及业务平台提供商（如有线电视运营商）参与协议的协商过程。
    2.2. HBB系统相关的需求
    1.HBB的技术规格，应该是基于现有的国际标准和规范，例如IPTV开放论坛、DVB，UPnP、DLNA、W3C和IETF等。
    2.HBB的功能和能力应该定义成最基本（或核心）的功能加上各种扩展功能，更高层次的功能和能力由核心功能加上扩展功能组成。
    3.HBB的系统架构应该在逻辑上分层并分配不同的功能块（模块），以便允许一些设计上的灵活性并避免层与层之间过渡依赖。
    4.HBB系统应该有方法支持一些高级功能如自适应流媒体技术和增强视频图像功能等。
    5.HBB应支持独立的广播服务（即没有互联网连接）和独立的因特网服务（即没有广播频道）。
    2.3. HBB内容相关的需求
    1.广播机构应该能够独立制作和发行创新的互动HBB节目而无需HBB价值链中其他参与者的支持。
    2.广播机构应能够完全并唯一地对节目内容及围绕其广播服务（全部或部分）所叠加的服务的控制，因而达到HBB的“编辑完整性”的原则。
    3.广播机构应负责确保内容相关的现行法规的限制得到尊重，版权拥有人的权利得到尊重。
    4.由于广播机构负责电视体验和所有相关数据的一致性，因此只有他们才能够有权力丰富他们节目内容，如果他们认为有需要（或授权他人这样做）。例如可以利用宽带信道和适当的应用信令来要做到这一点。
    5.根据HBB规范，它定义了消费电子设备的功能和特性，广播公司和内容提供商应该能够调整其生产设施，技术设备和工作流程来创作互动的HBB节目内容和服务。
    6.应尽量避免按照不同的格式和协议对相同的节目内容进行再处理，因而可以减少HBB内容的制作成本。HBB应当使广播机构能够采用同样的制作工具和格式为任何HBB消费电子设备制作节目。
    7.由广播公司制作的互动节目应该可以在广播信道中和视音频信号一起传输的信令来控制。
    8.和线性及非线性内容服务相关的安全性问题，应该以一种不让内容提供商和最终用户处于不利地位的方式加以处理和解决。
    9.HBB应允许终端用户上传内容，以便让广播机构通过合适的格式发布其内容（UGC -用户生成的内容）。
    10.在未事先达成协议的情况下，广播机构应该可以要求不允许把其节目的观众重定向到其它的节目或服务中去。
    11.HBB应该能够提供高质量的线性和非线性的服务，并逐步向高清（HD）质量的内容演进。
    2.4. HBB与服务有关的需求
    1.HBB应能提供地方、全国和国际性的电视服务。例如，互联网电视服务应该与覆盖范围相匹配，比如说，地面广播服务，应该能够提供地方性的服务，如当地新闻、当地天气报告、当地交通和当地体育比赛的结果等。为此，需要在其服务中提供区域性的节目信号。  
    2.无论节目是通过广播还是宽带信道发送的，其在节目内容中嵌入的用以标识节目所有者的广播机构的品牌和标志，都应该显示给终端用户。
    3.任何传统的中间件系统（传统的中间件例子包括DVB-MHP/GEM和MHEG-5等）可用于目前的广播服务的，应该考虑到可以与HBB系统共存。
    4.在那些已经在广播频道中使用这些中间件的国家，HBB需要能够和这些中间件共存，HBB的引入不应该对现有基于传统中间件的业务造成破坏性的影响。
    5.HBB应当作为一些广播中间件的替代技术，主要是在那些没有互动广播服务的国家。
    6.HBB应该允许个性化和独立寻址的服务，以及群组定位和本地化的服务。
    7.如果有需要，可以在宽带通道上采用适当的地理定位系统，只对那些有版权保护的地区提供特定节目内容的访问。
    8.如果需要，应该采用一个安全、开放与平台无关的有效的数字版权管理（DRM）系统。它应该允许多个CE设备在联网的家庭域中共享（节目）。
    9.在HBB系统中应该同时支持传统的图文电视和增强图文电视（通过HBB技术来实现）。
    10.系统应能支持受众研究和受众行为的跟踪。信息交通的基准化方法应当由主管的国际机构来研究开发。用户数据，不得用于商业目的，应当按照欧洲及本国的法律加以保护。
    2.5. HBB服务交付相关的需求
    1.宽带HBB服务应当适应广播领域观众需求，需要能提供支持百万计的并发观众服务。
    2. HBB系统（特别是其宽带部分）应有效地处理“Flash crowds”的情形，它是指大量的用户为了访问服务，在同一时间向服务器发送并发请求（例如：现场直播，视频点播及同一下载服务等）。

[NextPage]

    3.HBB系统应为通过广播和宽带路径并发传输的服务组件提供合适的同步机制。
    4.为了尽可能降低服务交付的成本，需要制订和规范一个有效的节目分配系统。
    2.6. HBB与消费电子设备相关的需求
    1.同样的CE设备可以用来接收不同服务商提供的任何与HBB兼容的服务。
    2.鉴于集成电视显示器市场规模和数量的巨大，支持互联网的HBB终端用户设备成本的增加应是微不足道的（相对于传统的消费电子电视设备）。
    3.所有的服务，应能够使用遥控器进行控制，并能够通过任何大小的现代电视机（通常是平板显示器）显示出来。
    4.由广播机构提供的宽带HBB应用，根据各国广播需求的不同，应该能够通过专用的或者可配置的遥控器按钮来访问。
    5.在HBB家用设备中应该支持家庭网络连接的功能，要么是有线、无线或两者同时都有。
    6.当内容作为个人拷贝或为“时移电视”的目的而复制时，如果这些应用涉及到编辑完整性的话，需要保持对相关应用的访问关系。
    7.HBB设备应能够通过广播或宽带路径升级或更新。
    8.HBB设备应该有足够的内存/存储空间以支持对电视节目的查找、组织、安排和录制等功能。
    2.7. 与终端用户相关的需求
    1.HBB应允许终端用户通过一种友好、直观的方式来使用系统的功能。
    2.HBB应允许终端用户查找、组织、安排和录制电视节目，包括单集和系列剧，无论是广播还是宽带的节目内容。
    3.终端用户应该能够保存访问过的网址和门户网站的链接信息（如书签和我最喜爱的节目等）。
    根据HBBTV的需求，预期公共广播机构应做出适当的努力，将他们的电视和网络内容的制作流程进行集成，以便为HBB提供一个稳固及有效的生产制作环境。HBB有能力提供新的业务平台，为客户提供有吸引力的内容，使最终用户能够享受到新的互动服务和应用，而这些服务和应用是无法通过传统的广播信道提供的。通过采用这种技术，PSB可以扩大其节目覆盖的范围并吸引更多的观众。
    3. HBBTV标准介绍[3]
    3.1 标准的范围
    HBBTV定义了一个HBB的平台，它是一种与DVB兼容的内容发布平台，可以为增强和互动的电视业务提供信令、传输和呈现机制。基于HBB的相关应用同时针对广播和互联网领域而设计，并可以在同时具有广播和互联网混合连接的终端上运行。
    广播连接的主要用途如下：
    •传输标准的电视，电台和数据服务。
    •承载和广播相关的应用的信令。
    •传输与广播相关的应用程序和相关数据。
    •对电视/电台/数据服务和应用程序之间进行同步。
    宽带连接的主要用途如下：
    •承载点播内容。
    •传输与宽带相关与广播无关的应用程序及相关数据。
    •应用和应用服务器之间进行信息交换。
    •发现与广播独立的应用程序。
    应用程序在一个HTML / JavaScript浏览器的环境下执行并呈现给用户。
    HBBTV平台具有以下特点：
    •它是开放的而且不是基于单个控制中心或聚合点。
    •应该可以通过同一个终端访问来自多个不同且独立的服务提供商提供的内容和服务。
    •所有的应用程序应该能够访问终端可用的标准功能。一些稀缺或敏感的终端功能只提供给受信任的应用程序。
    •服务和内容需要能够受到保护。
    •广播类的应用必须要能够在那些没有宽带连接的终端上运行。这包括两种情形：有宽带连接但尚未连接以及没有宽带服务的情形。
    •设备制造商提供的服务和应用不属于标准规范的范围，即使它们使用如HBBTV标准所述的相同浏览器和功能。
    •广播通道采用的视频、音频和系统格式不属于标准的范围。广播频道的协议也不属于HBBTV标准的范畴除非它们和互动应用有关。
    •应用程序可以在不同类型的终端中运行，如集成数字电视（内含HBBTV接收功能）、机顶盒和PVR等。
    •同时支持广播相关和广播独立的应用程序。
    该平台综合了IPTV开放论坛的标准协议和DVB的标准协议用于在广播/宽带混合环境下承载互动应用和信令。此外，HBBTV标准还定义了所支持的媒体格式、终端的最小功能集以及应用程序的生命周期等。
    本标准旨在没有特定国家/市场的规范标准的情形下可以被采用和进行方案实施。当然，该标准也可以和特定国家/市场的具体标准相结合而实施。
    3.2 应用
    基于HBBTV标准规定的HBB终端提供基于网络下载和执行应用程序的能力。这里的应用是指包含增强或互动服务在内的多个文件的集合。一个应用的文件可以是HTML、JavaScript、CSS、XML和各种多媒体文件。
    HBB系统架构支持各种应用，这些应用包括了浏览器、通过广播或宽带信道传送的信令和应用程序及用作广播服务和应用的同步信令等。
    HBBTV涉及的应用有以下几种：
    •广播独立的应用程序（即不与任何广播服务相关联）。这种类型的应用是通过宽带下载并通过宽带通道访问与其相关的所有数据。
    •广播相关的应用（即与一个或多个广播服务相关或与单个广播服务中的一个或多个事件相关），可自行启动（“Autostart”）或应用户要求而启动。这种类型的应用程序，既可以通过宽带或广播通道下载，也可以通过这两种通道之一访问相关的数据。
    下面可能使用的浏览器环境不属于HBBTV标准的范围：
    •和应用相关的服务供应商在OIPF规范中规定。
    •使用浏览器环境为用户提供诸如频道道航或终端安装菜单等具体的应用。
    •使用浏览器环境显示互联网网站的内容。
    •使用浏览器环境支持如CEA-2014等标准规范或IPTV开放论坛的全套相应规范。
    3.3系统架构
    3.3.1简介
    本节给对HBB体系结构进行了概述并对混合终端中一些必要功能部件进行了说明。说明的详细程度是一般性的而且是抽象的。有关组件内部结构的细节（例如DSM-CC客户端是否有集成的高速缓存）或组件的具体实现（例如，是否由特定的硬件或软件来完成组件的功能）都被省略掉了。而且在实际的系统中，几个逻辑组件可能被合并成一个实际的功能模块（例如某个浏览器可能已经集成了应用程序管理器的功能）。本节的主要目的是帮助读者理解HBB的总体概念和所需的组件。系统组件之间的通信不属于HBBTV标准的范围。
    3.3.2 系统概述
    混合终端具有同时连接到两个平行网络的能力。一方面它可以连接到DVB广播网络（如DVB-T、DVB-S或DVB-C等）。通过广播连接，混合终端可以接收标准广播的视音频信号（即线性内容）、 应用数据和应用信令。即使终端没有宽带连接，它仍然可以通过广播网络接收与广播相关的应用。此外，应用程序的流事件信令也可以通过广播网络传送。

[NextPage]

    此外，混合终端还可以通过宽带接口连接到互联网。这使得可以和应用服务器进行双向通信。通过该宽带接口，HBB终端可以接收应用程序数据和非线性的视音频内容（如点播的节目等）。该混合终端也可以支持将非实时的节目内容下载。
    图1显示了一个基于DVB-S和宽带混合连接的例子。

    3.3.3 终端的功能性组件
    图2 给出了一种混合终端上内部相关功能组件的示意图。下图给出了这些功能组件的描述。

    通过广播接口，终端接收AIT数据、线性节目内容、应用数据和流事件。最后两个数据流通过DSM-CC的对象传送带（Object Carousel）进行传送。因此，需要一个DSM-CC的客户端从对象传送带接收对象并提供给相应的运行环境。该运行环境可以被看作是一个抽象组件，互动应用程序在其中运行和显示。浏览器和应用程序管理器构成了该运行时环境。应用程序管理器根据AIT表来控制互动应用程序的生命周期。而浏览器则负责互动应用的执行和显示。
    线性节目的处理，采用和标准的非混合DVB终端相同的方法。该功能包括在“广播处理”的功能单元中，它包括了所有的DVB相关的功能，就和非混合DVB终端提供的功能一样。此外，通过广播处理单元，运行环境可以访问相应的信息和功能如频道列表、EIT表，及调台相关的功能等。这是都包含在了图2的“其它数据”模块中。此外，应用能够对线性节目进行缩放并把节目嵌入到应用程序的用户界面中。这些功能是由媒体播放器所提供的。在图2中，包括了所有和视音频相关的功能。
    通过宽带接口混合终端可以和互联网连接。该连接提供了另外一种方法从应用服务器请求应用数据。同时，该连接也可以用于接收非线性节目内容（如点播内容等）。“互联网协议处理”单元包含了终端处理互联网数据所需的所有功能。通过该模块，可以把应用数据提供给运行环境。进而，运行环境把非线性节目提交给媒体播放器处理，然后把结果嵌入到应用所提供的用户界面中。
    3.4终端功能和扩展
    HBBTV定义了一个基准的终端能力集合，所有的HBB终端都应该支持该能力集。该基准（能力集）支持的互动应用包括如下几种情形：
    •不把视频作为其用户界面的一部分。
    •使用广播视频作为其用户界面的一部分。
    •使用点播视频（单播流）作为其用户界面的一部分。
除了上述基准的能力集，HBBTV还包括了四个可选的特性供终端有选择地支持：
    •支持下载节目内容到终端的本地存储设备中（下载方式包括持续下载和渐进式下载两种方式）- 这又被称之为“下载功能”。
    •对在本地海量存储的广播节目，提供调度、回放以及时移电视的功能 - 这又被被称为“PVR功能”。
    •如在标准第7.3.2.1和9.1.1.3章节中所定义，支持基于RTSP/ RTP协议的流媒体技术 - 这又被称为“RTSP功能”。
    •支持使用DRM保护节目内容，如附件C中所定义

[NextPage]

    3.5规范概述
    HBBTV定义了在前面章节中所述系统的技术要求。它主要是参考了已有的标准和规范，并根据需要采纳适用的部分。最重要的参考文件包括如下：
    •CE-2014 - 在UPnP网络和互联网中为远程用户界面定义的基于Web的协议和框架（Web4CE），又称之为CE-HTML。
    •IPTV开放论坛第1版第5卷 - 陈述性的应用环境。
    •ETSI TS 102 809（前身为DVB蓝皮书A137）“广播/宽带混合环境下的互动应用和服务的信令及其承载”。
    HBBTV标准可以看作是这些参考标准的一个子集。图3显示了本标准所采纳的部分和原始标准之间的关系。

    由CEA-2014提供的重要部分包括：
    •应用程序语言的定义（XHTML，CSS和JavaScript 包括AJAX）。
    •应用程序中嵌入的非线性节目内容的定义。
    •DOM事件处理（如按键事件等）的定义。
    •静止图片格式的定义。
    CEA-2014目前已经被OIPF采纳作为其DAE规范。HBBTV标准包括了由CE-HTML定义的一些额外的配置。由OIPF DAE规范提供的其它重要组成部分包括：
    •在电视环境中运行的应用程序的JavaScript API（如调台等）。
    •在应用中嵌入线性节目内容的定义。
    TS 102 809 提供下列组成要素：
    •应用信令。
    •通过广播或HTTP传输应用程序。
    在OIPF媒体格式规范中定义的音频和视频格式。
    在某些罕见的情况下，所引用的标准都无法提供适当的解决办法。HBBTV标准则针对这些情形制定相应的规范（如应用程序的生命周期定义等）。此外，HBBTV标准还针对用户体验提供了相应的建议，并对HBB系统做了概述。
    对OIPF和DVB规范的参考都是明确的，即在HBBTV标准中都明确地标识了所采纳或参考的部分。没有在HBBTV标准中参考或定义的部分都不应该被实现，除非HBB另外的规范有明确的要求。CE-HTML被采纳的部分是那些在OIPF被明确要求的部分，同时去除了在HBBTV标准第8.1章节定义的内容。
    4. 标准化进程
    HBBTV已经完成了版本1.1.1，并已经在2009年底提交给了ETSI审批，有望很快成为欧洲的标准。
    5. HBBTV实际运行的例子[4]

    6. 小结
    本文主要是根据三个参考文献编写而成，它们分别是：
    •EBU建议R127，在广播/宽带混合环境下的电视系统或业务
    •EBU TECH 3388，关于HBBTV标准化的需求
    •HBBTV规范文本v1.1.1

[NextPage]

    HBBTV才刚刚起步，围绕该规范的争论很多，其面临的挑战也很多。比如：
    •浏览器和Java之争
    •现有中间件标准DVB-GEM和HBBTV之争
    •HBBTV是概念炒作还是新技术？
    •如何解决IPR和授权的问题？
    •如何照顾网络运营商的利益？
    本文的主要目的是向国内同行介绍HBBTV的由来、标准涵盖的范围及其背后的技术基石。作者计划在后续的文章中对其商业模式等内容做介绍，敬请关注流媒体网《中国IPTV产业动态》后续杂志内容。
    作者简介：金罗军，博士，从事视频通信专业工作近15 年，先后就职于华为技术、思科、RIM和UT 斯达康等国际知名公司。目前定居加拿大，就职于多业务运营商，负责下一代互动视频业务和应用的规划和设计，并参与相关国际标准制定的工作，曾经获得多项专业奖励并在美国拥有发明专利。

  更多最新最全的HBBTV资讯，敬请关注流媒体网近期推出的《中国IPTV产业动态》22期增刊！

    http://magazine.lmtw.com/read/201003/54879.html 

    《中国IPTV产业动态》22期增刊杂志印刷版也将于近日隆重推出，敬请期待！

责任编辑：lmtwadmin