包含连续播放的视频分配系统的制作方法
【专利摘要】本发明描述了一种接收器驱动的播放远程内容的方法。其中一实施方案包括：获取与来自远程服务器媒体文件的内容相关的信息；确定该媒体序列内的起始位置；确定由起始位置播放媒体序列所需要的媒体对应的媒体文件的字节范围，请求由上述起始位置开始播放该媒体序列所需要的字节范围；对接收到的信息的字节进行缓冲并且暂时不开始播放；播放被缓冲的信息字节；接收用户指令；根据用户指令确定与被要求播放的媒体序列对应的媒体文件的字节范围；刷新先前的字节范围请求；以及，根据用户的指令请求播放该媒体所需要的字节范围。
【专利说明】包含连续播放的视频分配系统
[0001]本申请是申请日为2008年01月07日，申请号为200880007014.9的发明名称为“包含连续播放的视频分配系统”的发明专利申请的分案申请。
【技术领域】
[0002]本发明总体上涉及在网络上播放多媒体文件，特别是涉及在网络上下载多媒体文件时对该多媒体文件的连续播放。
【背景技术】
[0003]连续播放(progressive playback)是指在下载远程内容的同时进行播放。这样用户能够选择远程影片并在其完全下载之前就开始观看。即便是联网速度很快，根据媒体文件的大小，等待一部影片完全下载也需要数分钟至数小时。利用连续播放功能，用户只需要等待几秒钟就可以开始播放。
[0004]目前的由接收器或播放器驱动(playerdriven)的连续播放尽管适合于目前仍处于主流的视频短片剪辑，但通常其能够提供的连续播放的范围和灵活性受到限制。播放器通常是对文件由头至尾进行线性下载。当播放器缓冲了足够数据使媒体播放可能不会中断时开始播放。所需要的缓冲量可以是占整个内容相当百分比的一个固定量，也可以是动态的，播放器参考播放整个内容需要多少数据才不至于使缓存欠载。这些方法尽管适合于播放较短的视频剪辑，但通常都不支持对远程存储的较长内容的搜索、特技播放(trick-play)和播放,例如长篇电影。
[0005]有些系统中采用了服务器驱动的技术方案。服务器驱动方案的例子包括美国专利申请号11/323，044、11/323，062、11/327，543和11/322，604中描述的系统，这些申请中所公开的全部内容作为参考并入本申请中。在这些系统中，服务器对数据文件进行解析并确定发送哪些数据。播放所涉及的网络效率和灵活性更易实现。然而，标准的HTTP网站服务器通常不提供这种功能，而提供此类功能的自定义的网站服务器在大量的播放器同时要求传送播放内容时通常显得规模太小。
[0006]基于浏览器的播放器通常是在线性下载视频文件时对其进行解析，实现由接收器驱动的播放。开始播放较长的剪辑时，不可能搜索或快进到文件中还未下载的部分。可以使用Samba (由http://us2.samba, org/samba/提供的开放源软件)实现就象本地文件一样的对远程文件的任意应用访问。该软件试图借助由可随机设定的对当前文件位置以预先缓存的方式尽量缩短访问等待时间。当试图执行“特技播放”(例如:倒片、快进、需要对媒体内容进行非序列访问的情节间跳跃)功能时，上述方法仍显不足。在这些情况下传送到播放器的视频帧之间的间隔可能很远或要求更为复杂的指令，大大地限制了传统的基于将要观看的内容就是后续视频帧这一假定的预先缓存方法的应用。
【发明内容】
[0007]本发明描述了在部分下载的媒体文件上执行连续播放和“特技播放”功能的系统和方法。本发明的许多实施例包括支持以下特性的接收器或播放器:随时仅对某些要求的数据维持满负荷下载流，包括某字节范围内的数据，丢弃之前的请求，发出对于最高优先的数据的新请求。此外，本发明的若干实施例包括以下特征:对文件上的任何一点上的随机文件访问以及异步请求，这些都为用户提供了播放文件方面的灵活性。在一些实施例中，该系统和方法支持在互联网服务器上实现存储多个片名、包含多个音轨的片名和/或包含一个或多个字幕轨的片名的可扩展性。
[0008]在一些实施例中，具备提供全功能连续播放的能力部分是因为媒体序列的播放引擎(即，对编码媒体进行解码和播放的系统)与能够提供对远程文件随机访问的传输协议的紧密结合。播放引擎与传输协议通过文件解析器进行接口能够减少冗余并使客户端与媒体服务器并行运行，提高了下载效率和交互性能。在一些实施例中，上述系统和过程被配置为能够使用这样一类经过格式化的文件:这些文件包含了文件内数据的索引和传输协议，以便允许对文件内的特定字节范围进行下载。
[0009]本发明的一个方法实施例包括以下步骤:获取与来自远程服务器媒体文件的内容相关的信息；确定该媒体序列内的起始位置；确定由起始位置播放媒体序列所需要的媒体对应的媒体文件的字节范围，请求由上述起始位置开始播放该媒体序列所需要的字节范围；对接收到的信息的字节进行缓冲并且暂时不开始播放；播放被缓冲的信息字节；接收用户指令；根据用户指令确定与被要求播放的媒体序列对应的媒体文件的字节范围；刷新先前的字节范围请求；以及，根据用户的指令请求播放该媒体所需要的字节范围。
[0010]本发明的另一方法实施例包括以下步骤:保持一个媒体文件中已经被下载部分的掩码，利用该掩码确定根据用户指令要求播放的媒体的字节范围的至少一部分，以及仅由媒体服务器请求尚未被下载的字节范围的某些部分。
[0011]本发明的又一方法实施例包括以下步骤:将下载的字节存储于一数据文件中，并当媒体文件的所有字节都被下载后才将下载的媒体文件输出。
[0012]在本发明的再一方法实施例中，上述数据文件是一个稀疏数据文件。
[0013]在本发明的再一方法实施例中，上述媒体文件包含多个媒体序列和菜单信息,并在上述媒体序列中确定还包含显示菜单信息的媒体序列中确定一起始位置，接收一个表明了对上述媒体序列进行的选择的用户指令，并接收一个表明了媒体序列内起始位置的用户指令。
[0014]在本发明的再一方法实施例中，上述媒体序列包括多个可互换的音轨，在上述媒体序列内确定起始位置的步骤还包括选定一个音轨的步骤，并且上述确定由起始位置播放媒体序列所需要的媒体对应的媒体文件的字节范围的步骤还包括选定那些不将未选中的音轨包括在内的字节范围。
[0015]在本发明的再一方法实施例中，上述媒体序列包括多个可互换的字幕轨，在上述媒体序列内确定起始位置的步骤还包括选定一个字幕轨的步骤，且上述的确定由起始位置播放媒体序列所需要的媒体对应的媒体文件的字节范围的步骤还包括选定那些不将未选中的字幕轨包括在内的字节范围。
[0016]在本发明的再一方法实施例中，上述序列包括关键帧，且上述的根据用户指令确定播放媒体所需要的媒体对应的媒体文件的字节范围的步骤还包括根据预先确定的用户指令确定关键帧的序列，并且确定与该已经确定的关键帧对应的媒体文件的字节范围。[0017]本发明的一实施例包括一媒体服务器、一客户端、和一网络。此外，所述客户端和媒体服务器通过网络进行通信，客户端向媒体服务器发出至少请求媒体文件一部分的请求，服务器向客户端提供媒体文件中被请求的部分，并且客户端接收用户有关播放媒体文件的指令并且向媒体服务器请求媒体文件中尚未被下载并且符合播放指令的部分。
[0018]在本发明的另一实施例中，媒体文件的邻近部分被分组，并且这些分组根据先到期先选择的原则被请求。
[0019]在本发明的另一实施例中，客户端保持媒体文件的被请求部分的队列。
[0020]在本发明的另一实施例中，客户端和服务器通过至少一条连接进行通信，并且客户端刷新媒体文件中被请求的部分的队列并根据收到的预定的用户指令断开至少一个连接。
[0021 ] 在本发明的另一实施例中，客户端存储文件映射和数据文件，文件映射包含了表明媒体文件中已经被下载的部分的掩码，并且数据文件包含媒体文件中已经被下载的部分。
[0022]在本发明的另一实施例中，数据文件是一个稀疏文件。
[0023]在本发明的另一实施例中，媒体文件包括媒体队列和索引，客户端包括播放引擎，该播放引擎获取索引并确定媒体队列中需要符合用户播放指令的部分，利用索引将媒体队列的部分映射到媒体文件的部分的文件解析器，以及与媒体服务器进行通信以便下载部分媒体文件的下载管理器。
[0024]在本发明的另一实施例包括:接收用户指令的用户界面、存储至少一个媒体文件的存储设备、网络连接、通过网络连接向远程存储的媒体文件异步请求文件的至少一个字节范围的下载管理器、依据由用户界面接收的用户指令确定远程存储的媒体文件中必需被下载的部分的播放引擎、以及将对远程存储的媒体文件中的一部分进行请求转换为字节范围并将该字节范围提供给下载管理器的文件解析器。
[0025]在本发明的另一实施例中，下载管理器创建包含媒体文件中被下载的区块的映射的状态文件，并且下载管理器创建用来存储媒体文件已经被下载区块的数据文件。
[0026]在本发明的另一实施例中，下载管理器保持被请求的字节范围的队列。
[0027]在本发明的另一实施例中，下载管理器刷新该队列。
[0028]在本发明的另一实施例中，播放引擎利用由远程媒体文件获取的菜单信息生成一个菜单。
[0029]在本发明的另一实施例中，播放引擎通过菜单接收对远程媒体文件中的多个媒体序列中的一个媒体序列的选择。
[0030]在本发明的另一实施例中，播放引擎通过菜单接收对远程媒体文件中的一个媒体序列中的多个音轨中的一个音轨的选择。
[0031 ] 在本发明的另一实施例中，播放引擎通过菜单接收对远程媒体文件中的一个媒体序列中的多个字幕轨中的一个字幕轨的选择。
【专利附图】
【附图说明】
[0032]图1是根据本发明一实施例的连续播放系统的网络原理简图。
[0033]图2是根据本发明一实施例对远程存储的媒体文件进行连续播放的程序的流程图。
[0034]图3是根据本发明一实施例用来向远程服务器请求字节范围和支持“特技播放”功能的客户端应用软件的概念图。
[0035]图4是根据本发明一实施例的下载管理器的概念图。
[0036]图5是根据本发明一实施例由媒体服务器请求字节范围的程序的流程图。
[0037]图6是根据本发明一实施例刷新与媒体服务器连接的程序的流程图。
[0038]图7是根据本发明一实施例在对字节范围进行非顺序下载时建立数据文件的程序的流程图。
[0039]图8是根据本发明一实施例可供文件解析器使用的用来确定远程媒体文件内的菜单信息和媒体序列并从文件抽取信息的程序的流程图。
[0040]图9是根据本发明一实施例供播放引擎使用的用来从远程媒体文件获取数据块的程序的流程图，该远程媒体文件利用数据块容器格式被格式化。
【具体实施方式】
[0041]下面请参阅附图，图中展示了一种连续下载和播放媒体的系统。在许多实施例中，该媒体存储于一远程服务器的文件中，并且一客户端应用程序配置的装置检索出该媒体文件的部分并播放该媒体。该客户端应用程序通常在开始播放时不占有整个媒体文件并能够请求媒体文件不连续的部分。这样，该客户端应用程序就能够支持“特技播放”功能。“特技播放”功能影响到媒体文件的播放，例如不连续播放功能，包括暂停、倒片、快进、章节间跳跃。根据本发明实例的客户端应用程序能够确定媒体文件中支持某特定“特技播放”功能所需要的部分并向远程服务器请求媒体文件中的这些部分，而不是按顺序下载媒体文件并一直等待请求的信息下载后执行“特技播放”功能。当“特技播放”功能涉及到跳至媒体中尚未被下载的部分时，例如快进和章节间跳转时，与连续下载相比，能够大大减少等待时间。
[0042]根据本发明一实施例的连续播放系统的配置可取决于该连续播放系统所支持的容器格式(container format)。容器格式的例子包括位于华盛顿州雷蒙德市的微软公司制定的AVI1.0文件格式、类似于已经全文并入本申请作为参考的美国专利申请号11/016，184 和 11/198，142 中规定的 OpenDML AVI 或 AVI2.0 格式、被称为 Matroska 的开放源格式和MPEG_4Partl5 (MP4)(参见www.matroska.0rg)。媒体文件取决于其所使用的容器格式可包含多个标题(即媒体序列)并且每个标题可包含多个音轨和/或一个或多个字幕轨道。媒体文件的容器格式影响到媒体信息在媒体文件中的定位方式。因此，连续播放系统的配置通常是依据某一特定应用程序中支持的容器格式。尽管以下对各种实施方式进行了讨论，依据本发明的实施方式还可构造出适合于不同容器格式的其他变化实施方式。
[0043]根据本发明一实施例的连续播放系统如图1所示。连续播放系统10包含一与网络14连接的媒体服务器12。媒体文件存储于媒体服务器14中并且被客户端应用程序配置过的设备能够访问这些媒体文件。在图中所示的实施例中，能够访问媒体服务器上的媒体文件的设备包括个人电脑16、用户电子设备如连接到电视机20等播放设备的机顶盒18、以及便携设备如个人数字助理22或移动电话。这些设备与媒体服务器12可通过经由网关26连接到因特网24的网络14进行通信。在另一实施例中，媒体服务器14和设备通过因特网进行通信。
[0044]使用客户端应用程序对上述设备进行配置，该客户端应用程序能够请求媒体服务器12上的媒体文件中的某些部分进行播放。客户端应用程序可植入软件、固件、硬件或其组合中。在许多实施例中，该设备播放由媒体文件下载的媒体。在若干实施例中，该设备提供一个或多个输出，使另一设备能够播放该媒体。当媒体文件包含索引时，由本发明一实施例的客户端应用程序配置的设备可利用该索引确定媒体中各个部分的位置。因此，可利用该索引为用户提供“特技播放”功能。当用户发出“特技播放”指令时，该设备利用该索引确定媒体文件中执行“特技播放”功能所需要的一个或多个部分并向服务器请求这些部分。在一些实施例中，该客户端应用软件利用一允许对媒体文件内特定的字节范围进行下载的传输协议请求媒体文件的部分。此类协议之一是Internet Society或BitTorrent公布的HTTP 1.1协议,可由www.bittorrent.0rg获得。在其他实施例中，可使用其他协议和/或机制获得媒体服务器上的媒体文件的特定部分。
[0045]图2表示根据本发明一实施例向媒体服务器请求媒体的流程图。过程40包括以下步骤:(42)从媒体服务器获取媒体文件索引。然后(44)确定播放媒体文件起始位置。在一些实施例中，所有文件都从媒体序列的起始位置开始播放。在一些实施例中，媒体文件可包括一个或多个能够让用户选择由不同的位置开始观看一个或多个媒体序列的一个或多个菜单。一旦确定位置，就请求由该确定位置开始播放媒体所需要的媒体信息(46)并在收到该媒体信息后播放(48)。该过程涉及听取用户指令(50)。当用户没有发出指令时，系统按照前一次从用户端接收到的用户指令继续播放。当用户发出指令时，该过程确定该指令是否为停止播放指令(52)。否则，该过程确定遵照指令所需要的媒体(54)并请求该需要的媒体(46)。持续该过程直至用户发出停止播放该媒体或已经到达该媒体序列的尾部。
[0046]根据本发明实施例的媒体服务器能够简单地通过存储媒体文件并接收对媒体文件内特定字节范围的请求支持连续播放功能和特技播放功能。客户端应用软件可确定适当的字节范围而媒体服务器只是简单地响应该字节范围请求。用来根据用户指令确定适当的字节范围的客户端应用软件可以通过各种方式实现。
[0047]根据本发明一实施例使用三个抽象层的客户端应用软件如图3所示。客户端应用软件60包括负责协调由远程服务器的文件下载的特定字节范围的下载管理器62。播放引擎64是用来协调应用户指令播放媒体文件的高层过程。当媒体文件被播放时，播放引擎利用媒体文件的一个索引确定继续播放媒体和/或响应用户指令所需要的那部分媒体文件。文件解析器66负责在播放引擎64和下载管理器62之间进行接口。文件解析器将高层数据请求由播放引擎映像到其后能够利用下载管理器指定请求的特定字节范围。下面讨论如何根据本发明实例实现下载管理器、文件解析器和播放弓I擎执行任务。在许多实施例中，客户端软件利用另外一些架构，这些架构利用媒体文件的索引将用户指令转换为字节请求提供给远程媒体服务器。
[0048]根据本发明的实施例下载管理器如图4所示。如上文所讨论，下载管理器负责与一个或多个媒体服务器进行通信并由储存由这些媒体服务器中的媒体文件获取特定字节范围。图4中所示的下载管理器70将远程文件对象72和部分文件对象74实例化，以便协助媒体文件的下载。远程文件对象72处理与向媒体服务器请求字节范围相关的通信并维持被请求的字节范围队列。部分文件对象74负责由媒体服务器下载的数据的储存。该部分文件对象74为下载管理器下载的文件建立一个临时数据通路75。
[0049]临时数据通路75包括数据文件78和状态文件76。数据文件76包含由媒体服务器接收到的数据。状态文件包含对数据文件的掩码(mask)，掩码中的每一位都与数据文件中一固定大小的区块对应。随着这些区块被下载，掩码中的位被设定。状态文件还可包括外部数据的一个区域，该区域可包含可被下载管理器使用的用来确定是否有部分下载的数据已经过期的信息，例如最近一次修改的服务器时间戳。当整个媒体文件被下载时，下载管理器创建一个输出文件通路80并且远程文件82的完整下载版本被输出到该下载通路。这时，客户端软件可以采用常规手段利用本地文件播放媒体并支持“特技播放”功能。
[0050]数据文件的长度可以达到若干千兆字节，这取决于被下载文件的大小。通常的文件分配方案是将零分配给文件内的每个字节，对于较大的文件来说这需要数分钟的时间。可以通过将文件作为稀疏文件分配来减少数据文件分配时产生的等待时间，稀疏文件仅使用真正被写入文件的字节数。当使用稀疏文件时，文件分配程序需要很少的时间。在另一些实施例中，可以使用其他一些针对下载管理器的需要权衡延迟文件分配方案。
[0051]数据文件的区块大小(由状态文件表示)确定了可以被下载的数据的粒度(granularity)。仅就下载需要的字节而言，较小的区块通常更为高效。但是较小的区块可导致较大的掩码尺寸。在许多实施例中，区块大小为128，以便在效率和掩码尺寸之间取得折衷。在另一实施例中，使用了根据应用软件的要求确定区块大小的方案。
[0052]根据本发明一实施例的利用下载管理器请求数据的过程如图5所示。过程90包括以下步骤:该过程开始于接收到由存储于远程服务器上的媒体文件下载字节范围的请求(91)。当使用类似于如图4所示的下载管理器时，下载管理器将远程文件对象和部分文件对象实例化并创建必要的支持文件。建立与远程服务器的连接(92)，将被请求的字节范围置于队列中(94)，然后请求该被请求的字节范围(96)。随着更多字节被接收到，该过程确定被请求的字节范围内是否有字节之前已经被下载并且只将之前未被下载的那部分字节范围置于请求队列中。
[0053]当使用类似图4所示的下载管理器用于实施图5所示的植入过程(90)时，使用状态文件76中的掩码确定已经被存储于数据文件78中的被请求的字节和剩余的应该被请求的字节。每个字节范围请求都具有相关的开销，因此，本发明的许多实施例在一个字节范围请求内包括多字节范围和/或检索请求队列中位于队列前端的邻近字节范围的字节范围并请求包含所有邻近字节范围的较大的字节范围。在一些实施例中，该过程打开多条连接以便增加下载数据速率和/或适应限制通过连接进行的字节请求的数量的服务器。再一次，开放的连接具有相关的开销。因此，可根据适合于某特定应用软件的限制对连接的数量进行限制(例如:5个)。
[0054]当确定请求队列中不再有字节范围时(100)，该过程确定是否整个文件已经被下载(102)。如果整个文件没有被完全下载，该过程向部分下载的文件对象请求丢失的字节。一旦整个文件被下载，该下载文件被输出至输出目录并且与远程服务器的连接被关闭(104)，整个过程结束。在许多实施例中，只有在完成播放后才将文件输出。
[0055]尽管图5中展示了一种下载字节范围的特定过程，仍然可以根据本发明的实施例使用这一过程的变化形态并且/或者能够进行特定字节范围和数据文件集合下载的其他过程。此外，这些过程还可进行种种优化以便尽量减少通信开销对媒体播放的影响。[0056]当用户发出一 “特技播放”指令时，前次被请求的字节范围可能不再需要，以便按用户的指令继续播放媒体。根据本发明一些实施例的下载管理器具有刷新等待中的字节范围请求并建立一个新的字节范围请求队列的能力。对某一请求队列进行刷新的优点在于，不会产生在下载当前具有更高优先级的字节范围之前必需要等待前次被请求的字节范围被请求之后才能进行所引起的延迟。在一些实施例中，关闭与远程服务器的连接和打开一个新的连接会进一步减少延迟。关闭连接会去除媒体服务器在响应新的下载请求之前响应等待中的下载请求所引起的延迟。
[0057]根据本发明一实施例对一请求队列进行刷新的过程如图6所示。过程110包括以下步骤:接收刷新请求(112)，刷新请求队列(114)并关闭与媒体服务器的连接(116)。在许多实施例中，可以使用其他过程来减少接收到“特技播放”请求时产生的延迟，并创建一个对远程媒体文件中前次未曾请求的部分的即时需求，该“特技播放”请求会取消对前次请求的媒体文件部分的即时需求。
[0058]当下载管理器接收到数据时，状态文件和数据文件都被更新以便反映接收到的数据。根据本发明的实施例处理由远程媒体服务器接收字节的过程如图7所示。过程130包括接收字节(132)，更新状态文件中的掩码(134)并更新数据文件(136)。然后确定是否已经下载了整个文件(138)。如果整个文件未被完全下载，该过程等待接收更多的字节。当整个文件已经被完整下载时，下载的媒体文件被输出到其输出目录(140)。在其他一些实施例中，使用其他一些过程组织接收到的字节范围。
[0059]使用根据本发明实施例的文件解析器将高层请求由播放引擎转换到用于下载管理器的字节范围请求中并将下载管理器下载的字节范围传递到播放引擎。当设备开始连续播放存储于远程服务器上的媒体文件时，文件解析器访问该文件并下载与媒体文件的内容相关的信息。例如，已经作为参考并入本申请的美国专利号11/016，184和11/198，142中所描述的媒体文件包括菜单信息和/来自多媒体序列的信息(即:不同的媒体演示)。文件解析器获取菜单信息和与媒体序列相关的信息。当用户选择了媒体序列时，文件解析器获取被选定的媒体序列的索引并且该索引在该媒体序列被播放时被用来鉴别要请求的远程媒体文件内的字节范围。
[0060]根据本发明实施例的确定远程媒体文件内包含的媒体序列和抽取选定媒体的过程如图8所示。过程150包括以下步骤:获取文件内包含的任何菜单信息和媒体文件中不同媒体序列的数量相关的信息(152)。在文件解析器与下载管理器结合使用的实施例中，文件管理器利用关于媒体格式的知识选择信息字节，以便利用下载管理器对媒体文件发出请求。可利用菜单信息和/或与媒体序列数量相关的信息获取与每个媒体序列相关的信息(154)。有用的信息包括与媒体序列的名称相关的信息、媒体序列的格式、媒体序列中可选音轨的数量、媒体序列中存在一个或多个字幕轨和/或任何用助于用户选择媒体序列或解码器对媒体序列进行解码的附加信息。当媒体被格式化为AVI格式或任何类似于美国专利申请号11/016，184和11/198，142中描述的文件格式时，可通过下载每个媒体文件的RIFF头标(header)的方式下载每个媒体序列的相关信息。一但获取了与媒体序列相关的信息，就可进行与将要播放的媒体序列相关的选择(154)。当媒体文件包含单一的媒体序列时，可以自动决定。当媒体文件包含多个媒体序列时，可以根据用户指令进行决定，该用户决定是利用通过文件解析器由远程媒体文件获取的菜单信息通过菜单界面获取的。文件解析器利用获取的媒体序列相关信息引导下载管理器下载对媒体序列的索引对应的字节范围(156)。文件解析器可利用索引由远程文件中抽取数据(158)。播放引擎确定被文件解析器抽取的数据。数据的抽取方式取决于媒体文件的格式。当媒体文件被格式为使用组块(chunk)的媒体格式时,文件解析器利用索弓I将组块参考(chunk reference)转换为能够利用下载管理器检索的特定字节范围。当使用其他格式时，文件解析器利用文件解析器可得到的适合于文件描述信息的字节映射。除了请示字节范围以外，根据本发明的实施例的文件解析器还能以与下载管理器进行通信以便检查特定请求的状态并可以向播放引擎提供下载字节。
[0061]当连续播放远程文件时，播放引擎的主要任务总是按用户请求的方式保持播放文件所需要的媒体信息。当媒体文件包括索引时，播放引擎可以根据索引确定按用户请求的方式保持播放文件所需要的媒体信息。根据本发明实施例的用来由被格式化为以信息组块的方式表示媒体的文件获取媒体的过程如图9所示。过程190包括以下步骤:由远程媒体文件获取索引。在播放引擎通过文件解析器请求信息的实施例中，播放引擎向文件解析器可向文件解析器发出指令，获取索引，并且文件解析器可利用下载管理器抽取必要的信息。然后播放引擎按照用户发出的包括“特技”播放在内的指令选择组块(194)，并向文件解析器发出指令将选定的组块下载(196)。在一些实施例中，播放引擎依照最早到期限最先选择的原则选择组块。来自媒体序列内部的多路未使用的音轨和未使用的字幕轨的组块可以忽视。在许多实施例中，在下载整个索引之前就请示媒体组块。通常是由媒体序列的起始处开始播放媒体，因此，在索引被下载时可以下载媒体序列起始处的组块。当播放引擎接收到来自文件解析器的组块时，这些组块被排列成队列并被提供给适宜的解码器，以便能够对媒体进行播放(198)。一旦足够的影片被下载了，就可以开始播放该影片了。缓冲的长度可通过与组块下载元件共享的播放列表的长度确定。
[0062]以上针对图9描述的组块选择过程中保持一个被请求组块的队列。该队列可以作为被请示组块的索引项清单保持。该组块下载过程对被请求的组块的下载状态进行轮询(poll)。一旦下载完成，由被请求的组块队列中移除一个组块并且被下载的组块被送至组块播放过程。
[0063]当接收到“特技播放”指令时，播放引擎选择适合“特技播放”指令的媒体信息。例如，接收到快进或倒片指令的播放引擎可以只请求在整个媒体序列中按照特技播放功能的速率确定的时间间隔的关键帧(即，完整帧)。在许多实施例中，间隔时间为0.1x特技帧速率，，以便在特技播放期间提供每秒10个关键帧的播放速率。在另一些实施例中，采用了各种其他算法确定要请求的媒体。一旦含有关键帧的组块被鉴别出来，播放引擎就利用文件解析器和下载管理器请求组块。
[0064]尽管上述描述中包括了本发明的许多特定实施例，但并非用来限定本发明，而是仅作为本发明的实施例的一个实例。上述的讨论中有很多都是假定媒体文件含有用来鉴别该媒体文件中不同的媒体信息片段的索引。在许多实施例中，媒体文件中含有分层索引和/或其他索引格式并且播放引擎和文件解析器适于容纳特定的索引结构。在一些实施例中，客户端应用软件适于容纳包括不含索引但利用其他信息来描述媒体文件内容的格式在内的多种文件格式。因此，本发明的范围不受以上展示的实施例的限制，而是由后附的权利要求书及其等同形式限定。
【权利要求】
1.一种连续播放媒体文件的系统，该系统包括: 媒体服务器； 客户端；以及 网络； 其中所述客户端和媒体服务器通过所述网络通信； 其中所述客户端用来向所述媒体服务器发出请求，请求所述媒体文件的至少一部分；其中所述服务器向所述客户端提供媒体文件中被请求的部分；及其中所述的客户端接收与播放所述媒体文件相关的用户指令并向所述媒体服务器请求所述媒体件中尚未被下载并符合所述播放指令的部分。
2.根据权利要求1所述的连续播放媒体文件的系统，其中所述媒体文件的邻近部分被分组并且这些组按照期限最早最优先的原则被请求。
3.根据权利要求1所述的连续播放媒体文件的系统，其中所述的客户端用来维持所述媒体文件中被请求的部分的队列。
4.根据权利要求3所述的连续播放媒体文件的系统，其中: 所述客户端和服务器通过至少一个连接进行通信；及 所述客户端刷新媒体文件中被请求的部分的队列并响应接收到的预定的用户指令断开至少一个连接。
5.根据权利要求1所述的连续播放媒体文件的系统，其中， 所述客户端用来存储文件映射文件和数据文件； 所述映射文件包含表明所述媒体文件中已经被下载的部分的掩码；及 所述数据文件包含所述媒体文件的已下载部分。
6.根据权利要求5所述的连续播放媒体文件的系统，其中所述的数据文件是稀疏文件。
7.根据权利要求1所述的连续播放媒体文件的系统，其中: 所述媒体文件包含媒体序列和索引； 所述客户端包括: 播放引擎，用来获取所述索引并确定符合用户播放指令所需要的那部分媒体序列； 文件解析器，用来利用上述索引将所述部分媒体序列映射到所述部分媒体文件；以及 下载管理器，用来与所述媒体服务器通信并下载所述部分媒体文件。
【文档编号】H04L29/06GK103561278SQ201310430673
【公开日】2014年2月5日 申请日期:2008年1月7日 优先权日:2007年1月5日
【发明者】罗兰·奥斯伯内 申请人:索尼克知识产权股份有限公司