CN101652997A - 用于高效递送数据内容的系统和方法 - Google Patents

Abstract

一种用于递送视频点播内容的方法，包括向具有存储单元的多个客户端设备组播内容，这包括递送开始于流中部以及针对丢失内容的恢复机制的实例。一些实施例包括将内容定义成强制的并且非自愿地递送强制内容。一些实施例包括具有多个数据集合的转盘，其以序列递送每个数据集合，然后开始从序列开始处循环地重复递送。各种示例性实施例包括下列内容中的一个或多个：在每个客户端设备存储标题；针对更多标题重复各步骤；以及监控所要求的动作，例如下载新标题、删除旧标题或更改数据传送日期，并且执行所要求的动作。

Description

用于高效递送数据内容的系统和方法

技术领域

本发明一般地涉及通过网络向具有存储单元的客户端高效递送信息，具体地涉及一种用于高效递送视频点播内容(VoD)的机制。

背景技术

数字视频录像机(DVR)实现了对视频播送记录的调度，这使得用户能够在方便时观看节目。早期的DVR是在1999年拉斯维加斯的电子消费品展览中发布的。从那时起，DVR逐渐开发出附加的能力，例如刻录到DVD上、商业中断(skip)、在互联网上共享记录以及利用PDA进行播送和遥控的工具、联网PC或Web浏览器。

DVR与传统的视频点播不同，因为按照传统视频点播，用户能够从很大范围的播送内容选择之中即刻地观看一个节目，并且使得节目跨越网络而被实时递送。一些技术提前向具有存储单元的用户设备递送广播内容，然后为用户提供接口以使得用户可以在方便时或通过“点播”来观看所存储的内容。

视频点播(VoD)系统使得用户能够通过作为交互式电视系统的网络选择并观看视频内容。VoD系统“流式传输”内容以实现实时观看，或者下载内容以在观看开始前部分地或全部地将节目传送至机顶盒。大多数使用有线电视或电话公司基础设施的VoD系统也使用VoD的流式传输方法。在VoD的流式传输方法中，用户购买或选择电影或电视节目，并且它几乎是即刻地开始在电视机上播放。

除了VoD技术和系统之外，许多卫星和有线公司将DVR功能并入其机顶盒中。同样，电视制造商开始提供具有内置的DVR功能的电视机。短语“数字视频录像机(DVR)”通常与短语“个人数字录像机(PVR)”替换地使用，以表示用于将不具有录像带的视频记录到基于硬驱的数字存储介质上的设备。这包括独立的机顶盒和能捕获视频且向和从磁盘回放的用于个人计算机的软件。这项技术也已经变成CCTV公司记录其监控的主要方式，因为DVR提供了比原来的VCR长很多的记录时间。

就个人视频录像机(PVR)而言，全世界有一系列产品，特别是代表模拟和数字技术合并的那些产品。例如Tivo的公司提供具有较大存储容量的PVR。这些设备存储数字或模拟视频，有可能对其在线编码，并且如上所述与VCR是不同的，因为它们存储视频到本地硬盘上。

在设有以太网端口的情况下，这种设备可以下载EPG(电子节目指南)信息并且使用该信息以使得用户能够调度记录。另外，许多公司现在在它们的卫星或有线接收机中提供PVR能力，并且随着互联网协议电视(IPTV)的出现，视频可是组播的并且可以被直接写到PVR的硬驱上。

IPTV是一种通过网络基础设施利用互联网协议递送数字电视服务的系统，其可以包括通过宽带连接实现的递送。对于住宅用户而言，IPTV通常与视频点播一起被提供并且可以与互联网服务绑定在一起。IPTV通常由宽带运营商利用闭合网络基础设施来提供。这个闭合网络方法与通过公共互联网实现的TV内容递送产生了竞争。这种递送通常称为互联网上的TV或互联网电视。在商业中，IPTV可以被用来通过公司LAN和商业网络递送电视内容。因此，IPTV是指由观众通过用于计算机网络的技术而接收到电视内容，而并非通过传统格式和布线被递送的电视内容。

几个公司也推出了PVR并且使用卫星、线缆或IP网络来分发VoD内容给这些设备。

前面描述的用于递送视频内容的系统和机制在可用标题数量方面以及以可靠方式递送内容的技术方面是受限的。因此，需要改进信息递送系统和方法。

前述任何目的和优点可以通过各种示例性实施例来实现。它们并不旨在被解释成需要所有可能的实施例，并且它们并不旨在是穷举的或限制可以实现的可能优点。因此，各种示例性实施例的所述和其他目的和优点通过阅读这里的描述而变得显而易见并且可以通过实施各种示例性实施例来学习，如这里所体现的那样或如关于任何变型所修改的那样，所述变型对于本领域技术人员是显而易见的。因此，本发明是这里以各种示例性实施例而显示和描述的一种新颖的方法、安排、组合和改进。

发明内容

由于当前对于一种用于高效递送数据内容的系统和方法的需要，介绍了各种示例性实施例的简要概述。下面的概述中进行了一些简化和忽略，这是为了强调和引入各种示例性实施例的一些方面，而并非旨在限制本发明的范围。

在一些实施例中，数据内容是视频数据内容。一些视频递送系统要求以单播或组播方式实时递送内容。术语“单播”是指向单个目的地发送信息分组。词语“单播”是从词语广播导出的。单播是与广播相反的极端。组播是指向多个目的地同时发送信息。因此，不像单播那样，组播具有广播的一些效率。

对于在用户设备存储内容的应用而言，认为分发内容的速率可以与最终消耗数据的速率无关。因此，在各种示例性实施例中，实现了一种将内容分发给具有存储单元的客户端的机制。在各种示例性实施例中，内容通过组播被分发。在各种示例性实施例中，内容被用来增加实时的点播视频服务。

因此，在各种示例性实施例中，针对例如视频点播的实时信息而最小化了网络上的负载。同样，在各种示例性实施例中，针对递送例如视频点播的实时信息而最小化了服务器上的负载。视频点播或其他实时信息递送服务的点对点特性对于网络而言是很大的负载。相应地，以预先定比(scaled)的方式经由IP网络递送这种服务需要很大的成本。可能要求机顶盒或其他具有内置存储单元的设备或具有所述设备的家庭具有非常高的密度。这种实现通常包括组播能力。在视频递送的情况下，认为前二十个视频点播标题通常带来在任一给定时刻的超过百分之九十的关于视频点播服务的用户请求。因此，认为可以实现网络和服务器基础设施成本的较大节约。

然而应当指出，这里描述的主题的各种优点是在这样的系统中达到的：其中少量的标题带来大量的用户请求。针对这里描述的主题的指定标题数目对于每个实施例是不同的。

将结合组播视频点播(MVoD)系统描述各种示例性实施例。

附图说明

参考附图，通过阅读下面的描述可以更好地理解各种示例性实施例，其中：

图1示意性地示出了视频点播递送系统的第一示例性实施例；

图2示意性地示出了视频点播递送系统的第二示例性实施例；

图3示意性地示出了提供视频点播的方法的第一示例性实施例；

图4示意性地示出了提供视频点播的方法的第二示例性实施例；

图5示意性地示出了提供视频点播的方法的第三示例性实施例；

图6示意性地示出了提供视频点播的方法的第四示例性实施例；

图7示意性地示出了提供视频点播的方法的第五示例性实施例。

具体实施方式

现在参考附图，其中相同的参考号码代表相同的部件或步骤，公开了各种示例性实施例的宽泛方面。应当清楚，各个图中公开的各个方面可以被组合以使得各个示例性实施例包括图1只7中不止一个附图中的方面。

MVoD是“组播视频点播”的缩写，并且是这样一种概念，即以非实时方式跨越网络向PC、机顶盒或其他具有存储单元的设备组播内容。

在各种示例性实施例中，一旦内容在设备上可用，就向用户通知其可用性，并且内容当被请求时从设备中被播放，就像是基于网络的视频点播服务那样。

在各种示例性实施例中，MVoD应用包括客户端和服务器应用。服务器应用创建流定义，然后通过非实时组播将这个信息(以及关联于这个流定义的所有数据)分发给客户端。在一个示例性实施例中，系统能够从网络中的系统可靠地同时复制完整目录层级至多个客户端。

尽管一些实施例聚焦于递送视频，然而其他实施例也用于任何类型的数据，包括音乐、图像或大量文件分发。

在视频的情况下，在各种示例性实施例中，内容通常利用数字权限/有条件访问而以加密形式被递送至客户端。在各种示例性实施例中，当用户播放内容时，客户端连接到网络、获取解密密钥、对消费者计费并且播放内容。

当配置流定义时，当文件对于用户可用时，各种示例性实施例指定了发布日期。这个字段并不影响内容调度。发送流的时间是基于调度信息的。然而，如果内容在其指定发布日期之前到达MVoD客户端设备，客户端应用不将内容显示成“可用”，直到发布日期过去。在这个过渡期间，内容被列于客户端的“即将到来”页面中。

前述特征对于跨越所有客户端而维持一个公共发布日期而言是有用的，同时给予每个客户端多个完全无损且无差错地接收内容的机会。因此，在各种示例性实施例中，如果之前仅部分地接收特定流，则MVoD客户端应用继续监听该流。这改进了丢失的网络上的纠错可能性。通过定义，丢失的网络是遭受数据丢失从而导致传输差错的网络。

在指定期限日期的各种示例性实施例中，日期并不影响服务器对内容的传输。在各种示例性实施例中，指定期限日期对客户端侧产生以下一个或多个影响。

在一些实施例中，MVoD客户端有规律地检查以获悉当前在存储单元中是否有任何过期的内容。在频道指定过期日期之后的预定义时期内，频道自动地从客户端设备被物理地移除。在各种示例性实施例中，这个特征被用来例如通过删除前一星期的连续剧集，来确保为下一星期的剧集腾出客户端硬驱上的空间。应当清楚，除了这个例子之外，其他实施例采用其他标准来确定从客户端设备中物理移除的内容。

在各种示例性实施例中，服务器发送消息至所有客户端以迫使它们从客户端设备中删除内容。

在各种示例性实施例中，不必通过将流添加到调度中而发送流，只要流的组地址没有被另一个流使用就可以随时发送该流。在各种示例性实施例中，MVoD服务器包括实现对流的跟踪和传输历史记录构建的特征。在各种示例性实施例中，所提供的信息被用来管理内容从客户端设备的远程删除。在各种示例性实施例中，这个信息被服务器自动记录和更新。不需要用户介入。应当清楚，在其他实施例中，响应于来自用户或系统操作员的相应提示来记录和更新信息。在其他实施例中，在系统中同时实现两个选项。

在各种示例性实施例中，MVoD通过确保传统VoD服务所需要的大部分负载被单个低数据速率组播流覆盖而大大节约了网络中的带宽。在各种示例性实施例中，这因而节约了容量，这意味着对于较不流行的内容而言，附加带宽对于传统的视频点播服务是可用的。

在各种示例性实施例中，利用MVoD可以递送服务至用户以保证他们随时具有“可用于点播的”前20个电影。如前文提到的，可用于点播的点播标题的数目对于每个实施例都是不同的，并且是基于各种标准来确定的。在各种示例性实施例中，为了递送这种具有MVoD的服务，新的电影每天被递送给客户端。在各种示例性实施例中，这使之能够每月完全地更新所有客户端PVR的内容。在各种示例性实施例中，较早的内容被新内容代替。因此，用户在任何时刻都能够例如选择前20个电影中的任一个。

为了作为传统点播服务而例如以DVD质量MPEG-2递送这个服务，需要网络上每用户大约5Mbit/s的带宽。相反，为了通过MVoD递送服务，需要例如单个100kbit/s流来持续更新所有用户设备中的内容。因此，在各种示例性实施例中，所有1000个用户可以同时观看前20个电影而不会影响网络。当然，这个概念适用于各种实施例中的不同数目的用户和标题。有时，内容以受保护形式而被存储在客户端设备中，并且当用户播放电影时，向网络发送对于解密密钥的请求从而能够播放内容。在各种示例性实施例中，用户同时被计费。在各种示例性实施例中，计费模型是灵活的以使得内容是24小时可播放的、单一播放等等，这取决于所使用的数字权限管理方案。

在各种示例性实施例中，所有用户都获得被递送给他们的内容而不管他们观看与否。在各种示例性实施例中，存在一种被认为是适度流行的内容，尽管并不是流行到足以阻塞所有用户的硬盘，并且该内容将仍被组播但是必须被用户专门预订以接收它。在各种示例性实施例中，这个内容包括流行电影、主题内容、连续剧、新闻等。

在各种示例性实施例中，对于较不流行的内容，尽管仍拥有广泛的观众群，当存在对于该特定内容的预订数目的请求时，用户可以订购将被组播的特定内容。因此，根据前面的描述，在一些实施例中，应当清楚，对于数据递送存在多种机制并且这些机制在单个系统中并行操作。

在各种示例性实施例中，对于其他可用内容，网络和访问负载的大大减少使得单播内容能被直接传送至特定用户。在各种示例性实施例中，这是以降低的数据速率传送的。在其他实施例中，客户端硬驱上的内容可以专门被用来增加实时流。

各种示例性实施例包括下列特征值的一个或多个：

内置式组播引擎，其实现了即刻的非实时组播多个视频流(客户端也可以即刻接收多个流)；

针对每个流的动态可配置的数据速率；

可配置的纠错；

对于内容递送的调度方案；

从服务器向客户端复制目录层级的能力；

动态监测理想的传输以确保文件只在完全无差错的情况下才显示；

通过多次接收文件而恢复丢失分组的能力；

将内容强制递送给用户而不管他们预订与否(例如前20个电影)；

针对并不太流行或标记成高级的内容的第二层服务中的非强制内容；

纠错方案；

健壮的文件信息分发；

使得服务器和服务器用户接口运行于不同机器上的能力；

客户端上动态更新的内容可用性；和

用于预订和解除预订非强制内容的接口。

在各种示例性实施例中，MVoD服务基于拥有组播使能的网络而工作，该网络能够同时递送若干组播频道。在各种示例性实施例中，MVoD服务器在已知信息频道上每n秒广播一个“心跳”，并且这个频道上的信息被所有客户端接收。在各种示例性实施例中，心跳使得频道保持激活并且使得客户端能够知道服务器是激活的。

在各种示例性实施例中，当服务器(人工地或通过调度内容递送事件)被命令递送内容时，几个消息在信息频道上被组播给所有客户端以使得它们知道新的频道将被发送。在各种示例性实施例中，该消息被发送几次以防止分组丢失。

在各种示例性实施例中，被发送给客户端的信息包括组播组和流将出现的端口地址以及指示内容是否是强制性(即客户端是否有接收或不接收的选择)的标志。在各种示例性实施例中，当内容是强制性的或用户预订了非强制性频道时，客户端将等待一随机的时间量，然后打开指定组播频道上的监听器。在一些这种实施例中，客户端等待一随机的时间量以防止由于多个客户端同时发送互联网小组管理协议(IGMP)加入请求而造成的网络过载。

IGMP是一种用于管理互联网协议组播组成员的通信协议。IGMP由IP主机和相邻组播路由器使用以建立组播组成员。它是IP组播规范的组成部分，与针对单播传输的互联网控制消息协议(ICMP)相似。IGMP被用于例如在线视频和游戏，并且实现了对资源的更高效使用(当支持这些使用时)。然而，当网络上的多个客户端同时发送IGMP加入请求时，网络可能经历过载条件。这个可能性被认为在这样的实施例中大大降低：其中客户端在发送IGMP加入请求之前等待随机的时间量。

在各种示例性实施例中，服务器开始广播对新的流的组播地址和端口的倒计数。在各种示例性实施例中，在这个倒计数时期内，关于将被发送的文件和每个文件的大小的信息被发送多次。在各种示例性实施例中，到倒计数结束且流被发送的时间为止，所有客户端都已加入组播组、接收所有文件信息并且准备好接收进入的流。

在各种示例性实施例中，服务器发送目录结构中的所有文件，其被定义成编号用户数据报协议(UDP)分组的连续流。UDP是互联网协议组中的核心协议。利用UDP，联网计算机上的节目可以相互发送有时称作数据报(利用数据报套接(socket))的短消息。UDP有时称为通用数据报协议或不可靠数据报协议，因为UDP并未提供可靠性和像TCP那样的有保障的排序。当使用UDP时，数据报可能没有按照顺序到达或者被丢失而没有通知。

然而，由于不存在检查每个分组是否真正到达的开销，对于许多轻型的或对时间敏感的应用，UDP更快且更高效。同样，UDP的无状态特性对于应答来自大量用户的少量查询的服务器而言是有用的。出于这些原因，与TCP相比，广播(被发送至本地网上的所有用户)和组播(被发送至所有订户)需要UDP。

在各种示例性实施例中，可以将一个报头添加至每个分组中以对其编号并且将其标识为“消息”、“文件”、“前向纠错”或其他类型的分组。在各种示例性实施例中，由于流被发送，服务器持续生成FEC(前向纠错)数据。在各种示例性实施例中，这是将少量数据分组散布于整个所发送到数据中。

在各种示例性实施例中，开销的实际量和纠错能力的健壮性是可配置的，尽管默认选项对于必须要发送的数据量增加大约10％，并且将导致至网络上所有客户端的大小平均的电影的有保证的无差错传输，其随机分组丢失率只在4％以下。在其他实施例中，应当清楚，对必须要发送的数据量的增加是不同于10％的值。同样，在其他实施例中，应当清楚，随机分组丢失率的降低是与低于4％不同的值。类似地，在其他实施例中，两种值都是不同的。

在各种示例性实施例中，当客户端已从服务器接收文件并且它们都无差错时，用户接口被动态地构建并且更新以显示所有可用内容。在各种示例性实施例中，如果客户端在接收文件时检测到差错，则下次这个内容从服务器被发送时，客户端接收丢失的分组以完善地重构信息。在各种示例性实施例中，客户端确保它具有足够的磁盘空间来存储进入流并且必要时自动删除旧的内容以腾出空间。

各种示例性实施例包括下列特征中的一个或多个：客户端、服务器、服务器用户接口。

在各种示例性实施例中，MVoD客户端包括用于从服务器接收组播内容且提供交互式用户接口的应用。在各种示例性实施例中，这实现了内容的导航和回放以及预订新内容的能力。

在各种示例性实施例中，客户端支持多个用户设备，这意味着可以在家庭网络环境中只运行一个客户端实例，并且通过web浏览器或其它机制从家庭网络上的任何其他机器访问其可用内容。在各种示例性实施例中，设置针对每个客户端设备而被单独地保存。在各种示例性实施例中，web应用是可选的服务器用户接口。在各种示例性实施例中，服务器用户接口的applet(Java小应用程序)版本通过运行于应用服务器上的JSP(java服务器页面)来与服务器通信。所述applet是一种用Java编程语言编写的程序，其可以并入HTML页面中。Java服务器页面(JSP)技术提供了创建动态web内容的简单快速的方式。JSP技术实现了与服务器和平台无关的基于web的应用的快速开发。在其他示例性实施例中，这个接口可以通过web服务或一些其他机制而被提供。

在各种示例性实施例中，前向纠错能够在客户端利用由少量额外发送的数据而提供的保护来恢复传输中的数据丢失。在各种示例性实施例中，MVoD所使用的前向纠错(FEC)方法被设计成用于使用UDP分组的组播IP环境。在各种示例性实施例中，UDP分组在传输层利用简单的校验和而被检验。校验和是一种冗余检查。它是通过检测发送数据中的差错而保护数据完整性的简单方式。因此，在各种示例性实施例中，有差错的分组决不会到达应用层。在各种示例性实施例中，MVoD FEC机制操作于应用层并且被设计成重构在传输组播流期间丢失的完整分组。

在各种示例性实施例中，在分组恢复期间，特定的FEC分组与其范围内的所有正确接收的数据分组(以及其任何FEC分组)一起使用，从而恢复可能在该范围内丢失的任何单个分组。在各种示例性实施例中，FEC分组被用来恢复其他FEC分组。在各种示例性实施例中，这导致用来确定另一丢失数据或FEC分组的FEC分组的恢复。在各种示例性实施例中，这在尝试恢复尽可能多的丢失数据分组时以递归的方式进行。

各种示例性实施例包括统一的分组标识和编号方案。在各种示例性实施例中，FEC用于组播UDP分组。因此，在各种示例性实施例中，这个信息在应用层被插入且被解释。在各种示例性实施例中，分组序号在整个FEC流/会话中是唯一的。

在各种示例性实施例中，MVoD应用适于在不可靠的网络中发送多个无差错文件而无需任何重传。在MPEG-2传输流或类似的用于防止丢失的视频方案的情况下，所述技术可以容易地大大降低接收的差错量，这与移除所有差错的实施例不同。

在各种示例性实施例中，观看电影的用户辅助设置自动化配置文件以确定将哪个内容下载到他们的PVR中。在各种示例性实施例中，用户定义他们自己的配置文件和/或预先订购指定内容。

在组播MVoD服务的内容的各种示例性实施例中，服务是可扩缩的并且带宽需求与内容量有关而不是与用户量有关。然而，不像广播业务那样，在各种示例性实施例中，MVoD是非实时广播的。因此，在各种示例性实施例中，5Mbit/s的内容在1Mbit的管道中被递送，如果是实时递送则其简单地采取距用户距离的5倍的长度。应当清楚，其他实施例使用其他数据传输速率和/或其他数据传输管道大小。在各种示例性实施例中，这使之能够以低数据速率递送非常高质量的内容。

在美国已经建议视频存储中的前12个标题对应于80％的请求。在MVoD被用来分发12个标题且保持它们为最新的各种示例性实施例中，新的电影只需要最差每隔几天被递送至机顶盒。在存在网络中的持续组播流的各种示例性实施例中，这使得DVD质量的标题能够利用140kbit/s的总网络组播带宽而被持续更新。在各种示例性实施例中，几百个同时的组播标题在同一带宽中被广播，如普通广播服务所需要的那样。再次，应当清楚，其他实施例使用其他数目的标题和/或其他总网络组播带宽。

不像传统的VoD或广播服务，在各种示例性实施例中，MVoD服务的网络利用率是运营商自行决定的，并且在一天中按照该时刻可用的带宽来增加或降低速率。各种示例性实施例实现了足够轻型的服务来使用现有的空闲网络容量(例如保持前20个电影最新)。

在各种示例性实施例中，从运营商角度来看，MVoD的非实时特性使之能够作为“组播窗口”而向内容所有者递送内容或销售“容量”。在各种示例性实施例中，由于内容是非实时组播的，因此管道持续地下载以更新本地存储的内容。

在各种示例性实施例中，使用MVoD基础设施提供了递送不同类型的服务的能力，例如以下服务中的一个或多个：视频订购(提前几小时、几天或几星期)、特殊事件的大量分发和递送、以及流行新闻、电视连续剧的分发，等等。

当提供MVoD服务时期望递送它的网络基础设施能够从一端到另一端地进行组播。

现在将参考特定服务来描述前面的内容。应当清楚，这里描述的各种示例性实施例的各方面按照各种示例性实施例中的多个组合而被组合。

图1示意性地示出了视频点播递送系统100的第一示例性实施例。示例性视频点播递送系统100包括视频源102、网络104、接入节点106和客户端设备108、110、112。在VoD递送系统100中，视频数据从视频源102通过网络104和接入节点106而被单独地递送至每个客户端设备108、110、112。

在各种示例性实施例中，通过网络104向每个客户端108、110、112分别递送数据拷贝。在各种示例性实施例中，从包含于视频源102中的视频服务器向每个客户端设备108、110、112单独递送分别的视频流114、116、118。这种实施例需要网络104的大量带宽。

图2示意性地示出了VoD递送系统200的第二实施例。示例性VoD递送系统200包括组播视频源202、网络204、接入节点206和具有存储单元208、210、212的客户端设备。示例性VoD递送系统200是一种其中递送组播内容的系统。

在各种示例性实施例中，相同的数据被递送至具有存储单元208、210、212的每个客户端设备。在各种示例性实施例中，单个视频流216经过网络204。在各种示例性实施例中，单个视频流216在接入节点206被复制并且随后被递送至具有存储单元208、210、212的每个客户端设备。

在示例性VoD递送系统200中，视频是被非实时地组播的。在各种示例性实施例中，仅一个视频流216的拷贝在网络204内是必需的。在各种示例性实施例中，如图2所示，客户端设备208、210、212包括存储单元。应当清楚，图1所示的特定单元可以与图2所示的单元组合。因此，在各种示例性实施例中，客户端设备108、110、112替代具有存储单元的客户端设备208、210、212。

在包括具有存储单元的客户端设备208、210、212的各种示例性实施例中，当视频标题在客户端设备208、210、212被播放时，该视频标题是从本地磁盘被访问的。在图1的单元与图2的单元相组合的其他示例性实施例中，当播放视频标题时，视频标题是从例如视频源102的视频服务器、跨越网络204、通过单播而被访问的。因此，一些实施例对应于图2但增加了图1所示的视频源102，作为组播视频源202的可选项或添加。与网络104相比，VoD递送系统200的示例性实施例通常降低了网络204中使用的带宽。

图3示意性地示出了提供VoD 300的方法的第一示例性实施例。开始于步骤302，标题调度被定义并且在已知组播组中被组播。示例性方法300然后进行到步骤304。在示例性步骤304中，客户端预订已知频道。示例性方法300然后进行到示例性步骤306。

在示例性步骤306中，客户端监听要求动作的事件或信息。示例性方法300然后进行到步骤308，其中做出关于是否存在要求动作的事件的评估。如果在示例性步骤308中确定不存在要求动作的事件，则示例性方法300返回示例性步骤306并且重复该步骤306。

如果在示例性步骤308中确定存在要求动作的事件，则示例性方法300进行到示例性步骤310。在示例性步骤310中，发生要求动作的事件。示例性方法300然后返回示例性步骤304。

在各种示例性实施例中，步骤302中的组播组包括关于即将到来的标题的信息。在各种示例性实施例中，所有客户端都在步骤304中预订组播组。在各种示例性实施例中，所有客户端都在示例性步骤306中监听组播组。在各种示例性实施例中，所有调度信息在分配给组播组的频道上被分发。根据前面的描述，图3示出了用于预订组播频道的方法的示例性实施例。

图4示意性地示出了用于提供VoD 400的方法的第二示例性实施例。示例性方法400开始于步骤402，其中创建转盘(carousel)定义递送参数。在各种示例性实施例中，步骤402中创建的递送参数包括指定内容标题、数据速率、组地址、递送调度、元数据等值的一个或多个。在各种示例性实施例中，转盘被定义成下列内容中的一个或多个：要以特定顺序播放的若干标题；一个或多个标题所属的组的定义；发送一个或多个标题的数据速率；开始递送一个或多个标题的调度时间；等等。

示例性方法400然后进行到示例性步骤404。在示例性步骤404中，内容递送调度到达。当按照内容递送调度确定应当发送的内容时，示例性方法400进行到示例性步骤406，在该步骤406中以回路的方式发送内容。

在各种示例性实施例中，一旦内容被递送，就可以在列表中添加或移除标题。在各种示例性实施例中，一旦内容被递送，就可以改变发送内容的速率。在各种示例性实施例中，发送内容的速率被人工改变。在各种示例性实施例中，发送内容的速率通过一个或多个动态网络反馈机制而被改变。

在各种示例性实施例中，示例性方法400从示例性步骤406进行到示例性步骤408。在示例性步骤408中，执行关于是否改变转盘中的标题的评估。如果在示例性步骤408确定不改变转盘中的标题，则示例性方法400返回示例性步骤406。如果在步骤408中确定改变转盘中的标题，则方法400进行到其中标题被添加至转盘或从其中被移除的示例性步骤410。示例性步骤410之后，示例性方法400返回步骤406。

在各种示例性实施例中，示例性方法400从示例性步骤406进行到示例性步骤412。在示例性步骤412中，进行关于参数是否要改变的评估。如果示例性步骤412中的评估结果是没有参数被改变，则示例性方法400返回示例性步骤406。如果示例性步骤412中的评估结果是参数要被改变，则示例性方法400进行到其中递送参数被重新定义的示例性步骤414。

在各种示例性实施例中，示例性步骤414中重新定义的递送参数是传送数据的速率。在示例性步骤414中重新定义递送参数之后，示例性方法400返回示例性步骤406。

因此，提供VoD 400的示例性方法包括从示例性步骤406开始的两个回路。第一回路经过步骤408和410而返回步骤406。第二回路经过步骤412和414而返回步骤406。在各种示例性实施例中，这两个回路同时存在。在各种示例性实施例中，只使用两个回路中的一个。

根据前面的描述，在各种示例性实施例中，转盘中的内容被顺序地发送以共享相同的组播组地址。同样，在各种示例性实施例中，转盘中的内容被顺序地发送以共享相同的基本传输速率。例如，在各种示例性实施例中，传输速率是100Kb/s。

在各种示例性实施例中，如果转盘中的内容匹配于用户的配置文件并且内容并不存在于用户机顶盒中的硬盘或其它存储介质中，则机顶盒加入组播组。

在各种示例性实施例中，存在几种不同的转盘，每个都在各自的组播地址上同时下载内容。例如，在各种示例性实施例中，存在不同的转盘并且每个都关联于不同种类的电影。因此，在各种示例性实施例中，转盘被分配给下列种类中的一个或多个：喜剧、科幻、动作、戏剧等。

图5示意性地示出了提供视频点播500的第三示例性方法。示例性方法500开始于步骤502，其中一个或多个标题被定义成强制的或非强制的。示例性方法500然后进行到步骤504。在示例性步骤504中，内容被递送至客户端机顶盒。在步骤504中将内容递送至客户端机顶盒之后，示例性方法500进行到步骤506。

在步骤506中，进行关于内容是否是强制的评估。如果步骤506中的评估结果是内容是非强制的，则方法进行到示例性步骤508。

在示例性步骤508中，进行关于客户端是否预订标题的评估。如果步骤508中的评估结果是客户端未预订该标题，则示例性方法500进行到示例性步骤510，其中标题被忽略。在示例性步骤510之后，示例性方法500返回示例性步骤504。

如果示例性步骤506中执行的评估结果是确定内容是强制性的，则示例性方法500进行到示例性步骤512。类似地，如果示例性步骤508中的评估结果是客户端预订了标题，则示例性方法500进行到示例性步骤512。

在示例性步骤512中，客户端预订组播组。在各种示例性实施例中，客户端然后将内容写入其磁盘或其它存储介质中。在各种示例性实施例中，信息针对特定频道而被发送。

指定至少一段内容为强制或非强制的能力使得基于服务器的机制能够迫使客户端存储该段内容而不管该客户端是否预订该段内容。在各种示例性实施例中，针对必须被写入客户端机顶盒的任何内容而使用强制标志。在各种示例性实施例中，在步骤506中确定强制标志的存在。在各种示例性实施例中，当在步骤506中确定强制标志存在时，强制标志的存在被解释成指示了该内容是强制的。

根据前面的描述，在各种示例性实施例中，标识成强制的内容是流行电影。在另一示例性实施例中，强制信息是一个或多个广告。例如，在各种示例性实施例中，包括这里描述的主题的实体的商业模型要求所有用户接收一个或多个广告。在各种示例性实施例中，剩余的内容作为预订内容而被提供。

在各种示例性实施例中，基于分组编号将文件写入存储介质中，例如磁盘。在其他示例性实施例中，如这里描述的，以到达和接收的顺序将文件写入例如磁盘的存储介质中。

图6示意性地示出了提供视频点播600的方法的第四示例性实施例。示例性方法600开始于示例性步骤602，其中标题和信息在流中被分发给所有客户端。示例性方法600然后进行到示例性步骤604。

在示例性步骤604中，客户端在流动中部开启。示例性方法600然后进行到示例性步骤606。在示例性步骤606中，所有当前信息被读取并被处理。

在各种示例性实施例中，当前频道上的周期性信息在信息频道上被发送。因此，在各种示例性实施例中，当在示例性步骤604中客户端在流中部开启时，该客户端被通知以该客户端流并且具有在当前流的传输中部加入该流的选项。

在示例性步骤606之后，示例性方法600进行到示例性步骤608，其中进行确定内容是否是强制性的评估。如果在示例性步骤608中确定内容是非强制性的，则示例性方法600进行到示例性步骤610。上面结合图5详细描述了关于强制内容的类型的讨论。

在示例性步骤610中，进行关于客户端是否预订标题的确定。如果在步骤610中确定客户端未预订标题，则示例性方法600进行到示例性步骤612，该步骤中标题被忽略。在示例性步骤612之后，示例性方法600返回示例性步骤606。

如果在示例性步骤608中确定内容是强制的，则示例性方法600进行到示例性步骤614。类似地，如果在示例性步骤610中确定客户端预订标题，则示例性方法600进行到示例性步骤614。

在示例性步骤614中，客户端预订组播组。在各种示例性实施例中，在预订组播组之后，客户端开始将内容写入其磁盘中。在各种示例性实施例中，在预订组播组之后，客户端定义还未从流接收到的分组。这样，在流中部开启的客户端能够接收包含于该流中的所有信息，特别是在内容如上面结合图4所描述的那样以回路或转盘的方式被分发的情况下。

图7示意性地示出了提供视频点播700的方法的第五示例性实施例。示例性方法700是一种例如用于从部分文件递送中恢复的方法。在示例性方法600的步骤614的结论中，在示例性步骤604开启于流中部的客户端会接收到部分文件递送。因此，示例性方法700开始于示例性步骤702，该步骤对应于示例性方法600中的示例性步骤602。在示例性步骤702之后，示例性方法700进行到示例性步骤704。

在示例性步骤704中，客户端读取指示正发送还不完整或包含丢失信息的文件的信息。在示例性步骤704之后，示例性方法700进行到示例性步骤706。在示例性步骤706中，确定文件是否是完整的。

如果在示例性步骤706确定文件不完整，则示例性方法700进行到示例性步骤708。在示例性步骤708中，客户端继续读取数据直到文件中的所有数据被无差错地接收。一旦文件中的所有数据被无差错地接收，示例性方法700就进行到示例性步骤710，该步骤中客户端停止接收文件。同样，如果在示例性步骤706确定文件是完整的，则示例性方法700进行到示例性步骤710，该步骤中客户端停止接收文件。

以前面描述的方式，在各种示例性实施例中，客户端跟踪它已接收了哪些数据以及还未接收哪些数据。在各种示例性实施例中，客户端标识还未完整接收到文件。在各种示例性实施例中，步骤702中的信息流指示标题被重发送。在各种示例性实施例中，客户端重新预订标题，直到它已从与该标题有关的数据流中无差错地接收所有数据。在各种示例性实施例中，只要确定文件是完整的，客户端就从该标题的数据流断开，即使该标题的流仍在继续。

根据前面的描述，在各种示例性实施例中，为了扩缩内容的分发，通过一个或多个FEC受保护组播流来执行递送机制。在各种示例性实施例中，FEC受保护组播流以与内容的数据传输速率完全无关的速率而被递送。在各种示例性实施例中，FEC受保护组播流以按照一个或多个网络需求的速率而被递送，该速率快于或慢于内容的数据速率。

在各种示例性实施例中，数据的每个分组由唯一的顺序标识符来标识。在各种示例性实施例中，提前向内容的接收方通知所发送的内容流的特性。因此，在各种示例性实施例中，内容的接收方提前获悉所传送的信息中何时存在空洞。在各种示例性实施例中，未被包含的内容的一个或多个分组如上面所述的那样可选地被恢复，或者作为对前述内容的补充。在各种示例性实施例中，作为请求数据流的丢失部分的机制而采用单播机制。

根据前述内容，在各种示例性实施例中，利用所谓的最大努力(besteffort)机制将数据传送至客户端。最大努力机制是优选地，因为例如FEC机制的其他机制不能在任何情况下重构所有丢失的分组。

根据前述内容，在各种示例性实施例中，减少了网络中的负载。因此，各种示例性实施例导致了成本节约。各种示例性实施例改进了端点数目。各种示例性实施例对于在网络中分发内容至VoD服务器而言是高效的。同样，各种示例性实施例是用于减少针对递送流行内容至客户端的带宽需求的有效机制。

根据前述内容，在包括具有硬盘的IPTV客户端设备的各种示例性实施例中，流行电影被存储在硬盘上。在各种示例性实施例中，当用户选择播放电影时，客户端首先检查电影标题在本地硬盘上是否可用。在各种示例性实施例中，当电影在本地硬盘上可用时，直接从硬盘播放期望的标题，而不是通过网络传送该标题。

在各种示例性实施例中，应用和系统查看客户端缓冲器并且确定丢失了哪些分组。在各种示例性实施例中，只从网络中的VoD服务器请求丢失的分组。各种示例性实施例使用滴漏(trickle down)机制来预先缓存电影的开始部分，例如电影标题开始处所包含的介绍内容。因此，在各种示例性实施例中，VoD标题能够即刻开始并预先填充机顶盒中的缓冲器。

尽管已经参考特定的示例性方面描述了各种示例性实施例，然而应当理解，也存在包括结合不同实施例或附图描述的各方面的组合的其他实施例，并且细节可以在各种明显的方面中被修改。在本公开的精神和范围内做出修改和变型对于本领域技术人员而言是显而易见的。因此，前面的公开、描述和附图只是用于说明而决非限制本发明，本发明只由权利要求书限定。

Claims (25)

1.一种用于递送数据的方法，包括：

开始数据的高效递送；

在所述数据的递送开始之后的中点处开启客户端设备；

从所述中点至结束点读取并处理所述数据；

评估所述数据是否是完整的；

确定所述数据是不完整的；

读取数据流中的附加数据；

标识所述数据流中的从开始点至所述中点的数据；

接收从开始点至所述中点的数据；和

确定所述数据是完整的。

2.根据权利要求1所述的用于递送数据的方法，还包括将所述数据存储在包含于每个所述客户端设备中的存储介质上。

3.根据权利要求2所述的用于递送数据的方法，还包括针对附加数据而重复开始、开启、读取和处理、评估、确定数据不完整、读取、标识、接收和确定数据完整的所述步骤。

4.根据权利要求1所述的用于递送数据的方法，还包括标识从所述数据中丢失的信息并且提供所丢失的信息。

5.根据权利要求1所述的用于递送数据的方法，其中，所述数据是视频点播内容。

6.根据权利要求5所述的用于递送数据的方法，其中，所述视频点播内容包括多个标题的调度。

7.根据权利要求1所述的用于递送数据的方法，其中，所述客户端设备针对要求动作的事件而监控所述数据流中的数据，所述客户端设备识别该要求动作的事件，并且所述客户端设备执行所要求的动作。

8.根据权利要求7所述的用于递送数据的方法，其中，所要求的动作包括下载新的视频点播标题。

9.根据权利要求8所述的用于递送数据的方法，其中，所要求的动作还包括从包含于所述客户端设备中的存储介质中删除旧的视频点播标题。

10.根据权利要求8所述的用于递送数据的方法，其中，新的视频点播标题具有将来的发布日期、并且在该将来的发布日期之前对该新的视频点播标题的访问都是不可用的。

11.根据权利要求7所述的用于递送数据的方法，其中，识别所述要求动作的事件包括确定该客户端设备已经预订新的视频点播标题。

12.根据权利要求7所述的用于递送数据的方法，其中，所要求的动作包括重新定义递送参数。

13.根据权利要求12所述的用于递送数据的方法，其中，所述递送参数是传送视频点播数据的速率。

14.根据权利要求1所述的用于递送数据的方法，还包括将所述数据存储在包含于客户端设备中的存储介质上。

15.一种用于递送数据的方法，包括：

将数据定义成强制数据；

使得多个客户端设备非自愿地预订对应于所述强制数据的组播组；

将所述强制数据从数据源发送至网络；

从所述网络将所述强制数据中继至接入节点；

在所述接入节点复制所述强制数据；和

从所述接入节点向所述多个客户端设备发送所复制的强制数据，所述多个客户端设备对应于未请求接收该强制数据的多个用户。

16.根据权利要求15所述的用于递送数据的方法，还包括将标志添加到所述强制数据中并且基于该标志的存在而确定该强制数据是强制的。

17.根据权利要求15所述的用于递送数据的方法，还包括：

将附加数据定义成可选数据；

使得所述多个客户端设备自愿地预订对应于所述可选数据的组播组；

从所述数据源向所述网络发送所述可选数据；

从所述网络将所述可选数据中继至所述接入节点；

在所述接入节点复制所述可选数据；和

从所述接入节点发送所复制的可选数据至所述多个客户端设备，所述多个客户端设备对应于想要接收该可选数据的多个用户。

18.根据权利要求17所述的用于递送数据的方法，其中，所述可选数据是相比所述强制数据而言较不流行的内容。

19.根据权利要求15所述的用于递送数据的方法，其中，在将数据定义成强制数据的步骤与使得所述多个客户端设备非自愿地预订对应于所述强制数据的组播组的步骤之间，所述多个客户端设备中的每一个等待一随机的时间量。

20.根据权利要求15所述的用于递送数据的方法，其中，所述数据是视频点播内容。

21.一种用于递送数据的方法，包括：

在数据源中建立包含多个数据集合的转盘；

从所述数据源向网络发送所述多个数据集合中的第一数据集合；

从所述网络将所述第一数据集合中继到接入节点；

在所述接入节点复制所述第一数据集合；

将所复制的第一数据集合从所述接入节点发送至多个客户端设备；

针对所述多个数据集合中的至少一个第二数据集合而重复发送、中继、复制和发送的所述步骤；和

在针对至少一个第二数据集合完成重复步骤之后返回发送第一数据集合的步骤。

22.根据权利要求21所述的用于递送数据的方法，还包括定义递送所述转盘的递送参数。

23.根据权利要求22所述的用于递送数据的方法，还包括：

评估是否期望改变所述递送参数；

确定期望改变所述递送参数；和

重新定义所述递送参数。

24.根据权利要求21所述的用于递送数据的方法，还包括：

评估期望改变所述多个数据集合中的一个或多个数据集合；

确定期望改变所述多个数据集合中的一个或多个数据集合；和

改变所述多个数据集合中的针对其而确定期望进行改变的一个或多个数据集合。

25.根据权利要求21所述的用于递送数据的方法，其中，所述多个数据集合是视频点播内容。

Images