用于DASH的客户端/服务器信令命令的制作方法

文档序号:18481915发布日期:2019-08-20 23:50阅读:281来源:国知局
用于DASH的客户端/服务器信令命令的制作方法

由于在移动设备上越来越多地消费数字视频内容,因此多媒体流送(streaming)服务已帮助驱动新的移动宽带技术和标准的演进。许多视频流送应用被频繁地用于移动设备以用于娱乐、通信和其他目的。例如,线上视频流送由流行的服务(例如,YouTubeTM、HuluTM、NetflixTM、亚马逊即时视频TM、WatchESPNTM以及其他服务)提供。在2011年,YouTube具有超过1万亿的全球视图。这些视图的10%是经由移动电话或平板电脑来访问的。随着更多的智能电话、平板电脑和其他移动计算设备被购买,媒体服务器将面临越来越繁重的、来自多个客户端设备的流送请求的负载。随着针对多媒体服务的如此高的消费者需求以及媒体压缩和无线网络基础设施的发展,增强未来蜂窝和移动宽带系统的多媒体服务能力以及将高体验质量(QoE)递送给消费者是有意义的,从而确保从任意位置、在任意时刻、用任意设备和技术来无处不在地对视频内容和服务进行访问。

附图说明

本公开的特征和优点将从下面结合附图的具体描述中明显看出,具体描述和附图一起以示例的方式示出了本公开的特征;并且其中:

图1根据示例,示出了媒体呈现描述(MPD)元数据文件配置的框图;

图2a根据示例,示出了随时间变化的超文本传输协议(HTTP)自适应流(HAS)的示例;

图2b根据示例,示出了超文本传输协议(HTTP)流送的框图;

图3根据示例,示出了针对基于超文本传输协议(基于HTTP)的视频流送的能量特征感知无线接入网(RAN)架构的框图;

图4根据示例,示出了提供具有可用表现和可用段的MPD文件的示例的表格;

图5根据示例,示出了针对选定的服务器带宽提供可用表现代码的示例的表格;

图6根据示例,描述了能操作为提供HTTP自适应流送的服务器的计算机电路的功能;

图7根据示例,描述了能操作为提供HTTP自适应流送的移动设备的计算机电路的功能;

图8根据示例,示出了用于提供从服务器到多个客户端的多媒体的可变比特率自适应流送的方法框图;以及

图9根据示例,示出了无线设备(例如,UE)的图。

现在将参考所示出的示例性实施例,并且在本文中将使用特定的语言来描述这些示例性实施例。然而应该理解,由此并不意欲限制本发明的范围。

具体实施方式

在本发明被公开和描述之前,应该理解,本发明不限于本文所公开的特定的结构、过程步骤或材料,而是延伸到本领域的技术人员将认识到的其等同形式。还应该理解,本文所使用的术语只被用于描述特定示例的目的而并不意图是限制性的。不同图中的相同标号表示相同的元件。在流程图和过程中所提供的数字被提供用于清晰地示出步骤和操作而不必指示特定的顺序或序列。

下面提供了对技术实施例的初始概述,并且然后更详细地描述了具体的技术实施例。该初始综述旨在帮助读者更快地理解技术,而不旨在标识技术的关键特征或基本特征,也不旨在限制被要求保护的主题内容的范围。

在多媒体正被流送时,自适应多媒体流送允许相同多媒体文件的不同版本被移动设备访问。无线链路条件的改变可以减少或增加移动设备处的可用带宽。在文件被呈现于移动设备处时通过改变为多媒体文件的不同版本来“适应”的能力使得能够即使在发生带宽减小的情况下继续进行呈现。

当前的自适应多媒体流送标准和规范,包括基于超文本传输协议(HTTP)的流送服务(例如,渐进下载和HTTP动态自适应流送(DASH)),具有可以在某些情况下降低用户的体验质量的限制。

例如,当媒体服务器将由于计划维修(或一些其他原因)而离线时,客户端当前不能够事先预期。客户端可能在若干请求尚未满足并且已经发生若干缓冲事件之后不得不推断服务器已经离线。此外,客户端还可能在已经发生若干缓冲事件之后不得不推断针对媒体服务器的上传速率已经改变。任一情况可能导致减弱的客户端QoE(体验质量)。

在另一示例中,当具有所期望内容的第一媒体服务器超载时,客户端可能被迫以较慢的速率来流送内容。具有相似内容的一个或多个额外服务器可能上线。然而,客户端可能未意识到额外的服务器已经上线,因此可能继续以较慢的速率从第一服务器流送内容。相对于在客户端意识到可以从额外的服务器流送所期望的内容的情形下可获得的QoE相比,这种情况也可能导致降低的客户端QoE(体验质量)。

在另一示例中,HTTP动态自适应流送(DASH)指定媒体呈现描述(MPD)元数据文件的格式,该MPD元数据文件提供关于服务器可用的媒体内容的不同格式、版本和段(segment)的信息。当额外的内容通过服务器可获得时,MPD元数据文件可以由服务器更新。然而,在客户端明确从服务器请求MPD更新之前,在一时间段内客户端可能未意识到额外的内容是可用的。在该时间段期间,可以立即改善其QoE的客户端未享有额外内容所带来的任何益处。

在另一示例中,媒体服务器可以支持转码(transcoding)(例如,将一种编码直接转换为另一种编码以实现所期望的格式或比特率)。一些客户端通过服务器现在不可用的、但是可能使用服务器的转码功能而变得可用的媒体内容进行编码而被更好地服务。然而,这些客户端可能未意识到服务器的转码功能,并且可能因此未享有所提供的益处。

在另一示例中,当移动设备被从一个地方搬运到另一地方时,网络传输速率可能突然减小。假设移动设备已经从服务器请求表现(representation)的高比特率段,然而当前不存在自动取消对高比特率段的请求以及用针对更适合于减少的网络传输速率的更低比特率段的请求来替换对高比特率段的请求的方式。这可能导致客户端经历缓冲事件,这可能降低客户端QoE。

无线多媒体标准

存在已经被开发为使得能够执行以下操作的多个多媒体标准:向移动计算设备传达多媒体、从移动计算设备传达多媒体或者在移动计算设备之间传达多媒体。例如,在流送视频中,第三代合作伙伴计划(3GPP)已经开发了技术规范(TS)26.234(例如,发布11.0.0),其描述了分组交换流送服务(PSS),该PSS基于针对点播或实时内容的多播流送的实时流送协议(RTSP)。此外,3GPP TS 26.247(例如,发布11.0.0)中描述了基于超文本传输协议(HTTP)的流送服务,包括渐进下载和HTTP动态自适应流送(DASH)。基于3GPP的多媒体广播多播服务(MBMS)规范TS 26.346(例如,发布11.0.0)针对多播/广播内容分发规定流送和下载技术。这样,基于DASH/PSS/MBMS的移动计算设备(例如,用户设备(UE))在UE设备处解码和呈现所流送的视频。在所有这些规范中授予对3GPP TS 26.244(例如,发布11.0.0)中的3GP文件格式的支持,以支持文件下载和基于HTTP的流送用例。

以上所描述的标准作为被用来进行以下操作的无线多媒体标准的示例被提供:向多媒体设备传达多媒体文件、从多媒体设备传达多媒体文件和/或在多媒体设备之间传达多媒体文件。示例不意图是限制性的。额外的标准可以被用来提供流送视频或视频共享。

流送媒体标准

在本发明的实施例的上下文中提供了对HTTP流送和DASH标准的更详细解释。详细的解释不意图是限制性的。如将在所下面的段落中进一步解释的,本公开所描述的示例可以被用来协助可以改善DASH设置中的客户端QoE的、客户端和服务器之间的通信。

超文本传输协议(HTTP)流送递送互联网视频。在HTTP流送中,多媒体文件可以被分成一个或多个段并且使用HTTP协议被递送至客户端。由于广泛采用HTTP协议和HTTP的基础协议(包括传输控制协议(TCP)/互联网协议(IP))二者,因此基于HTTP的递送可以提供可靠性和部署简单性。基于HTTP的递送可以通过避免网络地址转换(NAT)和防火墙穿越问题来使能简化的流送服务。基于HTTP的递送或流送还可以提供使用标准HTTP服务器和缓存而不是专用流送服务器的能力。由于在服务器侧具有最少或减少的状态信息,因此基于HTTP的递送可以提供可扩展性。HTTP流送技术的示例可以包括MicrosoftTM IIS平滑流送、AppleTM HTTP实时流送和AdobeTM HTTP动态流送。

DASH是标准化的HTTP流送协议。如图1所示,DASH可以针对媒体呈现描述(MPD)元数据文件102指定不同的格式。MPD元数据文件102可以提供关于服务器上所存储的媒体内容表现的不同版本和结构(以及段格式)方面的信息。MPD元数据文件包括关于媒体播放器的初始化和媒体段的信息。由MPD元数据文件提供的该信息可以被媒体播放器用来确定容器格式和媒体时序信息。这允许媒体播放器将段映射至媒体呈现时间线以用于切换和与其他表现同步呈现。DASH技术还被其他组织(例如,运动图像专家组(MPEG)、开放IPTV论坛(OIPF)和混合广播宽带TV(HbbTV))标准化。

DASH客户端可以通过一系列HTTP请求-响应事务来下载这些段,从而接收多媒体内容。随着移动设备可用带宽改变,DASH可以提供在媒体内容的不同比特率表现之间进行动态切换的能力。因此,DASH可以允许对以下各项进行快速适应:(1)变化的网络和无线链路条件;(2)用户偏好和设备能力(例如,显示分辨率);(3)不同类型的中央处理单元(CPU);(4)不同的存储器资源等。DASH的动态自适应比其他流送协议具有更短的启动延时和更少的重缓冲事件,其可以向用户提供更好的体验质量(QoE)。

在DASH中,如图2b所示,媒体呈现描述(MPD)元数据102可以提供关于web/媒体服务器212中所存储的媒体内容表现的不同版本和结构的信息。在图1所示的示例中,MPD元数据被暂时分成具有预定长度(例如,在该示例中为60秒)的周期。每一个周期可以包括多个自适应集104。每一个自适应集可以提供与具有多个编码的替换方案的一个或多个媒体组件有关的信息。例如,在该示例中的自适应集0可以包括各种以不同方式编码的音频替换方案,例如不同的比特率替换方案、单声道、立体声或环绕立体声替换方案等。除了在周期ID中针对多媒体呈现提供不同品质的音频,自适应集还可以包括不同语言的音频。自适应集中所提供的不同替换方案被称为表现106。

在图1中,自适应集1被示为以不同的比特率(例如,5兆比特每秒(Mbps)、2Mbps、500千比特每秒(kbps)或技巧模式(trick mode))提供视频。技巧模式可以被用于查找(seeking)、快进、倒回或在多媒体流送文件中的位置中执行其他改变。此外,视频还可以用不同格式,例如二维(2D)或三维(3D)视频。每一个表现106可以包括段信息108。段信息可以包括初始化信息110和实际媒体段数据112。在该示例中,MPEG 4(MP4)文件被从服务器流送至移动设备。尽管在该示例中使用MP4,但如以上所讨论的那样可以使用各种不同的编解码。

自适应集中的多媒体还可以被分成更小的段。在图1的示例中,自适应集1的60秒视频段还被分成四个子段112,每个子段15秒。这些示例不意图是限制性的。自适应集以及每一个媒体段或子段的实际长度取决于媒体类型、系统需求、潜在的干扰类型等。实际媒体段或子段可以具有从少于一秒到几分钟长的范围的长度。

图2a提供了随时间变化的HTTP自适应流(HAS)210的示例图示。在第一30秒时段中,客户端首先获取高质量表现202的段208。该示例中的段大约为10秒长。然而,这并不意图是限制性的。段可以在服务器处被配置为任意所期望的长度。此外,子段也可以被下载。

客户端然后获取中等质量表现204中的两个段。在第二时段的10秒持续时间中,客户端再次切换并获取低质量表现206的段。由于与多媒体服务器的无线链路质量改变,客户端可以切换到低质量表现。在第三时段的20秒持续时间中,如图2a所示,客户端切换回中等质量表现204。贯穿从在多媒体设备上操作的服务器到客户端的多媒体文件的HAS的长度,客户端可以继续请求来自选定表现的段。

如图2b所示,MPD元数据信息可以被传达至客户端220。客户端可以在移动设备上进行操作。移动设备可以是被配置为接收和显示流送媒体的无线设备。在一个实施例中,移动设备可以只执行该功能的一部分,例如接收流送媒体并且之后将其传达至另一设备或者用于呈现的显示设备。移动设备可以被配置为运行客户端220。客户端可以使用HTTP GET 240消息或一系列部分GET消息来请求这些段。客户端可以控制流送会话,例如,通过管理即时请求以及使段序列播放流畅,或者通过调整比特率或其他属性以对无线链路、设备状态或用户偏好的改变做出反应来控制。

图2b示出了基于DASH的流送框架。web/媒体服务器212中的媒体编码器214可以将来自音频/视频输入210的输入媒体编码成用于存储或流送的格式。媒体分段器216可以被用来将输入媒体拆分成可以被提供给web服务器218的一系列段232。客户端220可以使用被发送至web服务器(例如,HTTP服务器)的HTTP GET消息来请求段中的新数据(234)。

例如,客户端220的web浏览器222可以使用HTTP GET消息240来请求多媒体内容。web服务器218可以向客户端提供针对多媒体内容的MPD 242。MPD可以被用来传达每个段的索引和该段对应的位置,如相关联的元数据信息中所示(252)。web浏览器可以根据MPD 242将媒体逐段地从服务器中提取出,如236中所示。例如,web浏览器能够使用HTTP GET URL(frag 1 req)244来请求第一段。统一资源定位符(URL)或全球资源定位符可以被用来告知web服务器客户端将请求哪个段(254)。web服务器可以提供第一片段(fragment)(即,段1246)。对于后续的段,web浏览器可以使用HTTP GET URL(frag i req)248来请求段i,其中i是段的整数索引。因此,web服务器可以提供段i250。段可以经由媒体解码器和/或播放器224被呈现至客户端。

图3示出了提供多媒体内容的HTTP服务器310和在移动设备(例如,UE 336)上进行操作的3GPP客户端338之间的多媒体内容312的流。HTTP服务器可以与公共或私人网络322(或互联网)进行交互,其中公共或私人网络322与无线广域网(WWAN)的核心网络324通信。在一个实施例中,WWAN可以是基于3GPP LTE的网络(例如,Rel.11或12)或者基于IEEE 802.16的网络(例如,802.16-2009或802.16m-2011)。核心网络可以经由无线接入网(RAN)332来访问无线网络330(例如,演进分组系统(EPS))。RAN可以经由节点(例如,演进节点B(eNB)334)来向在UE上进行操作的客户端提供多媒体内容。

QoE感知自适应流送

HTTP自适应流送(HAS)的体验质量(QoE)可能受托管(host)表现和对应段的一个或多个服务器影响。如之前所讨论的,当前规范假定所有服务器(基础统一资源定位符(URL))中的每一个都包括所有表现和对应的段。这意味着只具有部分内容的服务器不能被列于MPD文件中。如果具有部分内容的服务器被列于MPD文件中,则直到进行请求并且不能从特定服务器满足该请求时,客户端才能够确定那些服务器不具有某些表现或段。当发生这种情况时,由于获取丢失段所产生的延迟,客户端QoE可能锐减。

服务器可能具有有限的可操作容量。如果特定服务器超载并且不能以适当的时间帧递送内容,则服务器没有方法来通知在移动设备上进行操作的一个或多个客户端减少其从服务器的下载速率以避免可能的段检索延迟或大的丢包。

此外,服务器可能具有有限的带宽。当多个客户端共享共同的有限带宽并且为资源竞争时,可能到多个用户的若干DASH流的出现将引起拥塞并减少客户端处的回放体验。由服务器提供段的能力降低可能导致客户端处不期望的重缓冲。这尤其适用于大量客户端尝试从服务器获取相同DASH内容的情况。

由于媒体流送经常需要相对较大的带宽资源,因此媒体服务器的负载经常可能非常繁重。一种可以有助于减少媒体服务器上的负载的方法是对等辅助(peer-assisted)DASH(pDASH)。在使用对等辅助DASH的方法中,已经下载并缓存媒体内容的某些段的客户端可以向对等布置中的其他客户端提供这些段。以这种方式,客户端可以从其他客户端流送至少一些段。因为这允许客户端通过作为有限容量的辅助服务器来承担一部分负载,因此减少了媒体服务器上的负载。根据一个实施例,媒体服务器可以通知客户端:通过发送对等(P2P)缓存可用性通信可获得对等缓存和流送。对等设备之间的缓存和流送安排可以由P2P服务器确定。媒体服务器可以将基于P2P服务器标识的通信发送至客户端以便将P2P服务器的标识通知给客户端。

根据另一实施例,服务器可以修改提供给清单文件中的客户端的DASH表现集(例如,MPD)。修改可以使得服务器能够向客户端传达信息(例如,可用表现和/或段、可用服务器容量和/或可用服务器带宽或吞吐量)。客户端然后可以请求活动可用(actively available)的表现。如果具有更大容量或带宽的另一服务器不可用,则客户端可以选择不会使可用服务器容量和带宽超载的表现或段。

服务器通常传达所支持的基础URL站点,所支持的基础URL站点包括服务器互联网协议(IP)地址,例如,<Base URL>http://192.168.10.10/sintel/,/Base URE>。除了服务器IP地址,还可以包括与每一个表现相对应的二进制代码,其指示选定表现在服务器处是否可用。例如,可以使用被称为可用表现代码(ARC)的二进制代码来传达表现可用性。来自服务器的通信可以包括ARC消息,例如<Base URL arc="0011001111">http://192.168.10.10/sintel/</BaseURL>。在下面的段落中将对此进行更充分的讨论。

传达表现可用性的能力可以使得服务器能够用可用表现的经更新的二进制代码来动态地通知客户端。该二进制代码可以被服务器用来限制客户端对表现的请求,该表现将使服务器的容量和/或吞吐量负重担(tax)。客户端可以在其比特率自适应逻辑中包括经更新的二进制代码,并且只请求活动可用列表内的表现。反馈机制允许由服务器服务的客户端来决定哪一个将帮助避免服务器处的拥塞问题,从而通过减少重缓冲事件以及增加可以被传达到客户端的表现等级来增加客户端设备处的QoE。

可用表现代码

根据实施例,二进制代码(例如,ARC)可以针对清单文件(例如,MPD文件)中的每一个表现而被预确定。在一个示例中,每一ARC可以针对每一个表现分配可能为“0”或“1”的位(称为表现访问位(RAB))。在运行时,服务器可以针对正为客户端服务的流送媒体计算服务器的上传速率,并且动态地更新ARC,经更新的ARC之后被用来相应地通知每一个客户端。

ARC可以以若干不同的方式被传达。在一个示例中,ARC可以作为属性被添加至MPD中的BaseURL元素。客户端然后可以定期地请求具有经更新的ARC值的MPD。然而,频繁的MPD更新可能导致网络连接的额外开销流量。在另一示例中,ARC可以经由HTTP投递(post)请求被发送至客户端。当使用这种方法时,客户端可以实现可监听这种HTTP投递请求的简单HTTP服务器。在另一示例中,ARC可以作为正被发送至客户端的段分组的前n位(其中,n是可用表现的数量)或头部值来被添加。

段可用性代码

在pDASH布置中,参与对等设备通常不会在相同时刻缓存全部表现段。因此,传达段可用性的有效方法将是非常有用的,以便对pDASH布置中的对等流送进行组织和协调。根据另一实施例,可以使用被称为段可用性代码(SAC)的二进制代码来传达段可用性。来自服务器的这种通信可以在消息中包括SAC,例如<表现_ID>:{0|1}m,其中m是所指定的表现中的段的数量。在下面的段落中将对其进行更充分的讨论。

通过将段可用性传达至客户端,服务器可以事先通知客户端哪些段从服务器不可获得。根据该信息,若在流送期间客户端要求某一段,该段在一个服务器上不可用,则该客户端可以立即从替换服务器(在对等辅助DASH中,对等设备可以作为服务器)请求该段。这在推断段在服务器处不可用之前,排除了客户端向服务器发送若干未满足的请求(以及可能经历缓冲事件)的需要。

根据实施例,二进制代码(例如,SAC)可以针对清单文件(例如,MPD文件)中的表现的每一段而被预确定。在一个示例中,每一SAC可以针对每一段分配位(可能为0或1)。在运行时,当一个或多个段的可用性改变时,服务器可以动态地更新SAC。

图4提供了示出具有可用表现的可用段的MPD文件的示例的表格。在该示例中,MPD文件包括6个不同的表现,每一个表现被标注有从0到5的表现标识号(RepID)。每一个表现具有不同的比特率。在该示例中,如以每秒千比特(Kbits/sec)为单位所测量的,RepID 0具有最低比特率,RepID 5具有最高比特率。如图所示,每一个表现RepID还被分配以速率可用性位(RAB),其中表现RepID 0被分配给RAB5,并且RepID 5被分配给RAB0。如可认识到的,替换布置也是可能的。

由于示例MPD文件包括6个表现,因此对应的ARC可以包括6个表现访问位(RAB),包括RAB5-RAB0。在该示例实现方式中,最高有效位与具有最低比特率的表现相对应,反之亦然。该示例不意图是限制性的。多种不同类型的代码可以被用来将ARC从服务器传达至每一客户端。

此外,针对每一个不同的表现,存在标注从0至19的段标识号(SegID)的20个不同的段。在该示例中,如图所示,每一个SegID还被分配以段可用性位(SAB),其中SegID 0被分配至SAB0。由于示例MPD文件中所描述的每一个表现包括20个段,因此与每一个表现相对应的SAC可以包括20个位(例如,SAB),包括SAB0至SAB19。SAB值为0表示对应的段不可用,而SAB值为1表示对应的段可用。SegID至SAB的替换映射也是可能的,同样,位值到段可用性的替换映射也是可能的,该示例不意图是限制性的。此外,如上所示,许多不同数量的段是可能的,20个段被用于该非限制性示例以防止图4过大或过难理解。

图5提供了被用来示出服务器处选定可用带宽速率的ARC代码的示例表格。由此可见,针对服务器处的每一个表现,当对应的可用表现位被设置为选定的二进制值(例如,“0”)时,禁用客户端进行表现访问。当可用表现位被设置为相反的二进制值(例如,“1”)时,使能表现访问。这允许每一客户端知道哪些表现对客户端是可用的。

在上述段的示例中,代码被用来传达哪些表现在服务器处可获得。代码在每一MPD文件中被传达。然而,基于HAS系统中服务器带宽或服务器容量多快发生改变,代码可以采用其他方式以期望的频率被传达。

在另一示例中,在流送会话期间,服务器和客户端可以执行一系列通信和其他操作以增加每一客户端的QoE。服务器可以从每一客户端接收反馈信息以计算分配给每一用户的带宽。反馈信息可以包括HAS会话期间由用户所感知的平均质量和由客户端所经历的重缓冲事件的数量。在一个实施例中,由用户感知的质量可以是预计算的质量因素,该预计算的质量因素与每一段相关联并粗略估计将实现的平均意见得分(MOS)。该预计算的质量因素可以被包括在清单文件(例如,MPD)中。用于带宽分配的算法还将在下述段落中被进一步讨论。

服务器可以动态地修改ARC,以使得一个或多个客户端的下载速率不超过服务器所支持的最大带宽速率或者特定客户端所支持的最大速率。服务器然后可以通过对用户HTTP请求的响应来将经更新的ARC发送至用户。传达ARC信息的示例包括:发送清单文件(例如,MPD)中的ARC信息、发送定制HTTP头部中的ARC信息、经由不同于用来传达HAS的无线信道的另一无线信道来发送ARC信息、经由更高层信令来发送ARC、经由HTTP投递请求来发送ARC、或者通过将ARC附加至被发送给客户端的段分组来发送ARC。当进行随后的请求时,客户端然后可以接收ARC并将该信息用于客户端比特率自适应算法中。

此外,存在可以帮助改进客户端QoE的多个其他类型的通信。如上所述,服务器可以更新与某一媒体内容相对应的ARC。由于服务器试图将多个客户端的QoE最大化,因此可能由于各种原因发生这种ARC更新。例如,如果网络流量对服务器太繁重以不能将最高比特率的表现流送至所有客户端,则服务器可以使最高比特率的表现不可用来减轻客户端之间的任何QoE不平衡。另一方面,如果服务器上负载减少,则服务器可以再次使得表现可用。不论哪种情况,ARC都将被更新以表示表现的已改变的可用性。当发生这种更新时,服务器可以将ARC-改变通信发送至一个或多个客户端,以通知客户端ARC已发生改变。客户端然后可以立即发送针对ARC的更新版本的请求。

在另一示例中,在流送会话期间,服务器处的MPD文件可以被更新。例如,该更新可指示可用表现的改变或者对一个或多个表现可用的段的改变。服务器可以向多个客户端发送指示MPD文件已改变的MPD-改变通信。客户端然后可以立即请求MPD文件的更新版本而不是根据一些预定的定期安排来等待进行请求。MPD文件的更新版本可以向客户端提供使能增加客户端QoE的信息。例如,经更新的MPD文件可指示具有更高比特率的新表现对于当前客户端正流送的媒体内容是可用的。客户端可以立即请求随后的段从具有更高比特率的新表现中选择。

在另一示例中,服务器可以向多个客户端发送指示媒体服务器将在指定时间离线的服务器可用性通信。接收该通信的客户端进而可以使用该信息来以若干种方式调整其操作。例如,如果对服务器的请求在指定时间之前还未满足,则客户端可以在到达指定时间时立即将请求发送至替换服务器。此外,客户端可以立即将任意随后的请求发送至替换服务器。在这两种情况下,客户端将会被提前告知:等待来自服务器的将被满足的请求是徒劳的。

在另一示例中,在流送会话期间,服务器可以(例如,响应于不同的加载条件)调整其上传速率。当服务器进行这种调整时,服务器可以向多个客户端发送指示上传速率已经改变的上传-速率通信。当观测到流送性能改变时,这种情况不需要客户端等待并最终推断上传速率已经改变。因此,客户端可立即以若干方式来调整其操作。例如,如果上传速率已经减小,则客户端可以立即选择请求来自具有更低速率的表现的随后的段,以避免缓冲事件。另一方面,如果上传速率已经增加,则客户端可以请求来自具有更高速率的表现的随后的段。

在另一示例中,在流送会话期间,第一服务器可以接收如下通知:具有与服务器处的MPD文件一样的至少一个表现的第二服务器最近已经离线。第一服务器然后可以向多个客户端发送新-服务器通信,该新-服务器通信指示了第二服务器可用作客户端可以从其流送期望的媒体内容的替换服务器。客户端然后可以做出或是继续从第一服务器流送所期望的内容或是开始从第二服务器流送所期望的内容的知情决定。例如,已经经历了与第一服务器的较低传输速率的客户端可以立即选择开始从第二服务器进行流送,以便以更快的传输速率来接收所期望的媒体内容。

在一些情况下,客户端设备可以受益于接收编码中的媒体内容,该编码在媒体服务器上不是立即可用的,但是其可以由媒体服务器通过进行转码来提供。例如,客户端设备可能具有有限的存储容量,并且因此可以受益于使得文件大小减小。客户端设备还可以不支持媒体服务器上用来存储媒体内容表现的任意格式。为了处理这些类型的问题,媒体服务器可以提供转码能力,从而一种编码可以被直接转换成另一种编码。可以使用许多不同的转发方法(例如,恒定比特率(CBR)转码、可变比特率(VBR)转码和双通(2-pass)可变比特率(双通VBR)转码)。在DASH上下文中,媒体服务器可以将转码-能力通信发送至多个客户端,以通知客户端媒体服务器能够对DASH媒体内容进行转码。媒体服务器还可以向多个客户端发送转码-支持通信,该转码-支持通信指示媒体服务器支持哪些具体类型的转码,包括用于转换编解码、封装格式、MIME类型、比特率、分辨率和帧率的可用配置。作为响应,(如果有的话)客户端可以发送指示客户端选择哪种类型的转码的通信。

在流送会话期间,客户端可以经历QoE的改变。为了辅助媒体服务器改善客户端QoE,客户端可以定期地向服务器发送指示平均QoE的通信。该通信可以包括与一个或多个度量(例如,平均下载速率、缓冲事件的数量和平均意见得分(MOS))有关的信息。媒体服务器可以使用这种类型的客户端反馈来动态地确定如何最好地在流送客户端之间执行负载均衡。

此外,客户端用户装置可以被配置为检测在流送会话期间UE何时经历QoE的改变。当已发生这种改变时,客户端UE可以被配置为自动发送针对新表现段的请求,部分地基于所检测的QoE改变来选择该段。例如,如果QoE已因为下载速率降低而改变,则UE可以以更低的比特率来请求新段,以使得不大可能发生缓冲事件。另一方面,如果下载速率已经增加,则UE可以以更高的比特率来请求新段。此外,UE还可以被配置为针对在新段的请求之前被请求的任意下载自动向媒体服务器发送取消请求。这使得媒体服务器能够立即停止发送任意之前所请求的段。

在对等辅助DASH(pDASH)设置中,客户端UE还可以发送指示UE是否支持对等(P2P)流送模式的P2P缓存可用性通信。P2P服务器可以从多个UE接收这种类型的通信,并且相应地针对对等设备来设计缓存和流送安排。

在媒体服务器提供转码服务的情况下,UE还可以被配置为向媒体服务器发送DASH表现-推荐通信,该DASH表现-推荐通信指示针对UE推荐哪种编解码、封装、MIME类型、比特率、分辨率和/或帧率格式。这可以使得媒体服务器能够选择适合于UE的表现和表现段。

如图6的流程图所示,图6示出了能操作为执行以下各项的媒体服务器的计算机电路的功能600:提供超文本传输协议(HTTP)自适应流送以及向客户端发送不同类型的通信。如在610,媒体服务器可以向多个客户端发送指示媒体服务器将在指定时刻离线的服务器-可用性通信。如在620,媒体服务器可以向多个客户端发送指示针对媒体服务器的上传速率改变的上传-速率通信。如在630,媒体服务器可以向多个客户端发送指示具有与媒体服务器处的MPD文件一样的至少一个表现的新服务器何时变得可用的新-服务器通信。如在640,媒体服务器可以向多个客户端发送指示媒体服务器处的MPD文件何时进行了至少一次改变的来自媒体服务器的媒体呈现描述(MPD)MPD-改变通信。这些消息中的一个或多个可以根据需要被发送。不同类型的消息还可以以任意顺序被发送。在一个示例中,媒体服务器可以具有还被配置为将可用表现代码(ARC)与媒体服务器上可用的表现相关联的电路。ARC可以包括二进制串,其中每一位与媒体服务器上可用的表现相对应。在一些实施例中,ARC中位值为1可以表示与该位相对应的表现可用。ARC中的一个或多个位可以经由HTTP投递请求被发送至客户端。ARC还可以被附加到被发送至客户端的段分组中或者被包括在段分组的头部中。ARC还可以作为属性被包括在MPD元文件中。此外,媒体服务器还可以具有被配置为无论何时ARC发生改变都自动向多个客户端发送ARC-改变通信的电路。

在另一示例中,媒体服务器可以具有被配置为将段可用性代码(SAC)与媒体呈现描述(MPD)元文件相关联的电路。SAC可以包括二进制串,其中每一位与关联于MPD元文件的表现中的段的可用性相对应。在一些实施例中,SAC中位值为1可以表示与该位相对应的段可用。

在另一示例中,媒体服务器可以具有被配置为执行以下操作的电路:向多个客户端发送指示P2P缓存和流送是否可用的对等(P2P)缓存可用性通信。此外,媒体服务器可以具有被配置为执行以下操作的电路:向多个客户端发送指示P2P服务器标识的P2P-服务器-标识通信,该P2P服务器负责管理对等设备之间的缓存和流送安排。

如图7的流程图所示,图7示出了能操作为执行以下各项的媒体服务器的计算机电路的功能700:提供超文本传输协议(HTTP)自适应流送以及向客户端发送若干不同类型的转码通信。如在710,媒体服务器处的计算机电路可以被配置为向客户端发送指示媒体服务器能够对HTTP动态自适应流送(DASH)媒体内容进行转码的转码-能力通信。如在720,媒体服务器处的计算机电路还可以被配置为向客户端发送指示媒体服务器所支持的转码类型的转码-支持通信。转码-支持通信可以包括用于转换编解码、封装格式、MIME类型、比特率、分辨率和帧率的可用配置。转码-支持通信还可以指示媒体服务器是否支持恒定比特率(CBR)转码、可变比特率(VBR)转码和双通可变比特率(双通VBR)转码。如在730,媒体服务器处的计算机电路还可以被配置为从客户端接收指示由客户端选定的转码类型的通信。如在740,媒体服务器可以向客户端发送具有选定转码内容的DASH媒体内容。

如图8的流程图所示,图8示出了能操作为执行以下各项的UE的计算机电路的功能800:使用超文本传输协议(HTTP)自适应流送以及与媒体服务器通信。如在810,UE处的电路可以被配置为检测UE何时经历所接收的流送媒体的体验质量(QoE)的改变。如在820,UE处的电路还可以被配置为向媒体服务器发送针对DASH表现中的新段的请求。如在830,UE处的电路还可以被配置为向媒体服务器发送针对在对新段的请求之前所请求的段下载的取消请求,以使得媒体服务器能够停止发送在针对新段的请求之前所请求的段下载。

在另一示例中,UE处的电路还可以被配置为向媒体服务器发送指示UE是否支持对等(P2P)流送模式的P2P缓存可用性通信。UE处的电路还可以被配置为向服务器发送QoE通信,该QoE通信指示在对媒体服务器的流送事件期间所接收的流送媒体的平均体验质量。UE处的电路还可以被配置为向媒体服务器发送DASH表现-推荐通信,该DASH表现-推荐通信指示针对UE推荐哪种编解码、封装、MIME类型、比特率、分辨率和/或帧率格式。UE处的电路还可以被配置为:当用户执行与流送媒体相关联的查找操作时自动地发送针对DASH表现中新段的请求以及取消请求。UE处的电路还可以被配置为:当流送媒体的QoE低于阈值时自动地发送针对DASH表现中新段的请求以及取消请求。

图9提供无线设备(例如用户设备(UE)、移动站(MS)、移动无线设备、移动通信设备、平板电脑、手机或其他类型的无线设备)的示例图示。无线设备可以包括一个或多个天线,该一个或多个天线被配置为与节点或传输站(例如,基站(BS))、演进的节点B(eNB)、基带单元(BBU)、远程无线电头(RRH)、远程无线电设备(RRE)、中继站(RS)、无线电设备(RE)、远程无线电单元(RRU)、中央处理模块(CPM)或其他类型的无线广域网(WWAN)接入点进行通信。无线设备可以被配置为使用包括3GPP LTE、WiMAX、高速分组接入(HSPA)、蓝牙和WiFi的至少一个无线通信标准进行通信。无线设备可以针对每个无线通信标准使用单独的天线或针对多个无线通信标准使用共享的天线进行通信。无线设备可以在无线局域网(WLAN)、无线个人区域网(WPAN)和/或WWAN中进行通信。在移动无线设备的示例被提供的同时,设备不必需要是无线的。有线的设备也可以用于HAS。

图9还提供了可以用于来自无线设备的音频输入和输出的一个或多个扬声器和麦克风的图示。显示屏可以是液晶显示(LCD)屏或其他类型的显示屏(例如,有机发光二极管(OLED)显示器)。显示屏可以被配置为触摸屏。触摸屏可以使用电容性、电阻性或另一类型的触摸屏技术。应用处理器和图形处理器可以被耦合到内部存储器以提供处理和显示能力。非易失性的存储器端口还可以被用来向用户提供数据输入/输出选项。非易失性的存储器端口还能够被用来扩展无线设备的存储容量。键盘可以与无线设备集成或者被无线地连接到无线设备以提供额外的用户输入。使用触摸屏还可以提供虚拟键盘。

各种技术或其某些方面或部分可以以在有形介质中实现的程序代码(即,指令)的形式,有形介质例如是,软盘、光盘只读存储器(CD-ROMs)、硬盘驱动器、非暂态计算机可读存储介质或任意其他机器可读存储介质,其中,当程序代码被载入机器(例如,计算机)并且被其执行时,机器成为用于实现各种技术的装置。电路可以包括硬件、固件、程序代码、可执行代码、计算机指令和/或软件。非暂态计算机可读存储介质可以是不包括信号的计算机可读存储介质。在程序代码在可编程计算机上执行的情况下,计算设备可以包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备和至少一个输出设备。易失性和非易失性的存储器和/或存储元件可以是随机存取存储器(RAM)、可擦除可编程只读存储器(EPROM)、闪存驱动器、光学驱动器、磁硬盘驱动器、固态驱动器或者用于存储电子数据的其他介质。节点和无线设备还可以包括收发机模块(即,收发机)、计数器模块(即,计数器)、处理模块(即,处理器)和/或时钟模块(即,时钟)或计时器模块(即,计时器)。可以实现或使用本文所描述的各种技术的一个或多个程序可以使用应用程序接口(API)、可重用控制等。这些程序可以以高级程序上或面向对象的编程语言来实现以与计算机系统进行通信。然而,如果需要,则(一个或多个)程序可以以汇编或机器语言的形式来实现。在任何情况下,语言都可以是经编译或经翻译的语言,并且可以与硬件实现相结合。

应该理解,该说明书中所描述的许多功能单元已经被称为模块以便更特别地强调其实现独立性。例如,模块可以作为硬件电路而被实现,该硬件电路包括自定义超大规模集成(VLSI)电路或门阵列、现有(off-the-shelf)的半导体(例如,逻辑芯片)、晶体管或其他离散组件。模块还可以在可编程硬件设备(例如,现场可编程门阵列、可编程阵列逻辑、可编程逻辑设备等)中被实现。

模块还可以在用于被各种类型的处理器执行的软件中被实现。例如,可执行代码的被标识的模块可以包括计算机指令的一个或多个物理或逻辑块,例如,其可以被组织为对象、程序或功能。然而,被标识模块的可执行文件不必在物理上被放置到一起,而是可以包括在不同位置中存储的不同的指令,当这些指令在逻辑上被结合在一起时,包括模块并且实现模块所描述的目的。

事实上,可执行代码的模块可以是单个指令,也可以是许多指令,并且甚至可以被分布在若干不同的代码段上、不同程序中以及跨越若干存储器设备。相似地,操作数据在本文中可以在模块内被标识并示出,并且可以以任意合适的形式被实现并且在任意合适类型的数据结构中被组织。操作数据可以被收集为单个数据集,或者可以被分布在不同的位置上(包括在不同存储设备上),并且可以至少部分地仅作为系统或网络上的电子信号存在。模块可以是被动的也可以是主动的,包括可操作为执行所期望的功能的代理。

贯穿该说明书,提及“示例”或“示例性”指的是结合示例所描述的具体特征、结构或特性被包括在本发明的至少一个实施例中。因此,贯穿该说明书的各个地方,短语“在示例中”或词语“示例性”的出现不必全部指代相同的实施例。

如本文所使用的,为了方便起见,多个术语、结构元件、组成元件和/或材料可以在共同的列表中被呈现。然而,这些列表应该被解释为好像列表的每个成员分别被标识为单独且唯一的成员一样。因此,在没有相反指示的情况下,不应仅基于成员出现在共同的组中而将该列表的单独成员解释为相同列表的任何其他成员的实际等同。此外,本发明的各种实施例和示例在本文中可以连同其各种组件的替换方案一起被参考。应该理解,这些实施例、示例和替换方案不被解释为彼此的实际等同形式,而是将被认为是本发明的单独和自主的表示。

此外,所描述的特征、结构或特性可以以任意合适的形式在一个或多个实施例中进行合并。在下面的说明中,提供了许多具体的细节(例如,布局示例、距离、网络示例等)以提供对本发明的实施例的全面理解。然而,本领域的技术人员应该认识到本发明可以在没有这些具体细节中的一个或多个或使用其他方法、组件、布局等的情况下被实现。在其他实例中,众所周知的结构、材料或操作没有被示出或详细地描述以避免使本发明的方面模糊。

尽管上面的示例在一个或多个特定应用中示出了本发明的原理,但对于本领域的技术人员显而易见的是,在没有发明人员的实践并且在不脱离本发明的原理和概念的情况下,可以做出实现方式的形式、使用和细节上的许多修改。因此,除了被所附权利要求限制,本发明不意图是限制性的。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1