用来从网络节点获取数字多媒体内容的系统和方法转让专利

申请号 : CN200580013083.7

文献号 : CN101099142B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 迈克尔·福斯特迈克尔·塞弗拉P·克里格·舍伍德戴维·科西巴吴伟舍克·陈托马斯·曾

申请人 : 分组视频网络技术方案有限公司

摘要 :

一种用来从网络节点获取数字多媒体内容的方案。由在数字多媒体设备上执行的客户端应用程序向该网络节点提供RTSPSET_PARAMETER消息,其中该消息包含播放列表标识符、媒体剪辑索引和对与END OF CLIP值对应的激活时间的指示中的至少一个。响应于该消息,在响应于该激活时间而确定的时间上,将来自由该播放列表标识符或该媒体剪辑索引或者这两者所标识的特定内容源的不同的内容流式传送到该数字多媒体设备。

权利要求 :

1.一种用来从网络节点获取数字多媒体内容的方法,其包括:

由在数字多媒体设备上执行的客户端应用程序生成到所述网络节点的实时流协议RTSP SET_PARAMETER消息,所述消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与“剪辑结束”值对应的激活时间的指示中的至少一个;以及由所述网络节点从由所述播放列表标识符和所述媒体剪辑索引中的至少一个所标识的特定内容源向所述数字多媒体设备传送不同的数字多媒体内容,所述传送开始于响应于对所述激活时间的所述指示而确定的时间,其中在所述网络节点将当前数字多媒体内容从先前所标识的内容源流式传送到所述数字多媒体设备的同时,响应于所述客户端应用程序生成SWITCH消息,所述客户端应用程序生成所述RTSPSET_PARAMETER消息;

其中所述先前所标识的内容源包括第一媒体剪辑,从所述第一媒体剪辑访问所述当前数字多媒体内容用于流式传送,并且所述特定内容源包括第二媒体剪辑,从所述第二媒体剪辑访问所述不同的数字多媒体内容用于流式传送,其中所述第一媒体剪辑包括与所述第二媒体剪辑不同的多媒体内容;

其中所述网络节点连续从所述第一媒体剪辑进行流式传送直到到达所述第一媒体剪辑的边界;并且

其中响应于在所述流式传送期间到达所述第一媒体剪辑的边界而开始从所述第二媒体剪辑进行流式传送。

2.一种用来从网络节点获取数字多媒体内容的方法,其包括:

由在数字多媒体设备上执行的客户端应用程序生成到所述网络节点的实时流协议RTSP SET_PARAMETER消息,所述消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与“剪辑结束”值对应的激活时间的指示中的至少一个;以及由所述网络节点从由所述播放列表标识符和所述媒体剪辑索引中的至少一个所标识的特定内容源向所述数字多媒体设备传送不同的数字多媒体内容,所述传送开始于响应于对所述激活时间的所述指示而确定的时间,其中在所述网络节点将当前数字多媒体内容从先前所标识的内容源流式传送到所述数字多媒体设备的同时,响应于所述客户端应用程序生成SWITCH消息,所述客户端应用程序生成所述RTSPSET_PARAMETER消息;

其中所述先前所标识的内容源包括第一媒体剪辑,从所述第一媒体剪辑访问所述当前数字多媒体内容用于流式传送,并且所述特定内容源包括第二媒体剪辑,从所述第二媒体剪辑访问所述不同的数字多媒体内容用于流式传送,其中所述第一媒体剪辑包括与所述第二媒体剪辑不同的多媒体内容;

其中所述网络节点紧接在从所述客户端应用程序接收到另一个SET_PARAMETER消息之后终止来自所述第一媒体剪辑的流;并且其中响应于所述网络节点终止来自所述第一媒体剪辑的流而开始从所述第二媒体剪辑进行流式传送。

3.根据权利要求1或2所述的用来从网络节点获取数字多媒体内容的方法,其中所述网络节点响应于所述RTSP SET_PARAMETER消息而向所述客户端应用程序返回标准播放时间NPT值,并且其中所述NPT值在时间顺序上对应于所述激活时间。

4.根据权利要求1或2所述的用来从网络节点获取数字多媒体内容的方法,其中所述数字多媒体设备通过有线网络、无线网络和电缆网络中的至少一个访问所述网络节点。

5.根据权利要求1或2所述的用来从网络节点获取数字多媒体内容的方法,其中所述数字多媒体设备包括以下至少一个:数字音乐播放器、数字视频播放器、计算机和能够接受流媒体的手持通信设备。

6.一种用来从网络节点获取数字多媒体内容的系统,其包括:

与在数字多媒体设备上执行的用来生成到所述网络节点的实时流协议RTSP SET_PARAMETER消息的客户端应用程序相关联的装置,所述消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与“剪辑结束”值对应的激活时间的指示中的至少一个;以及用来由所述网络节点从由所述播放列表标识符和所述媒体剪辑索引中的至少一个所标识的特定内容源向所述数字多媒体设备传送不同的数字多媒体内容的装置,所述传送开始于响应于对所述激活时间的所述指示而确定的时间,其中在所述网络节点将当前数字多媒体内容从先前所标识的内容源流式传送到所述数字多媒体设备的同时,响应于所述客户端应用程序生成SWITCH消息,所述客户端应用程序生成所述RTSPSET_PARAMETER消息;

其中所述先前所标识的内容源包括第一媒体剪辑,从所述第一媒体剪辑访问所述当前数字多媒体内容用于流式传送,并且所述特定内容源包括第二媒体剪辑,从所述第二媒体剪辑访问所述不同的数字多媒体内容用于流式传送,其中所述第一媒体剪辑包括与所述第二媒体剪辑不同的多媒体内容;

其中所述网络节点连续从所述第一媒体剪辑进行流式传送直到到达所述第一媒体剪辑的边界;并且

其中响应于在所述流式传送期间到达所述第一媒体剪辑的边界而开始从所述第二媒体剪辑进行流式传送。

7.一种用来从网络节点获取数字多媒体内容的系统,其包括:

与在数字多媒体设备上执行的用来生成到所述网络节点的实时流协议RTSP SET_PARAMETER消息的客户端应用程序相关联的装置,所述消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与“剪辑结束”值对应的激活时间的指示中的至少一个;以及用来由所述网络节点从由所述播放列表标识符和所述媒体剪辑索引中的至少一个所标识的特定内容源向所述数字多媒体设备传送不同的数字多媒体内容的装置,所述传送开始于响应于对所述激活时间的所述指示而确定的时间,其中在所述网络节点将当前数字多媒体内容从先前所标识的内容源流式传送到所述数字多媒体设备的同时,响应于所述客户端应用程序生成SWITCH消息,所述客户端应用程序生成所述RTSPSET_PARAMETER消息;

其中所述先前所标识的内容源包括第一媒体剪辑,从所述第一媒体剪辑访问所述当前数字多媒体内容用于流式传送,并且所述特定内容源包括第二媒体剪辑,从所述第二媒体剪辑访问所述不同的数字多媒体内容用于流式传送,其中所述第一媒体剪辑包括与所述第二媒体剪辑不同的多媒体内容;

其中所述网络节点紧接在从所述客户端应用程序接收到另一个SET_PARAMETER消息之后终止来自所述第一媒体剪辑的流;并且其中响应于所述网络节点终止来自所述第一媒体剪辑的流而开始从所述第二媒体剪辑进行流式传送。

8.根据权利要求6或7所述的用来从网络节点获取数字多媒体内容的系统,其中所述网络节点包括用来响应于所述RTSPSET_PARAMETER消息而向所述客户端应用程序返回标准播放时间NPT值的装置,并且其中所述NPT值在时间顺序上对应于所述激活时间。

9.根据权利要求6或7所述的用来从网络节点获取数字多媒体内容的系统,其中所述数字多媒体设备通过有线网络、无线网络和电缆网络中的至少一个访问所述网络节点。

10.根据权利要求6或7所述的用来从网络节点获取数字多媒体内容的系统,其中所述数字多媒体设备包括以下至少一个:数字音乐播放器、数字视频播放器、计算机和能够接受流媒体的手持通信设备。

说明书 :

用来从网络节点获取数字多媒体内容的系统和方法

技术领域

[0001] 本发明一般地涉及在网络上进行媒体的流式传送。更特别地且不作任何限制地,本发明针对一种用来从客户端-服务器体系结构中的网络节点获取数字多媒体内容的系统和方法。

背景技术

[0002] 随着当今因特网作为一种主要通信媒介的广泛使用,计算机网络越来越多地被用来传输多媒体数据(例如音频、全运动(full-motion)视频、图片,等等)。在基于网络的上下文中,一种简单的产生信息的模型包括请求从服务器下载多媒体数据的客户端设备。一旦已下载下来,该客户端就可以接着使用(consume)或呈现该信息。这种模型相对容易实现;然而,它不是最优的,原因在于客户端在呈现可以开始之前需要等待下载完成。当涉及到大型多媒体数据的时候这种延迟可能相当可观。
[0003] 一种更为复杂的产生信息的模型涉及一个网络站点处的内容服务器将多媒体信息经过网络“流式传送”到另一个站点处的客户端。流式传送是这样一种处理,其中在基于网际协议(IP)的网络上发送的分组被用来在媒体材料到达时,如用户所感知的那样基本上实时地连续不断地将该媒体材料呈现给接收客户端。像这样,客户端就不必在显示材料之前先下载并存储一份大型文件。也就是说,客户端在信息到达时开始呈现该信息(也即,即时呈递),而不用在开始呈现前等待整个数据集到达。从而,在客户端设备处,为了实时地呈现多媒体内容,所接收的数据在被客户端接收之时或者之后立即被缓存到高速缓冲存储器并被连续不断地处理。
[0004] 大多数流会话包括直播或视频点播(VOD)源,并且通常与单个内容源(也即单个VOD文件或例如视频照相机之类的单个直播源)相关联。然而,通过添加将多个源合并成单个流会话的能力,可以基于多媒体流来构建更加丰富的应用。
[0005] 最简单形式的“播放列表”就是媒体列表,其可被用来简单地管理本地内容(也即音频文件)的回放或者用来控制流媒体会话。当被用在多媒体流的上下文中时,播放列表提供一种用来经由流式传送向用户递送定制的音频和视频内容的可扩展的、动态的方法。播放列表代表着服务器可流式传送到客户端的媒体项列表,其可包括例如节目内容和广告(ad)的混合。播放列表还可用来播放若干短片或用来给用户提供长节目块。
[0006] 在客户端-服务器流体系结构中,可以提供两类播放列表:客户端侧播放列表和服务器侧播放列表。这两类播放列表的主要差别在于当使用客户端侧播放列表时,客户端播放应用程序能控制流体验,而当使用服务器侧播放列表时,流服务器能控制流体验。服务器侧播放列表给流服务器提供合并(顺序地)来自多个源的流并且在单个会话内流式传送到客户端的能力。该客户端不需要(并且甚至可以不)知晓存在多个媒体源。这对于提供广告插入能力或对于这些期望(从多个源)进行不中断的流式传送,也即其中客户端不必明确地请求从每个新的源进行流式传送式传送的应用来说是有用的。
[0007] 当利用服务器侧播放列表时的问题之一是支持动态的播放列表导航,动态的播放列表导航在给终端用户提供强制性的且有用的用户体验上具有优点。另外,由于相当多的客户端设备资源限制,必须以对客户端设备应用程序带来最小影响的方式来完成该播放列表导航功能。然而,现有的服务器侧播放列表方案不完善,原因是它们不支持对播放列表搜索的客户端侧导航控制。

发明内容

[0008] 一方面,本发明针对一种用来从网络节点获取数字多媒体内容的方法,其包括:由在数字多媒体设备上执行的客户端应用程序生成到该网络节点的实时流协议(RTSP)SET_PARAMETER(设置参数)消息,该消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与ENDOF CLIP值对应的激活时间的指示中的至少一个;以及由网络节点从由播放列表标识符和媒体剪辑索引中的至少一个所标识的特定内容源向该数字多媒体设备传送不同的数字多媒体内容,该传送开始于响应于对该激活时间的指示而确定的时间。
[0009] 另一方面,本发明针对一种用来从网络节点获取数字多媒体内容的系统,其包括:与在数字多媒体设备上执行的用来生成到网络节点的RTSP SET_PARAMETER消息的客户端应用程序相关联的装置,该消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与END OFCLIP值对应的激活时间的指示中的至少一个;以及用来由网络节点从由播放列表标识符和媒体剪辑索引中的至少一个所标识的特定内容源向该数字多媒体设备传送不同的数字多媒体内容的装置,该传送开始于响应于该对激活时间的指示而确定的时间。
[0010] 又一方面,本发明针对一种可用来从网络节点获取数字多媒体内容的数字多媒体设备,其包括:用来由在数字多媒体设备上执行的客户端应用程序生成到该网络节点的RTSP SET_PARAMETER消息的逻辑,该消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对与ENDOF CLIP值对应的激活时间的指示中的至少一个;以及可用来回放来自由播放列表标识符和媒体剪辑索引中至少一个所标识的特定内容源的流内容的播放器引擎,该流内容开始于响应于该对激活时间的指示而确定的时间。
[0011] 又一方面,本发明针对一种可用来将数字多媒体内容流式传送到数字多媒体设备的网络节点,其包括:数字多媒体内容的存放器,该数字多媒体内容被组织成任意数目的播放列表,每个播放列表包括至少一个媒体剪辑;用来处理由在数字多媒体设备上执行的客户端应用程序向网络节点传输的RTSP SET_PARAMETER消息的逻辑,该消息包含播放列表标识符、媒体剪辑索引和剪辑偏移量以及对激活时间的指示中的至少一个;以及用来将内容从由播放列表标识符和媒体剪辑索引中至少一个所标识的特定内容源流式传送到数字多媒体设备的逻辑,该流内容开始于响应于该对激活时间的指示而确定的时间附图说明
[0012] 附图被包括在说明书中并形成了说明书的一部分,以便说明本发明的一个或多个当前优选的示例性实施例。根据以下结合所附权利要求书并参考附图而进行的详细描述,可以理解本发明的各种优点和特征,其中:
[0013] 图1描绘了可以实现本发明实施例的示例性网络环境;
[0014] 图2描绘了可根据本发明实施例来操作的服务器侧媒体管理系统的示例性实施例;
[0015] 图3描绘了根据本发明的实施例的可操作为在网络环境中用来对数字多媒体内容进行流式传送的客户端-服务器配置的框图;
[0016] 图4是关于图3所示的客户端-服务器配置的操作的一方面的流程图;
[0017] 图5是关于图3所示的客户端-服务器配置的操作的另一方面的流程图;
[0018] 图6是根据本发明实施例的用来切换到服务器侧播放列表内容源的示例性SET_PARAMETER过程的流程图;
[0019] 图7描绘了根据本发明的实施例的与示例性SET_PARAMETER过程相关联的请求/响应语法结构;
[0020] 图8描绘了与用来从网络节点获取数字多媒体内容的实施例相关联的消息流程图。

具体实施方式

[0021] 现在将参考关于如何最好地完成并使用本发明的各种例子来描述本发明的实施例。贯穿整个说明书和附图的多个视图,使用同样的参考标号来表示相同的或对应的部分,其中各种单元不一定是按比例绘制的。现在参考各图并且更特别地参考图1,图1中所描绘的是可以实现本发明的实施例的示例性网络环境100。参考标号102A和102B说明了网络基础设施,其中可以包括任意的有线、无线、卫星或电缆网络配置,或者其组合,其可支持通过客户端-服务器网络体系结构将数字多媒体内容从服务器节点110传送到各种能够接受这种内容的客户端设备。在一种实现中,网络102A可包括公共分组交换网络,诸如可以经由同时包括窄带(例如拨号)和宽带(例如电缆、数字用户线或DSL,等等)接入机制的合适的接入装置来接入的因特网。作为替代,网络102A可以被实现成专用企业级内网(intranet)。无线网络102B可以被实现成无线分组数据服务网络,诸如使用基于全球移动通信系统(GSM)承载网络的蜂窝基础设施来为移动设备提供分组无线接入的通用分组无线服务(GPRS)。在另一个实现中,无线网络102B可包括任意已知的或迄今未知的第三代合作伙伴计划(也即3GPP、3GPP2,等等)网络,其可操作为通过使用包括短距离无线保真(WiFi)接入点(AP)或“热点”(hot spot)等的适当的无线基础设施112来为例如移动客户端设备114之类的支持网际协议(IP)的手持设备提供服务。就像将在下面所看到的,将在不考虑网络102A、102B的任意特定的无线或有线网络实现的情况下对用来由客户端设备获取基于服务器的数字多媒体内容的本专利申请的实施例进行描述。
[0022] 虽然服务器节点110被示出为耦合到网络102A的单个节点,但是根据底层流媒体体系结构,可以将其功能分布于多个节点之中。示例性的客户端设备可以是肥客户端或瘦客户端,具有不同级别的处理能力,可操作为执行适当的流客户端应用程序,这些程序可包括Java应用程序、插件程序(plug-in),等等。客户端设备可包括一般地表示为计算机104的便携式计算机、笔记本计算机、手持计算机和桌面计算机,诸如数字音乐播放器、数字视频播放器等一般地表示为A/V组件108的能感知网络(network-aware)的音频/视频(A/V)设备,或者诸如iPodTM设备等专用多媒体设备106。另外,如同前面间接提到的,客户端设备还可包括能接受并播放数字多媒体内容的移动客户端设备(例如设备114)。
[0023] 图2描绘了根据本发明实施例的与服务器(例如服务器节点110)相关联的服务器侧媒体管理系统200的示例性实施例。该服务器侧媒体管理系统200可包括媒体管理器202和数字多媒体内容数据库204,其中该媒体管理器210控制着对该数据库204的访问。在一种实现中,该媒体管理器210从在数字多媒体设备上执行的客户端应用程序接收请求,访问该内容数据库,并返回对该客户端应用程序的响应。该数据库204优选地用作数字多媒体内容的存放器,该数字多媒体内容基于用来对该数据库204内的媒体(也即媒体项)进行分类、标识和/或描述的参数来进行组织。例如,与服务器相关联的数字多媒体内容可包含能在诸如实时流协议(RTSP)之类的合适的基于文本的协议的控制下在网络上进行流式传送的音乐文件。应当意识到,其他媒体文件可包括任意形式的数字媒体,其可包括声音文件、图片数据、电影、文本文件或能被数字地存储在计算机上的任意其他类型的媒体。从而,服务器侧播放列表可被概括为媒体集合,包括混合数字媒体的集合,每个列表包括一个或多个单独的多媒体文件或剪辑。媒体管理器202具有或者能够获得关于数据库204的信息,其例如可包括服务器的名称、正在使用的数据库的版本、所需的安全类型、服务器可用的数据库数目、是否支持非标准媒体类型、是否支持持久的标识,等等。本领域的普通技术人员应当意识到,关于数据库204的信息可以存在于单个记录文件中或者可以部分地或者全部根据需要来生成,根据需要识别各条信息。一个或多个元数据文件206包括关于可在数据库204中获得的每个媒体项的元数据。通过说明的方式,当媒体项是歌曲时,元数据可包括例如歌曲的名字或标题、标识号码、持久的标识号码、艺术家、专辑、歌曲的大小、歌曲的格式、所需比特率以及可能依赖于媒体类型的任意其它适当信息。视频文件可具有另外的字段,例如导演和制片人字段、男演员或女演员字段,等等。图片还可以不需要比特率信息。尽管一些字段可能是标准的,但其他字段却有可能专用于某种应用程序。例如,除其他与视频相关的元数据信息之外,视频信号可具有辅助音频程序(SAP)信息。
[0024] 播放列表记录208包含关于可在数据库204中获得的每个播放列表的信息,其中播放列表通常包括可具有或可不具有任何特定顺序的媒体剪辑的集合。用户可以选择通过流派、基调、艺术家、导演/制片人、听众或任意其他富有意义的配置来对媒体进行组合。尽管服务器110上的播放列表通常将只包括包含在它自己的音乐数据库204中的媒体剪辑,但是根据服务器侧媒体管理系统200的实现方式,播放列表记录208还可以包括存储在其他服务器上的多媒体剪辑或播放列表。
[0025] 图3描绘了根据本发明的实施例的可操作为在网络环境中用来对数字多媒体内容进行流式传送的示例性客户端-服务器配置300的框图,其中该服务器侧体系结构分布于多个可共同操作的模块中。本领域的普通技术人员应当认识到,该客户端-服务器配置300是涉及在上文中针对图1和图2而描述的服务器节点110和客户端设备的说明性的实现。针对经由路径316而提供的用户请求和用户反馈,在任意适当的数字多媒体设备上执行的流客户端应用程序302可操作为与Web(网络)服务器306进行交互。与客户端应用程序302相关联的是媒体播放器引擎304,其可以用软件、硬件、固件或者其任意组合来具体实现,用来回放通过流会话接收的流媒体。Web服务器306包括通过向服务器应用程序模块(AM)308进行元数据文件创建请求318来调用表示(presentation)描述的逻辑结构和功能,该服务器应用程序模块(AM)308针对特定的播放列表生成会话描述协议(SDP)文件。
一般而言,表示描述可描述一个或多个表示,其中的每个表示都保持公共的时间轴。单个表示可以包含若干媒体流,这些媒体流的描述包括编码信息、语言和使客户端应用程序能够选择最合适的媒体组合的其他参数。当涉及多个媒体流时,它们可以位于不同的媒体服务器上;例如为了分担负载,可将音频流和视频流分到多个服务器上。
[0026] 通过示例的方式,与内容数据库312和本地内容管理器(LCM)314相关联的服务器流模块(SM)310代表了用来经由实时媒体递送路径324将数字多媒体流式传送到客户端播放器引擎304的媒体服务器,实时媒体递送路径324经由诸如实时传送协议(RTP)之类的传送协议来实现。由流模块经由路径322将流事件通知给服务器AM 308并且由服务器AM模块308经由路径320将流会话状态更新提供给Web服务器306。Web服务器306可操作为经由路径326针对播放列表和媒体内容管理以及播放列表标识符(例如,统一资源定位符或URL)与该LCM进行交互。
[0027] 如同上文间接提到的,可以通过诸如RTSP之类的基于文本的应用程序级协议来实现对在客户端-服务器配置300内对具有实时性质的数据(也即数字多媒体)的递送进行控制,RTSP协议可操作为控制多个数据递送会话,提供用来选择诸如用户数据报协议(UDP)信道、多播UDP信道等递送信道的装置,还提供用来基于RTP而选择数据递送机制的装置。由于本专利公开的叙述是在RTSP消息的上下文中特别地进行例示的,下面将立即给出RTSP消息的简要描述。
[0028] RTSP建立和控制诸如音频和视频之类的连续媒体的一个或多个时间同步的流,其中待控制的一组流由表示(presentation)描述来定义。不存在RTSP连接的概念;作为替代,服务器维持通常由标识符进行标记的会话。一般而言,RTSP会话不绑定到诸如传输控制协议(TCP)之类的传输级连接。在RTSP会话期间,RTSP客户端应用程序可以打开和关闭到服务器的多个TCP传送连接以发出RTSP请求。作为替代,可以使用诸如UDP之类的无连接传输协议。
[0029] “表示”是通过使用表示描述信息而被作为完整的媒体馈送呈现给客户端的含一个或多个流的一组流。在RTSP上下文中的多数情况下,这意味着对这些流的集中控制,但是并非必须这样做。表示描述包含关于表示内的一个或多个媒体流的信息,诸如编码集、网络地址和关于内容的其他信息。诸如SDP之类的其他因特网工程任务组(IETF)协议使用术语“会话”来描述正在活动的表示(1ive presentation)。表示描述可以采取若干不同格式,包括但是不局限于上文间接提到的基于SDP的会话描述格式。
[0030] 虽然通过RTSP来控制的流可使用RTP来进行数据递送,但是RTSP的操作不依赖于用于承载连续媒体的传送机制。RTSP的语法和操作与更为常见的超文本传输协议(HTTP)类似,虽然这二者之间存在若干重要的差别。例如,RTSP服务器和客户端都可发出请求,而HTTP是非对称协议,其中客户端发出请求而服务器作出响应。还有,对于RTSP,数据通常由不同的协议(例如RTP)进行带外承载。RTSP支持下面的操作:(i)从媒体服务器获取媒体;(ii)邀请媒体服务器参加会议;以及(iii)将媒体添加到现有表示。
[0031] 就整个操作而言,每个表示和媒体流可由RTSP URL来标识。例如,RTSP URL:
[0032] rtsp://media.example.com:554/twister/audiotrack标识了表示“twister”内的音频流,其可经由在到主机的端口554的TCP连接上发出的RTSP请求来控制。如先前所指出的,表示和媒体的性质由表示描述文件来定义,其可由客户端应用程序使用HTTP或以诸如电子邮件和RTSP DESCRIBE(描述)请求之类的其他方式来获得,并且可以不必存储在媒体服务器上。下表总结了RTSP方法标记(token),其表明了要对请求消息中所标识的资源执行的特定方法。
[0033] 表I
[0034]
[0035]
[0036] 无论是应用在单个流上还是应用在一组流(也即表示)上,这些方法中的每种方法通常都配备有用于进一步定义客户端-服务器配置中的RTSP事务的多个报头字段。关于这些和相关的RTSP需求的另外的细节可以在Schulzrinne等人的(日期为1998年4月的)IETF请求注解(RFC)2326,即“Real Time Streaming Protocol(RTSP)”(实时流协议)中找到,在此通过引用的方式包含其内容。
[0037] 应当意识到,RTSP的用途很多,足以通过以新参数来扩展现有方法或者通过定义被设计成用来赋予增强的功能的新方法来提供扩展。正如下面将看到的,针对诸如上面所描述的配置300之类的客户端-服务器配置内的服务器侧播放列表,本专利公开通过将附加的参数包含在适当的RTSP报头中,提供了一种实现了增强的播放列表搜索能力的新方案。
[0038] 现在参考图4,其中示出了关于图3中示出的客户端-服务器配置300的操作的一方面的流程图。Web服务器306可操作为有可能在用户注册服务(方框402)时生成初始播放列表。在一种实现中,该初始播放列表可简单地是以后才会得以定制的默认播放列表。客户端应用程序302向Web服务器306发出访问特定的播放列表的请求(方框404),于是Web服务器306向服务器应用程序模方框308上的CreateMetafile(创建元文件)服务发出对关于特定的播放列表的SDP文件的请求(方框406)。在此之后,该CreateMetafile服务向LCM 314传播该请求以请求SDP文件(方框408)。本领域的普通技术人员应当意识到,该SDP文件包含应当已经经由RTSP DESCRIBE请求而获得的数据,以及附加信息,这样客户端应用程序302就不必发出独立的RTSP DESCRIBE请求。响应于该SDP文件,LCM 314打开播放列表文件和适当的媒体文件,生成SDP信息,并且将它返回给CreateMetafile服务(方框410),CreateMetafile服务将该SDP文件传递给发出请求的Web服务器306(方框412)。随后,Web服务器306向在数字多媒体设备上执行的客户端应用程序302返回该播放列表(先前生成的)和相应的SDP文件(方框414)。客户端应用程序302将该SDP文件传递给播放器引擎304,播放器引擎304与流模块310建立流会话以便接受对所选媒体的递送(方框416)。例如,当涉及音频文件时,可以用诸如高级音频编码(AAC)、媒体音频(WMA)、MP3等多种方法对它们进行编码。
[0039] 在又一个变型中,生成SDP文件可以不涉及LCM 314。相反,CreateMetafile服务(经由RTSP DESCRIBE)直接向流服务器发出请求以接收基础SDP描述。在此之后,CreateMetafile服务对所接收的SDP描述进行修改使得其适合于客户端消费。另外,并不一定要在所有情况下都将播放列表文件与SDP文件一起递送给客户端应用程序。在客户端应用程序理解播放列表的语法的实施例中,除了SDP文件之外可以提供播放列表,藉此实现更丰富的用户体验和与客户端的交互。在客户端可能根本不能感知播放列表的情况下,将只接收SDP文件。
[0040] 图5是关于图3所示客户端服务器配置的操作的另一方面的流程图。该服务器侧模块310可操作为向播放器引擎304发送周期性的消息(例如,采用RTSP的SET_PARAMENTER(设置参数)消息),表明要切换到所选播放列表内的新媒体剪辑或者完全切换到新播放列表(方框502)。响应于此,播放器引擎304在剪辑切换消息内将定时信息传递给客户端应用程序302以协调用来向用户进行显示的媒体同步操作(方框504)。另外,客户端应用程序302还可基于用户反馈而向Web服务器306发送用户偏好的周期性更新(方框506)。响应于此,Web服务器306基于用户偏好来创建新播放列表并且将该新播放列表推送给LCM。在此之后,当请求从该新播放列表进行流式传送时,LCM返回待使用的URL(方框508)。另一方面,客户端应用程序302可操作为请求从新播放列表进行流式传送,于是Web服务器306返回该播放列表的URL并且还可以可选地返回新播放列表文件(方框510)。响应于此,该客户端应用程序302指示该播放器引擎304向该流模块310发送适当的消息以切换为从该新播放列表进行流式传送(方框512)。如在图5中所说明的,可以实现两个示例性的过程以便完成服务器侧播放列表的切换:定义SET_PARAMETER消息内的新附加参数的RTSTSET_PARAMETER方案(方框514),以及用于现有RTSP技术的PLAYLIST_PLAY(播放列表播放)扩展方案(方框516)。该PLAYLIST_PLAY扩展方案在同一天提交的(律师存档号为1285-164PCT)标题为“SYSTEM AND METHOD FOR RETRIEVINGDIGITAL MULTIMEDIA CONTENT FROM A NETWORK NODE”(用来从网络节点获取数字多媒体内容的系统和方法)的相关的共同未决、共同转让的专利申请中进行了描述,在此通过引用的方式包含其内容并且不在本专利公开中更加详细地专门详述其内容。将在以下的“具体实施方式”部分中给出包含用来控制服务器侧内容源的新附加参数的SET_PARAMETER方案。
[0041] 如先前所指出的,与服务器侧网络节点相关联的数字多媒体内容可被组织为任意数目的播放列表,每个播放列表包括多个媒体项或剪辑,其中媒体剪辑索引确定各个媒体项在播放列表内的排列。在一种典型的服务场景中,用户能够定制为访问用于回放的“信道”。最初,该用户可根据诸如基调或流派之类的分类来选择信道。通过周期性的用户反馈,该用户的偏好可被更新并且该信道成为针对每个特定用户而定制的。
[0042] 在正常的回放期间,服务器侧网络节点(也即与Web服务器相集成或相关联的流模块)可操作为无缝地打开播放列表内的每个连续的内容源文件并且无中断地连续进行流式传送,这被播放器引擎看成连续的RTP会话。参考图6,其中示出了根据本发明的实施例的用来切换到服务器侧播放列表内容源的示例性SET_PARAMETER系统和方法的流程图。客户端应用程序在提供周期性的用户反馈后的特定时间量之后请求新播放列表(方框602)。类似于上面参考图5而描述的某些操作方面,该网络节点返回新播放列表元数据文件和相关联的URL(方框604),。在此之后,客户端应用程序可操作为调用在播放器引擎上的合适的应用程序接口(API)(例如,SWITCH(切换)播放列表API)并且将该播放列表URL传递给它,以请求从该新播放列表进行流式传送(方框606)。作为响应,该播放器引擎向网络节点的流模块传送RTSPSET_PARAMETER消息,其中该消息包括播放列表URL,可选的媒体剪辑索引和剪辑偏移量,以及关于何时应该激活切换(也即激活时间或有效时间)的指示(方框608)。该流模块包括用来返回基于在SET_PARAMETER消息中收到的参数来确定的标准播放时间(NPT)值,其中NPT值提供切换为从新媒体源进行流式传送将发生的时间(方框610)。当接收到该NPT值时,该播放器引擎将它传递给该客户端播放器应用程序,使得该应用程序可适当地更新显示(方框612)。
[0043] 图7描绘了根据本发明的实施例的与示例性SET_PARAMETER过程相关联的请求/响应语法结构。参考标号702是指SET_PARAMETER形式的客户端请求,其包括参数(<播放列表url>)、(<剪辑索引>)、(<剪辑偏移量>)和(<激活>)。与相关联的END OF CLIP(剪辑结束)指示表明了切换应当在当前剪辑(也即先前已标识并且当前正进行流式传送的那个剪辑)结束时发生。参考标号704是指流模块对播放器引擎的响应,其包括参数(<剪辑ts>)。与相关联的NPT值65000是END OF CLIP指示所映射到的示例性标准播放时间值,其最终被传递到客户端播放器应用程序。按照从服务器侧到客户端的剪辑过渡通知来完成SET_PARAMETER请求706和相关联的客户端响应708。
[0044] 图8描绘了与用来使用前面给出的SET_PARAMETER过程而从网络节点获取数字多媒体内容的实施例相关联的消息流程图。通过说明的方式,通过飞速地跳转到新媒体剪辑或新服务器侧播放列表(也即动态播放列表更新或切换)来完成示例性的媒体获取。客户端播放器应用程序302和相关联的播放器引擎304被概括成数字多媒体设备802,其被部署在带有概括的服务器侧网络节点804的客户端-服务器配置中,该概括的服务器侧网络节点804包括流模块310和应用程序模块308。当从播放器应用程序302向它的播放器引擎304传播(经由合适的应用程序接口)PLAY(播放)消息806时,生成到流模块310的RTSP SETUP(建立)消息808。相关地,由播放器引擎304向流模块310传送RTSPPLAY消息810,该播放器引擎304接着实现它们之间的流数据递送会话。如所说明的,由流模块310将多个流事件报告回服务器应用程序模块308。事件812表明SETUP(建立)被处理,于是随后传播诸如PLAYLIST_START 814(播放列表开始814)、CLIP_STRAT 816(剪辑列表开始816)和CLIP_END 818(剪辑结束818)之类的事件以表明对特定媒体剪辑的流式传送。在剪辑的结束,该流模块无中断地过渡到从先前所标识的内容源的下一个剪辑进行流式传送,如由新的CLIP_START 820事件所指示。
[0045] 在继续从当前媒体剪辑进行流式传送的同时,由包括如上面所描述的新内容源参数的客户端播放器应用程序302生成SWITCH(切换)消息822。响应于此,由播放器引擎304向网络节点804的流模块310传播RTSP SET_PARAMETER消息823,以表明动态的播放列表更新或切换。根据特定的实现细节,可以连续从当前剪辑进行流式传送直到结束或者可以基本上紧接在从播放器引擎304接收到带有参数的另一RTSP SET_PARAMETER消息之后直接终止。如图8中所说明的,表明继续播放当前剪辑直到到达剪辑的边界(方框824)。同时,响应于第一个SET_PARAMETER请求823,由网络节点804生成包括NPT值的响应消息826,其被作为包括所请求的播放列表的URL、剪辑索引以及NPT值的RETURN(返回)消息828传递给播放器应用程序302。
[0046] 在到达当前剪辑的边界之后,CLIP_END事件830被通告给服务器应用程序模块308。随后,传播通报前一个播放列表的终止的事件832。事件834和事件836通报已开始从新内容源也即所请求的播放列表和其中的特定媒体剪辑进行流式传送。提供从流模块310到播放器引擎304的RTSP SET_PARAMETER请求827以及随后的从播放器引擎304到播放器应用程序302的CALLBACK(回叫)消息829以便实现剪辑过渡通告。在到达如由CLIP_END 838(剪辑结束838)所表明的新媒体剪辑的结尾之后,流模块继续从新播放列表内的下一个剪辑进行流式传送。如PLAYLIST_END 840(播放列表结束840)所示,该过程连续进行直到播放列表结束。由于流会话终止,因此相应地通报STREAM_TERMINATED(流终止)事件842。
[0047] 本领域的普通技术人员将认识到,对实现动态切换的SET_PARAMETER请求可包含对跳转到当前播放列表内的新剪辑、切换到新播放列表、跳转到新播放列表内的特定剪辑或跳转到剪辑内的偏移量的指示。如在前面的讨论中所看到的,服务器节点的流模块的行为由RTSP请求内的各种适当的报头参数的存在来控制。播放列表URL报头表明从中进行流式传送的URL,并且根据一种实现,可以在所有请求中要求保证服务器和相应的客户端之间的同步,而不管该请求是否跳转到同一个播放列表内的新剪辑。如果该剪辑索引报头丢失,那么将提供默认处理,这样该流模块就切换到所请求的播放列表的第一个剪辑。至于激活时间指示,可能的值可以是NOW(立即切换)、END OF CLIP(在当前剪辑结束时)、或END OF PLAYLIST(在当前播放列表结束时)。在又一种实现中,激活时间可以取基于时钟的任意值。
[0048] 在另一种实现中,如果流模块接收到未得到立即履行的连续的播放列表更新请求,那么所接收的最后一个请求是获得执行的那个请求。也就是说,还没有被履行的任意先前的请求将被覆盖。在示例性的场景中,考虑流模块正在从播放列表P2对剪辑C4进行流式传送,并且它接收到当C4完成后P3开始生效的播放列表更新请求。但是在C4完成前,流模块接收到关于立即跳回到播放列表P1内的剪辑C3的另一个请求。既然第一个请求还没有被满足,那么第二个请求就覆盖了先前的播放列表更新请求(其只有在从C4进行流式传送完成后才将生效)。这样,流模块立即切换到播放列表P1并且开始从C3进行流式传送。
[0049] 在又一个例子中,考虑到流模块正在从播放列表P2对剪辑C4进行流式传送,并且它接收到针对P3的播放列表更新请求。但是在C4完成前,该流模块接收到另一个更新播放列表P4的请求。在当前剪辑也即播放列表P2内的C4结束时,这些请求都将生效。因为前一个要求切换到播放列表P3的请求还没有被满足,所以当播放列表P2内的剪辑C4完成时,流模块将从播放列表P4内的第一个剪辑(C1)开始流式传送。
[0050] 基于前述详细描述,应当意识到本专利公开有利地为流客户端应用程序提供了请求流服务器节点在播放列表边界内或者跨过播放列表边界动态地进行导航的能力,该导航采取的形式有跳转到同一个播放列表内的媒体源或从另一个播放列表文件进行跳转,或者在某个剪辑内以某个偏移量进行跳转。另外,不管底层流体系结构(例如,RealMedia、Windows Media、QuickTime,等等)如何,在示例性的客户端-服务器网络配置中这种导航是可能的。此外,应当认识到,本公开的叙述可结合诸如会话启动协议(SIP)、H.323等其他客户端/服务器协议来实现。
[0051] 虽然已经参考某些示例性的实施例来描述了本发明,但是应当理解所示出和描述的本发明的各种形式仅作为示例性的实施例。因此,在不偏离由所附权利要求书限定的本发明的精神和范围的情况下,可以实现各种改变、替代和修改。