减少媒体流延迟的系统和方法

文档序号:7736772阅读:112来源:国知局
专利名称:减少媒体流延迟的系统和方法
技术领域
本发明涉及数字媒体递送,并且更具体地涉及减少媒体流延迟的系统和方法。
背景技术
现在越来越多的消费者在其家中具有到因特网的高速或宽带连接。由这些宽带连接提供的增加的带宽允许将数字电视、视频和多媒体服务递送给客户驻地(customer premise)(例如,家庭消费者)。这些服务以媒体流的形式通过网络被输运。在客户驻地, 数字媒体接收器对一个或多个媒体流进行解码。数字媒体接收器还生成供电视机或监视器显示的影像信号。向不同媒体流切换会在新的流可被解码并显示之前产生有限量的延迟。 因此,产生了减少这种延迟的需求。


参考附图可以更好地了解本公开的许多方面。附图中的组件不一定按比例绘制, 而是强调清楚地图示出本公开的原理。图1是用于减少媒体流延迟的系统和方法的一个实施例所处的语境的框图。图2是图示出在用于减少媒体流延迟的系统和方法的一些实施例中的来自图1的加速递送处理机Oiandler)的操作的流程图。图3A-3D总地包括这样的流程图,其图示出了在用于减少媒体流延迟的系统和方法的一些实施例中的来自图1的加速递送客户端的操作。图4A-4C是图示出在因频道改变事件引起的加速递送期间在图1的系统的一个实施例中的组件之间的信息交换的序列图。图5A-5C是图示出在因特技模式(trick mode)事件引起的加速递送期间在图1 的系统的一个实施例中的组件之间的信息交换的序列图。图6A-6D是图示出在因流切换事件引起的加速递送期间在图1的系统的一个实施例中的组件之间的信息交换的序列图。图7是来自图1的加速递送处理机的一个实施例的硬件框图。图8是图示出在用于减少媒体流延迟的系统和方法的一些实施例中的来自图1的加速递送客户端的操作的流程图。图9是来自图1的加速递送客户端的一个实施例的硬件框图。
具体实施例方式鍵这里公开了提供用于减少媒体流延迟的系统和方法的实施例。一个这样的实施例是一种方法,该方法包括接收对加速递送指定媒体流的请求。该方法还包括基于包括资源利用率、当前网络拥塞或它们的组合的一组因素来决定准予或拒绝加速递送请求。该方法还包括向加速递送请求响应以指示准予或拒绝的决定的响应。另一个这样的实施例是一种方法,该方法包括接收对加速递送指定媒体流的请求。该请求包括所请求的突发大小。该方法还包括至少部分地基于所请求的突发大小来决定准予或拒绝加速递送请求。该方法还包括向加速递送请求响应以这样的响应,该响应指示准予或拒绝的决定并且还指示当该决定为准予时所准予的突发大小。示例实施例图1是用于减少媒体流延迟的系统和方法的一个实施例所处的环境的框图。系统 100利用因特网协议(IP)向订户递送各种数字服务。这些服务包括但不限于电视节目、视频点播、按次计费、音乐、因特网访问、购物以及语音(即,电话)。系统100包括一个或多个媒体编码器110 ;频道改变服务器120 ;视频点播(VOD)服务器130 ;加速递送处理机140 ; 以及至少一个数字媒体接收器150。数字媒体接收器150以外的组件有时被称为“头端”或者位于头端处,尽管不限于该位置。系统100的组件通过IP网络160通信。每个编码器110获取来自电视或视频节目的广播源(例如有线电视网络或者无线广播电视台)的信号作为输入,并且输出经压缩经编码的数字媒体流。常见编码格式包括 MPEG-2、MPEG-4和VC-I,但是其它格式也被构想为在本公开的范围之内。在IPTV环境中,该数字流表示单个节目,因此该流通常包含视频基本流和音频基本流。在本公开中,术语“媒体流”或“流”是指包括视频帧、音频帧、多媒体或其任意组合的流。编码器110的输出在此被称为线性(linear)媒体流165,这是因为由编码器110 提供的广播节目是“线性的”节目以线性方式被播出。线性流165在频道改变服务器120 中被捕获并被缓冲达某一时间段以提供频道改变能力,如下面将描述的。 与编码器110输出的线性流相比,VOD服务器130的输出被称为点播或VOD媒体流 170,这是因为可以在用户请求时随机地访问节目的各个部分。数字媒体接收器150通过诸如倒带、快进、慢放、暂停等之类的各种“特技模式”播放选项来提供这种随机访问。为了支持随机访问,除了用于常规播出的流(170R)以外,VOD服务器130通常还动态地计算(在播出时)或存储(在摄取时)每个节目的一个或多个特技模式流(170T)。除了编码器110 和VOD服务器130输出的流以外,其它服务器(未示出)也可生成其它类型的流以提供各种其它服务。 线性流165和VOD流170通过网络160被发送给一个或多个数字媒体接收器150。 在一个实施例中,行进通过网络160的流包括运动图像专家组(MPEG)传输流(化)分组,而在另一实施例中,取而代之使用VC-I流。在一些实施例中,MPEG TS分组被封装在UDP分组内,UDP分组进而被封装在IP分组内。在其它实施例中,MPEG TS分组被封装在RTP分组内,RTP分组进而被封装在UDP分组内并且然后被封装在IP分组内。(使用IP分组来载运节目流通常被称为“IPTV”。)在一些实施例中,IP多播被用来将线性节目递送给数字媒体接收器150,而VOD节目使用IP单播来将流递送给数字媒体接收器150,然而还可构想出用于各种类型的节目的其它寻址模式。每个数字媒体接收器150将IPTV分组的流转换为标准模拟或数字视频信号,该信号被提供给显示器(例如,电视机或计算机监视器)以供客户观看。数字媒体接收器150 的一些实施例还提供交互特征,例如,电子节目指南(EPG)、Web浏览器或者DVR (数字视频记录器)功能。在一些实施例中,数字媒体接收器150采取连接到电视机的机顶盒(例如, 数字家庭通信终端或DHCT)的形式。在其它实施例中,数字媒体接收器150由个人计算机 (PC)实现。在另外的实施例中,数字媒体接收器150被实现为移动设备(例如,个人数字助理、移动电话、数字媒体播放器等)。各种流转换事件可以使得数字媒体接收器150接收与转换前的 (pre-transition)流不同的转换后(post-transition)流。例如,频道改变使得递送载运了被请求频道的新的流,并且特技模式请求使得在不同模式(例如,快进)中递送载运了相同内容的新的流。这两种转换是用户发起的。其它转换是网络发起的。例如,网络可以自动地转换为新的流以递送基于语境(context)或用户行为选择的广告。作为另一示例,相同内容可以作为来自不同源的新的流被递送,以便在视频点播或其它类型的内容服务器中实现负载均衡或故障恢复。在一些情况中,数字媒体接收器150并不知道新的源。流转换使得在内容可被解码并显示之前产生了一定量的延迟。若干个因素可能导致这种延迟。一个因素是缓冲延迟,其确保数字媒体接收器150中的解码器缓冲器在解码相对大的帧序列期间不会低负荷运行。在MPEG视频的情况中,该缓冲器延迟可以对应于节目时钟参考(PCR)/呈现时间戳(PTS)偏移。另一因素是图片组(GOP)延迟,其是用于使数字媒体接收器150在切换为新的流之后获取第一帧内编码帧(例如,MPEG中的I帧)的时间。当诸如前向纠错(FEC)和重传输之类的错误修复技术被使用时,附加缓冲级进一步添加了节目流切换之后的延迟。当多播被用来递送IPTV时,频道改变包括离开旧的多播群组并且加入新的多播群组。多播离开和加入处理引起了一定量的延迟。在一个实施例中,流转换事件之后的延迟通过这里描述的加速递送技术而被减少,加速递送技术是通过数字媒体接收器150中的加速递送客户端180以及通过加速递送处理机140实现的。在一些实施例中,加速递送处理机140被集成到另一硬件/软件组件中,例如频道改变服务器120或VOD服务器130中。在其它实施例中,加速递送处理机140 是单独的组件。本领域普通技术人员应当理解,在本公开的上下文中,加速递送处理机140 的功能也可以以其它方式被分布并被分布在其它组件间。如前所述,数字媒体接收器150接收流转换事件之前的一个流(转换前的流)以及流转换事件之后的另一流(转换后的流)。加速递送客户端180通过对数字媒体接收器 150处的流转换事件响应以对加速递送转换后流(这里也称为“突发”)的请求来减少流转换延迟。该请求包括所希望的突发大小,突发大小可以以各种方式来表达,例如,以帧数,或字节数,或时间单位或者其组合来表达。可以利用诸如单播或多播之类的各种IP寻址模式中的任一种来递送转换后流中的经加速部分(190)。在一些实施例中,客户端180对流转换事件本身作出响应。在其它实施例中,客户端180通过对耗尽的解码器缓冲器(其是因转换事件之后的延迟引起的)作出响应来间接地作出响应。加速部分190以比转换后流的标称速率快的速率被递送。(加速部分190在这里也可被称为“突发”)。当加速部分190的递送完成时,该转换后流的剩余部分以其标称速
6率被递送。例如,当用户从高清晰频道切换到低清晰频道时,加速递送相对于低清晰频道的标称速率而非高清晰频道的标称速率来说较快。在一些语境中,加速部分190和转换前的流具有不同的源。例如,当流转换事件是由频道改变引起的时,转换前的流(16 源自于编码器110,而转换后流(190L)的加速部分源自于频道改变服务器120。在其它语境中,转换前的流和转换后流的加速部分具有相同的源。例如,当流转换事件是视频点播特技模式请求时,转换前的正常速率流(170)和转换后流的加速部分(190V)可以源自于VOD服务器130。在这些语境中,其它信息将VOD流的加速部分190V与VOD转换前的正常速率流170相关联(例如,会话标识符或者连续序列号空间)。当接收到来自加速递送客户端180的加速递送请求时,加速递送处理机140准予或拒绝该请求。在准予的情况中,回到加速递送客户端180的讯息包括被准予的突发大小, 其可能不同于所请求的突发大小。加速递送客户端180基于加速递送是被准予还是被拒绝并且基于被准予的突发大小来适配其行为。将结合图2、3A-3D以及4A-4C更详细地描述加速递送客户端180和加速递送处理机140的操作,然而现在将呈现简要概述。在决定准予时,加速递送处理机140确定加速部分190的起始帧,然后与频道改变服务器120和/或VOD服务器130 (视情况而定)交互,以从线性流165或VOD流170中检索或生成加速部分190。注意,加速递送处理机140的一些实施例通过与频道改变服务器 120交互来减少因频道改变事件引起的延迟,一些实施例与VOD服务器130交互以减少因特技模式事件引起的延迟,而一些实施例执行这两种。当接收到加速递送中的第一帧时,加速递送客户端180指导解码器通过立即解码所缓冲的流来执行“提早开始”回放,而不是等待解码器缓冲器或(一个或多个)错误修复缓冲器填充到其通常的阈值(后者是传统技术)。将提早开始回放与降低速率的解码(“慢速播出”)或者正常速率的解码相组合,同时以较快速率从所接收到的流填充解码器和/或错误修复缓冲器(“快速填充”)。加速递送客户端180处的慢速播出与快速填充之间的选择取决于加速递送请求的结果,如将结合图2和图3A-3D进一步描述的。图2是图示出用于减少媒体流延迟的系统和方法的一些实施例中的加速递送处理机140的操作的流程图。处理200开始于块210,在块210中,加速递送处理机140接收针对指定媒体流的加速递送请求。该媒体流可以通过包括名称、统一资源定位符或统一资源标识符、IP地址和端口号等在内的多种机制来标识。在一些实施例中,该请求包括所请求的突发大小。在块220,加速递送处理机140判断是准予还是拒绝该请求。在判断该动作时,可以考虑多种因素,包括与当前资源利用率、作出请求的数字媒体接收器150所关联的权益属性(entitlement attribute)的特性以及作出请求的数字媒体接收器150上的加速递送的预期效果有关的因素。一列因素(旨在作为示例而非穷尽性列表)包括加速递送处理机140上的指示该服务器是具有服务于该请求的超额容量还是接近于用完资源的当前资源利用率。将被用来将加速递送内容发送给数字媒体接收器150的网络路径上的当前拥塞。加速递送客户端180所请求的突发大小。
用来在将内容递送给作出请求的数字媒体接收器150时强制优先对待或平等对待的诸如服务级别协定(SLA)参数之类的参数。就如下方面而言的加速递送的预期结果与加速递送请求被准予相比,如果加速递送请求被拒绝则预期会引起多少延迟。从起始帧的各种选择得到的突发的大小。服务器对用于开始加速递送的帧具有数种选择,一些较早而一些较迟。当多播被用于递送线性流165时,选择较早帧意味着要较长时间才进行加速递送,因为这样做要花费较长时间来赶上载运了新的频道的正在行进的多播流。如本领域技术人员应当明白的,可以以各种方式对这些因素进行组合、加权和均如果在块220处的决定是拒绝该请求,则处理继续到块230,在块230中,对加速递送请求的否定响应被发送给加速递送客户端180。处理200随后完成。然而,如果在块220 处的决定是准予该请求,则块240确定哪个帧将开始加速递送。在确定初始帧时,可以考虑多种因素,包括与当前资源利用率、订户的权益属性的特性以及加速递送的预期结果有关的因素。这样的因素的非穷尽列表已在上面结合块220 呈现出。在一些实施例中,被选择用于加速递送的初始帧是帧内编码帧。例如,当加速递送请求是作为频道改变事件或特技模式事件的结果而产生的时,这可以是适当的。在其它实施例中,被选择用于加速递送的初始帧是将数字媒体接收器150处的延迟时间减少目标量的帧。例如,当加速递送请求是作为从一个内容源到另一内容源的切换的结果而产生的时, 这可以是适当的。当以某一延迟时间为目标时,所选择的初始帧不必是帧内编码帧。当在块240中确定了哪个帧将开始加速递送之后,处理继续到块250,在块250中, 对加速递送请求的肯定响应被发送给加速递送客户端180。该加速递送响应包括将被提供给数字媒体接收器150的、可能与数字媒体接收器150所请求的突发大小不同的突发的大小。以在块240处选择的帧开始的加速部分190随后被提供给数字媒体接收器150(未示出)。在一些实施例中,加速部分190由加速递送处理机140直接提供给数字媒体接收器 150,而在其它实施例中,加速递送处理机140指导或指示另一组件将加速部分190提供给数字媒体接收器150。处理200随后完成。如上所述,块220和240处的决定包括加权各种因素。下面是加权因素的数个示例。作为一个示例,在期望加速递送仅将延迟减少较小的量,而加速递送处理机140具有相对低的资源利用率并且到数字媒体接收器150的路径上的网络拥塞较小的状况下,则块 220可以决定准予该请求。此外,由块240选择的第一帧可以足够早以确保缓冲器足够快地从所接收流被重新填满以避免低负荷运行,而不在数字媒体接收器150上使用慢速播出。 反之,在网络路径拥塞或者加速递送处理机140上的资源利用率接近容量的情形中,即使预期到将在数字媒体接收器150处引起大的延迟,块220也可以决定拒绝该请求。另一方面,在相同状况下,块220可以转而决定准予,同时块240选择更新近的帧内编码帧作为用于加速递送的起始点。如上所述,在块240处加速递送处理机140确定哪个帧将开始加速递送。在一些线性内容实施例中,加速递送处理机140与频道改变服务器120协作来选择转换后流的起始点,以使得转换后流的加速部分足够大以满足加速递送客户端180所请求的最小值。来自加速递送处理机140的该输入允许频道改变服务器120递送比传统频道改变服务器可以产生的加速部分更大的转换后流的加速部分。尽管传统频道改变服务器可以执行转换后流的加速递送(作为其正常改变功能的一部分),然而在没有来自加速递送处理机140的输入的情况下,转换后流的加速部分可能没有足够的大小来满足客户端作出的请求。图3A-3D总地包括一个流程图,其图示出了用于减少媒体流延迟的系统和方法的一些实施例中的加速递送客户端180的操作。转向图3A,处理300开始于块310,在块310 中,数字媒体接收器150向加速递送处理机140发送加速递送(突发)请求。在一些实施例中,加速递送请求是由于解码器缓冲器消耗(draining)到预定水平之下而被触发的。在一些实施例中,这可以是接收新的帧中的延迟的自然结果。在一些实施例中,数字媒体接收器150响应于流转换事件而清空(flush)转换前媒体流的缓冲器。加速递送请求包括所请求的突发大小。所请求的突发大小由加速递送客户端180 计算为这样的最小数据量,该最小数据量准许数字媒体接收器150中的解码器对其解码器低负荷运行缓冲器以及数字媒体接收器150内的任何错误修复缓冲器执行快速填充,同时还执行提早开始解码。快速填充和提早开始都已在上面结合图1进行了描述,将在下面进一步讨论突发大小的影响。在块315,加速递送客户端180接收指示准予或拒绝的针对该加速递送请求的响应。块320检查该响应,并且如果加速递送请求被拒绝,则处理在块325处继续(转到图:3B),在块325中,数字媒体接收器150中的解码器缓冲器从以正常速率被递送的流被填充。在块330,数字媒体接收器150中的解码器响应于第一帧内编码帧的接收而解码并呈现帧,而不等待解码器低负荷运行缓冲器或错误修复缓冲器填满(一种在这里被称为“提早开始”的技术)。为了防止低负荷运行状况,块330以比正常速率慢的速率来解码并呈现帧(一种在这里被称为“慢速播出”的技术),或者将播出延迟一时间段。在解码器以慢于缓冲器填充速率的速率消耗或根本未消耗缓冲器的情况下,随着帧被从网络接收到,在某个点处,缓冲器又填充达到其所需要的阈值。块335确定何时达到该状况,然后以正常速率开始解码/呈现。处理300随后完成。返回图3A的块320处的判定,如果加速递送请求被准予,则加速递送客户端180 在块340处进行将所准予的突发大小与所请求的突发大小相比较的另一判断。如果准予大小大于或等于请求大小,则数字媒体接收器150准备以正常播出速度进行提早开始解码。转到图3C,数字媒体接收器150开始从由加速递送处理机140递送的帧的突发中填充其缓冲器(块34 。在一些实施例中,流的加速递送部分在数字媒体接收器150的单播地址而非多播群组地址上被接收到。加速递送以快于正常速率的速率被发送。在块350, 数字媒体接收器150中的解码器在接收到第一帧内编码帧时就解码并呈现帧,而不等待解码器低负荷运行缓冲器或者错误修复缓冲器填满。这些帧以正常播出(全速)速率被解码并被呈现。然而,缓冲器填充速率快于消耗速率,因为加速递送流比正常的快,因此缓冲器随着加速递送的进行而逐渐填满。当流的加速递送部分赶上转换后流时,加速递送处理机 140停止发送,并且加速递送结束。此时,数字媒体接收器150开始从新的多播流进行接收并且以全速播出速率进行解码(块35 。处理300随后完成。返回图3A的块340处的判定,如果所准予的突发大小小于请求大小,则数字媒体接收器150准备以慢速播出进行提早解码。转到图3D,数字媒体接收器150在块360处在其单播地址而非多播群组地址上接收通过加速递送的帧,并且开始从突发填充其缓冲器。 在块365,解码器执行慢速播出下的提早开始数字媒体接收器150在接收到第一帧内编码帧时就解码并呈现帧,而不等待解码器低负荷运行缓冲器或错误修复缓冲器填满。这些帧以慢于全速播出速率的速率被解码/呈现,或者播出被延迟一时间段。由于较慢播出和较快填充的组合,缓冲器填充速率快于消耗速率,因此,缓冲器随着加速递送的进行而逐渐填满。当流的加速递送部分赶上转换后流时,加速递送处理机140停止发送,并且加速递送结束。此时,数字媒体接收器150开始从新的多播流进行接收并且以全速播出速率进行解码 (块370)。处理300随后完成。现在将结合图4A-4C以及图5A-5C的序列图进一步说明加速递送处理。这些附图组的每组形成了图示出加速递送期间的系统100中的组件之间的信息交换的序列。图 4A-4C图示出了针对多播流转换的加速递送的数据流程。图5A-5C图示出了针对单播流转换的加速递送的数据流程。图6A-6D图示出了因流切换或故障恢复引起的加速递送的数据流程。系统100中的某些连接被简化。例如,网络160未被示出,并且流被示出为设备之间的逻辑连接,中间设备被省去。图4A示出了当数字媒体接收器150被调谐到特定节目源或频道(这里为CNN)并正接收由编码器IlOA产生的线性流165A时的系统100的初始状态。在此示例中,从多播到单播的转换是因频道改变事件引起的。然而,结合图4A-4C描述的原理可被应用于其它多播到单播转换。图4B示出了与频道改变事件相关联的事件的序列。数字媒体接收器150 (通过事件410)接收指示数字媒体接收器150切换到另一节目源(这里为ESPN)的频道改变命令。 在此示例中,网络160使用IP多播来实现频道改变,因此数字媒体接收器150响应于频道改变事件410采取两组动作。动作中的一些与IP多播有关,而其它动作与加速递送有关。 本领域技术人员应当理解,这些动作的顺序可以变化。为了停止接收当前节目,数字媒体接收器150通过向IP多播路由器430发送请求 (420)、要求从与当前频道(这里为CNN)相关联的IP多播群组中被移除,来对频道改变事件410作出响应。在此示例实施例中,请求420是利用因特网群组成员协议(IGMP)离开消息来实现的。结果,IP多播路由器430停止向数字媒体接收器150递送线性流165A(载运 CNN)。在该频道改变处理中,稍后,数字媒体接收器150向IP多播路由器430发送另一请求G40),要求被添加到与新的频道(这里为ESPN)相关联的IP多播群组中。结果,网络 160开始向数字媒体接收器150递送线性流165A (载运新近被请求的ESPN)。频道改变的加速递送方面按如下这样进行。响应于频道改变事件410,数字媒体接收器150内的加速递送客户端180向加速递送处理机140发送加速递送请求450。响应于加速递送请求450,加速递送处理机140决定(在此示例中)准予该请求,并且发送包括所准予的突发大小的肯定响应460。加速递送处理机140还从频道改变服务器120检索(470) 对应的所缓冲线性节目流。这里,对应流是与由编码器IlOB产生的165B相对应的所缓冲流,因为该流与被请求的新的频道ESPN相对应。在此实施例中,加速递送处理机140指导另一组件,即,频道改变服务器120来产生并递送加速部分190给数字媒体接收器150。在其它实施例中,加速递送处理机140封装所缓冲流165B以产生加速部分190,并且将该流提供给数字媒体接收器150。如前面结合图2和图3A-3D的流程图所述的,加速递送客户端180指导解码器视情况利用经延迟、慢速或正常播出来执行加速部分190的提早解码。图4C示出了当加速递送完成时的系统100的状态。在加速部分的解码结束之前的某点处,数字媒体接收器150完成到载运新频道(ESPN)的新加入多播流(其作为线性流 165B源自于编码器110B)的转换。此时,数字媒体接收器150将加速部分190中载运的帧与多播流中载运的帧拼接起来。最后,数字媒体接收器150仅从载运被请求频道(这里为 ESPN)的多播流进行接收并解码。已经讨论了针对多播语境的加速递送的数据流程,现在将描述针对单播语境的加速递送。图5A示出了特技模式请求之前的系统100的初始状态。数字媒体接收器150接收存储在VOD服务器130上的VOD正常播放流170N形式的VOD节目。在此示例中,从一个单播流到另一单播流的转换是因特技模式请求引起的。然而,结合图4A-4C描述的原理也可应用于其它单播到单播转换。这样的转换的示例是“暂停广告”,其中,响应于用户在观看所缓冲的直播广播、视频点播节目或所记录节目的同时调用暂停功能,画中画广告被流传输给数字媒体接收器150。图5B示出了 VOD语境中的加速递送请求和响应的事件的序列。数字媒体接收器 150(通过事件510)接收指示数字媒体接收器150在快进、四倍速度模式中操作的特技模式命令。响应于特技模式事件510,加速递送客户端180向加速递送处理机140发送加速递送请求520。响应于加速递送请求520,加速递送处理机140决定(在此示例中)准予该请求,并且发送包括所准予的突发大小的肯定响应530。加速递送处理机140还指示(540) VOD 服务器130以较快速率产生并递送对应的特技模式流,来作为加速部分190。这里,对应流是所存储的VOD流170F,因为该流对应于所请求的特技模式(这里为快进、四倍速度)。在其它实施例中,该流的加速部分由加速递送处理机140提供。在另外的实施例中,另外的内容服务器在加速递送处理机140的指导下产生并递送该流的加速部分。如前面结合图2和图3A-3D的流程图所述的,数字媒体接收器150视情况利用经延迟、慢速或正常播出来执行加速部分190的提早开始解码,直到加速递送结束为止。当加速递送结束时,VOD服务器130以正常速率来递送相同内容(特技模式流170F),如图5C所
7J\ ο已经讨论了单播和多播语境中的加速递送的数据流程,现在将结合图6A-6D描述因流切换引起的加速递送。该场合涉及多个内容服务器,这多个内容服务器具有相同内容并且被布置为使得从一个内容服务器递送的流可以转而从另一内容服务器被递送。这样的配置可被用于负载均衡或者用于出故障情况中的冗余。图6A示出了包括VOD服务器130_1和VOD服务器130_2的系统100的初始状态。 在此初始状态中,数字媒体接收器150从VOD服务器130-1接收VOD正常播放流170N形式的节目。接下来,如图6B所示,VOD服务器130-2接收流切换通知610。在一些实施例中, 通知610源自于VOD服务器130-1,而在其它实施例中,通知610源自于对一组VOD服务器间的流分发进行管理的组件(未示出)。VOD服务器130-1停止向数字媒体接收器150递送VOD正常播放流170N(如图6B中的流上的“X”所指示的)。注意,切换通知610可以在递送停止之前(例如,如在经协调的切换的情况中)或者在递送停止之后(例如,如在故障转移的情况中)发生。当递送停止时,加速递送客户端180中的帧缓冲器被耗尽。因此,如图6C所示,加速递送客户端180向加速递送处理机140发送加速递送请求620。响应于620,加速递送处理机140决定(在此示例中)准予该请求,并且发送包括所准予的突发大小的肯定响应 630。加速递送处理机140还指示(640) VOD服务器130-2以加速速率产生并递送中断流。 VOD服务器130-2以较快的速率生成并递送相同内容来作为加速部分190。当加速递送结束时,VOD服务器130-2以正常速率递送相同内容,如图6D所示。图7是加速递送处理机140的一个实施例的硬件框图。加速递送处理机140包括在计算机技术领域中公知的多个组件,包括处理器710、网络接口 720、存储器730和存储装置740(例如,非易失性存储器或盘驱动器)。这些组件经由总线750相耦合。从图7中省略了说明加速递送处理机140的操作所不需要的多个传统组件。如图7所示,加速递送处理机逻辑760可以用硬件实现,或者可以作为指令驻留在存储器730中,所述指令在被处理器710执行时,实现用于减少媒体流延迟的系统和方法。 硬件实现方式包括但不限于可编程逻辑器件(PLD)、可编程门阵列(PGA)、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、片上系统(SoC)以及封装内系统(SiP)。此外,加速递送处理机逻辑760可被实现为处理器可执行软件与硬件逻辑的组合。图8是图示出用于减少媒体流延迟的系统和方法的一些实施例中的加速递送客户端180的操作的流程图。处理800开始于块810,在块810中,加速递送客户端180请求加速递送指定媒体流。在块820,对该请求的响应被接收。在块830,客户端180基于该加速递送响应中的信息来选择用于播出的源媒体流源。由各个实施例使用的适当源的示例包括不同IP流类型(例如,单播或多播)和不同组件(频道改变服务器、VOD服务器、另外的媒体内容服务器等),如前面结合图3A-3D的流程图以及图4A-4C、图5A-5C和图6A-6D的序列图所述的。在块840,来自所选源的媒体流被接收到解码器缓冲器中。在块850,以所选播出速率对来自缓冲器的流进行解码。处理800随后完成。图9是数字媒体接收器150的一个实施例的硬件框图。数字媒体接收器150包含在计算机技术领域中公知的多个组件,包括处理器910、存储器920、网络接口 930、外围输入输出(I/O)接口 940、解码器950和显示系统960。一些实施例还包括存储设备970 (例如,非易失性存储器或盘驱动器)。这些组件经由总线980相耦合。从图9中省略了说明数字媒体接收器150的操作所不需要的多个传统组件。外围I/O接口 940提供输入和输出信号,例如,来自遥控器或前面板按钮或键盘的用户输入以及前面板上的诸如LED或IXD之类的输出。网络接口 930接收流。解码器950 将进入的视频流解码为经解码视频帧的流。在一些实施例中,解码器950还执行对多个流 (例如,音频和视频)的解复用。在一些实施例中,解码器950还对经编码流进行解密。显示系统960将经解码视频帧转换为视频信号以供计算机监视器或电视机显示。如上所述,数字媒体接收器150经由网络接口 930接收数字视频流。在一些实施例中,其是局域网(LAN)接口或诸如因特网之类的广域网(WAN)接口。在其它实施例中,网络接口 930接口连接到射频(RF)网络,并且因此可以包括对经由RF网络接收的数字信号进行处理的调谐器/解调器(未示出)。如图9所示,加速递送客户端逻辑990可以用硬件实现,或者可以作为指令驻留在存储器920中,所述指令在被处理器910执行时,实现用于减少媒体流延迟的系统和方法。 硬件实现方式包括但不限于可编程逻辑器件(PLD)、可编程门阵列(PGA)、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、片上系统(SoC)以及封装内系统(SiP)。此外,加速递送客户端180可被实现为处理器可执行软件与硬件逻辑的组合。加速递送处理机140和加速递送客户端180可被体现在供指令执行系统、装置或设备使用的或者结合它们使用的任何计算机可读介质中。这样的指令执行系统包括任何基于计算机的系统、包含处理器的系统,或者可从指令执行系统取回指令并执行的其它系统。 在本公开的上下文中,“计算机可读介质”可以是可包含、存储、传输、传播或输运供指令执行系统使用或结合指令执行系统使用的程序的任何手段。计算机可读介质例如可以是但不限于系统或者基于电、磁、光、电磁、红外或半导体技术的系统。使用电技术的计算机可读介质的具体示例包括(但不限于)如下的随机存取存储器(RAM);只读存储器(ROM);以及可擦除可编程只读存储器(EPR0M或闪存)。使用磁技术的具体示例包括(但不限于)便携式计算机磁盘盒。使用光技术的具体示例包括(但不限于)致密盘(CD)和数字视频盘(DVD)。这里所图示的软件组件是在这里公开的加速递送处理机140和加速递送客户端 180的一些实施例中被选择来图示出如何在组件之间划分功能的抽象概念。功能的其它划分也是可以的,并且希望这些其它可能性落在本公开的范围内。此外,在某种程度上软件组件是按照具体数据结构(例如,阵列、列表、标志、指针、集合等)来描述的,单也可以转而使用提供类似功能的其它数据结构。软件组件在此是按照代码和数据而非参考执行该代码的特定硬件设备来描述的。 此外,在某种程度上系统和方法是用面向对象的术语描述的,然而不一定需要用面向对象的语言来实现系统和方法。而是,系统和方法可以用任何编程语言实现并且在任何硬件平台上被执行。这里提及的软件组件包括例如被封装为独立的可执行文件、库、共享库、可载入模块、驱动器或程序集的可执行代码,以及例如被封装为类的解释码。一般地,由用于减少媒体流延迟的系统和方法使用的组件在此是按照代码和数据而非参考执行该代码的特定硬件设备来描述的。此外,系统和方法可以用任何编程语言来实现并且在任何硬件平台上被执行。根据这里公开的实施例,这里的流程图、消息传送图、状态图和/或数据流程图提供了用于减少媒体流延迟的系统和方法的操作示例。替代地,这些示图可被看作描绘了由用于减少媒体流延迟的系统和方法的逻辑实现的方法示例的操作。这些示图中的块表示代码的过程、功能、模块或部分,该代码包括用于实现处理中的逻辑功能或步骤的一个或多个可执行指令。替代实现方式也被包括在本公开的范围内。在这些替代实现方式中,功能可以不按所示出或讨论的顺序执行,而是可取决于所涉及的功能基本上并发地或以逆序来执行。前面的描述是出于图示说明和描述的目的而呈现的。不意图是穷尽的或者将本公开限制于所公开的精确形式。根据以上教导,各种修改或变更也是可以的。然而,所讨论的实现方式被选择并被描述来图示出本公开的原理及其实践应用,由此使得本领域技术人员能够以各种实现方式以及通过适于所构想的特定运用的各种修改来利用本公开。当根据公正地合法地赋予所附权利要求的宽度来解释时,所有这些修改和变更落在如所附权利要求确定的本公开的范围之内。
1权利要求
1.一种方法,包括接收加速递送指定媒体流的请求;基于包括资源利用率、当前网络拥塞或它们的组合的一组因素来决定准予或拒绝加速递送请求;以及向所述加速递送请求响应以指示准予或拒绝的决定的响应。
2.如权利要求1所述的方法,还包括响应于准予的决定,以比所述指定媒体流的标称递送速率快的递送速率来递送所述指定媒体流。
3.如权利要求2所述的方法,其中,所述递送包括 将所述指定媒体流作为单播流进行递送。
4.如权利要求1所述的方法,还包括响应于准予的决定,协调所述指定媒体流的递送,递送速率比所述指定媒体流的标称递送速率快。
5.如权利要求1所述的方法,其中,所述决定包括评估所述因素中的一个或多个以判断所评估的因素支持准予该递送请求还是拒绝该递送请求,其中,所述决定是基于该评估的。
6.如权利要求1所述的方法,其中,所述决定包括评估所述因素中的一个或多个以判断所评估的因素支持准予该递送请求还是拒绝该递送请求;以及向评估结果中的每个指派权重, 其中,所述决定是基于经加权评估的。
7.一种方法,包括接收加速递送指定媒体流的请求,该请求包括所请求的突发大小; 至少部分地基于所请求的突发大小来决定准予或拒绝加速递送请求;以及向所述加速递送请求响应以指示准予或拒绝的决定以及还指示当该决定为准予时所准予的突发大小的响应。
8.如权利要求7所述的方法,其中,所述决定还基于资源利用率、当前网络拥塞或它们的组合。
9.如权利要求7所述的方法,还包括 确定用于加速递送的所准予突发大小。
10.如权利要求7所述的方法,其中,所述指定媒体流包括多个视频帧,所述方法还包括从所述多个视频帧中选择帧内编码帧作为被递送流中的第一视频帧,该选择是基于所准予突发大小、当前资源利用率、当前网络拥塞或它们的组合的;以及生成流以使得所选帧内编码帧在被递送流中作为第一视频帧出现。
11.如权利要求7所述的方法,还包括响应于准予的决定,以比所述指定媒体流的标称递送速率快的递送速率来递送所述指定媒体流。
12.如权利要求11所述的方法,其中,所述递送包括 将所述指定媒体流作为单播流进行递送。
13.如权利要求7所述的方法,还包括响应于准予的决定,协调所述指定媒体流的递送,递送速率比所述指定媒体流的标称递送速率快。
14.一种装置,包括存储器,其上存储可执行指令;以及处理器,该处理器由所述可执行指令配置来 接收加速递送指定媒体流的请求,该请求包括所请求的突发大小; 至少部分地基于所请求的突发大小来决定准予或拒绝加速递送请求;以及向所述加速递送请求响应以指示准予或拒绝的决定以及还指示当该决定为准予时所准予的突发大小的响应。
15.如权利要求14所述的装置,其中,所述处理器还被配置来基于资源利用率、当前网络拥塞或它们的组合来进行决定。
16.如权利要求14所述的装置,其中,所述处理器还被配置来 确定用于加速递送的所准予突发大小。
17.如权利要求14所述的装置,其中,所述指定媒体流包括多个视频帧,其中,所述处理器还被配置来从所述多个视频帧中选择帧内编码帧作为被递送流中的第一视频帧,该选择是基于所准予突发大小、当前资源利用率、当前网络拥塞或它们的组合的;以及生成流以使得所选帧内编码帧在被递送流中作为第一视频帧出现。
18.如权利要求14所述的装置,其中,所述处理器还被配置来响应于准予的决定,以比所述指定媒体流的标称递送速率快的递送速率来递送所述指定媒体流。
19.如权利要求18所述的装置,其中,所述处理器还被配置来将所述指定媒体流作为单播流进行递送。
20.如权利要求14所述的装置,其中,所述处理器还被配置来响应于准予的决定,协调所述指定媒体流的递送,递送速率比所述指定媒体流的标称递送速率快。
全文摘要
在一个实施例中,一种方法包括接收加速递送指定媒体流的请求。该方法还包括基于包括资源利用率、当前网络拥塞或它们的组合的一组因素来决定准予或拒绝加速递送请求。该方法还包括向加速递送请求响应以指示准予或拒绝的决定的响应。
文档编号H04L29/06GK102177691SQ200980139858
公开日2011年9月7日 申请日期2009年8月7日 优先权日2008年8月8日
发明者乔舒亚·B·伽木, 卡皮尔·沙玛, 卡罗尔·埃特·伊图拉尔德, 斯蒂格 威廉·C·威尔, 约翰·罗伯特·皮肯斯 申请人:思科技术公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1