CN100458747C - 用于确定计算机的连接速度的方法 - Google Patents

Abstract

一种用于远程确定多媒体内容用户的计算机配置的方法，包括：将播放器检测代码发送到用户的计算机，并且接收有关用户计算机的配置信息。一种确定计算机的连接速度的方法，包括：基于估计的带宽确定计时块的大小，并且检取该计时块。基于计时块大小以及传输开始和结束时的时间，确定连接速度。

Description

用于确定计算机的连接速度的方法

技术领域

此处描述的发明涉及信息系统，并且尤其涉及多媒体内容客户端配置信息的检测。

背景技术

在假定数据网络的可用性和高速数据连接的可用性的情况下，现在让终端用户访问多媒体内容是很普通的。许多网络站点现在向用户提供音频与视频。理论上，用户简单地点击在网页上给出的链接或者控制，就递送一个或多个多媒体文件。如果用户具有适当的硬件和软件配置，则然后可以播放该文件。

然而，当前有显著多样的用户配置。一些用户具有基于INTEL(英特尔)的个人计算机(PC)，而其它用户可能具有APPLE(苹果)MACINTOSH计算机。还存在不同的操作系统。一些用户将具有来自MICROSOFT(微软)公司的MICROSOFT WINDOWS(微软视窗)版本，而其它用户具有来自APPLE(苹果)公司的MAC OS版本。此外，这些操作系统中的每一个现在在用户团体中都具有几个版本。此外，现在存在许多软件程序可用于在用户计算机上播放多媒体。这些播放器包括QUICKTIME(来自苹果公司)、REALPLAYER(来自REALNEI WORKS公司)、以及WINDOWS MEDIAPLAYFR(来自微软公司)。此外，这些播放器中的每一个都有几个现在在用户团体中使用的版本。最后，不同的用户可能以不同的数据速率进行操作。一些用户可能具有高速宽带连接，而其它用户可能具有56K调制解调器连接。

在假定平台、操作系统、播放器、和数据速率具有这样的多样性的情况下，内容供应商受困于如何格式化要递送的内容的问题。不正确的格式化将导致与用户配置不兼容的内容的递送。这导致不可用的内容。如果内容是可用的，则内容可能处于未能充分利用在用户配置中可用的全部特征的格式中，从而使得用户体验的内容并没有像它所能具有的那样的丰富。

在过去，内容供应商已经通过选择一些通用的用户配置集合来解决了这个问题。例如，供应商可以识别最通用的媒体播放器及其版本。供应商为这些播放器中的每一个格式化内容，并且存储内容的这些相配套的版本。供应商然后会开发要提供给用户的备忘录，其实际上询问用户具有哪个媒体播放器，或者如果用户具有一个以上的媒体播放器，则询问哪个播放器是用户优选的。用户然后进行选择，并且将已经以选定格式预编码的内容递送给用户。

这种解决方案具有局限性。首先，它是相对不灵活的。选项的数目是有限的。用户的特定配置可能被未必给出作为菜单中的选项。而且如果终端用户具有一个以上的他可用的媒体播放器，则用户优选的选择未必已经作为选项而列出。此外，上述解决方案每次都要求用户输入。用户可能不想被询问。用户反而可能更喜欢为他解决了格式化问题。在其它情况下，用户可能不知道菜单所请求的信息。用户可能不知道他具有什么版本的媒体播放器。这种解决方案还要求内容供应商改变他们的菜单，以及每当新的播放器(或者现有播放器的新版本)变得流行时重新编码内容。因此，上述解决方案是不灵活的，而且对于用户和供应商来说都是难以承担的。

因此，需要一种用于确定用户的配置以便向用户提供导致最佳视觉体验的、以兼容格式的内容的方法。此外，配置的确定应当以使对用户输入的需要最小化的方式或者以用户友好的方式进行。此外，确定用户连接速度的有效方法也是所期望的。

发明内容

提供了一种用于远程确定多媒体内容用户的计算机配置的方法。

该方法包括发送播放器检测代码到用户的计算机。接收有关用户计算机的配置信息，其中该配置信息包括有关OS版本、网络浏览器版本、硬件平台、用户接口语言类型、编码格式、或者压缩算法的信息或者这些信息的组合。该方法可以包括在接收之前执行在用户的计算机处设置到递送管理服务器域的cookie，而且其中以cookie的形式接收配置信息。

还提供了一种用于远程确定多媒体内容用户的计算机配置的方法，其包括：将播放器检测代码发送到用户的计算机，接收有关用户计算机的配置信息，以及发送修改的信息头指令。

该方法还可以包括发送唯一的客户端ID。可以在发送信息之后接收指令，而且该修改的信息可以包括一些未包括在所发送信息中的信息，和/或该修改的信息可以排除一些包括在所发送信息中的信息。还可以在接收之前发送修改的信息头指令，而且可以根据该修改的信息头指令准备要接收的配置信息。

所接收的配置信息可以包括一个或多个诸如硬件适配信息(adaptation)和/或用户接口版本适配信息之类的适配信息。可以根据该适配信息准备修改的头信息指令。

还提供了一种用于远程地确定多媒体内容用户的计算机配置的方法，其包括：在用户的计算机处接收来自第二计算机的播放器检测代码，向第二计算机发送有关用户计算机的配置信息，以及接收修改的信息头指令。

可以接收唯一的客户端ID。客户端ID指针地址可以附加到配置信息上以便发送给第二计算机。可以基于所接收的头指令准备修改的头信息。可以将具有附加的客户端ID的修改的头信息发送给第二计算机。可以在发送修改的头信息之前接收进一步的配置信息请求。可以在发送配置信息之后接收指令。该修改的信息可以包括一些未包括在所发送信息中的信息，和/或可以排除一些包括在所发送信息中的信息。还可以在发送配置信息之前接收指令。可以根据修改的信息头指令准备要发送的配置信息。该配置信息可以包括一个或多个诸如硬件适配信息和/或用户接口版本适配信息之类的适配信息，而且可以根据该适配信息准备修改的头信息指令。

还提供了一种用于确定计算机的连接速度的方法，该方法包括：基于估计的带宽确定计时块的大小，标记计时块传输开始时的时间，标记计时块传输结束时的时间，以及基于所确定的计时块大小以及传输开始和结束时的时间确定连接速度。

还提供了一种用于确定计算机的连接速度的方法，该方法包括：接收具有已知大小的数据计时块，接收要开始计时块传输时的启动时间，在该启动时间上开始计时块传输，标记计时块传输结束时的时间，以及基于计时块大小以及传输开始和结束时的时间确定连接速度。

在每种情况下，可以通过下述操作来确定计时块大小：取出估计的带宽信息，确定检取数据以便用足够的分辨率来确定连接速度的估计时间；以及确定将花费所确定的估计时间来进行检取的计时块大小。可以以作为首选项页面一部分的标记语言注释的形式接收计时块。该方法还可以包括在cookie中存储连接速度。该方法可以包括将cookie发送到递送管理服务器。计时块可以包含随机数据。

根据本发明的进一步方面，提供了一种用于远程地确定多媒体内容用户的计算机配置的方法。这种方法包括：发送播放器检测代码到用户的计算机，接收有关用户计算机的配置信息，以及基于所接收的配置信息确定在用户计算机上的数字权利管理信息的类型。

还提供了一个或者多个处理器可读存储设备，其上包含有处理器可读代码。该处理器可读代码用于对一个或多个处理器进行编码，以便根据任何一种上述方法执行用于确定多媒体内容用户的计算机配置的方法和/或用于确定计算机的连接速度的方法。

附图说明

此处并入并且成为该说明书一部分的附图说明了本发明，并且连同该描述一起，进一步用来说明本发明的原理以及允许相关领域的技术人员构造和使用该发明。

在附图中：

图1说明了本发明实施例的一般体系结构。

图2是说明本发明实施例的计算环境的框图。

图3A是说明本发明实施例的总体处理过程的流程图。

图3B是说明根据一个实施例、包括接收递送管理器HTTP请求在内的服务器端请求处理的流程图。

图3C是说明根据实施例、包括接收检测URL HTTP请求在内的服务器端请求处理的流程图。

图3D是说明根据本发明实施例的进一步请求处理的流程图。

图4A是说明根据本发明的实施例的媒体播放器检测处理的流程图。

图4B是说明根据本发明的示例实施例的客户端视窗媒体播放器(WMP)检测的流程图。

图4C是说明根据本发明的另一示例性实施例的客户端RealPlayer(Real)检测的流程图。

图4D是说明根据本发明的示例性实施例的客户端QuickTime(QT)检测的流程图。

图5A是说明根据本发明的实施例、向用户给出首选项(preferences)页面的处理的流程图。

图5B是一般地说明根据本发明的实施例的带宽检测方法的流程图。

图6A-6C是描述根据本发明的实施例、用于访问媒体内容的例程的流程图。

图7描述了根据本发明的实施例、可以使用的示例性代码转换器。

图8是示出根据本发明的实施例、用于各种发布变量的示例性代码转换源类型和目标类型的表格。

图9是示出根据本发明实施例的示例性客户端环境变量类型的表格。

现在，将参考附图描述本发明的优选实施例。在附图中，类似的参考数字指示相同或者功能上相似的单元。

引入的参考文献

下面是参考文献的引用列表，其中的每个参考文献除了是被描述为本发明的背景技术、摘要和发明内容、由此还通过引用并入到以下优选实施例的详细说明中的文献外，还公开了在下面没有详细阐述的、优选实施例中的单元或者特征的替换实施例。可以查阅这些参考文献中的一个文献或者两个或多个文献的组合，以获得在此处的详细说明中描述的优选实施例的变体。这些参考文献为：

1968年7月授权的美国专利3,394,352；1976年2月授权的美国专利3,937,881；1997年8月授权的美国专利5,657,015；2003年7月15日授权的美国专利6,593,860；2002年6月授权的美国专利6,407,680；2002年10月15日授权的美国专利6,466,939；1999年7月27日授权的美国专利5,928,330；2001年11月13日授权的美国专利6,317,134；以及2000年5月30日授权的美国专利6,070,002；以及

2003年8月21日公开的美国公开申请2003/0158913，2003年5月15日公开的美国公开申请2003/0093507，2002年7月25日公开的美国公开申请2002/0099858，2002年7月25日公开的美国公开申请2002/0099770，以及2002年7月11日公开的美国公开申请2002/0091800；以及

2003年8月20日提交的美国专利申请10/644,602；以及

Chapman、Nigel等人所著的“Digital Multimedia”(John Wiley& Sons Ltd.，Copyright 2000)；以及

Murray、James D.等人所著的“Encyclopedia of Graphics FileFormats：Second Edition”(O′Reilly & Associates，Inc.，Copyright1994，1996)。

具体实施方式优选实施例的概述

公开了一种用于确定终端用户的计算机系统的配置的系统、方法和计算机程序产品。特别是，确定用户的媒体播放器和网络连接速度。然后由第二计算机、优选为递送管理服务器接收这个配置信息。配置信息用于格式化用于递送给用户的多媒体内容。因为内容根据配置信息进行格式化，所以该内容与用户的配置兼容。配置确定处理涉及放置在内容供应商的网页中的服务器联络代码。当用户加载该网页时，服务器联络代码引导浏览器从递送管理服务器检取代码。当该代码由用户执行时，确定用户的媒体播放器。这个信息保存在用户处的cookie中，并且发送给递送管理服务器。如果配置信息是不确定的或者不完全的，则向用户给出用户可以在其中指示配置的首选项(preferences)页面。首选项页面还包含用于确定用户的连接速度的机制。该首选项页面还可以向用户进行特定推荐，例如推荐用户选择特定的媒体播放器。首选项页面包含具有已知大小的数据块。测量传输该块所需要的时间，然后计算连接速度并且将其提供给递送管理服务器。

根据一个优选实施例，配置确定处理涉及放置在内容供应商的网页中的服务器联络代码。当由用户加载该网页时，服务器联络代码引导浏览器从递送管理服务器检取脚本。当由用户执行该脚本时，确定用户的媒体播放器。这个信息保存在用户处的cookie中，并且发送给递送管理服务器。该配置信息然后可以由代码转换器使用，该代码转换器根据配置信息格式化媒体内容。

如果配置信息是不确定的或者不完全的，则向用户给出用户可以在其中指示配置的首选项页面。通过首选项页面确定的这个配置也存储在cookie中，并且发送给递送管理服务器以允许内容的格式化。该首选项页面还可以向用户进行特定的推荐，例如推荐用户选择特定的媒体播放器。

优选实施例的描述

此处描述的优选实施例涉及允许远程确定用户的计算机系统配置的系统、方法、和计算机程序产品。这允许对发往该计算机的多媒体内容以与用户的配置兼容的方式进行格式化。如果获得了足够的配置信息，则可以格式化该内容以便为用户提供最佳可能的媒体体验。

要注意到，在后续的描述中，广泛地定义了用户计算机的概念以包括可编程或者已编程设备的完全范围。用户计算机可以是但不局限于：个人计算机或者其它工作站、膝上型、掌上型、个人数据助理、或者蜂窝电话。

根据一个优选实施例，服务器联络代码包含在由内容供应商发送给用户的网页中。服务器联络代码从递送管理服务器检取一个或多个脚本。该脚本使得能够确定用户的计算机系统的配置信息。在本发明的一个实施例中，配置信息包含用户的媒体播放器(一个或多个)的身份(identity)和版本。该配置信息然后被返回到递送管理服务器。该配置信息然后可以用于适当地格式化多媒体内容。在本发明的一个实施例中，还可以以cookie的形式将配置信息本地地存储在用户的计算机处。在随后的超文本传输协议(HTTP)请求中，可以将cookie发送到递送管理服务器以作为传送配置信息的一种方式。

如果配置信息被确定为是不完全或者可能过时的，则打开另外的网页。这是一个首选项页面，在其中用户可以向递送管理服务器指定他的配置(例如，他的可用或者优选的媒体播放器类型和版本，和/或优选的连接速度)。首选项页面还可以用于推荐用户选择特定的媒体播放器。

根据一个优选实施例，首选项页面包括已知大小的数据块。这个块作为首选项页面的一部分而被传输到用户的计算机。测量传输这个数据块所需要的时间，以便确定用户计算机的连接速度。连接速度表示另外一部分配置信息。连接速度也以cookie的形式本地存储在用户的计算机处。还可以将这个cookie发送到递送管理服务器，以作为将用户的连接速率传送到递送管理服务器的方法。

优选实施例中的系统基本上支持检测两个事物：服务器到客户端的连接速度(带宽)，以及安装在客户端上的媒体播放器(包括播放器版本)。关于连接速度检测，仅仅期望服务器到客户端的估计，这是因为媒体流将由服务器发送到客户端。一些媒体播放器控制信道数据将从客户端发回到服务器，但是该数据量远远小于发自服务器的实际媒体数据。

当检测媒体播放器时，理想的是能够检测所有以下信息：所安装的媒体播放器(例如，QuickTime，Windows Media Player，RealPlayer等)，所安装的媒体播放器的版本(例如，QuickTime 5.0.2，WindowsMedia Player 6.4，RealPlayer 8.0)，以及安装在每个媒体播放器中的各个音频与视频编解码器(用于QuickTime的Sorenson v3，Windows Media Video V8，用于RealPlayer的Sony ATRAC等)。

对于通用媒体的应用，知道客户端环境的细节也是有用的。有用的信息包括操作系统版本、网络浏览器版本、硬件平台、和优选的用户接口语言。其中某些信息是容易获得的(通常作为由客户端发送到服务器的HTTP头的一部分)，而其它信息是更难以获得或者想要获得是费时的，并且最好定期进行(不是为每个请求进行)。在这些情况下，在存储在客户端的网络浏览器中的cookie中保存检测到的信息(以及任何用户首选项)，是所期望的。当向通用媒体服务器提出请求时，网络浏览器将自动地将附属的cookie数据发送到该服务器。

检测系统

根据一个优选实施例的整体体系结构包括嵌入在内容供应商的网页中的服务器联络代码。服务器联络代码将用户的浏览器导向递送管理服务器，该服务器发送一个或多个脚本给用户。脚本的执行可以识别用户的媒体播放器的类型和版本。这个递送管理服务器从用户接收这个信息。该配置信息可以最终用于格式化用于递送给用户的多媒体内容。

图1中说明了本发明中的系统的一个实施例。内容供应商105被示为向用户110递送信息。网页115中包括服务器联络代码120。当用户110的浏览器访问服务器联络代码120时，该浏览器与递送管理服务器125建立联系，并且请求一个或者多个播放器检测脚本140。服务器125通过将脚本140发送到用户110而做出响应。以下面将要更详细描述的方式，当被执行时，脚本140确定用户110的配置信息135。在本发明的一个实施例中，通过设置包含配置信息135的cookie的处理，将这个配置信息与用户110一起存储。cookie由用户110保持，并且当用户110提出HTTP请求130以访问内容时，将配置信息135以cookie的形式发送到递送管理服务器125。代码转换器(未示出)以由配置信息135指定的方式格式化多媒体内容。所产生的格式化后的内容然后可以通过流式(streaming)服务器(未示出)递送到用户110。

如果配置信息135不可用的(或者需要澄清)，则作为脚本140之一提供给用户110的另外的脚本打开一个加载首选项网页150的新窗口。利用这个页面，用户110可以通过在首选项页面150中的用户接口明确地标识配置信息135(例如，播放器类型和版本)。如以前一样，配置信息135可以以cookie的形式保持在用户110处，并且被转发到递送管理服务器125。

在本发明的一个实施例中，可以由递送管理服务器通过首选项页面150向用户进行关于用户可以或者应该选择的特定媒体播放器的推荐。这样的推荐基于关于用户的选项的已知内容。在这样的首选项页面150的一个实施例中，可以通过页面的一部分传送该推荐。这个部分可以被认为是服务器接口，这是因为服务器通过这个接口与用户进行通信。

如下面将要更详细描述的那样，首选项页面包括具有已知大小的数据块155。对块155的传输进行计时，以便确定用户10的连接速度。在本发明的实施例中，块155(在下文中称为计时(timing)块)并入在首选项页面150中的HTML注释中。

在本发明的某些环境中，递送管理服务器125是这样的服务器集合中的一个服务器。这里，该递送管理服务器集合借助于此处描述的发明为用户团体服务。在假定用户提出内容请求的情况下，将通过平衡由多个用户产生的负载的选择机制，将用户分配给特定递送管理服务器。

在本发明的一个实施例中，递送管理服务器125的功能体现为到代码转换引擎的观众网络服务器接口。代码转换引擎通常从内容供应商接收内容，并且以使该内容可由用户110使用的方式格式化(“代码转换”)该内容。观众网络服务器接口是在代码转换引擎和用户110之间的网络接口，其允许由用户110请求内容。观众网络服务器接口接收并且处理来自用户110的内容请求，由此启动所请求的内容的代码转换以及向用户110的递送。观众网络服务器接口发送对用户110的请求的答复，以将用户110重定向到适当的流式服务器，以便从该流式服务器中接收所请求的媒体内容。格式化(“代码转换”)了的内容然后通过流式服务器和/或代理服务器(还有代码转换引擎的一部分)流式传输(stream)给用户110。美国专利6,407,680和6,593,860中更详细地描述了这样的代码转换引擎，这些专利通过引用全部并入在此。作为选择，递送管理服务器125和观众网络服务器接口可以被实现为分离的服务器。

要注意到，此处描述的发明可以在各种组织的环境中实现。例如，如上所述的代码转换和递送管理操作可以由递送管理服务执行。这个服务可以是例如单独的独立于内容供应商105的组织或者企业实体。在这种情况下，可以由内容供应商105独立于递送管理服务而开发网页115。网页115因此能包括内容供应商105特定的徽标或者其它商标图像和/或“外观(look and feel)”。同样地，首选项页面150虽然由递送管理服务器125递送给用户110，但是它也可以由内容供应商105独立于递送管理服务而开发。

递送管理服务和内容供应商105的独立性还将允许递送管理服务自己对服务做出改变。递送管理服务将通过添加或修改功能而自由地升级它的服务。例如，可以与特定的内容供应商105无关地改进播放器检测脚本140，以便使播放器检测处理更快或者更全面。

例如，也可以独立于内容供应商105而升级代码转换处理，以容纳另外的媒体格式或者提供更快的代码转换。可以使用硬件、软件或者它们的组合实现递送管理服务器125。特别是，可以使用计算机系统或者其它处理系统实现服务器125。图2示出了这样的计算机系统200的示例。计算机系统200包括诸如处理器204之类的一个或者多个处理器。处理器204连接到通信基础设施206(例如，总线或者网络)。就这个示例性计算机系统而言，可以描述各种软件实施例。在阅读了这个描述之后，对于本领域技术人员来说，如何使用其它计算机系统和/或计算机体系结构实现本发明将会是显而易见的。

计算机系统200还包括优选为随机存取存储器(RAM)的主存储器208，并且还可以包括辅助存储器210。辅助存储器210可以包括例如硬盘驱动器212和/或表示磁带驱动器、光盘驱动器等的可移动存储设备驱动器214。可移动存储设备驱动器214以众所周知的方式从可移动存储单元218中进行读取和/或向其进行写入。可移动存储单元218表示磁带、光盘等。如所理解的那样，可移动存储单元218包括其中已经存储了计算机软件和/或数据的计算机可用存储介质。

辅助存储器210还可以包括其它类似的装置，用于允许将计算机程序或者输入数据加载到计算机系统200中。这样的装置可以包括例如可移动存储单元222和接口220。这样的示例可以包括：程序盒和盒接口(诸如在视频游戏设备中可找到的那些)，可移动存储器芯片(诸如EPROM，或者PROM)以及相关联的插口，及其他允许将软件和数据从可移动存储单元222传输到计算机系统200的可移动存储单元222和接口220。

计算机系统200还可以包括通信接口224。通信接口224允许软件和数据在计算机系统200和外部设备之间进行传输。通信接口224的示例可以包括调制解调器、网络接口(诸如以太网卡)、通信端口、PCMCIA插槽和卡等。经由通信接口224传输的软件和数据具有信号228的形式，其中信号228可以是能够由通信接口224接收的电、电磁、光或者其它信号。这些信号228经由通信路径(即，信道)226提供给通信接口224。这个信道226将信号228送进和送出计算机系统200，并且可以使用导线或者电缆、光纤、电话线、蜂窝电话链路、射频链路及其他通信信道实现。在本发明的一个实施例中，信号228可以传送由递送管理服务器125所需要的信息，诸如HTTP请求130和配置信息135。信号228还可以将诸如脚本140和首选项页面150之类的信息传送到用户110。

在这个文档中，术语“计算机程序介质”和“计算机可用介质”用于泛指诸如可移动存储设备驱动器214、安装在硬盘驱动器212中的硬盘、和信号228之类的介质。这些计算机程序产品是用于向计算机系统200提供软件的装置。本发明的部分目的是提供这样的计算机程序产品。

计算机程序(也称作计算机控制逻辑)存储在主存储器208和/或辅助存储器210中。还经由通信接口224接收计算机程序。这样的计算机程序当被执行时允许计算机系统200执行此处所述的本发明的特征。特别是，当被执行时，该计算机程序允许处理器204执行本发明的特征。因此，这样的计算机程序表示计算机系统200的控制器。

检测方法

在根据优选实施例的方法中，确定用户的计算机的配置信息，并且将其发送给递送管理服务器。递送管理服务器然后将配置信息传递给代码转换器，代码转换器根据配置信息格式化多媒体内容。然后可以把格式化了的内容发送给用户。

图3A-3D中说明了根据本发明实施例的整体处理。该处理从步骤305开始。在步骤310，用户开始加载内容供应商的网页。如Section(章节)11所述，该网页包含引导用户的浏览器到递送管理服务器的服务器联络代码。在本发明的实施例中，这在内容供应商的网页的HTML头中实现。例如，HTML头可以包含以下服务器联络代码：<SCRIPT SRC＝”http://js.genericmedia.net/js”LANGUAGE＝javascript></SRC>，其中“js.genericmedia.net”表示递送管理服务器。

在本发明的一个实施例中，服务器联络代码的执行由用户的动作、诸如点击在内容供应商网页上的控制或者链接或者通过输入显式命令来启动。在替换实施例中，在加载该网页之后自动地执行服务器联络代码。在步骤320，用户的浏览器从递送管理服务器中取出播放器检测代码(在上述示例中为“js”)。在步骤325，确定可以由用户使用的媒体播放器。下面将更详细地描述这个步骤。在步骤330，将媒体播放器的身份记录在用户计算机中的一个或者多个cookie中。下面也将更详细地描述这个步骤。

结合这个步骤，在递送管理服务器处进行关于所接收的配置信息是否足以格式化所请求的多媒体内容的判定(步骤331)。如果接收了cookie并且将其验证为具有有效的设置，则送回暗指有效的最小HTTP响应。如果所接收的配置信息足以格式化所请求的多媒体内容，则如下所述，在步骤335处理继续进行。在参考图3A描述和说明的方法中，可以在步骤320和325之间构造另外的判定点(类似于步骤331)。也就是说，在一个实施例中，如果接收了足够的信息，则可以完全跳过播放器检测。在另一个实施例中，即使当已经接收了足够信息时也还进行一些轻量级的播放器检测。但不论是哪种情况，当客户端从服务器请求播放器检测代码时，都可以在步骤320之后执行发送什么播放器检测代码(如果有的话)的判定。

如果js没有接收到有效的cookie(即，如果用户处的配置信息不充分或者不存在)，则在步骤332继续本方法。在步骤332，为用户显示首选项页面。在本发明的一个实施例中，这通过向用户发送一段javascript(java脚本)来完成，该javascript打开一个加载首选项页面的新窗口。该首选项页面允许用户有意地向递送管理服务器指示关于媒体播放器和/或用户的连接速度的用户配置或者首选项。在本发明的实施例中，首选项页面还可以向用户推荐选择一个特定的媒体播放器。此外，如下面将要更详细描述的那样，首选项页面包括这样的机制，通过该机制可以确定用户计算机的连接速度，并且将该连接速度转发给递送管理服务器。

在步骤333，由用户的计算机接收由用户提供的首选项。在步骤334，将首选项存储在cookie中。然后在步骤335继续处理。在步骤335，用户通过提出HTTP请求，来请求由内容供应商通过网页使其可用的多媒体内容。例如可以通过在内容供应商的网页中的一些区域上进行点击来提出这样的请求。作为这个请求的一部分，将任何包含配置信息的cookie发送给递送管理服务器。这些cookie可以例如描述媒体播放器类型和版本。这些cookie还可以存储所测量的连接速度，以及用户可能具有的任何优选连接速度。例如，用户可能希望仅仅使用可用带宽的一部分用于流式传输。此时，用户将选择比由用户配置所允许的最大值慢的速度。该处理在步骤370结束。

HTTP请求(“GET”)的一个示例如下所示。将现有的cookie(gmPlayers，gmPlayerPref，和gmBitratePref)作为GET命令的一部分发送给递送管理服务器。

GET/xc？p＝keith&s＝media/Trailer.mov&v＝1 HTTP/1.1

Accept：image/gif，image/x xbitmap，image/jpeg，image/pjpeg，application/vnd.ms-powerpoint，application/vnd.ms-excel，application/msword，*/*

Accept-Language：en-us

Accept-Encoding：gzip，deflate

User-Agent：Mozilla/4.0(compatible；MSIE 5.5；Windows NT 5.0)

Host：xc.genericmedia.net

Connection：Keep-Alive

Cookie：gmPlayers＝v1％2F％2FQuickTime-4.12％2F％2FReal-6.0.7.788％2F％2FWMP-6.4％2F％2F；gmPlayerPref＝real；gmBitratePref＝300000

服务器使用该URL信息和cookie信息来确定将电影“media/Trailer.mov”(在用户Keith的帐户中)代码转换为适于RealPlayer G2的300kbps编码：

HTTP/1.1200 OK

Date：Mon，Jul.16，2001 23:52:00 GMT

Server：Apache/1.3.14(Unix)mod_perl/11.24

Connection：close

Expires：Thu，Dec.1，1994 16:00:00 GMT

Pragma：no-cache，no-store，must-revalidate，no-transform

Transfer-Encoding：chunked

Content-Type：audio/x-pn-realaudio 41

rtsp://64.124.76.136：554/cache/Mlk3JeFIY0209200d7dn-a/Trailer.rm 0

要注意到，用户可以被配置为具有一个以上的媒体播放器。如果是这样的话，则如何格式化内容，即选择哪个播放器，可能是不清楚的。此外，用户可能具有一个播放器优于另一个播放器的特定优先选择。首选项页面通过让用户将播放器首选项传送给递送管理服务器，而提供了一种解决这些情况的方法。在本发明的实施例中，首选项页面可以向用户传送关于哪个媒体播放器可能提供最佳结果的推荐。

还可能存在有上述处理未能肯定地识别用户配置的情况。例如，播放器检测处理可能未必能够清楚地确定用户的媒体播放器，而且用户可能不十分知道如何回答首选项页面上的询问。在此情况下，递送管理服务器可以基于关于用户配置的已知内容进行一或多次推断。例如，如果已知用户具有MACINTOSH平台，则一般可以假定QUICKTIME在该平台上可用，这是因为MACINTOSH计算机经常装有QUICKTIME。其它这样的关联也可以用于推断否则就不可得到的配置信息。在本发明的实施例中，可以通过经由首选项页面请求用户确认而具有对这样的推断的确认。

图3B是说明根据发明的实施例、包括接收递送管理器HTTP请求371在内的服务器端请求处理的流程图。在步骤372检查是否已经接收了递送管理器cookie。如果没有的话，则在步骤373，向客户端发送包含要发送的代码的HTTP响应以检测URL。如果是的话，则在步骤374，返回空的HTTP响应。

图3C是说明根据优选实施例、包括接收检测URL HTTP请求375在内的服务器端请求处理的流程图。在步骤376，分析HTTP头以确定客户端的配置信息。如所述的那样，所确定的信息中包含操作系统、平台和HTTP客户端或者用户代理。如根据此处例如参考图7-9的进一步描述和其他处的描述所理解的那样，有许多可以在步骤376中确定的客户端计算机的特征、特性和变化。此外，如图3D所示以及下面更详细的描述所述，可以向客户端指示期望在服务器处接收的特定信息项。

为了确定客户端的带宽或者连接速度，可以在步骤377中发送TimerStart(计时器启动)代码。在步骤378，将数据块或者计时块发送给客户端以用于带宽测量。在步骤379，发送TimerStop(计时器停止)代码。在一个实施例中，在步骤380，根据在由TimerStop时间和TimerStart时间之间的差值而确定的时间期间传递的数据量，计算带宽，并且将其存储在cookie中。如以下更详细描述的那样，并不是固定该时间并且基于在该时间期间发送了多少数据来确定带宽，而是可以固定组块(chunk)大小或者计时块大小并且基于传送该块需要多长时间来确定带宽。有利地是，可以这样选择组块大小或者计时块大小，以便过程持续刚刚超过进行相当准确的带宽确定所需的最少时间。在步骤381，发送客户端媒体播放器检测代码。

检测机制细节

在示例性使用情况下，用户可能通常从个人计算机或者PDA(Palm，PocketPC)进行连接。该连接通常可以经由HTTP而来自于网络浏览器或者可以提出HTTP请求的媒体播放器。

这类环境的困难方面是客户端设备软件通常可能不被写入或者控制，而是在现有客户端的限制下工作。更具体地说，可能没有特定的现有浏览器(例如，Internet Explorer，Netscape，Mozilla等)，而且因此配置检测算法必须在它们对Javascript的支持下工作并且处理各个浏览器版本的程序错误/奇特之处。

同样地，不同的媒体播放器支持变化的版本等级以及所安装的编解码器查询。在许多情况下(特别是对于老版的播放器)，没有办法直接查询是否安装了特定编解码器。而是它依赖于已知配置间接地完成。例如，如果媒体播放器是Windows Media Version 7.0，则可理解该版本具有Windows Media Video 7、Microsoft MPEG4v3、和Microsoft ISO-MPEG4v1视频编解码器。

在PDA的情况下，根据当前支持PDA的媒体播放器是有限的这一事实，通常可以简化媒体播放器检测。例如，在基于PalmOS的PDA上，可能仅有单个视频播放器可用和/或仅支持单个视频播放器。作为另一个示例，在PocketPC上，长时间以来，微软的Pocket WindowsMedia Player是唯一可用的播放器。RealNetworks和PacketVideo也已经引入了用于PDA的播放器。利用有限的播放器选择，检测逻辑经常可以被简化为在给定PDA和(缺省)媒体播放器之间的1:1映射。

带宽测量也不容易在HTTP和Javascript的限制下进行估计。带宽测量工具通常可以通过计时客户端花费多少时间来接收已知量数据而进行它们的估计。如果时间测量仅仅限于实际传输数据所花费的时间，以及如果数据大小真正估计了实际传输的位数，则可以获得较高的带宽估计精确度。理想地，采取多次测量以平均掉异常。

在一个示例性实现中，(用于检测机制的)设计要求/限制可以包括：

必须从网页内部(在网络浏览器中)进行；

代码/脚本必须仅仅使用早已由客户端的现有浏览器支持的语言(例如，Javascript，VBScript，HTML)；

用户不必需要安装任何下载的模块/插件；

检测应该尽可能快地且尽可能少影响地进行(理想上，用户将不会注意到检测代码正在运行)。

为了在上述限制内进行带宽测量，经由HTML和Javascript代码测量带宽，可以是一种方法。小的Java小程序可以允许更细粒度以及更复杂的测量算法，但是可能需要下载的小程序和Java运行时环境，这二者都可能违反了设计限制。

可以通过对客户端接收HTML数据的组块需要多长时间进行计时，来有利地进行带宽测量。优选使用“随机”ASSCII数据或者其它随机数据来防止由数据压缩调制解调器、路由器、和网络服务器进行的压缩(这将减少实际接收的位数，并且因此影响带宽计算)。为了最小化用户影响，带宽测量计算优选为仅仅运行一次，并且作为选择可以多次运行。可以将数据组块的大小选择为20千字节，以便可以平衡调制解调器用户对方便测量的需要与在大约300kbps的LAN连接速度上用户对准确测量的需要。

此外，由于设计限制，更高级/准确的带宽测量技术可能是不合需要的。该测量仍然可能有易出现计算错误的缺点。例如，其它的应用或者浏览器窗口可能正在发送数据，因此减慢了传输时间。此外，中间路由器可能正在缓冲数据并且以大的组块来传输数据。此外，数据仍然可能由中间路由器/调制解调器压缩。数据可能在如从防火墙到计算机的最后网络链路上爆发，或者在例如可以分几部分分析/执行Javascript的浏览器中爆发，所有这些或者其中任意一个都错误地减少了传输时间。

对于不支持Javascript的客户端，可以使用缺省检测结果。用户可以在稍后的日期通过点击链接以进入设置/首选项改变网页来改变他们的首选项。可以基于从HTTP请求头中收集的信息(例如操作系统，硬件平台)有利地为不同客户端定制缺省检测结果。在一个实施例中，Macintosh客户端可能把安装了QuickTime作为缺省值，而PocketPC客户端可以具有安装了Pocket Windows Media Player的这个缺省值。对于经由无线调制解调器载波的连接，缺省带宽可以是56kbps。

持久数据

一个优选实现利用“cookie”用于在用户会话之间存储持久数据。Cookies是由HTTP客户端存储的、与域相关联的名称-值对。当客户端提出后续的HTTP请求时，它将附属于HTTP服务器域的cookie与请求一起发送。可以进一步指定Cookies在某一日期之后过期(被删除)。

可以在一个示例实现中创建/使用单独的cookie用于存储例如所测量的带宽、所检测的媒体播放器(以及它们的版本)、用户比特率首选项、用于流处理的用户媒体播放器首选项和/或用于所下载内容的用户媒体播放器首选项等信息。每个cookie可以具有它自己的有效期，其可被用来设置这样一个频率，在该频率上，可以认为部分所检测的信息失效并且应该重新检测。

具体地说，耗费相对大量时间来进行检测的事物(带宽以及已安装的媒体播放器的版本)可以进行一次，然后仅仅定期地(或者依据用户的请求)重新检测。典型配置检测实现的困难和复杂度大部分是由于仅仅能够写入/控制服务器端环境而导致的。有利地，根据优选实施例，不需要总是处理客户端平台、浏览器、媒体播放器、脚本语言、程序错误等，这是因为，例如，它们被认为是不变的。根据设计要求，现在可以允许客户端已安装软件的升级/改变，虽然做为选择可以明确地不允许该升级/改变。

实现示例

在根据优选实施例的示例实现中，因为在客户端环境中有多得多的自由度，所以可以避免许多障碍。并不是设计间接查询方法来确定客户端软件配置或者性能，而是从开始起就有利地设计直接查询支持。同样地，可以指定客户端HTTP头值(和/或添加新的头)以提供详细的客户端信息。

就此而论，图3D是说明根据本发明实施例的进一步请求处理的流程图。在步骤382，发送修改的信息头指令。也就是说，向客户端发送一个请求，以请求与客户端基于标准或者先前的请求而早已发送或者准备发送的信息不同的信息。在步骤383，发送唯一的客户端ID，以便使所请求并且然后从客户端接收的特定信息与该客户端相关联。例如，可以请求其它客户端的不同信息。有利的是，不同的终端用户机器可能具有内置的、用于检测的唯一ID代码。

客户端操作384-386说明了由于服务器操作382-383而对客户端处理的影响。在步骤384，客户端应答基于步骤382接收的指令，并且将客户端ID指针地址信息附加到基于步骤383的所请求的头信息中。在步骤385，取决于在步骤382的指令中请求的信息，客户端准备修改的头信息。在步骤386，客户端应进一步的请求发送具有ID的修改的头信息。该子例程在步骤387结束。该修改的信息可以包括未包括在先前接收的信息中的信息，或者可以包括服务器所期望的、客户端理解的信息。这有利地允许了服务器获取所有期望的信息。该修改的信息也可以排除之前包括的信息，或者排除客户端否则会发送给服务器的信息。特别是当一些数据不是服务器处的处理或者用于代码转换和/或提供媒体代码转换服务所期望的时，这可以有利地减少正在发送的数据量。

客户端硬件、客户端用户接口版本或者其它客户端配置特征的适配信息可以被包括在由服务器请求和/或从客户端发送的配置信息中。可以依据这个适配信息准备修改的头信息指令。这些适配信息例如可以依据在客户端处的特定浏览器配置。

实现体系结构的设计要求可被设计为提供编写定制客户端软件的更大自由度。例如，如果没有Javascript的编程限制，则定制的扩展(或许以C/C++编写)可以实现更高级或更准确的带宽测量算法。

可以提供一种形式的持续存储，以便可以从一个会话到另一个会话存储所检测的信息。这可以有利地减少花费在带宽测量上的时间。作为选择，可以基于从服务器发送到客户端的数据的定时/时戳，不断地、定期地或者按照要求测量和/或更新带宽估计。在给定会话内，例如，检测信息可以被保持在存储器中，以便它可以由客户端与请求一起发送到服务器。

实现示例细节

如先前所述，客户端性能的直接报告通常比间接查询更容易和更有效。对于媒体播放器检测，客户端可以有利地具有快速/容易地知道在客户端上安装了什么媒体播放器的方法。根据一个实施例，在操作系统(或者软件安装管理器)中提供钩子(hooks)，以便使检测软件可以直接查询安装了什么媒体播放器软件、其版本是什么、安装了什么版本的编解码器、和/或其它配置信息。如果这样进行实现，以便仅仅安装了一个媒体播放器和/或其它的安装不可用，或者检测管理软件被集成到媒体播放器中，则作为替代、让媒体播放器软件直接报告这个信息可能是有利的。

在服务器端，根据所报告的版本信息，可以进行有关客户端的实际媒体播放器性能的直接关联。例如，人们知道V XYZ视频编解码器的版本1.0.4能够解码用XYZ算法压缩的视频，但该解码器需要视频帧/尺寸大小为8个像素的倍数。另一个示例可以是，如果客户端报告了它具有音频编解码器A ABC版本1.1和音频编解码器A DEF版本3.0，则服务器不能发送用任何其它音频编解码器编码的数据，而且所使用的压缩算法必须可由客户端的音频编解码器之一解码。

所有的带宽测量算法基本上归结为测量需要多长时间来接收已知大小的数据组块，或者在预定时间段内传输了多少数据。有利地是，下面参考图5B更详细描述了这样一种算法，其包括发送多个数据组块中的一个或者多个，以便可以根据当前粗略估计的带宽改变或者选择组块大小或者计时块大小。

检测信息可以在服务器端用于确定代码转换的比特率以及媒体播放器的格式/版本。以所有可能的带宽和编解码器组合提供代码转换通常是效率低且资源密集的。所使用的编解码器可以限于例如最普遍安装的编解码器，而且所编码的比特率可以限于支持最普遍目标听众的比特率，例如，20kbps用于28.8调制解调器，34kbps用于56k调制解调器，90kbps用于ISDN，300kbps用于DSL，以及500kbps用于电缆调制解调器。

返回到图3A中的步骤325，在图4A中更详细地描述了执行播放器检测的步骤。这个处理从步骤405开始。在步骤410，进行关于用户具有什么浏览器的确定。通常，用户的浏览器将是NETSCAPENAVIGATOR的版本，或者INTERNET EXPLORER(IE)的版本。如果用户具有NETSCAPE NAVIGATOR，则处理在步骤411继续。在步骤411，贯穿驻留的mime(多用途的网际邮件扩充协议)类型数组和插件数组执行对给定媒体播放器的字符串搜索。mime类型数组是当接收到具有给定mime类型响应时加载什么应用的映射。任何给定媒体播放器一般具有它自己的mime类型。插件数组是已经安装了的所有浏览器插件的列表；通常，每个插件都已经登记了相应的mime类型。因此，这些数组通常将包含指示驻留在用户计算机上的媒体播放器(一个或多个)的字符串。例如，QUICKTIME由字符串“QuickTime”指示，而WINDOWS MEDIAPLAYER由字符串“video/x-msvideo”所指示。

如果在步骤413中字符串搜索成功，则在步骤415确定存在播放器。否则，处理在步骤416继续。在步骤416，进行关于是否要搜索另一媒体播放器的确定。如果是的话，则处理返回到步骤411，并且实施对另一媒体播放器的字符串搜索。因此，虽然本发明可以实现为执行单次搜索，但是在所说明的实施例中，通常将执行多次字符串搜索。该处理在步骤417结束。

要注意到，可以使用稍有不同的名称或者属性向浏览器登记给定播放器的不同版本。通过字符串搜索检测这些区别，可以提供关于特定版本的信息。在本发明的实施例中，字符串搜索使用javascript实现。

如果在步骤410中确定用户的浏览器是INTERNETEXPLORER，则处理在步骤420继续。此时，要求浏览器为给定媒体播放器和版本实例化一个对象。在本发明的实施例中，这个实例化使用Vbscript来进行。例如，将利用以下的语句尝试创建REALPLAYER版本5的对象：

CreateObject(″RealPlayer.RealPlayer(tm)ActiveX Control(32-bit)″.

如果在步骤425中允许这个实例化，则如步骤430所示，这暗示媒体播放器实际上已存在于用户计算机上。该处理然后在步骤440继续。如果在步骤425中不允许给定媒体播放器对象的实例化，则可以假定该媒体播放器不存在于用户计算机上。在步骤440，确定是否应该判断任何其它媒体播放器的存在。如果是的话，则处理返回到步骤420，并且进行另一次尝试，这次实例化用于不同媒体播放器的对象。如果在步骤440中确定将不搜索其它媒体播放器，则该处理在步骤417结束。要注意到，在播放器之间的差别，尤其是在播放器版本之间的差别，可以由在步骤420中如何实例化播放器对象中的相应差别所检测。此外，对于支持版本查询的播放器对象(例如，QUICKTIME和REALPLAYER)，可以向播放器直接询问有关它的版本。

WINDOWS MEDIA PLAYER检测

图4B是说明根据本发明的示例实施例的客户端视窗媒体播放器(WMP)检测的流程图。在步骤441，检查WMP在这个客户端的OS/平台上是否可用。如果不可用的话，则在步骤451将WMP版本设置为否，而且该方法移到根据这个示例的RealPlayer检测。如果是的话，则在步骤442，检查ActiveX在客户端浏览器上是否可用。如果是的话，则在步骤443，检查是否可以创建用于WMP 7.1或者WMP8的ClassID(类别ID)。如果是的话，则在步骤444，将WMP版本设置为版本7.1，并且该处理移到在这个示例中，根据图4C的RealPlayer检测。如果在步骤443确定不能创建用于WMP 7.1或者WMP 8的ClassID，则在步骤445，检查是否可以创建用于WMP 7的ClassID。如果是的话，则将WMP版本设置为WMP 7并且处理移到RealPlayer检测。如果在步骤445确定不能创建用于WMP 7的ClassID，则在步骤447检查是否可以创建用于WMP 6.4的ClassID，并且如果是的话，则将WMP版本设置为6.4，以及如果不是的话，则处理移到步骤449。在那里检查是否可以创建WMP对象，以及如果是的话，则将WMP版本设置为是，以及如果不是的话，则将WMP版本设置为否，然后不管怎样，该处理都移到如图4C中所说明的RealPlayer检测。

如果在步骤442中有关ActiveX在客户端浏览器上是否可用的检查结果是否，则处理移到步骤452。在步骤452，检查是否由插件登记了mime类型应用/x-ms-wmd。如果是的话，则将WMP版本设置为版本7，以结束WMP检测过程。如果不是的话，则在步骤453，检查是否向插件登记了mime类型应用/x-ms-wmv。如果是的话，则将WMP版本设置为版本6.4，以结束该子例程。如果不是的话，则在步骤454，检查是否向插件登记了mime类型应用/x-msplayer2。如果是的话，则将WMP版本设置为是，而如果不是的话，则将WMP版本设置为否，并且不管怎样，该处理都移到RealPlayer检测。

REALPLAYER检测

图4C是说明根据本发明的示例实施例的客户端RealPlayer(Real)检测的流程图。在步骤455，检查Real在这个客户端的OS/平台上是否可用。如果不可用，则将Real版本设置为否，以结束该子例程，并且将该处理移动到QuickTime检测。如果是的话，则在步骤456，检查ActiveX在这个浏览器上是否可用。如果是的话，则在步骤457，检查是否可以创建RealPlayer G2对象。如果可以的话，则把Real版本设置为RealPlayerG2Object.GetVersioninfo( )，而且处理移到如图4D中所述的QuickTime检测。如果不可以的话，则在步骤459，检查是否可以创建RealPlayer对象。如果可以的话，则将Real版本设置为版本5，以结束该子例程，而如果不可以的话，则处理移到步骤461，在其中检查是否可以创建RealVideo对象。如果可以的话，则把Real版本设置为版本4，而如果不可以的话，则把Real版本设置为否，并且不管怎样，都结束该子例程。

如果在步骤456中确定ActiveX在这个浏览器上可用，则该子例程移到步骤464，如图4C所述，在其中检查是否由插件登记了mime类型音频/x-pn-realaudio-plugin。在步骤465，将Real版本设置为是。然后，在步骤466，检查是否有包含“RealOne”的插件名称。如果有，则在步骤467将Real版本设置为One，以结束该子例程。如果没有，则在步骤468，检查是否有包含“RealPlayerG2”的插件名称，并且如果有，则把Real版本设置为G2，以结束该子例程。如果没有，则在步骤470，检查是否有包含“RealPlayer”的插件名称。如果有，则把Real版本设置为版本5，而且如果没有，则在步骤471，检查是否有包含“Realvideo”的插件名称。如果有，则把Real版本设置为版本4，并且如果没有，则把Real版本设置为否，而且不管怎样，该处理都移到图4D并且进行QuickTime检测。

QUICKTIME播放器检测

图4D是说明根据本发明的示例实施例的客户端QuickTime(QT)检测的流程图。在步骤472，检查QT在这个客户端的OS/平台上是否可用。如果不可用，则将QT版本设置为否，以结束该子例程。如果可用，则在步骤473，检查ActiveX在这个浏览器上是否可用。如果可用的话，则在步骤474，检查是否可以创建QuickTimeCheck对象。如果不可以，则将QT版本设置为否，而且如果可以，则该子例程移到步骤475。这里通过使用Call(调用)QuickTimeCheckObjectVersion.IsQuickTimeAvailable( )来检查QuickTime是否可用。如果在步骤475的检查结果是否，则将QT版本设置为否，而且如果步骤475的结果为是，则将QT版本设置为QuickTimeCheckObject.QuickTimeVersion，而且不管怎样，当在步骤482中保存检测结果时都结束该子例程。

如果在步骤473中确定ActiveX在这个浏览器上不可用，则在步骤478，检查是否由插件登记了mime类型音频/quicktime。如果没有登记，则把QT版本设置为否，并且如果登记了，则在步骤479把QT版本设置为是。然后，在步骤480，检查是否有包含“QuickTimePlug-in”的插件名称。如果没有包含，则结束该子例程，并且在步骤482保存检测结果。如果包含了，则将QT版本设置为QuickTimePlug-in版本，并且然后在步骤482保存该结果，以结束在图4B-4D所说明的处理组。

参见图3A中的步骤355，根据本发明的实施例，在图5A中更详细地说明向用户呈现首选项页面的步骤。该处理从步骤505开始。在步骤510，从递送管理服务器加载首选项页面。在步骤515，开始传输存储在首选项页面中的、已知大小的数据块。对这个块的传输进行计时，以确定用户的连接速度。这个块在下文中被表示为计时块。在本发明的实施例中，计时块作为HTML注释被包含在首选项页面中。因此，浏览器为了处理目的而忽略该计时块。

在计时块的传输开始的同时，浏览器记录该计时块传输开始时的时间。在步骤520，计时块的传输结束，并且浏览器也记录传输结束时的时间。在步骤530，基于传输计时块所需要的时间以及基于块的已知大小，进行关于连接速度、即数据传输率的计算。在步骤535，首选项页面的加载结束，并且为用户显示用户可能具有的可能配置。在步骤540，接收用户对于该配置的输入。该处理在步骤545结束。

首选项页面还可以在不同于上面关于图3A所述的时间上进行显示。在本发明的实施例中，向用户给予内容供应商的网页中的链接，每当希望时，用户可以通过该链接访问首选项页面。这允许用户随意地改变所声明的首选项。在本发明的另一个实施例中，定期地、例如每六个月一次向用户显示首选项页面。这允许用户进行配置信息的定期更新。

关于cookie的设置，当浏览器向服务器提出请求时，浏览器仅仅发出与该服务器域相关联的cookie。cookie以以下两种方法之一与新的域相关联：

1)Set-Cookie：从在新域内的服务器接收报头，或者

2)由从新域中的服务器加载的页面经由javascript设置cookie。

因为播放器检测代码并不总是从递送管理服务器页面运行(例如，其中作为内容供应商的网页头的一部分而加载播放器检测的情况)，所以需要设置cookie的方法。其目标是第三方cookie，借此代之以将否则会被设置为原有域(内容供应商域)的cookie设置为递送管理服务器域。在本发明的实施例中，这可以通过从javascript内进行dummy image( )(哑图像( ))请求来进行。在假定具有从递送管理服务器域加载图像的请求的情况下，递送管理服务器可以通过送回Set-Cookie：header(报头)来作出应答。

这可以在上述步骤330和334中应用。例如，可以在用户计算机处构造指向递送管理服务器处的cookie设置脚本的URL。接下来，可以在用户计算机处创建哑图像对象。这个对象仅用于允许从javascript内向递送管理服务器域提出哑图像请求。然后，浏览器提出HTTP请求，以要求从递送管理服务器域加载哑图像；这个请求包括对cookie设置脚本的请求。递送管理服务器通过将cookie与服务器相关联(即，送回Set-Cookie：header)做出响应。这将允许将cookie发送到递送管理服务器，即使它们在用户计算机处的存在最初已经由内容供应商或者某些其它域所确定了也是如此。该配置信息存储在cookie中。

在用户和递送管理服务器之间的这种交换示例如下所述：

GET/ssp/cookieet？gmPlayerPref＝real HTTP/1.1

Accept：image/gif，image/x-xbitmap，image/jpeg，image/pjpeg，application/vnd.ms-powerpoint，application/vnd.ms-excel，application/msword，*/*

Accept-Language：en-us

Accept-Encoding：gzip，deflate

User-Agent：Mozilla/4.0(compatible；MSIE 5.5；Windows NT 5.0)

Host：js.genericmedia.net

Connection：Keep-Alive

Cpokie：gmPlayers＝v1％2F％2FQuickTime-4.12％2F％2FReal-6.0.7.788％2F％2FWMP-6.4％2F％2F；gmPlayerPref＝wmf；gmBitratePref＝300000

服务器然后响应：

HTTP/1.1 200 OK

Date：Tue，Jun.12，2001 20:08:29 GMT

Server：Apache/1.3.14(Unix)mod_perl/1.24

Set-Cookie：gmPlayers＝v1％2F％2FQuickTime-4.12％2F％2FReal-6.0.7.788％2F％2FWMP-6.4％2F％2F；domain＝.genericmedia.net；path＝/；expires＝Mon，Sep.10，2001 20:08:29 GMT

P3P：CP＝″IND OUR PRE UNI ONL COM″.

Set-Cookie：gmPlayerPref＝real；domain＝.genericmedianet；path＝/；expires＝Mon，Sep.10，2001 20:08:29 GMT

Connection：close

Cache-Control：no-cache，max-age＝l

Transfer-Encoding：chunked

Content-Type：text/html

图5B是一般地说明根据本发明的实施例的带宽检测方法的流程图。在这个实施例中，子例程在步骤550开始，并且在步骤552继续进行以取出估计的带宽信息，例如该信息根据先前的带宽检测或其它方式确定。在步骤554，确定检取数据的估计时间，以便用足够的分辩率、即使用所估计的带宽信息来确定连接速度。这里，这个步骤的原因是，我们希望基于这个步骤的结果选择计时块或者组块大小，而且我们希望这个估计时间不短于可以其内在可容忍的分辩率内确定带宽信息的最小时间，并且不比这个最小时间长很多。例如，如果该估计时间对于具有缓慢连接速度的客户端来说太长了，则该带宽测量将可能涉及对用户的令人讨厌的以及不需要的延迟。然而，如果例如对于具有非常快连接速度的客户端来说所估计的时间太短了，则在确定中的误差将会太大或者在可容忍的误差范围之外。

一旦确定了估计时间，则在步骤556确定将花费所估计的时间来进行传送的组块大小或者计时块大小。根据优选实施例，在计时块或者组块中使用了诸如随机ASSCII数据之类的随机数据，以便调制解调器将不会压缩该数据并且使通信时间显著短于所估计的时间，并且使结果在分辨率容限范围之外。

一旦确定了将大致花费所估计时间的计时块大小或者组块大小，就在步骤558中将具有所确定大小的计时块或者数据组块传送到客户端。测量传送计时块所花费的实际时间。然后，在步骤560，基于在步骤558中发送的数据组块或者计时块的大小、以及基于由客户端测量的检取时间，确定带宽。在图5B所说明的子例程在步骤562结束。

根据实施例访问媒体内容

如此处所述，根据优选实施例的系统和方法响应于观众对访问媒体内容的请求，对点播媒体内容进行代码转换。另外，在媒体内容的发布之后，作为媒体内容递送处理的一部分，优选实施例实质上“实时”执行媒体内容的代码转换。在特定实施例中，在向媒体代码转换引擎(参见通过引用并入在此的美国专利6,407,680和美国专利申请10/644,602)提交观看媒体内容的请求以及将媒体内容递送给观众客户端之间的延迟将大致为三十秒或者更少。然而，本发明不局限于特定的递送时间，并且可以包含大于或者小于三十秒的各种递送时间。

图6A-6C描述了根据本发明实施例的一种方法的流程图1500，观众通过该方法访问媒体内容。然而，本发明不局限于由流程图1500提供的描述。相反，根据此处的示教，在本发明的范围和精神之内的其它功能流程对于本领域的技术人员来说将会是显然的。

在图6A的步骤1502处，观众经由观众客户端将访问媒体内容的请求发送到在媒体代码转换引擎内的观众网络服务器接口。在实施例中，该请求是当观众点击内容供应商网站上的URL时由观众客户端生成的HTTP请求。如上所述，可以在媒体内容发布处理期间由媒体代码转换引擎提供给内容供应商的URL链接，包含地址信息和源信息，这些信息将观众客户端指向媒体代码转换引擎，并且向媒体代码转换引擎提供有关所请求的媒体内容源的信息。在观众网络服务器接口接收了该请求之后，它将该请求转发到任务管理器(再次参见通过引用并入的专利6,407,680和申请10/644,602)。

在步骤1504，任务管理器分析该请求，以确定是否包括了用于服务于该请求的必要的请求信息。在本发明的其中请求包含HTTP请求的实施例中，任务管理器分析HTTP请求的头，以确定是否包含了用于服务于该请求的必要的信息。在实施例中，必要信息至少包括源位置、源类型、目标位置、和目标类型。源类型和目标类型每个都由至少一个发布变量所定义。在实施例中，用于媒体内容的发布变量可以包括但不局限于文件格式、比特率、通信协议(一个或多种)、物理介质、压缩算法、数字权利管理信息、或者它们的任何组合。在一个实施例中，为服务于该请求所需要的信息至少包括源位置、源格式、源比特率、目标位置、目标格式、和目标比特率。

如果任务管理器确定请求信息不完整，则如步骤1506和1508所示，任务管理器将取出必要的信息。例如，如果源类型或者源位置没有包括在该请求中，而且所请求的媒体内容存储在媒体代码转换引擎之内，则任务管理器可以查阅数据库以查找必要的源信息。作为选择，如果媒体内容相对于媒体代码转换引擎存储在外面，则任务管理器可以执行网络请求，以从内容供应商的网站取出必要的信息。例如，任务管理器可以执行HTTP请求、RTSP请求、或者使用任何其它标准的网络应用协议的请求。另外，如果目标类型不可得到，则任务管理器可以通过查询观众客户端来取得所需要的信息。如上所述，在实施例中，可以将用于目标位置的最佳目标类型存储为观众客户端上的“cookie”，其可由任务管理器访问。

在步骤1510，一旦任务管理器具有必要的信息来为该请求服务，则确定为了递送所请求的媒体内容需要执行什么任务。该任务包括递送所请求的媒体内容所必需的全部步骤，并且可以包括：取出所请求的媒体内容，将所请求的媒体内容代码从源类型代码转换为目标类型，以及将代码转换后的媒体内容流式传输到观众客户端。一旦任务管理器已经确定了需要执行什么任务，则它与资源管理器(再次参见通过引用并入的专利6,407,680和申请10/644,602)进行对接，并且指示资源管理器执行所需要的任务。

资源管理器从任务管理器接收用于执行所需要的任务的指令，并且在步骤1512，将每个任务分配给在该机器群内的一个或者多个机器。对资源管理器进行编程，以通过可用的资源实现任务的高效执行。在实施例中，基于各种因素，其中包括但不限于哪些机器支持用于执行所需任务的必要工具、哪些机器具有可用资源(例如，可用CPU)、以及当为了执行而需要协作时哪些机器可以互相协作来执行任务，确定资源管理器对给定任务的资源分配。还可以对资源管理器进行编程，以基于包括避免网路拥塞在内的各种其它标准来分配任务。例如，资源管理器可以被编程为将解压缩和压缩任务分配给同一机器，以便避免可能由在媒体代码转换引擎的内部网络内从一台机器向另一台机器传输未压缩的数据而导致的网路拥塞。

根据优选实施例，资源管理器在分配任务之后监督这些任务以确保它们被适当地执行。资源管理器通过在数据库中保持全部已分配任务的列表、并且定期与运行给定任务的每台机器的从属监视器进行通信以便确定任务的状态，来监督所分配任务的执行。

在实施例中，资源管理器定期轮询已经向其分配了任务的机器的从属监视器，以确定任务的状态。在替换实施例中，从属监视器本身发送定期状态消息到资源管理器，以向资源管理器通知所分配任务的状态。资源管理器将它从从属监视器接收的、有关每个任务以及每台机器的状态的信息存储在数据库中，以便有助于其分配和监视必需任务的功能。

在替换实施例中，从属监视器仅仅启动从资源管理器接收的任务，而任务本身直接向资源管理器报告而不是向从属监视器报告。

资源管理器根据容错例程监视每个分配的任务，该例程允许资源管理器确定何时任务已经失败了，并且允许资源管理器执行用于改正问题以及确保所请求的媒体内容的递送的必要步骤。例如，如果已经向其分配了任务的机器不对状态查询作出响应长达预定的时间段，则资源管理器可被编程为将任务重新分配到不同的机器并且重新启动未响应的机器。另外，在任务的失败还导致一连串分配的相关任务失败时，资源管理器可被编程为停止全部相关的任务，并且重新分配整组任务，以便确保所请求的媒体内容的递送。这些示例不是限制性的，而且基于此处包含的示教，其它容错方案对于本领域的技术人员来说将会是显然的，而且本发明包含这样的其它容错方案。

在进一步的实施例中，分别向各个任务分配优先级。资源管理器监视新任务，并且当现有任务的优先级低于需要被分配的新任务的优先级时，资源管理器将指示现有任务取消其自己以容纳新的较高优先级的任务。作为选择，从属监视器可以取消现有任务。低优先级任务的示例包括在观众已经停止观看所请求的内容之后，为观众进行媒体内容的代码转换。

在步骤1514，在已经分配了全部任务之后，任务管理器构造对从观众客户端接收的、访问媒体内容的初始请求的答复。该答复用来将观众客户端重定向到流式服务器或者代理服务器，观众客户端最终将从这些服务器接收所请求的媒体内容。在实施例中，该答复包含HTTP答复。

在步骤1532，进行根据优选实施例的自动源类型检测是否打开的确定。系统可以被永久地设置为自动源类型检测打开，或者被永久地设置为自动源类型检测关闭，或者可以有选择地进行切换。如果永久地打开或者关闭了自动源类型检测，则该确定不是必需的，而且本方法可以移到相应的步骤1534或者1536。在图6B所述的方法中，在进行了上述确定之后，然后该方法移到下一个相应步骤。也就是说，如果打开了自动源类型检测，则在步骤1534，自动地从源服务器或者客户端取出源类型信息。优点是，这对于用户来说是较快速和较简单的。做为选择，如果关闭了自动源类型检测，则在步骤1536，请求通过源用户接口来自正点播该内容的用户的输入。优点是，具有多个用于内容的源类型的用户可以在这些类型之间做出选择，或者如果源具有防火墙，则不能利用用户输入容易地检测出源类型。

在步骤1538，进行根据优选实施例的自动目标类型检测是否打开的确定。系统可以被永久地设置为自动目标类型检测打开，或者被永久地设置为自动目标类型检测关闭，或者可以有选择地进行切换。如果永久地打开或者关闭了自动目标类型检测，则该确定不是必需的，而且本方法可以移到相应的步骤1540或者1542。在图6B所述的方法中，在进行了上述确定之后，然后该方法移到下一个相应步骤。也就是说，如果打开了自动目标类型检测，则在步骤1540，自动地从目标服务器或者客户端取出目标类型信息。优点是，这对于用户来说是较快速和较简单的。做为选择，如果关闭了自动目标类型检测，则在步骤1542，请求通过目标用户接口来自正点播该内容的用户的输入。优点是，具有多个用于内容的目标类型的用户可以在这些类型之间做出选择，或者如果目标具有防火墙，则不能利用用户输入容易地检测出目标类型。

基于指定的规则、例如由媒体内容的发布者所提出的规则，或者基于商业规则，可以检测和应用独立于目标类型的进一步标准。例如，带宽标准可以基于客户的合同，或者按发布者的要求、利用代码转换后的媒体内容插入片尾或者剪辑或者这两者。

在图6C的步骤1516-1526，在机器群内的机器根据从资源管理器接收的所分配任务，执行递送所请求的媒体内容所必需的步骤。在本发明的实施例中，媒体内容的递送是流水线处理，其中可以同时进行同一个媒体内容流中的不同部分的取出、代码转换和流式传输。资源管理器通过媒体代码转换引擎内的资源分配，安排这些步骤的流水线处理。这些步骤的流水线处理导致媒体代码转换引擎对所请求媒体的更快递送时间。

如步骤1516所示，如果所请求的媒体内容早已驻留在已被代码转换为适当目标类型(例如、适当目标格式和比特率或者其它适当的发布变量)的代码转换高速缓存中的话，则由流式服务器在步骤1524实现内容的递送，该流式服务器将代码转换后的媒体内容流式传输到观众客户端。

然而，如果所请求的媒体内容没有驻留在已被代码转换为适当目标类型的代码转换高速缓存中，则如步骤1518所示，在机器群内的一个或者多个发送器服务器开始从源位置中取出所请求的媒体内容作为数据流。如上面关于图3A-3B和4A-4D所述，在本发明的实施例中，所请求的媒体内容可以最初驻留在媒体代码转换引擎内的主存档内，驻留在媒体代码转换引擎外部的存档中，或者作为直接从内容供应商客户端馈送的流被接收。在所请求的媒体内容驻留在主存档内时，发送器服务器之一在媒体代码转换引擎的内部网络上取出所请求的媒体内容。

在所请求的媒体内容驻留在媒体代码转换引擎之外的存档中时，发送器服务器之一使用在发布处理期间提供的访问信息来取出所请求的媒体内容。在实施例中，在发送器服务器使用访问信息取出所请求的媒体内容之后，所请求的媒体内容可以被暂时高速缓存在主存档中，以允许当媒体代码转换引擎接收到对同一媒体内容的后续请求时，加快对该媒体内容的访问。

当所请求的媒体内容是直接从内容供应商客户端馈送的流时，发送器服务器之一从内容供应商网络服务器接口取出流式数据。因为在实际上由观众请求该数据之前，本发明的实施例不取出流式数据并且也不代码转换流式数据，所以由此避免了媒体内容的不必要的代码转换。

如步骤1520所示，在发送器服务器开始取出所请求的媒体内容之后，如果源类型与目标类型相同(例如，源格式和比特率与目标格式和比特率相同)，则没有代码转换是必需的，而且只要取出媒体内容就把该媒体内容传输到流式服务器。如下所述，在步骤1524，流式服务器然后将该内容流式传输到观众客户端。然而，如果源类型与目标类型不相同，则如步骤1522所示，在机器群内的代码转换服务器之一将把媒体内容从源类型代码转换为目标类型。根据上面关于步骤1512的论述，资源管理器将代码转换任务分配给代码转换服务器，该服务器运行必要的代码转换器软件，以便执行发布变量的适当转换。在实施例中，代码转换使用各种众所周知的方法之一实现，并且用于将一种类型的媒体内容转换为另一种类型，其包括用于将媒体内容进行代码转换的传统编解码例程。下面提供了代码转换操作和示例的进一步描述。在实施例中，在代码转换完成之后，将代码转换后的媒体内容的副本暂时存储在代码转换高速缓存中，以允许当媒体代码转换引擎接收到对被代码转换为同一目标类型的同一媒体内容的后续请求时，加快该媒体内容的递送。

在步骤1524，一旦从代码转换器、发送器或者代码转换高速缓存中接收了以适当目标类型的媒体内容，流式服务器之一就将该媒体内容流式传输到观众客户端。在实施例中，经由可选的代理服务器将代码转换后的媒体内容流式传输到观众客户端。在进一步的实施例中，要么流式服务器要么可选的代理服务器保持有关正被递送的媒体内容以及正进行递送的媒体内容的目标类型的使用统计数据，这些使用统计数据由资源管理器使用以用于高速缓存管理目的。

在实施例中，用于将媒体流式传输到观众客户端以及用于在发送器服务器、代码转换器服务器和流式服务器之间流式传输数据的协议是诸如RTSP之类的、用于流式媒体的标准协议。作为选择，可以使用在如TCP/UDP那样的标准网络协议上定义的专有协议。在进一步的实施例中，不同的协议可以用来容纳不同的网络基础设施需要。例如，可以实现根据网络通信状况动态改变的协议。然而，这些示例是说明性的。本发明不限于特定的通信协议或者应用，而且可以使用其它的专有或者非专有的网络通信协议和应用。

在步骤1526，观众客户端要么从流式服务器要么从代理服务器接收流式媒体。此时，观众客户端根据与驻留在观众客户端上的媒体播放器相关联的目标类型，播放媒体内容。在本发明的替换实施例中，媒体内容可以作为下载文件而接收并且存储在观众客户端上，用于在稍后时间播放，或者用于传输到替换的媒体播放设备。在步骤1526之后，流程图1500结束。

媒体内容示例

如专利6,407,680中所述，例如，媒体代码转换引擎可以包括一个或多个代码转换器。代码转换器将某些类型的媒体内容(此处称为源类型)转换为另一类型的媒体内容(此处称为目标类型)。代码转换可以涉及许多不同的转换操作。所使用的特定转换操作取决于正被转换的媒体内容以及相关联的发布变量。这是为什么可能作为目标的客户端的配置信息的有效检测是有利的原因。此处使用的发布变量涉及媒体内容的不同特征。

根据优选实施例，媒体内容是在网络上发布的数字数据。在这种情况下，发行物是指已经被格式化以便在网络上递送以及由目标媒体播放器观看的数字数据。用于媒体内容的发布变量可以包括但不局限于文件格式、比特率、通信协议(多个)、物理介质、压缩算法、和/或数字权利管理信息。

数字数据可以是任何类型的文件格式，其包括当不限于容器格式、位图格式、视频格式、音频格式、矢量格式、元文件格式、场景格式、动画格式、多媒体格式、混合格式、超文本以及超媒体格式、三维数据(3D)格式、虚拟现实建模语言(VRML)格式、字体格式(位图字体、笔划字体、基于样条的轮廓(spline-based outline)字体)、页面描述语言(PDL)格式、以及任何其它类型的图形文件格式或者其他文件格式。表格1列出了可以在本发明的实施例中使用的这样的文件格式的示例：

                   表格1

                示例文件格式

格式                               类型

ADOBE ILLUSTRATOR                  元文件

ADOBE PHOTOSHOP                    位图

ATARI ST GRAPHICS FORMATS          位图和动画

AUTOCAD DXF                        矢量

AUTODESK 3D STUDIO                 场景描述

BDF                                位图

BRL-CAD                            其它

BUFR                               其它

CALS RASTER                        位图

CGM                                元文件

CMU FORMATS                        多媒体

DKB                                场景描述

DORE RASTER FILE FORMAT            位图

DPX                                位图

DR.HALO                            位图

DVM MOVIE                          动画

ENCAPSULATED POSTSCRIPT            元文件(页面描述语言)

FACESAVER                          位图

FAX FORMATS                        位图

FITS                               其它

FLI                                动画

GEM RASTER                         位图

GEM VDI                            元文件

GIF                                位图

GRASP                              动画

GRIB                               其它

HARVARD GRAPHICS                   元文件

HIERARCHICAL DATA FORMAT           元文件

IFF                                位图

IGES                               其它

INSET PIX                          位图

INTEL DVI                          多媒体

JPEG FILE INTERCHANGE FORMAT       位图

KODAK PHOTO CD                     位图

KODAK YCC                          位图

LOTUS DIF                          矢量

LOTUS PIC                          矢量

LUMENA PAINT                       位图

MACINTOSH PAINT                    位图

MACINTOSH PICT                     元文件

MICROSOFT PAINT                    位图

MICROSOFT RIFF                     多媒体

MICROSOFT RTF                      元文件

MICROSOFT SYLK                     矢量

MICROSOFT WINDOWS BITMAP           位图

MICROSOFT WINDOWS METAFILE         元文件

MIFF                               位图

MPEG                               其它

MTV                                场景描述

NAPLPS                             元文件

NFF                                场景描述

OFF                                场景描述

OS/2 BITMAP                        位图

P3D                                场景描述

PBM.，PGM.，PNM.，以及PPM.         位图

PCX                                位图

PDS                                其它

PICTOR PC PAINT                    位图

PIXAR RIB                          场景描述

PLOT-10                            矢量

PNG                                位图

POV                                矢量

PRESENTATION MANAGER METAFILE      元文件

PRT                                场景描述

QRT                                场景描述

QUICK TIME                         其它

RADIANCE                           场景描述

RAYSHADE                           场景描述

RIX                                位图

RTRACE                             场景描述

SAF                                位图及其它

SENSE8NFF                          场景描述

SGI IMAGE FILE FORMAT              位图

SGI INVENTOR                       场景描述

SGI YAODL                          场景描述

SGO                                矢量

SPIFF                              位图

SUN ICON                           位图

SUN RASTER                         位图

TDDD                               位图和动画

TGA                                位图

TIFF                               位图

TTDDD                              位图和动画

URAY                               场景描述

UTAH RLE                           位图

VICAR2                             位图

VIFF                               位图

VIS-5D                             矢量

VIVID AND BOB                      场景描述

WAVEFRONT OBJ                      矢量

WAVEFRONT RLA                      位图

WORDPERFECT GRAPHICS METAFILE      元文件

XBM                                位图

XPM                                位图

XWD                                位图

ZBR                                元文件

参见Murray和vanRyper等人的著作，第12-26页。这些示例是说明性的而不用于限制本发明。在给出这个描述的情况下，本领域技术人员显然可知，可以使用其他文件格式(现在已知或者在将来开发的文件格式)。

即使在相同的文件格式内，也可以根据不同的压缩算法压缩数字内容。例如，在QUICK TIME格式化的文件中，可以根据H.263、CINEPAK、JPEG、QT ANIMATION、或者QT VIDEO标准压缩视频。作为进一步的示例，在WINDOWS MEDIA ASF格式化的文件中，可以根据MICROSOFT AUDIO FORMAT、ACELP、VOXWARE、或者MP3标准压缩音频。可以基于根据比特率的选择、或者根据内容的属性进行的优化，进行压缩算法选择。例如，可以使用不同的压缩算法更有效地分别压缩其中很少出现运动的视频文件(“说话者头部特写”)和其中有大量运动的视频文件(“高速运动”视频)。

在任何一个压缩算法内，可以有进一步的改变。例如，根据JPEG标准压缩的文件可以是基于YUV的或者基于RGB的。

关于优选实施例中的数字权利管理系统，根据本发明的一个方面检测的、在客户端计算机上的媒体播放器确定DRM信息类型、或者它可以处理的使用规则类型。例如，Windows Media Player可以解释和/或处理由微软Windows Media DRM系统提供的使用规则，但是通常不能解释和/或处理由Real的Helix DRM系统提供的那些使用规则。此外，RealOne播放器可以解释和/或处理由Real的Helix DRM系统提供的那些使用规则，但是不能解释和/或处理由微软WindowsMedia DRM系统提供的那些使用规则。也就是说，媒体播放器类型通常与它可以解释的DRM类型之间具有一一对应关系。

此外，DRM信息或者使用规则信息可以由包括标签以及它们的值的XrML、XML等描述。DRM信息或者使用规则信息还可以附加到内容上。或者，它可以与内容物理分离，并且通过内容ID等与内容在逻辑上相关联。DRM信息或者使用规则信息还可以定义怎样和/或何时用户可以使用该关联的内容。

根据这个发明的一个方面，服务器系统可以自动地检测在客户端计算机上的媒体播放器类型，基于媒体播放器类型确定在客户端计算机上的DRM类型，并且自动地对DRM信息或者使用规则信息进行代码转换，以便能够在客户端计算机上解释和/或处理该信息。如美国专利6,407,680所述，DRM信息可以从源类型(例如，MSFT WindowsMedia DRM)代码转换为目标类型(例如，Real Helix)。

根据本发明的这个方面，因此提供了一种用于远程确定多媒体内容用户的计算机配置的方法。这种有利的方法包括：发送播放器检测代码到用户的计算机，接收有关用户计算机的配置信息，以及基于所接收的配置信息确定在用户计算机上的数字权利管理信息的类型。

除上面所阐述的发布变量之外，还存在有对于视频数据和音频数据而言唯一的发布变量。视频数据的发布变量包括视频图像的以像素为单位的宽度和高度以及视频的帧速率。取决于比特率要求和数据的属性，为了确保最佳画面质量，不同的设置可能是必需的。例如，即使具有相同的比特率，一些视频可能以每秒15帧、160×120像素能较好地观看，而一些其它视频可能以每秒5帧、320×240像素能较好地观看。在比特率为56K bps时，画面质量变得非常有限，而且几乎不会优化为以640×480像素分辨率递送视频。另一个用于视频数据的发布变量是每个分量的位数。

用于音频数据的发布变量包括每秒的样本数目、声道数目(例如，单声道、立体声、5声道)以及样本大小(8位、16位等)。考虑到特定的内容类型和比特率，不同的设置可能是确保音频质量所必需的。发布变量还可以包括正被发送的数据包大小，以及对传输协议的选择(例如，TCP对比UDP)。

图7示出了一个示例代码转换器，其应请求将源类型媒体内容610代码转换为目标类型媒体内容650。源类型媒体内容610是以一个或多个分组的形式在网络上递送的数字数据。形成源类型媒体内容610的数字数据由一个或多个发布变量定义。图7所示的发布变量包括以下变量中的一个或者多个：源文件格式、源比特率、源物理介质、源通信协议、源编码、或者它们的任何组合。目标类型媒体内容650是以一个或者多个分组的形式在网络上递送给点播媒体内容的终端用户的数字数据。形成目标类型媒体内容650的数字数据也由一个或多个发布变量所定义。图7所示的发布变量包括以下变量中的一个或者多个：目标文件格式、目标比特率、目标物理介质、目标通信协议、目标编码、或者它们的任何组合。

图8示出了这样一个示例实现的表格，其中一个或多个代码转换器应请求从源类型媒体内容710代码转换为第一目标类型750。图8还示出了这样一个示例实现，其中一个或多个代码转换器将点播内容从源类型媒体内容710代码转换为第二目标类型760。源类型媒体内容710包括根据以下源发布变量发布的数字数据，这些源发布变量为：物理介质是本地磁盘，通信协议包括文件I/O，文件格式是使用以128千位/秒(kbps)的比特率的MP3编码的MP3。第一目标类型媒体内容750包括根据以下目标发布变量而被代码转换用于发布的数字数据，这些发布变量为：物理介质是分组交换网络(Internet)，通信协议包括WINDOWS MEDIA STREAMING MMS协议，文件格式是使用以56kbps的比特率的MP3编码的WINDOWS MEDIA FILE。

第二目标类型媒体内容760包括根据以下目标发布变量而被代码转换用于发布的数字数据，这些发布变量为：物理介质是无线网络，通信协议包括HTTP，文件格式是包括以12kbps比特率的MP3编码在内的MP3。

其它示例如以下的表格所示：

         表格2-5：示例代码转换器操作

                    表格2

发布变量                源类型     目标类型

物理介质                盘         网络

通信协议(一种或多种)    文件I/O    RTSP

容器格式                MPEG1      QUICK TIME

编码                    MPEG1      SORENSON(视频)

                                   QDESIGN(音频)

比特率                  1.5Mbps    300kbps

                    表格3

发布变量                源类型      目标类型

物理介质                有线网络    无线网络

通信协议(一种或多种)    HTTP        MMS

容器类型                MPEG1       WINDOWS MEDIA

编码                    MPEG1       MPEG4(视频)

                                    MSAUDIO(音频)

比特率                  1.5Mbps     100kbps

                    表格4

发布变量                源类型         目标类型

物理介质                有线网络       有线网络

通信协议(一种或多种)    HTTP           RTSP

容器格式                QUICK TIME.    REAL

编码                    H.263          REAL

                                       PROPRIETARY G2视频/音频

比特率                  56kbps         56kbps

                   表格5

发布变量                源类型     目标类型

物理介质                盘         无线网络

通信协议(一种或多种)    文件I/O    HTTP

容器格式                MPEG1      MP3

编码                    MPEG1      仅仅音频-MP3.

比特率                  1.5Mbps    16kbps

图9是示出根据本发明实施例的示例客户端环境变量类型的表格。优选实施例中的系统能够确定进一步的包括操作系统(OS)版本、网络浏览器版本、硬件平台和用户接口语言在内的客户端系统的特征。即使在包括有利的性能以辨别那种类型的OS、例如Windows、Mac或者Linux正在客户端机器上使用的系统上，这个性能也是有利的改进。例如，即使已知该系统使用Windows，关于比客户端实际上所具有的版本更新的版本的假定也可能导致媒体流的完全失败，而早很多的版本的保守假定可能导致效率低。

提供了源类型810(即媒体内容来自该处并且最初为其进行配置)的一个示例，其具有Window XP作为它的OS版本，具有Navigator3.0作为它的浏览器版本，安装了奔腾4处理芯片并且使用Navigator3.0的Javascript作为其用户接口语言。可以与此处根据实施例所描述的客户端配置的确定相类似地提供或者确定这些源类型。然后，将目标类型850说明为是Mac OS X操作系统，Omniweb 4.1网络浏览器版本，G3处理器芯片，以及用于Omniweb 4.1的用户接口语言XSLT。一旦根据此处的实施例远程确定了目标类型850，并且还确定了源类型810，则可以使用诸如可能优选为此处通过引用并入的美国专利申请10/644,602中所描述的之类的有利代码转换处理，以便将从源提供的媒体内容流式传输到目标，而不管所使用的不同类型的硬件和软件如何。

这些示例是说明性的而不是用于限制本发明。在给出这个描述的情况下，本领域技术人员显然可知，可以使用现在已知或者将来开发的其他类型的应请求执行的代码转换操作。

替换实施例

此处已经描述了本发明的方法和系统的示例实施例。如在别处所述的那样，仅仅为了说明目的而已经描述了这些示范实施例，而不是将其用于限制。基于此处包含的示教，对于本领域的技术人员来说，与此处描述的那些实施例稍微不同或者基本上不同的替换实施例是显而易见的。例如，本领域的技术人员应当理解：本发明中的代码转换系统和方法不仅局限于媒体内容的代码转换和递送，而且还包含所有类型信息的代码转换和递送，这些类型包括但不限于压缩文件、电子文档、HTML页面、XML文档、以及任何其它可以多种格式存储并且电子地递送的信息。其它替换的实施例包括但不局限于本发明中的方法、系统和部件的硬件、软件、以及软件/硬件实现。这样的替换实施例落在本发明的范围和精神之内。

此外，还可以提供用于应请求将媒体内容从源类型代码转换为目标类型的系统和方法，其中该系统包括多个代码转换器，其用于从多个源类型代码转换为多个目标类型，以及其中该系统接收对媒体内容的代码转换请求，响应于该代码转换请求取出媒体内容，基于源类型和目标类型将媒体内容发送到多个代码转换器之一，将媒体内容从源类型代码转换为目标类型，由此生成代码转换后的媒体内容，并且传输该代码转换后的媒体内容。该系统可以以流水线方式取出、发送、和代码转换媒体内容、以及传输代码转换后的媒体内容。该系统还提供了将媒体内容发布作为数字数据文件或者流，以用于存档媒体内容，以及高速缓存代码转换后的媒体内容以改进系统效率。

此外，在可以根据此处的优选实施例执行并且已经在上面描述过的方法中，已经以所选择的排版顺序描述了其中的操作。然而，已经为了排版方便而选择并因此排序了这些顺序，该顺序不用于暗指用于执行这些操作的任何特定次序。

Claims (10)

1、一种用于确定计算机的连接速度的方法，包含：

(a)基于估计的带宽确定计时块的大小；

(b)标记计时块的传输开始时的时间；

(c)标记计时块的传输结束时的时间；以及

(d)基于所确定的计时块大小以及传输开始和结束时的时间，确定连接速度，

其中，所述计时块大小确定步骤包含：

(1)取出估计的带宽信息；

(2)确定用于检取数据以便用足够的分辨率确定连接速度的估计时间；以及

(3)确定将花费所确定的估计时间来进行检取的计时块大小。

2、如权利要求1所述的方法，其中以作为首选项页面一部分的标记语言注释的形式接收计时块。

3、如权利要求1所述的方法，还包含：在cookie中存储连接速度。

4、如权利要求3所述的方法，还包含：将cookie发送到递送管理服务器。

5、如权利要求1所述的方法，该计时块包含随机数据。

6、一种用于确定计算机的连接速度的方法，包含：

(a)接收具有已知大小的数据计时块；

(b)接收要开始计时块的传输时的启动时间；

(c)在该启动时间上开始计时块的传输；

(d)标记计时块的传输结束时的时间；以及

(e)基于计时块大小以及传输开始和结束时的时间，确定连接速度，

其中，通过以下步骤确定计时块的已知大小：

(1)取出估计的带宽信息；

(2)确定用于检取数据以便用足够的分辨率确定连接速度的估计时间；以及

(3)确定将花费所确定的估计时间来进行检取的计时块大小。

7、如权利要求6所述的方法，其中，以作为首选项页面一部分的标记语言注释的形式接收计时块。

8、如权利要求6所述的方法，还包含：在cookie中存储连接速度。

9、如权利要求8所述的方法，还包含：将cookie发送到递送管理服务器。

10、如权利要求6所述的方法，该计时块包含随机数据。

Images