CN107210999A - 链路感知流送自适应 - Google Patents

链路感知流送自适应 Download PDF

Info

Publication number
CN107210999A
CN107210999A CN201580063676.8A CN201580063676A CN107210999A CN 107210999 A CN107210999 A CN 107210999A CN 201580063676 A CN201580063676 A CN 201580063676A CN 107210999 A CN107210999 A CN 107210999A
Authority
CN
China
Prior art keywords
section
http
mobile device
physical layer
slope
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201580063676.8A
Other languages
English (en)
Other versions
CN107210999B (zh
Inventor
维什瓦纳思·拉马穆尔蒂
厄兹格尔·欧伊曼
穆罕默德·里恩
艾哈迈德·拉加布
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel IP Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel IP Corp filed Critical Intel IP Corp
Publication of CN107210999A publication Critical patent/CN107210999A/zh
Application granted granted Critical
Publication of CN107210999B publication Critical patent/CN107210999B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic

Abstract

公开了用于提供链路感知流送自适应的技术。在示例中，移动设备可以包括一个或多个处理器，其被配置为：处理在移动设备处从节点接收到的HTTP自适应流的清单文件；确定移动设备相对节点针对HAS的物理层有效吞吐量；标识针对HAS的段吞吐量估计；以及基于针对HAS的物理层有效吞吐量和针对HAS的段吞吐量，在清单文件中选择针对所选择的时段的表示。

Description

链路感知流送自适应
背景技术
多媒体服务(包括流服务和会话服务)的发展是新型移动宽带技术和标准演进的关键驱动因素之一。数字视频内容越来越多地用于移动设备中。在日常生活中，有许多视频应用广泛用于移动设备上。例如，在线视频流包括诸如YouTube和Hulu之类的受欢迎的服务。视频录制和视频会议包括诸如Skype和Google Hangout(谷歌环聊)之类的服务。在2013年，YouTube每天有超过10亿的移动视频观看量。随着更多的智能电话、平板计算机和其它移动计算设备被购买，这些设备在视频录制和视频会议方面的使用将显著增加。伴随消费者对多媒体服务的如此高的需求以及媒体压缩和无线网络基础设施的发展，焦点在于增强未来蜂窝和移动宽带系统的多媒体服务能力并向消费者提供高体验质量(QoE)，从而确保在任何时间、从任何位置、使用任何设备和技术无所不在地访问视频内容和服务。
附图说明
本公开的特征和优势将从下面结合附图的具体实施方式中变得显而易见，具体实施方式和附图一起通过示例的方式示出了本公开的特征；并且，其中：
图1示出了根据示例的媒体呈现描述(MPD)元数据文件配置的框图；
图2示出了根据示例的超文本传输协议(HTTP)流的框图；
图3示出了根据示例的用于基于超文本传输协议的(基于HTTP的)链路感知自适应流的无线电接入网络(RAN)架构的框图；
图4示出了根据示例的由客户端用来计算帧数目和表示等级的帧等级的图示；
图5示出了根据示例的链路感知自适应流客户端播放器状态的图示；
图6示出了根据示例的链路感知速率自适应流程图；
图7a示出了根据示例的延迟受限质量优化启动流程图；
图7b示出了根据示例的状态依赖型链路感知HAS客户端速率自适应：
图8示出了根据示例的具有替换请求特征的链路感知HAS速率自适应的流程图；
图9示出了根据示例的用于选择替换段的质量的算法的流程图；
图10描绘了其上实施有指令的计算机可读存储介质的流程图，指令在被一个或多个处理器运行时执行根据示例的用于提供超文本传输协议(HTTP)自适应流(HAS)的操作；
图11描绘了根据示例公开的用于提供HAS的方法的流程图；
图12描绘了根据示例的可操作以接收HAS的移动设备的一个或多个处理器的功能；以及
图13示出了根据示例的无线设备(例如，UE)的图示。
现在将参照所示出的示例性实施例，并且本文将使用具体语言来描述这些示例性实施例。然而，将理解的是，不意在由此限制本发明的范围。
具体实施方式
在公开和描述本发明之前，将理解的是，本发明不限于本文所公开的特定结构、处理步骤或材料，而是扩展至其等价形式，如将被相关领域的普通技术人员认识到的那样。还应该理解的是本文所采用的术语仅用于描述特定示例的目的而不意在是限制性的。不同附图中的相同标号表示相同的元件。流程图和过程中所提供的标号被提供用于清楚示出步骤和操作，而不一定指示特定的顺序或次序。
示例实施例
下文提供了对于技术实施例的初步概述，并且随后进一步详细描述了具体的技术实施例。该初步概述旨在帮助读者更快地理解技术，而既不旨在标识技术的关键特征或必要特征，也不旨在限制所要求保护的主题的范围。
超文本传输协议(HTTP)自适应流(HAS)可以用作互联网视频的多媒体传送形式。由于对HTTP和HTTP的底层协议(包括传输控制协议(TCP)/互联网协议(IP))这二者的广泛采用，基于HTTP的传送可以提供可靠性和部署简单性。基于HTTP的传送可以通过避免网络地址转换(NAT)和防火墙穿越问题来实现简单和轻松的流服务。基于HTTP的传送或流送还可以提供使用标准HTTP服务器和缓存替代专用流服务器的能力。由于服务器侧的状态信息被减少或降至最少，基于HTTP的传送可以提供可扩展性。
当使用HAS传送互联网多媒体内容时，可以将在移动设备上运行的视频客户端配置为通过使用HTTP GET或部分GET命令从视频服务器选择和请求适当的视频表示等级来在速率适配中起主要作用，以从指定的资源(例如，多媒体服务器)取回数据。视频客户端在开始播放诸如音频或视频之类的流媒体内容之前，首先将缓冲器构建到一定水平。该阶段被称为启动阶段。之后，客户端开始播放经缓冲的多媒体内容。
客户端设备处多媒体播放的质量和分辨率取决于可用的链路带宽。视频客户端通常仅基于诸如HTTP级视频流吞吐量或传输控制协议(TCP)吞吐量之类的较高层吞吐量估计来估计可用链路带宽。这类方法在追踪无线网络中发生的信道状况的快速变化方面具有限制。这些在追踪变化方面的限制可以限制速率自适应算法适应链路状况变化的能力。此外，在接收到前几个视频帧之前，无法使用较高层吞吐量估计来估计可用链路带宽。
根据本发明的一个实施例，通过使用针对HAS系统(例如，被配置为使用通过HTTP的动态自适应流(DASH)标准的系统)的物理层感知视频自适应方法，可以为无线网络中的HAS提供对可用带宽的更好的估计。该方法尤其适用于其特性随时间而波动的无线链路，这取决于物理环境以及系统上的负载。
然而，仅使用物理层吞吐量也可能具有局限性。由于传输状况的变化(例如，移动设备的位置的变化)，物理层吞吐量可能具有相对较快速的变化。
在一个实施例中，作为对传输层或应用层处的较高层估计的补充，可以基于物理层吞吐量信息来估计可用链路带宽信息。在蜂窝场景中，这类信息可以由用户设备(UE)的无线电装置提供给HAS客户端的视频自适应模块。
链路带宽信息的使用可以用作HAS中的可选特征，其中仅当满足关于链路状况、缓冲器状态或其它期望的准则的某些条件时，PHY层吞吐量才可以用于视频速率自适应。例如，当无法获得对较高层吞吐量的良好估计时，可以使用PHY层吞吐量。在流会话开始时，较高层吞吐量估计在精度方面可能受限。当无线信道状况相对快速地变化时，也可以使用PHY层吞吐量。可以设置阈值来确定使得使用物理层有效吞吐量测量来替代较高层吞吐量估计的无线信道状况的变化量。阈值等级可以基于系统设计和使用而变化。在一个实施例中，如果较高层吞吐量估计使得HAS的多个视频帧的实际吞吐量相对于使用的物理层有效吞吐量降低了超过所选择的百分比，则可以使用物理层有效吞吐量。阈值可以从小百分比(例如0.1％)变化到相对高的百分比(例如，20％或更高)，这取决于无线设备在其中操作的系统的类型。
当信道状况频繁发生变化时，例如当无线设备正在移动时，较高层吞吐量估计无法及时跟随无线链路状况的变化。通过观察物理层吞吐量随时间的趋势，可以推断出快速的无线信道变化。使用物理层吞吐量估计的能力使得多媒体播放器能够通过解决重新缓冲百分比和用户视频质量的关键性能度量，来适机地(opportunistically)适应信道波动并提高用户体验质量(QoE)。
在一个实施例中，使用基于物理层链路状况和缓冲器状态适机地调整视频速率的视频速率自适应算法，可以用于在可容忍的启动延迟下提高启动视频质量，并减少视频播放期间的重新缓冲。因此，可以显着改善用户的QoE。这将在前面的段落中进一步讨论。
无线多媒体标准
已经开发了大量能够使得多媒体被传送到移动计算设备、从移动计算设备被传送、或者在移动计算设备之间被传送的多媒体标准。例如，在流视频中，第三代合作伙伴计划(3GPP)已经开发了描述了分组交换流服务(PSS)的技术规范(TS)26.234(例如，版本11.0.0)，PSS是基于针对点播或直播内容的单播流送的实时流协议(RTSP)。此外，在3GPPTS 26.247(例如，版本11.0.0)中描述了基于超文本传输协议(HTTP)的流服务，包括渐进式下载和通过HTTP的动态自适应流(DASH)。基于3GPP的多媒体广播和多播服务(MBMS)规范TS26.346(例如，版本11.0.0)指定针对多播/广播内容分发的流送和下载技术。因此，基于DASH/PSS/MBMS的移动计算设备(例如，用户设备(UE))在UE设备处解码和渲染所流送的视频。对3GPP TS 26.244(例如，版本11.0.0)中的3GPP文件格式的支持在所有这些规范中均被强制规定，以支持文件下载和基于HTTP的流用例。
3GPP TS 26.114(例如，11.0.0)中提供了针对会话视频通信(例如，视频会议)的标准的一个示例。该标准描述了通过IMS的多媒体电话服务(MTSI)，MTSI允许通过基于互联网协议(IP)多媒体子系统(IMS)的网络传送高级多媒体会话服务和内容。IMS在3GPP TS26.140(例如，版本11.0.0)中得以标准化。基于MTSI的发送器UE终端可以捕获和记录视频，然后通过3GPP网络将视频传输到基于MTSI的接收器UE终端。然后，接收器UE终端可以对视频进行解码和渲染。3GPP TS 26.140还能够使用多媒体共享服务(MMS)进行视频共享，在MMS中提供了对3GPP文件格式的支持。
提供了上述标准作为可用于向多媒体设备传送多媒体文件、从多媒体设备传送多媒体文件、和/或在多媒体设备之间传送多媒体文件的无线多媒体标准的示例。这些示例不旨在是限制性的。其它标准也可用于提供流视频、会话视频或视频共享。
流媒体标准
本文在本发明的实施例的上下文中提供了对HTTP流(更具体地，DASH标准)的更详细说明。详细说明不旨在是限制性的。如在前面的段落中进一步解释的，本发明的实施例可以用于通过使得移动设备或与移动设备通信的服务器能够选择和/或传送具有所需能量表征的多媒体来有效地向移动设备传送多媒体、从移动设备传送多媒体、和/或在移动设备之间传送多媒体。可以使用标准化或非标准化的通信方案来传送多媒体。
超文本传输协议(HTTP)流可以用作互联网视频的多媒体传送形式。在HTTP流中，多媒体文件可以被划分成一个或多个段，并使用HTTP协议被传送给客户端。由于对HTTP和HTTP的底层协议(包括传输控制协议(TCP)/互联网协议(IP))这二者的广泛采用，基于HTTP的传送可以提供可靠性和部署简单性。基于HTTP的传送可以通过避免网络地址转换(NAT)和防火墙穿越问题来实现简化的流服务。基于HTTP的传送或流送还可以提供使用标准HTTP服务器和缓存而替代专用流服务器的能力。由于服务器侧的状态信息被减少或降至最少，基于HTTP的传送可以提供可扩展性。HTTP流技术的示例可以包括Microsoft IIS SmoothStreaming(Microsoft IIS平滑流送)、Apple HTTP Live Streaming(Apple HTTP直播流送)和Adobe HTTP Dynamic Streaming(Adobe HTTP动态流送)。
DASH是一种标准化的HTTP流协议。如图1所示，DASH可以为媒体呈现描述(MPD)元数据文件102指定不同的格式，MPD元数据文件102提供关于存储在服务器中的媒体内容表示的结构和不同版本以及段格式的信息。MPD元数据文件包含关于媒体播放器的初始化和媒体段的信息(例如，媒体播放器可以查看初始化段以确定容器格式和媒体定时信息)，以确保将段映射到媒体呈现时间线中用于切换和与其它表示同步呈现。DASH技术还已经由运动图像专家组(MPEG)、开放IPTV论坛(OIPF)和混合广播宽带电视(HbbTV)等其它组织进行了标准化。
DASH客户端可以通过经由一系列HTTP请求-响应事务下载段来接收多媒体内容。随着移动设备可用带宽的改变，DASH可以提供在媒体内容的不同比特率表示之间动态切换的能力。因此，DASH可以允许快速适应变化的网络和无线链路状况、用户偏好和设备能力(例如显示分辨率)、所采用的中央处理单元(CPU)的类型、可用的存储器资源等等。DASH的动态适应相比其它流协议具有更短的启动延迟和更少的重新缓冲事件，可以为用户提供更好的体验质量(QoE)。
在DASH中，如图2所示，媒体呈现描述(MPD)元数据102可以提供关于存储在web/媒体服务器212中的媒体内容表示的结构和不同版本的信息。可以在清单文件中传送MPD元数据。在图1所示的示例中，MPD元数据在时间上被划分为具有预定长度的时间段，例如，在该示例中为60秒。每个时间段可以包括多个适应集104。每个适应集可以提供关于具有许多编码替代方案的一个或多个媒体组件的信息。例如，该示例中的适应集0可以包括各种不同编码的音频替代方案，例如不同的比特率、单声道、立体声、环绕声等等。除了在时间段ID上提供用于多媒体呈现的不同质量的音频之外，适应集还可以包括采用不同语言的音频。在适应集中提供的不同的替代方案被称为表示106。
在图1中，适应集1被示出以不同比特率(例如，每秒5兆比特(Mbps)、2Mbps、每秒500千比特(kbps)或特技模式)提供视频。特技模式可用于寻找、快进、倒回、或对多媒体流文件中位置的其它变化。此外，视频还可以以不同的格式(例如，二维(2D)或三维(3D)视频)获得。每个表示106可以包括段信息108。段信息可以包括初始化信息110和实际的媒体段数据112。在该示例中，MPEG 4(MP4)文件从服务器被流送到移动设备。尽管在该示例中使用MP4，但是可以使用各种不同的编解码器，正如前面所讨论的。
适应集中的多媒体可以进一步被划分为更小的段。在图1的示例中，适应集1的60秒视频段进一步被划分为四个子段112，每个子段为15秒。这些示例不旨在是限制性的。适应集和每个媒体段或子段的实际长度取决于媒体的类型、系统要求、潜在的干扰类型等等。实际的媒体段或子段的长度可以为小于1秒至几分钟长。
如图2所示，MPD元数据信息可以被传送到诸如移动设备的客户端220。移动设备可以是被配置为接收和显示流媒体的无线设备。在一个实施例中，移动设备可以仅执行该功能的一部分，例如接收流媒体，然后将流媒体传送到另一设备或显示设备用于渲染。移动设备可以被配置为运行客户端220。客户端可以使用HTTP GET 240消息或一系列部分GET消息来请求段。客户端可以控制流会话(例如，管理段序列的流畅播出和接通时间(on-time)请求)、或潜在地调整比特率或其它属性)以对无线链路、设备状态或用户偏好的变化做出反应。
图2示出了基于DASH的流框架。web/媒体服务器212中的媒体编码器214可以将来自音频/视频输入210的输入媒体编码为用于存储或流送的格式。媒体分段器216可以用于将输入媒体分成一系列段(232)，这一系列段可以被提供给web服务器218。客户端220可以使用发送到web服务器(例如，HTTP服务器)的HTTP GET消息来请求段中的新数据(234)。
例如，客户端220的web浏览器222可以使用HTTP GET消息240来请求多媒体内容。web服务器218可以向客户端提供针对多媒体内容的MPD 242。MPD可以用于传达相关联的元数据信息中所示的每个段的索引和段的相应位置(252)。如236中所示，web浏览器可以根据MPD 242逐段地从服务器拉取媒体。例如，web浏览器可以使用HTTP GET URL(frag 1 req)244请求第一段。统一资源定位符(URL)或通用资源定位符可以用于告知web服务器客户端要请求哪些段(254)。web服务器可以提供第一片段(即，段1 246)。对于后续段，web浏览器可以使用HTTP GET URL(frag i req)248请求段i，其中i是段的整数索引。因此，web服务器可以提供段i 250。可以经由媒体解码器/播放器224将段呈现给客户端。
图3示出了在提供多媒体内容的HTTP服务器310至在诸如UE 336之类的移动设备上操作的3GPP客户端338之间的多媒体内容312的流。HTTP服务器可以通过接口与公共或私有网络322(或因特网)连接，公共或私有网络322(或因特网)与无线广域网(WWAN)的核心网络324通信。在一个实施例中，WWAN可以是基于3GPP LTE的网络或基于IEEE 802.16的网络(即，802.16-2009)。核心网络可以经由无线电接入网络(RAN)332访问诸如演进型分组系统(EPS)的无线网络330。RAN可以经由节点(例如，演进型节点B(eNB)334)向在UE上操作的客户端提供多媒体内容。另外，还可以在HTTP服务器与UE之间实现WLAN网络。WLAN网络可以是IEEE 802.11网络，包括、但不限于IEEE 802.11a、802.11b、802.11g、802.11n、802.11ac和802.11ad。WLAN可以经由接入点(AP)向在UE上操作的客户端提供多媒体内容。还可以使用其它类型的WLAN网络，例如Bluetooth(蓝牙)网络或其它短距离网络。
链路感知流送自适应
根据一个实施例，公开了一种具有由基站服务的多个无线视频用户的系统。虽然该系统包含多个视频客户端，但每个客户端都可以独立于其它客户端来行动。代表客户端所请求的视频的不同表示可以使用字母k进行索引。可以将值k＝1设置为表示最低比特率表示等级，并且k＝N可以表示最高表示等级。变量bk可以表征表示等级k的编码视频的比特率，其中b1≤b2≤b3≤...≤bN。
MPD中的服务器可以将MPD中不同视频表示等级的速率传送至客户端。这在多媒体的流送开始之前发生。播放过程和速率自适应可以按照视频帧持续时间τ的时间粒度进行。视频帧持续时间τ是视频帧速率Fr的倒数，即τ＝1/Fr。某视频帧持续时间被称为帧时隙。可以使用字母i对每个帧时隙进行索引。
HTTP段吞吐量
典型的较高层吞吐量估计是片段或段吞吐量，其被定义为段尺寸与段的下载时间的平均比率：
其中，Sfrag(j)、和是所请求的第j个视频片段的尺寸、下载时间和获取时间，St是直到时间t为止所请求的最新片段，以及F是用于求平均以获得稳定估计的段数目。
物理层有效吞吐量
为了使得视频速率自适应算法能够适机地适应无线电链路吞吐量的波动，可以执行对物理层有效吞吐量的估计，并且对物理层有效吞吐量的估计可用于视频速率自适应。有效吞吐量是物理级吞吐量。吞吐量是每单位时间由网络向某个目的地(例如，UE)传送的有用信息比特数。吞吐量数据不包括协议开销比特以及重传的数据分组。
如果Xi是在第i个视频帧时隙中成功接收到的比特数，则第i个帧时隙中的物理层有效吞吐量由下式给出：
第i个帧时隙中的平均物理有效吞吐量是过去的T个帧时隙上的物理层有效吞吐量的平均值，即：
平均PHY层有效吞吐量还可以被定义为在某一时间段期间接收到的比特数与该时间段的持续时间的比率：
其中，X(t)是直到时间t为止接收到的比特数，T是反馈的持续时间，以及TRx≤T是子持续时间，在子持续时间期间UE期望数据。对平均物理层有效吞吐量的估计通常涉及与物理层的协作。例如，可以由PHY层针对由PHY层接收的每个数据突发计算该估计，并通过API(应用程序接口)周期性地向应用层报告该估计。
使用较高层的吞吐量测量
传统上，TCP或应用层处的较高层吞吐量估计已被用于针对HAS中的视频速率自适应估计可用链路带宽。在前面的段落中提供了较高层吞吐量估计的示例。
平均视频片段吞吐量
平均视频片段是下载视频片段时经历的平均吞吐量，如下面的等式所示：
其中Sfrag(j)、和分别是所请求的第j个视频片段的尺寸、下载时间和获取时间。变量LF是所请求的最新片段，以及F是用于求平均的段数目。这是对带宽的保守估计。因为这种吞吐量估计涉及对片段求平均，所以估计可能无法追踪无线链路带宽随时间的变化。此外，在下载前几个视频片段之前，无法获得平均视频片段吞吐量。
TCP吞吐量
另一较高层方法是使用由以下等式给出的可用链路带宽的TCP估计：
其中Cwnd是所谓的TCP拥塞窗口，以及RTT是信号的估计往返时间。变量Cwnd是TCP对可用链路带宽的当前估计。通常，Cwnd在接收到确认(ACKS)时增大，因为这是对于网络可以支持较高的带宽的指示，并且Cwnd在它感知到损耗(通过超时或重复的ACK感知)时减小，因为其假设损耗是由拥塞造成的。存在缓慢启动阶段，其中Cwnd在接收到确认时以指数方式增大，并且存在拥塞避免阶段，其中Cwnd在接收到确认时以线性方式增大。
然而，TCP被设计用于有线网络和用于连续发送数据的批量应用。它既不被设计用于无线网络，也不被设计用于应用速率受限的应用，例如HTTP自适应流送。使用TCP来估计吞吐量至少有两个问题。首先，使用TCP估计假设无线损耗也是拥塞。即使实际吞吐量不要求减小窗口尺寸，该假设也会不必要地减小窗口尺寸。其次，即使在应用率受限的情况下，TCP估计也会不必要地使Cwnd增大。因此，Cwnd带宽估计可以变得远高于应用在RTT时间段内发送的TCP分组的数目。当应用发送的分组少于Cwnd带宽估计所允许的分组时，TCP无法正确探测可用网络带宽。因此，Cwnd带宽估计不再反映当前的可用网络带宽。由于这些原因，基于TCP的带宽估计的使用不太适用于在无线场景中HAS中的速率自适应。
链路层有效吞吐量的优势
根据一个实施例，链路层有效吞吐量可以用作对较高层估计的补充。链路层有效吞吐量可以追踪链路吞吐量随时间的变化，从而为适机视频速率自适应和缓冲器构建提供更高的范围，以改善用户的QoE。链路层的使用表示用户获得的实际的当前有效吞吐量，这不同于可能已经过时的较高层估计。链路层有效吞吐量可以在相当短的时间内显著地改变。然而，链路层吞吐量可以通过时间求平均以呈现平滑的估计，从而避免剧烈变化，同时仍然捕获无线链路的总体趋势。此外，使用链路层有效吞吐量避免了基于TCP的带宽估计对于通过无线信道的速率受限应用所具有的一些缺点。另外，可以从流会话的第一视频段获得链路层有效吞吐量，而不是在下载了前几个视频段之后才获得。
因此，链路层有效吞吐量可以提供关于HTTP自适应流中的实际吞吐量的更快、更准确的知识。然后，由于无线链路的变化，当有其它带宽可用时，该知识可用于主动下载额外的帧以构建缓冲器。此外，在HAS会话开始时准确知道有效吞吐量实现了更快的启动和更好的显示分辨率。
所选择的吞吐量
在一个实施例中，平均链路层有效吞吐量可以与诸如视频片段吞吐量之类的较高层吞吐量结合使用。针对视频速率自适应所选择的吞吐量可以基于无线链路状况的变化的演进以及基于HAS客户端的缓冲器等级。由帧时隙i中的代表用户所选择的用于速率自适应的吞吐量可以由表示。在一个实施例中，可以基于PHY有效吞吐量和段吞吐量来确定保守估计，如下所示：
其中常数β防止链路状况的短期变化改变速率自适应。可以在稳定状态下使用这种保守的方法，因为通常PHY吞吐量对无线链路变化很快做出响应，而段吞吐量对链路变化的响应则要慢得多。
在HAS会话的启动阶段，关系可用于获得更好的视频质量。变量χ小于或等于1，并且是可用于获得启动视频质量和启动延迟之间的设计折衷的缩放因子。可以基于用户QoE偏好来设置χ的值。这些仅是代表性的示例，并且基于客户端缓冲器状态和链路状况的其它一般化条件可用于确定针对HAS视频速率自适应所选择的吞吐量。
缓冲器演进和追踪
为了请求适当的表示等级，客户端可以追踪所请求的、所接收的、所缓冲的和所播放的帧。图3示出了UE客户端进行的帧追踪。Ni和Qi分别表示由速率自适应算法所确定的在帧时隙i中所请求的帧数目和表示等级，即在每个帧时隙i的末端，客户端从服务器请求Ni个表示等级为Qi的帧。客户端可以基于物理层有效吞吐量以及在较高等级处确定的段吞吐量来决定Ni和Qi。
图4提供了视频帧追踪的示例图示。变量Ai、Bi、Ci和Ei表示客户端在计算Ni和Qi时使用的各种帧等级。变量Ai表示在客户端在帧时隙i中做出其请求之前由客户端所接收的视频帧的总数目。变量Bi表示客户端缓冲器中可用于播放的帧数目，以及Ci表示由客户端请求的帧数目：
变量Ei表示由客户端请求的但未接收到的视频帧的数目。客户端可以基于所请求的全部帧和所接收的帧来估计Ei。例如：
Ei＝Ci-Ai
缓冲器演进与用户体验到的PHY有效吞吐量密切相关。用bi，k表示在帧时隙i中所下载的视频表示等级的速率。则在帧时隙i中进入客户端缓冲器的帧数目为：
其中βi是链路层处的有效吞吐量与视频表示等级的速率的比率。它表示客户端缓冲器被填充的速率。
客户端状态
HTTP自适应流送(HAS)中的中心智能驻留在客户端而不是服务器中。要下载的视频段的适应等级由客户端确定，并在自适应流会话内周期性地被传送到服务器。基于帧等级，我们的链路感知自适应流框架中的客户端播放器的操作可以被表征为四种模式或状态，如图5所示：i)启动；ii)过渡状态；iii)稳定状态；或iv)重新缓冲状态。
启动模式表示初始缓冲模式，在此期间，客户端在开始播放由HAS传送的视频或音频之前将视频帧缓冲到一定限度。稳定状态表示UE缓冲器等级高于某个阈值的状态。过渡状态是在开始播放之后，UE缓冲器等级下降到某一限度以下的状态。重新缓冲状态是当开始播放之后缓冲器等级变为零时客户端进入的状态，并且它保持在该状态，直到它将缓冲器等级重建为令人满意的等级以再次开始重放。应该注意，只有在启动和重新缓冲模式期间，客户端不播放多媒体。
链路感知速率自适应框架
根据一个实施例，在无线设备上操作的客户端可以确定每个帧时隙i中的帧数目Ni和视频表示等级Qi。在图6的流程图中示出了链路感知速率自适应算法的一个示例。
图6示出了不包括替换请求特征的链路感知HAS速率自适应算法。该算法被示出用于帧时隙i中的HAS客户端j。在该示例实施例中，HAS客户端可以在每个帧时隙中计算对HAS段吞吐量以及PHY层有效吞吐量的估计。客户端然后可以基于这两种吞吐量估计保守地计算可能的最佳视频表示等级。为此，可以基于PHY有效吞吐量和段吞吐量确定对最大吞吐量的保守估计，如下所示：
其中，上述等式中的和常数β用于考虑无线链路状况的短期变化。当链路状况良好时，并且当链路状况不好时，该方法确保：i)当链路状况不好且段吞吐量无法跟随链路状况的变化时，则PHY有效吞吐量可以用于降低对于视频速率自适应所使用的链路带宽的估计，并且ii)当链路状况良好时，段吞吐量是保守估计。视频质量可以与使用PHY链路无感知方法时的视频质量一样好，同时允许段吞吐量赶上链路吞吐量。基于可以保守地确定在帧时隙i中可能的最佳视频表示等级
延迟受限质量优化
在一个实施例中，可以根据对延迟的约束来优化视频质量。目标时间被设置。在目标时间期间，启动阶段将通过下载启动所需的所有帧来完成。在此约束下，尝试在启动阶段期间优化视频质量。该算法可以使用图7中的流程图进行总结。该算法的细节可以被概述如下：
延迟受限质量优化：在每个帧时隙i中
1.确定所要求的最小帧下载速率：
其中Bi是就视频帧而言的当前缓冲器等级，以及是缓冲器中用于开始播放所需的帧的阈值数目。
2.计算针对当前链路状况下的所有视频表示等级的帧下载速率。具有速率bk的视频表示等级的帧下载速率由以下等式给出：
注意，针对表示等级的帧下载与PHY有效吞吐量成正比，并且与视频表示等级的速率成反比。
3.选择最佳视频表示等级使得即：
Ni＝1
图7a提供了示出延迟受限质量优化启动的流程图。对于每个帧时隙，可以确定满足延迟约束所需的最小帧速率。然后，可以基于链路状况针对每个表示等级确定帧下载速率。可以选择满足最小阈值的最佳表示等级。可以调整阈值和以获得视频质量和启动(缓冲)延迟之间的折衷。
在确定最佳表示等级后，可以更新缓冲器等级，并且HAS客户端可以更新其状态。然后，如果先前请求的段尚未被接收，则HAS客户端可以等待下一个帧时隙。如果先前的视频段已经被接收，则根据HAS客户端状态可以请求新的段。图7b示出了状态依赖型链路感知HAS客户端速率自适应的示例。基于启动/重新缓冲/过渡状态，可以基于Ni＝1的延迟受限质量优化(DBQOpt)来选择Qi值。
标识链路带宽隧道
可以按周期性的方式每T秒通过API向应用/客户端报告PHY层有效吞吐量。在一个实施例中，变量RPhy(k)可以表示第k个PHY层吞吐量反馈周期期间的物理层有效吞吐量。值Rphy(1)....Rphy(k)可以表示从周期1到周期k的PHY层有效吞吐量的序列。在时间t处，反馈循环数可以由给出。过去的N个样本，即Rphy(m-N+1)，...，Rphy(m)可用于确定无线信道的趋势。样本的线性拟合在时间t处的斜率可以被确定为Rphy(m-N+1)，...，Rphy(m)。这个由s(t)表示的斜率确定了链路带宽的趋势。s(t)的符号表示变化的方向，并且其幅度表示无线电链路带宽的变化的陡度。如果s(t)为负，并且s(t)的幅度大于阈值，即|s(t)|＞δ，则可以在链路层带宽中标识陡降。当值s(t)≤-δ时，其被称为链路带宽隧道条件。
当信道急剧下降时，PHY层有效吞吐量估计与实际链路带宽密切相关。保守估计等于该估计。然而，当链路带宽急剧下降时，就像s(t)≤-δ时一样，除了对未来的段请求使用保守估计之外，HAS客户端可能必须采取某些其它校正动作。
图8示出了具有替换请求特征的示例链路感知HAS速率自适应的流程图。根据本发明的一个实施例，替换请求特征可以与前面段落中描述的链路感知流送自适应一起使用。在对HAS的这种增强中，链路感知可用于标识无线电链路带宽急剧下降的隧道条件。
当先前请求的段尚未被完全接收时，可以检查隧道条件。如果隧道条件为假，则HAS客户端可以设置Ni＝0和Qi＝0。然而，如果先前的HAS段尚未被接收并且隧道条件被满足(即，s(t)≤-δ)，则HAS客户端可以继续检查进一步的条件以确定是否替换先前的段请求。
如果满足一组特定的条件，则可以在服务器处取消先前的段请求，并且HAS客户端可以发出对于采用较低质量等级的同一视频段的新请求。所测试的一组条件可以包括所接收的视频段的持续时间、所接收的视频段的尺寸和客户端媒体缓冲器等级的组合。
图9中示出了该组条件和用于选择替换段的质量的算法的一个示例实施例。在该示例中，仅在所接收的视频段的持续时间(SegDurRcvd)小于阈值Dth，所接收的段的尺寸小于阈值Sth，并且客户端处的缓冲器等级小于阈值Bth时使用替换请求特征。如果满足这些条件，则HAS客户端发信号通知服务器取消先前所请求的视频段。
此外，吞吐量的保守估计可以减小恒定值α，其中α小于1，并且可以重新计算帧时隙i中可能的最佳视频表示等级HAS客户端可以发出对于采用较低质量等级的同一视频段的新请求。可以将值Ni重置为1，并且可以将视频表示等级设置为重新计算的的值。
一个示例实施例提供了一种具有体现在其上的指令1000的非暂态机器可读存储介质，该指令在由一个或多个处理器运行时，执行以下操作以提供超文本传输协议(HTTP)自适应流(HAS)，如图10的流程图所示。操作包括处理在用户设备(UE)处从节点接收到的HTTP自适应流的清单文件，如框1010所示。清单文件标识针对一时间段的多个表示等级。每个表示等级可以标识多个段，如图1所示。
指令1000的进一步操作包括确定UE相对节点针对HAS的物理层有效吞吐量，如框1020所示。可以从HAS中选择多个物理层有效吞吐量样本，如框1030所示。可以计算在时间t处采用的物理层有效吞吐量样本的曲线拟合的斜率，如框1040所示。在一个实施例中，曲线拟合可以是物理层有效吞吐量样本的线性曲线拟合。时间可以是针对其计算斜率的时间段。
指令1000的附加操作包括基于所计算的斜率标识何时将在HAS的清单文件中所标识的先前接收到的段替换为处于不同表示等级的同一段替换。例如，可以使用处于较低的表示或较高的表示的同一段来替换所接收的段。如本文所使用的，术语“较高的表示”用于指代具有更高数据速率的表示，例如从图1中的数据速率为2Mbps的表示2(106)变动到数据速率为5Mbps的表示1。相反地，术语“较低的表示”用于指代具有更低数据速率的表示，例如从数据速率为2Mbps的表示2变动到处于500Kbps的表示3。
指令1000还可以包括下述操作：确定斜率何时为负；标识负斜率何时大于预定阈值，即例如||s(t)|＞δ；以及将大于预定阈值的负斜率归类为链路带宽隧道条件。在一个示例中，当存在链路带宽隧道条件时，可以基于一组条件来替换先前接收到的段。当发生链路带宽隧道条件时，可以监测替换段条件集的状态。替代地，即使在尚未发生链路带宽隧道条件时，也可以监测状态。替换段条件集是针对先前接收到的段的一组条件，包括：针对先前在UE处接收到的段所接收的段持续时间小于持续时间阈值；针对先前在UE处接收到的段所接收的段尺寸小于尺寸阈值；以及在UE处操作的HAS客户端处的缓冲器等级小于缓冲器阈值。在一个实施例中，当已经满足所有条件时，则替换段条件集的状态为真。
指令1000还可以包括以下操作：基于替换段条件集的状态和链路带宽隧道条件来取消针对先前接收到的段的请求；以及请求按照较低的表示等级将先前接收到的段发送给UE。例如，当斜率为负时，可以发送较低的表示。替代地，当斜率为正时，可以发送较高的表示。可以针对正斜率和负斜率设定不同的阈值。另外的指令包括当替换段条件的状态为真并且发生带宽隧道条件时，将吞吐量值减小恒定量。替代地，如果满足针对正斜率的阈值，则当替换段条件的状态为真时，吞吐量值可以增加恒定量。
在另一示例中，公开了用于提供超文本传输协议(HTTP)自适应流(HAS)的方法1100，如图11的流程图所示。该方法可以作为机器、计算机电路或移动设备(例如，UE)的一个或多个处理器上的指令被执行，其中指令被包括在至少一个计算机可读介质或一个非暂态机器可读存储介质上。该方法包括在用户设备(UE)处从节点接收HTTP自适应流的清单文件的操作，如框1110所示。清单文件可用于标识多个表示等级，其中每个表示等级包含针对多个段的信息。进一步的操作包括：确定UE相对节点针对HAS的物理层有效吞吐量，如框1120所示；选择一时间段上的多个物理层有效吞吐量样本，如框1130所示；计算物理层有效吞吐量样本在该时间段上的曲线拟合的斜率，如框1140所示；以及基于所计算的斜率，标识何时在UE处将HAS的清单文件中标识的先前接收到的段替换为处于不同表示等级的同一段，如框1150所示。如前所述，曲线拟合可以是用于计算斜率的线性曲线拟合。
方法1100还可以包括以下操作：确定斜率何时为负；标识负斜率何时大于预定阈值；以及将大于预定阈值的负斜率归类为链路带宽隧道条件。
在方法1100中，可以监测替换段条件集的状态。在一个实施例中，当链路带宽隧道条件发生时，可以监测该集合。替代地，可以独立于链路带宽隧道条件来监测该集合。替换段条件集是针对先前接收到的段的一组条件，包括：先前接收到的段在UE处接收到的段持续时间小于持续时间阈值；先前接收到的段在UE处接收到的段尺寸小于尺寸阈值；以及在UE处操作的HAS的客户端处的缓冲器等级小于缓冲器阈值。
方法1100还可以包括：基于替换段条件集的状态和链路带宽隧道条件来取消先前的段请求；以及请求按照较低的表示等级将先前的段发送至UE。如在该方法中使用的，术语“较低的表示”和“较高的表示”具有与先前定义的含义相同的含义。该方法还可以包括：当曲线拟合的所计算的斜率为正时以及当斜率大于所选择的阈值时，基于替换段条件集的状态来取消先前的段请求；以及请求按照更高的表示等级将先前的段发送至UE。
方法1100还可以包括以下操作：当替换段条件的状态为真并且带宽隧道条件发生时，将吞吐量值减小恒定量。此外，当替换段条件的状态为真并且所计算的曲线拟合的斜率为正并且大于所选择的阈值时，可以将吞吐量值增加恒定量。
另一示例提供如图12的流程图所示的可操作以接收超文本传输协议(HTTP)自适应流(HAS)的移动设备的一个或多个处理器的功能1200。功能可以被实现为方法，或者功能可以作为机器上的指令被运行，其中指令被包括在至少一个计算机可读介质或一个非暂时机器可读存储介质上。如本文所述，处理器可以是被配置为处理数字数据的数字处理器和被配置为辅助收发器发送和接收数据的基带处理器。
一个或多个处理器可以被配置为处理在移动设备处从节点接收到的HTTP自适应流的清单文件，如框1210所示。清单文件可以标识多个表示，其中每个表示具有针对多个段的信息。一个或多个处理器还可以被配置为：确定移动设备相对节点针对HAS的物理层有效吞吐量，如框1220中所示；标识针对HAS的段吞吐量估计，如方框1230中所示；以及基于针对HAS的物理层有效吞吐量和针对HAS的段吞吐量，在清单文件中选择针对所选择的时段的表示，如框1240所示。
一个或多个处理器还可以被配置为基于针对HAS的物理层有效吞吐量和针对HAS的段吞吐量估计，从节点中请求采用清单文件中所标识的表示的所选数量的段。此外，(一个或多个)处理器可以被配置为至少部分地基于针对HAS的物理层有效吞吐量和来自传输层的针对HAS的段吞吐量估计或者来自应用层的针对HAS的段吞吐量估计之一来选择针对所选择的时段的表示。
在一个实施例中，(一个或多个)处理器可以被配置为选择在帧时隙i中用于速率自适应的吞吐量，如下所示：
其中是每个视频帧持续时间内成功接收到的比特数，是段的段尺寸与段的下载时间的平均比，β是链路层处的有效吞吐量与视频表示等级的速率的比率。
在另一实施例中，(一个或多个)处理器可以被配置为：从HAS中选择多个物理层有效吞吐量样本；计算时间t处的物理层有效吞吐量样本的线性拟合的斜率；以及基于斜率确定物理层处的带宽变化。处理器可以标识何时带宽变化为负并且带宽的变化大于所选择的阈值，以创建链路带宽隧道条件。此外，处理器可以被配置为当链路带宽隧道条件发生时检查替换段条件集。
替换段条件可以包括：接收到的段持续时间小于持续时间阈值、接收到的段尺寸小于尺寸阈值、以及在移动设备上操作的客户端处的缓冲器等级小于缓冲器阈值。(一个或多个)处理器还可以被配置为基于替换段条件集和链路带宽条件来取消先前的段请求；以及请求采用不同的表示等级的先前的段。在一个实施例中，处理器可以被配置为当替换段条件集为真并且带宽隧道条件发生时，将吞吐量值减小恒定量。
图13提供了移动设备的示例图示，无线设备例如是用户设备(UE)、移动台(MS)、移动无线设备、移动通信设备、平板计算机、手机、或其它类型的无线设备。无线设备可以包括被配置为与节点或传输站通信的一个或多个天线，节点或传输站例如是基站(BS)、演进型节点B(eNB)、基带单元(BBU)、远程无线电头(RRH)、远程无线电设备(RRE)、中继站(RS)、无线电设备(RE)、远程无线电单元(RRU)、中央处理模块(CPM)或其它类型的无线广域网(WWAN)接入点。无线设备可以被配置为使用至少一个无线通信标准(包括3GPPLTE、WiMAX、高速分组接入(HSPA)、Bluetooth(蓝牙)、以及WiFi)进行通信。无线设备可以使用针对每个无线通信标准的独立天线或者使用针对多个无线通信标准的共享天线进行通信。移动设备可在无线局域网(WLAN)、无线个域网(WPAN)、和/或WWAN中进行通信。
图13还提供了能够用于来自无线设备的音频输入和输出的麦克风和一个或多个扬声器的图示。显示器屏幕可以是液晶显示器(LCD)屏幕或其它类型的显示器屏幕，例如，有机光发射二极管(OLED)显示器。显示器屏幕能够被配置为触摸屏。触摸屏可以使用电容式、电阻式、或另一类型的触摸屏技术。应用处理器和图形处理器能够被耦合到内部存储器以提供处理和显示能力。非易失性存储器端口也能够被用于向用户提供数据输入/输出选项。非易失性存储器端口还可以被用于扩展无线设备的存储能力。键盘可以被与无线设备集成，或者被无线地连接到无线设备，以提供附加用户输入。还可以使用触摸屏来提供虚拟键盘。
各种技术或其某些方面或部分可以采用体现于有形介质中的程序代码(即，指令)的形式，有形介质例如是：软盘、光盘只读存储器(CD-ROM)、硬盘驱动器、非暂态计算机可读存储介质、或任何其它机器可读存储介质，其中，当程序代码被载入到机器(比如，计算机)中并由该机器来执行时，使得该机器成为用于实践各种技术的装置。电路可以包括硬件、固件、程序代码、可执行代码、计算机指令、和/或软件。非暂态计算机可读存储介质可以是不包括信号的计算机可读存储介质。在在可编程计算机上执行程序代码的情况下，计算设备可以包括：处理器、可由处理器读取的存储介质(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备、和至少一个输出设备。易失性和非易失性存储器和/或存储元件可以是：随机存取存储器(RAM)、可擦除可编程只读存储器(EPROM)、闪盘驱动器、光驱动器、硬磁盘驱动器、固态驱动器、或用于存储电子数据的另一介质。节点和无线设备还可以包括收发器模块(即收发器)、计数器模块(即计数器)、处理模块(即处理器)、和/或时钟模块(即时钟)或计时器模块(即定时器)。可以实现或利用本文所描述的各种技术的一个或多个程序可以使用应用编程接口(API)、可重用控件等等。这样的程序可以以高级过程编程语言或面向对象的编程语言来实现以与计算机系统通信。然而，若需要的话，(一个或多个)程序可以以汇编语言或机器语言来实现。在任何情况下，语言可以是编译或解译语言，并且可以与硬件实现方式相组合。
应当理解的是，本说明书中所描述的许多功能单元已经被标注为模块，以便更具体地强调它们的实现方式的独立性。例如，可以使用一个或多个数字处理器来实现模块和/或可以将模块实现为硬件电路，该硬件电路包括定制超大规模集成(VLSI)电路或门阵列、现成的半导体器件(比如，逻辑芯片、晶体管、或其它分立组件)。模块还可以以可编程硬件设备(例如，现场可编程门阵列(FPGA)、可编程阵列逻辑、可编程逻辑设备等等)来实现。
如本文所使用的，术语“处理器”可以包括通用处理器、专用处理器(例如，VLSI、FPGA和其它类型的专用处理器)、以及在收发器中用于发送、接收和处理无线通信的基带处理器。
模块还可以以由各种类型的处理器执行的软件来实现。可执行的代码的经标识的模块例如可以包括计算机指令的一个或多个物理或逻辑块，其例如可以被组织为对象、程序、或功能。尽管如此，经标识的模块的可执行文件不一定在物理上位于一处，而是可以包括存储于不同位置的不同指令，这些指令当被逻辑地结合在一起时组成该模块并实现所注明的该模块的用途。
实际上，可执行代码的模块可以是单一指令或许多指令，或者甚至可以分布于若干不同的代码段上、分布于不同程序之间、并分布于若干存储器设备之间。类似地，可操作数据可以在本文被标识和示出于模块内，并且可以以任何合适的形式来体现并且被组织在任何适当类型的数据结构内。可操作数据可以被收集在单一数据集中，或者可以分布在不同位置上(包括在不同存储设备上)，并且可以至少部分地仅作为系统或网络上的电子信号而存在。这些模块可以是无源的或有源的，包括可操作来执行期望的功能的代理。
整个说明书中对“示例”的提及意思是结合该示例描述的特定特征、结构、或特性被包括在本发明的至少一个实施例中。因此，在整个说明书中各处出现的短语“在示例中”或词语“示例性的”不一定全部指代同一实施例。
为方便起见，本文所使用的多个项、结构元件、组成元素、和/或材料可以被呈现于共同的列表中。然而，这些列表应当被看作列表中的每个元素被单独地标识为分离且唯一的元素。因此，在没有相反指示的情况下，这样的列表中的个体元素都不应当仅基于其出现在共同的组中而被看作该同一列表中的任何其它元素的实际等同物。另外，本发明的各种实施例和示例随其各种组分的替代物一起被提及。应当理解，这样的实施例、示例和替代物不应被看作彼此的等同物，而应被看作本发明的分开且独立存在的表示。
此外，所描述的特征、结构或特性可被以任何适当的方式组合在一个或多个实施例中。在下面的描述中，提供了众多具体的细节(比如，布局的示例、距离、网络示例等)以提供对本发明的实施例的透彻的理解。然而，相关领域的技术人员将认识到本发明可以在不具有这些具体细节中的一个或多个的情况下或者以其它方法、组件、布局等来实践。在其它实例中，未详细示出或描述众所周知的结构、材料或操作以避免模糊本发明的各方面。
尽管上述示例在一个或多个特定应用中说明了本发明的原理，但是本领域普通技术人员将清楚在不付出创造性劳动的情况下、并且在不背离本发明的原理和概念的情况下可以在实现方式的细节、形式、和使用方面做出诸多修改。因此，不意在本发明受到除所附权利要求之外的限制。

Claims (24)

1.一种其上实施有指令的非暂态机器可读存储介质，所述指令在由一个或多个处理器运行时执行以下操作以提供超文本传输协议(HTTP)自适应流(HAS)，所述操作包括：
处理在用户设备(UE)处从节点接收到的HTTP自适应流的清单文件，其中所述清单文件标识针对一时间段的多个表示等级，每个表示等级标识多个段；
确定所述UE相对所述节点针对所述HAS的物理层有效吞吐量；
从所述HAS中选择多个物理层有效吞吐量样本；
计算所述物理层有效吞吐量样本的曲线拟合在时间t处的斜率；以及
基于所计算的斜率标识何时将在所述HAS的清单文件中标识的先前接收到的段替换为处于不同表示等级的同一段。
2.如权利要求1所述的至少一种非暂态机器可读存储介质，还包括指令，所述指令在由所述一个或多个处理器运行时包括以下操作：
确定所述斜率何时为负；
标识负斜率何时大于预定阈值；以及
将大于所述预定阈值的负斜率归类为链路带宽隧道条件。
3.如权利要求2所述的至少一种非暂态机器可读存储介质，还包括指令，所述指令在由所述一个或多个处理器运行时包括以下操作：
当所述链路带宽隧道条件发生时，监测替换段条件集的状态。
4.如权利要求3所述的至少一种非暂态机器可读存储介质，其中所述替换段条件集是针对所述先前接收到的段的一组条件，包括：
针对所述先前接收到的段在所述UE处接收到的段持续时间小于持续时间阈值；
针对所述先前接收到的段在所述UE处接收到的段尺寸小于尺寸阈值；以及
在所述UE处操作的HAS客户端处的缓冲器等级小于缓冲器阈值。
5.如权利要求4所述的至少一种非暂态机器可读存储介质，还包括指令，所述指令在由所述一个或多个处理器运行时包括以下操作：
基于所述替换段条件集的状态和所述链路带宽隧道条件来取消针对所述先前接收到的段的请求；以及
请求按照较低的表示等级将所述先前接收到的段发送给所述UE。
6.如权利要求4所述的至少一种非暂态机器可读存储介质，还包括指令，所述指令在由所述一个或多个处理器运行时包括以下操作：
当所述替换段条件的状态为真并且带宽隧道条件发生时，将吞吐量值减小恒定量。
7.一种用于提供超文本传输协议(HTTP)自适应流(HAS)的方法，操作包括：
在用户设备(UE)处从节点接收HTTP自适应流的清单文件，其中所述清单文件标识多个表示等级，每个表示等级包含针对多个段的信息；
确定所述UE相对所述节点针对所述HAS的物理层有效吞吐量；
选择一时间段上的多个物理层有效吞吐量样本；
计算所述物理层有效吞吐量样本在该时间段上的曲线拟合的斜率；以及
基于所计算的斜率，标识何时在所述UE处将在所述HAS的清单文件中标识的先前接收到的段替换为处于不同表示等级的同一段。
8.如权利要求7所述的方法，还包括：
确定所述斜率何时为负；
标识负斜率何时大于预定阈值；以及
将大于所述预定阈值的负斜率归类为链路带宽隧道条件。
9.如权利要求8所述的方法，还包括：当所述链路带宽隧道条件发生时，监测替换段条件集的状态。
10.如权利要求9所述的方法，其中所述替换段条件集是针对所述先前接收到的段的一组条件，包括：
针对所述先前接收到的段在所述UE处接收到的段持续时间小于持续时间阈值；
针对所述先前接收到的段在所述UE处接收到的段尺寸小于尺寸阈值；以及
针对在所述UE处操作的所述HAS的客户端处的缓冲器等级小于缓冲器阈值。
11.如权利要求10所述的方法，还包括：
基于所述替换段条件集的状态和所述链路带宽隧道条件来取消先前的段请求；以及
请求按照较低的表示等级将先前的段发送给所述UE。
12.如权利要求10所述的方法，还包括：
基于下述各项来取消先前的段请求：
所述替换段条件集的状态；以及
所计算的所述曲线拟合的斜率为正并且大于所选择的阈值；以及请求按照更高的表示等级将先前的段发送给所述UE。
13.如权利要求10所述的方法，还包括：当所述替换段条件的状态为真并且带宽隧道条件发生时，将吞吐量值减小恒定量。
14.如权利要求12所述的方法，还包括：当所述替换段条件的状态为真并且所计算的所述曲线拟合的斜率为正并且大于所选择的阈值时，将吞吐量值增加恒定量。
15.一种能操作以接收超文本传输协议(HTTP)自适应流(HAS)的移动设备，所述移动设备具有一个或多个处理器，所述一个或多个处理器被配置为：
处理在所述移动设备处从节点接收到的HTTP自适应流的清单文件，其中所述清单文件标识多个表示，每个表示具有针对多个段的信息；
确定所述移动设备相对所述节点针对所述HAS的物理层有效吞吐量；
标识针对所述HAS的段吞吐量估计；以及
基于针对所述HAS的所述物理层有效吞吐量和针对所述HAS的所述段吞吐量，在所述清单文件中选择针对所选择的时段的表示。
16.如权利要求15所述的移动设备，其中所述一个或多个处理器还被配置为：
基于针对所述HAS的所述物理层有效吞吐量和针对所述HAS的所述段吞吐量估计，从所述节点请求采用所述清单文件中标识的表示的所选数量的段。
17.如权利要求15所述的移动设备，其中所述一个或多个处理器还被配置为：
至少部分地基于针对所述HAS的所述物理层有效吞吐量和来自传输层的针对所述HAS的所述段吞吐量估计或者来自应用层的针对所述HAS的所述段吞吐量估计之一来选择针对所选择的时段的表示。
18.如权利要求15所述的移动设备，其中所述一个或多个处理器还被配置为选择在帧时隙i中用于速率适应的吞吐量，如下所示：
其中是每个视频帧持续时间内成功接收到的比特数，是段的段尺寸与该段的下载时间的平均比，以及β是链路层处的有效吞吐量与视频表示等级处的速率的比率。
19.如权利要求15所述的移动设备，其中所述一个或多个处理器还被配置为：
从所述HAS选择多个物理层有效吞吐量样本；
计算所述物理层有效吞吐量样本的线性拟合在时间t处的斜率；以及
基于所述斜率确定物理层处的带宽变化。
20.如权利要求19所述的移动设备，其中所述一个或多个处理器还被配置为：
标识何时带宽的变化为负并且所述带宽的变化大于所选择的阈值，以创建链路带宽隧道条件。
21.如权利要求20所述的移动设备，其中所述一个或多个处理器还被配置为当所述链路带宽隧道条件发生时检查替换段条件集。
22.如权利要求21所述的移动设备，其中所述替换段条件包括：
接收到的段持续时间小于持续时间阈值；
接收到的段尺寸小于尺寸阈值；以及
在所述移动设备上操作的客户端处的缓冲器等级小于缓冲器阈值。
23.如权利要求20所述的移动设备，其中所述一个或多个处理器还被配置为：
基于所述替换段条件集和所述链路带宽条件来取消先前的段请求；以及
请求采用不同的表示等级的先前的段。
24.如权利要求22所述的移动设备，其中所述一个或多个处理器还被配置为：
当所述替换段条件集为真并且带宽隧道条件发生时，将吞吐量值减小恒定量。
CN201580063676.8A 2014-12-24 2015-11-25 链路感知流送自适应 Active CN107210999B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/583,034 US10812546B2 (en) 2014-12-24 2014-12-24 Link-aware streaming adaptation
US14/583,034 2014-12-24
PCT/US2015/062791 WO2016105846A1 (en) 2014-12-24 2015-11-25 Link-aware streaming adaptation

Publications (2)

Publication Number Publication Date
CN107210999A true CN107210999A (zh) 2017-09-26
CN107210999B CN107210999B (zh) 2021-01-15

Family

ID=54838456

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580063676.8A Active CN107210999B (zh) 2014-12-24 2015-11-25 链路感知流送自适应

Country Status (6)

Country Link
US (2) US10812546B2 (zh)
EP (2) EP3923544A1 (zh)
KR (1) KR102486847B1 (zh)
CN (1) CN107210999B (zh)
HK (1) HK1244121A1 (zh)
WO (1) WO2016105846A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105227535B (zh) * 2014-07-01 2019-12-06 思科技术公司 用于边缘缓存和客户端设备的装置及方法
US10433023B1 (en) * 2015-10-27 2019-10-01 Amazon Technologies, Inc. Heuristics for streaming live content
US10652123B2 (en) * 2015-11-06 2020-05-12 Nec Corporation Throughput measuring apparatus, method, and recording medium
US10587934B2 (en) * 2016-05-24 2020-03-10 Qualcomm Incorporated Virtual reality video signaling in dynamic adaptive streaming over HTTP
US10334238B2 (en) * 2017-01-03 2019-06-25 Black Sails Technology Inc. Method and system for real-time rendering displaying high resolution virtual reality (VR) video
US11076188B1 (en) * 2019-12-09 2021-07-27 Twitch Interactive, Inc. Size comparison-based segment cancellation
US11153581B1 (en) 2020-05-19 2021-10-19 Twitch Interactive, Inc. Intra-segment video upswitching with dual decoding
US11588877B2 (en) * 2020-07-08 2023-02-21 Qualcomm Incorporated Attention (AT) interface for radio access network bitrate recommendations

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8089939B1 (en) * 2007-05-18 2012-01-03 Marvell International Ltd. Predictive roaming by a wireless LAN client station
CN103475906A (zh) * 2012-06-08 2013-12-25 华为技术有限公司 用于多媒体流的测量方法和测量装置
CN103535047A (zh) * 2011-05-17 2014-01-22 阿尔卡特朗讯公司 流式传输视频内容的方法、监视视频内容流的网络中的节点
WO2014134309A1 (en) * 2013-03-01 2014-09-04 Intel IP Corporation Link-aware streaming adaptation
US20140351386A1 (en) * 2011-10-07 2014-11-27 Ericsson Television Inc. Http adaptive streaming server with automatic rate shaping
CN104205734A (zh) * 2012-04-27 2014-12-10 英特尔公司 用于基于HTTP的视频流送的QoE知晓的无线电接入网络架构

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149291B1 (en) * 2000-06-27 2006-12-12 Cisco Technology, Inc. Method and apparatus for reducing inbound traffic congestion in a voice frame network
US7397805B2 (en) * 2003-04-02 2008-07-08 Ntt Docomo Inc. Systems and methods for goodput guarantee through adaptive fair queuing
US9185439B2 (en) * 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
CN110087262B (zh) * 2011-10-21 2023-12-01 弗劳恩霍夫应用研究促进协会 无线资源管理设备及方法
WO2013090280A2 (en) * 2011-12-15 2013-06-20 Dolby Laboratories Licensing Corporation Bandwidth adaptation for dynamic adaptive transferring of multimedia
US9769281B2 (en) * 2011-12-19 2017-09-19 Google Technology Holdings LLC Method and apparatus for determining a multimedia representation for a multimedia asset delivered to a client device
US20130227158A1 (en) * 2012-02-24 2013-08-29 Stmicroelectronics S.R.L. Media-quality adaptation mechanisms for dynamic adaptive streaming
US8762563B2 (en) * 2012-04-16 2014-06-24 Adobe Systems Incorporated Method and apparatus for improving the adaptive bit rate behavior of a streaming media player
US9591513B2 (en) * 2012-08-06 2017-03-07 Vid Scale, Inc. Rate adaptation using network signaling
US20140040496A1 (en) * 2012-08-06 2014-02-06 General Instrument Corporation On-demand http stream generation
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
KR101667950B1 (ko) * 2012-10-29 2016-10-28 알까뗄 루슨트 모바일 ｈｔｔｐ 적응형 스트리밍을 갖는 무선 네트워크들에서의 정체 관리를 위한 방법들 및 장치들
EP2939420B1 (en) * 2013-01-15 2018-03-14 Huawei Technologies Co., Ltd. Using quality information for adaptive streaming of media content
US20140372569A1 (en) * 2013-06-14 2014-12-18 Samsung Electronics Co., Ltd. Controlling dash client rate adaptation
ITBA20130077A1 (it) * 2013-11-25 2015-05-26 Cicco Luca De Meccanismo per il controllo del bitrate di codifica in un sistema di video streaming adattivo basato su buffer di playout e sulla stima di banda.
US9794155B2 (en) * 2014-12-19 2017-10-17 Tube Incorporated System and method for coordinating client-side inference of mobile network loading and capacity

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8089939B1 (en) * 2007-05-18 2012-01-03 Marvell International Ltd. Predictive roaming by a wireless LAN client station
CN103535047A (zh) * 2011-05-17 2014-01-22 阿尔卡特朗讯公司 流式传输视频内容的方法、监视视频内容流的网络中的节点
US20140351386A1 (en) * 2011-10-07 2014-11-27 Ericsson Television Inc. Http adaptive streaming server with automatic rate shaping
CN104205734A (zh) * 2012-04-27 2014-12-10 英特尔公司 用于基于HTTP的视频流送的QoE知晓的无线电接入网络架构
CN103475906A (zh) * 2012-06-08 2013-12-25 华为技术有限公司 用于多媒体流的测量方法和测量装置
WO2014134309A1 (en) * 2013-03-01 2014-09-04 Intel IP Corporation Link-aware streaming adaptation

Also Published As

Publication number Publication date
CN107210999B (zh) 2021-01-15
KR20170101192A (ko) 2017-09-05
EP3923544A1 (en) 2021-12-15
US10812546B2 (en) 2020-10-20
HK1244121A1 (zh) 2018-07-27
US20210029181A1 (en) 2021-01-28
US11477257B2 (en) 2022-10-18
EP3238405B1 (en) 2022-01-05
EP3238405A1 (en) 2017-11-01
KR102486847B1 (ko) 2023-01-11
US20160191585A1 (en) 2016-06-30
WO2016105846A1 (en) 2016-06-30

Similar Documents

Publication Publication Date Title
US10455404B2 (en) Quality of experience aware multimedia adaptive streaming
CN104956631B (zh) 用于执行链路感知自适应流传输的设备和方法
US11038944B2 (en) Client/server signaling commands for dash
CN107210999A (zh) 链路感知流送自适应
CN107005727A (zh) 媒体内容流
CN104412253B (zh) 用于在超文本传输协议上的质量知晓自适应流传输的方法
CN106576182A (zh) 视频质量提升
CN104604286A (zh) 用于流式传输和对话服务的能量感知多媒体自适应

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1244121

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20210705

Address after: California, USA

Patentee after: INTEL Corp.

Address before: California, USA

Patentee before: INTEL IP Corp.

TR01 Transfer of patent right