CN109842613A - 用于提供和接收媒体数据的方法和装置以及存储介质 - Google Patents

Abstract

本发明涉及一种用于提供和接收媒体数据的方法和装置以及存储介质。提供了用于管理经由通信网络的流传输的方法。服务器装置和客户端装置共享推送策略，使得客户端装置可以预期服务器所进行的数据推送。预期使得可以及早取消一些所推送数据的发送，因此减少了带宽消耗。所共享的推送策略对于服务器和客户端这两者而言可以是隐式的。在实施例中，所共享的推送策略是由服务器以显式方式向客户端指定的，例如嵌入在媒体呈现描述文件中或者包括在特定HTTP头部中。客户端还可以请求更新所共享的推送策略以满足其自身的要求。

Description

用于提供和接收媒体数据的方法和装置以及存储介质

(本申请是申请日为2014年7月11日、申请号为201480050434.0、发明名称为“利用推送消息控制的自适应数据流传输方法”的申请的分案申请。)

技术领域

本发明涉及经由HTTP通信网络的数据流传输。

更特别地，本发明涉及用于满足网络制约的自适应数据流传输。本发明可以应用于DASH网络。

DASH(经由HTTP的动态自适应流传输(Dynamic Adaptive Streaming over HTTP)的首字母缩略词)是使得能够经由HTTP进行媒体内容流传输(通常为音频/视频内容)的通信标准。根据DASH，将媒体呈现描述为被称为“媒体呈现描述”文件(以下为MPD)的XML文件。MPD文件向客户端装置提供使得这些客户端装置能够请求并控制媒体内容的传递的信息。

背景技术

图3示出经由HTTP的媒体流传输的一般原则。针对经由HTTP的自适应流传输的新协议和标准中的大部分协议和标准均基于该原则。

媒体服务器300将数据流传输至客户端310。媒体服务器存储媒体呈现。例如，媒体呈现301包含音频数据和视频数据。音频和视频可以交错存在于同一文件中。以下参考图4a来说明构建媒体呈现的方式。该媒体呈现从时间上分割成可以单独进行寻址并下载的诸如MP4片段等的小的独立且连续的时间片段302a、302b和302c。这些时间片段各自的媒体内容的下载地址(HTTP URL)由服务器向客户端进行设置。音频/视频媒体内容的各时间片段与一个HTTP地址相关联。

媒体服务器还存储描述媒体呈现的内容的(以下参考图5所述的)清单(manifest)文件文档304，其中该内容包括媒体内容特性(例如，媒体的类型：音频、视频、音频-视频、文本等)、编码格式(例如，比特率、定时信息等)、时间媒体片段的列表和关联的URL。可选地，该文档包含使得可以重建时间媒体片段的显式列表和关联的URL的模板信息。可以使用可扩展标记语言(XML)编写该文档。

将清单文件发送至客户端。在步骤305中接收到清单文件时，向客户端通报媒体内容的时间片段和HTTP地址之间的关联。此外，清单文件向客户端提供与媒体呈现的内容(在本示例中为交错存在的音频/视频)有关的信息。该信息可以包括分辨率、比特率等。

基于所接收到的信息，客户端的HTTP客户端模块311可以发出用于下载清单文件中所描述的媒体内容的时间片段的HTTP请求306。服务器的HTTP应答307传送所请求的时间片段。HTTP客户端模块311从应答中提取时间媒体片段并且将这些时间媒体片段提供至媒体引擎312的输入缓冲器307。最后，可以在步骤308和309期间，分别对媒体片段进行解码并显示。

媒体引擎312与DASH控制引擎313相互作用，以在适当时间发起针对后续时间片段的请求。从清单文件中识别下一片段。发起请求的时间依赖于接收缓冲器307是否为满。DASH控制引擎313控制该缓冲器以防止该缓冲器过载或完全为空。

参考图4a来说明媒体呈现和清单文件的生成。在步骤400和401期间，获取音频数据和视频数据。接着，在402期间对音频数据进行压缩。例如，可以使用MP3标准。此外，在步骤403期间并行地对视频数据进行压缩。可以使用如MPEG4、MPEG/AVC、SVC、HEVC或可分级HEVC等的视频压缩算法。一旦进行了音频数据和视频数据的压缩，则可利用音频基本流404和视频基本流405。在步骤406期间将这些基本流封装到全局媒体呈现中。例如，可以使用ISO BMFF标准(或该ISO BMFF标准向AVC、SVC、HEVC、HEVC的可分级扩展等的扩展)来将编码后的音频基本流和视频基本流的内容描述为全局媒体呈现。使用如此获得的封装后的媒体呈现407来在步骤408期间生成XML清单文件409。视频数据401和音频数据400的多个呈现可被获取、压缩、封装并描述在媒体呈现407中。

针对图4b所示的MPEG/DASH流传输协议的特定情况，将清单文件称为“媒体呈现描述”(或“MPD”文件)。该文件的根元素是包含适用于所有呈现的属性和如profile或schema那样的DASH信息的MPD元素。将媒体呈现分割成由Period(时间段)元素表示的时间段。MPD文件410包含与各时间段有关的所有数据。通过接收该信息，客户端知晓各段时间的内容。针对各Period 411，定义AdaptationSet(自适应集)元素。

可能的组织是呈现中所包含的各媒体类型具有一个或多个AdaptationSet。与视频有关的AdaptationSet 412包含与在服务器处可利用的编码视频的可能的不同表现有关的信息。在Representation(表现)元素中描述各表现。例如，第一表现可以是以空间分辨率640×480进行编码并且以比特率500kbits/s进行压缩后的视频。第二表现可以是以比特率250kbits/s进行压缩后的同一视频。

如果客户端得知与该视频有关的HTTP地址，则可以利用HTTP请求来下载各视频。通过使用附加描述级别即时间片段来进行各表现的内容和HTTP地址之间的关联。将各视频表现分割成时间片段413(通常为几秒)。各时间片段包括服务器中所存储的经由HTTP地址(URL或具有一个字节范围的URL)可访问的内容。可以使用如下的多个元素来描述MPD文件中的时间片段：SegmentList(片段列表)、SegmentBase(片段基础)或SegmentTemplate(片段模板)。

另外，可利用特定片段即初始化片段。该初始化片段包含(在使用ISO BMFF或其扩展对视频进行了封装的情况下)描述封装后的视频流的MP4初始化信息。例如，该初始化片段帮助客户端实例化与视频有关的解码算法。

在MPD中示出初始化片段和媒体片段的HTTP地址。

在图5中，示出示例性MPD文件。在所示的MPD文件中描述两个媒体。第一媒体是英语音频流并且第二媒体是视频流。使用AdaptationSet标签500来引入英语音频流。针对该音频流，可利用两个可选表现：

-第一表现501是比特率为64000bits/sec的封装了MP4的基本音频流。在标准中利用具有值“mp4a.0×40”的属性codecs来定义用于(在该MP4解析之后)处理该基本流的编解码器。可经由针对作为相对URI的通过片段层级体系中的BaseURL(基URL)元素的串接所形成的地址即<BaseURL>7657412348.mp4</BaseURL>的请求来访问第一表现501。利用“http://cdn1.example.com/”或“http://cdn2.example.com/”(可利用两个服务器来对同一内容进行流传输)在MPD元素的顶层所定义的<BaseURL>是绝对URI。然后客户端可以从对地址“http://cdn1.example.com/7657412348.mp4”或对地址“http://cdn2.example.com/7657412348.mp4”的请求中请求英语音频流。

-第二表现502是比特率为32000bits/sec的封装了MP4的基本音频流。可以作出与第一表现501相同的解释，并且客户端装置由此可以通过针对以下地址中的任一地址的请求来请求该第二表现502：

“http://cdn1.example.com/3463646346.mp4”或

“http://cdn2.example.com/3463646346.mp4”。

与视频有关的自适应集503包含六个表现。这些表现包含具有不同的空间分辨率(320×240、640×480、1280×720)并且具有不同的比特率(256000～2048000位/秒)的视频。针对这些表现中的各表现，经由BaseURL元素来关联各个URL。因此客户端可以根据如所估计带宽、屏幕分辨率等那样的不同标准来在同一视频的这些可选表现之间进行选择。(注意，在图5中，为了清楚，没有示出将表现分解成时间片段。)

图5a示出DASH客户端的标准行为。图5b示出图4a所示的方法中所使用的示例性清单文件(描述文件或MPD)的树表现。

在开始流传输会话的情况下，DASH客户端以请求清单文件开始(步骤550)。在等待服务器的响应并且接收到清单文件(步骤551)之后，客户端分析该清单文件(步骤552)，选择适合其环境的AdaptationSet的集合AS_ij(步骤553)，然后在各AdaptationSet AS_ij内选择例如适合其带宽、解码和渲染能力的采用MPD的Representation(步骤554)。

然后，DASH客户端可以预先构建以针对媒体解码器的初始化信息开始的要请求的片段的列表。由于该初始化片段是多个表现、自适应集和时间段所共通的或者是各Representation特有的或者甚至包含在第一媒体片段中，因此必须在MPD中识别该初始化片段(步骤555)。

然后，客户端请求初始化片段(步骤556)。一旦接收到初始化片段(步骤557)，则解码器启动(步骤558)。

然后，客户端以片段为单位请求第一媒体数据(步骤560)，并且在实际开始解码并显示(步骤563)之前，(由于步骤559的条件)对最小数据量进行缓冲。MPD下载和首先显示的帧之间的这多个请求/响应在流传输会话中引入启动延迟。在这些初始步骤之后，DASH流传输会话以标准方式继续进行，即DASH客户端一个接一个地变更并请求媒体片段。

当前DASH版本没有在清单文件内提供关注区域(Region-Of-Interest)的描述。针对这种描述提出了多个方法。

特别地，可以使用SubRepresentation(子表现)元素来描述媒体内容的component(组成部分)。这些元素描述嵌入在Representation中的一个或多个组成部分的性质。在图6中，示出将区块轨描述为视频的组成部分的DASH清单文件的示例。为了简洁和清楚，仅示出一个Period 600。然而，将以相同方式组织后续的时间段元素。在部分601中，使用第一自适应集元素来描述可分级视频的基本层。例如，根据SVC或可分级HEVC来对视频进行编码。在部分602中，使用第二自适应集来描述可分级视频的最高分辨率层。对于非可分级视频，将仅存在第二自适应集602，而不存在对基本层的依赖性即dependencyId属性。在该第二自适应集602中，描述单个表现603、即与可显示的视频相对应的表现。将该表现描述为各自具有客户端请求所用的URL的片段的列表610。

因而，该表现依赖于利用“R1”(dependencyId属性)所标识的另一表现(实际是来自第一自适应集601的基本层表现)。该依赖性迫使流传输客户端在获得针对增强层的当前片段之前，首先请求针对基本层的当前片段。这不能用于表达针对区块轨的依赖性，这是因为会以这种方式被参考的轨将由客户端自动下载。要避免该操作，因为在媒体呈现期间的任何时间选择用户感兴趣的区块是取决于用户的。因此，为了表示复合轨和区块轨之间的依赖性，使用SubRepresentation元素。将可显示视频描述为子表现604～608的列表。各子表现实际代表封装后的MP4文件中的轨。因而，针对各区块(本示例中为四个区块)存在一个子表现并且针对复合轨608存在一个子表现。各子表现利用内容组成部分元素614～618来进行描述，以表示该子表现是与区块轨614、615、616和617相对应还是与复合轨618相对应。DASH/MPD中可利用的Role(角色)描述符类型是连同区块化的具体方案一起使用的。Role描述符还表示区块在全帧视频中的位置。例如，组成部分614描述位于视频的左上方的区块(第一行和第一列为1:1)。将区块的尺寸、宽度和高度指定为子表现的属性(如通过MPD所制定的那样)。还可以将带宽信息放置到此处以帮助DASH客户端根据其带宽来确定区块的数量并选择区块。关于复合轨，由于在下载结束时强制性能够构建可以进行解码的视频流，因此必须以与区块轨不同的方式用信号通知复合轨。为此，向描述添加两个元素。首先，相关内容组成部分618中的描述符表示该组成部分是所有组成部分中的主要组成部分。其次，在子表现中，添加新属性“required(必须)”以向客户端指示必须请求相应数据。根据片段列表610中所设置的URL来计算针对复合轨或者针对区块轨中的一个或多个的所有请求(针对各时间间隔进行一次)。在示例中，与MPD的开头处的“BaseURL”相组合的“URL_X”提供了客户端可以用来进行HTTP GET(HTTP获得)请求的完整URL。利用该请求，客户端将获得复合轨的数据和所有区块轨的所有数据。为了优化传输，代替该请求，客户端可以首先使用可从index_range(索引范围)属性620获得的数据来请求片段索引信息(通常是本领域技术人员众所周知的ISO BMFF中的“ssix”和/或“sidx”信息)。该索引信息使得可以确定各个组成部分的字节范围。然后，DASH客户端可以发送与所选择的轨(包括所需的复合轨)一样多的具有适当的字节范围的HTTP GET请求。

在开始流传输会话时，DASH客户端请求清单文件。一旦接收到清单文件，则客户端分析该清单文件，选择适合其环境的一组自适应集。接着，客户端在各自适应集内选择MPD中符合其带宽、解码和渲染能力的Representation。接着，客户端预先构建以针对媒体解码器的初始化信息开始的要请求的片段的列表。在解码器接收到初始化信息的情况下，这些解码器被初始化，并且客户端在实际开始进行显示之前，请求第一媒体数据并且对最小数据量进行缓冲。

这多个请求/响应可能在流传输会话的启动时引入延迟。其风险是服务提供方注意到其客户端在没有开始观看视频的情况下离开服务。常见是将在客户端所进行的针对第一媒体数据块的初始HTTP请求和该媒体数据块实际开始播放的时间之间的这个时间命名为启动延迟。该启动延迟依赖于网络往返时间，而且还依赖于媒体片段的大小。

服务器推送(Server Push)是用于缩短web资源加载时间的有用特征。参考图1a～1e来论述这些服务器。

在图1b中，示出在HTTP/2交换中，必须针对所需的每个资源即资源R1～R4和子资源A～I(如图1a所示)发送请求。然而，在利用服务器使用推送特征的情况下，如图1c所示，请求的次数局限于元素R1～R4。元素A～I由服务器基于图1a所示的依赖性“推送”至客户端，由此使得关联的请求变得不必要。

因而，如图1b和1c所示，在服务器使用推送特征的情况下，加载资源及其子资源所需的HTTP往返(请求+响应)的次数减少。这是诸如移动网络等的高延迟网络特别关注的。

HTTP是发送web资源(通常是网页)所使用的协议。HTTP向客户端和服务器表明：

·客户端向服务器发送请求；

·服务器利用包含web资源的表现的应答来回复客户端的请求。

请求和应答是包括各个部分(特别是HTTP头部)的消息。HTTP头部包括名称和值。例如，“Host:en.wikipedia.org”是“Host”头部，并且其值是“en.wikipedia.org”。该“Host:en.wikipedia.org”用于表示所查询的资源的主机(例如，描述HTTP的Wikipedia(维基百科)页面可在http://en.wikipedia.org/wiki/HTTP处获得)。HTTP头部出现在客户端请求和服务器应答上。

HTTP/2使得可以经由流来交换请求/应答。针对每个HTTP请求和应答在HTTP/2连接内创建流。帧在流内进行交换，以传送请求和应答的内容和头部。

HTTP/2定义具有不同含义的有限组帧，诸如以下等：

-HEADERS(头部)：其是针对HTTP头部的发送所提供的

-DATA(数据)：其是针对HTTP消息内容的发送所提供的

-PUSH_PROMISE(推送承诺)：其是为了通报所推送的内容所提供的

-PRIORITY(优先级)：其是为了设置流的优先级所提供的

-WINDOW_UPDATE(窗更新)：其是为了更新控制流窗的值所提供的

-SETTINGS(设置)：其是为了传送配置参数所提供的

-CONTINUATION(继续)：其是为了继续头部块片段的序列所提供的

-RST_STREAM(RST流)：其是为了终止或取消流所提供的。

在HTTP/2中引入了利用服务器的推送，以使得服务器能够将未经请求的web资源表现发送至客户端。诸如网页等的web资源通常包含向其它资源的链接，而这些其它资源自身可能包含指向其它资源的链接。为了完全显示网页，客户端通常需要检索所有链接和子链接的资源。特别是在诸如移动网络等的高延迟网络上，该递增式发现可能得到网页的缓慢显示。

在接收到针对给定网页的请求的情况下，服务器可能知晓针对所请求的源的完整处理而需要哪些其它资源。通过同时发送所请求的资源和所链接的资源，服务器使得能够缩短网页的加载时间。因而，使用推送特征，服务器可以在该服务器被请求了给定资源时，发送附加源表现。

参考图1e的流程图来说明实现推送特征的服务器的示例操作模式。

在步骤100期间，服务器接收到初始请求。接着，服务器在步骤101期间识别作为应答的一部分的要推送的资源，并且在步骤102期间开始发送内容应答。并行地，服务器在步骤103期间将推送承诺消息发送至客户端。这些消息例如基于图1a所示的依赖性来标识出服务器正计划推送的其它资源。这些消息是为了让客户端预先知晓将发送哪些推送资源而发送的。特别地，这样降低了客户端针对正同时推送或将要推送的资源发送请求的风险。为了进一步降低该风险，服务器应在发送涉及推送承诺中所描述的资源的应答的任何部分之前，发送推送承诺消息。这样还使得客户端能够在这些客户端不想要这些资源的情况下，请求取消所承诺的资源的推送。接着，服务器在步骤104期间发送应答和所有承诺的资源。该处理在步骤105期间结束。

图1d的流程图示出客户端侧的处理。

在客户端识别出要从服务器检索的资源的情况下，客户端首先在步骤106期间检查相应数据是否已存在于该客户端的高速缓冲存储器中。在资源已存在于高速缓冲存储器中的情况下(“是”)，在步骤107期间从该高速缓冲存储器检索该资源。高速缓存数据可以是根据先前的请求所检索到的数据或者服务器先前推送的数据。在资源不存在于高速缓冲存储器中的情况下(“否”)，客户端在步骤108期间发送请求并且等待服务器的应答。在从服务器接收到帧时，客户端在步骤109期间检查该帧与PUSH承诺是否对应。如果数据帧与PUSH承诺相对应(“是”)，则在步骤110期间，客户端处理推送承诺。客户端识别要推送的资源。如果客户端不希望接收资源，则客户端可以向服务器发送错误消息，因而服务器不会推送该资源。否则，客户端存储该推送承诺，直到接收到相应的推送内容为止。使用推送承诺，使得在服务器正推送所承诺的资源的情况下，客户端不会请求该所承诺的资源。在数据帧与PUSH承诺不对应的情况下(“否”)，在步骤111期间检查该帧是否是与推送数据有关的数据帧。在该帧与推送数据有关的情况下(“是”)，客户端在步骤112期间处理所推送的数据。将所推送的数据存储在客户端高速缓存内。在该帧不是与推送数据有关的数据帧的情况下，在步骤113期间检查该帧与从服务器接收到的应答是否对应。在帧与来自服务器的应答相对应的情况下(“是”)，在步骤114期间处理该应答(例如，发送至应用程序)。否则(“否”)，在步骤115期间检查帧是否标识出应答的结束(“是”)。在这种情况下，在步骤116期间终止该处理。否则，处理返回至步骤109。

因而，似乎客户端接收到应答和所承诺的资源。因此，所承诺的资源通常存储在客户端高速缓存中，同时应答由诸如显示所检索到的网页的浏览器等的应用程序使用。在客户端应用程序请求所推送的资源其中之一的情况下，从客户端高速缓存立即检索到该资源，而不会引起任何网络延迟。

使用高速缓存控制指令来控制高速缓存中的所推送的资源的存储。高速缓存控制指令还用于进行应答的控制。这些指令特别适用于代理：所推送的或未被推送的任何资源均可仅由代理或仅由客户端来进行存储。

图1a是服务器所拥有的一组资源及其关系的图。该组资源交织存在：R₁、R₂、R₃和R₄是需要共同下载以由客户端进行适当处理的资源。另外，定义了子资源A～H。这些子资源与1个、2个或3个资源相关。例如，A链接至R₁，并且C链接至R₁、R₂和R₄。

以上已论述的图1b示出没有使用服务器PUSH特征的HTTP交换：客户端请求R₁，接着发现R₂、A、B、C和D并且请求这五者。在接收到这些资源之后，客户端请求R₃、R₄、F和G。最后，客户端请求H子资源和I子资源。这样需要四次往返以检索到整组资源。

以上已论述的图1c示出服务器使用直接推送所连接的子资源这一特征的HTTP交换。在请求R₁之后，服务器发送R₁并且推送A、B、C和D。客户端识别出R₂并且请求该R₂。服务器发送R₂并且推送F和G。最后，客户端识别出R₃和R₄并且请求这些资源。服务器发送R₃和R₄并且推送H和I。该处理需要三次往返以检索整组资源。

为了缩短一组资源(通常是网页及其子资源)的加载时间，HTTP/2使得能够并行地交换多个请求和应答优先级。如图2所示，网页可以要求下载如JavaScript、图像等的多个资源。在初始HTTP交换200期间，客户端检索HTML文件。该HTML文件包含指向两个JavaScript文件(JS1,JS2)、两个图像(IMG1,IMG2)、一个CSS文件和一个HTML文件的链接。在交换201期间，客户端针对各文件发送请求。图2的交换201中所给出的顺序基于网页顺序，即，一发现链接，客户端就发送请求。然后，服务器接收到针对JS1、CSS、IMG1、HTML、IMG2和JS2的请求，并且根据该顺序来处理这些请求。然后，客户端按该顺序检索这些资源。

HTTP优先级使得客户端可以声明哪些请求与其它请求相比更加重要并且应更快地进行处理。在交换202中示出优先级的特殊使用。向JavaScript文件分配最高优先级。向CSS文件和HTML文件分配中等优先级，并且向图像分配低优先级。该方法使得能够与其它文件相比更快地接收阻塞式文件(blocking file)或者可能包含对其它资源的参考的文件。在进行响应时，如交换202所述，预期服务器会试图更快地发送JavaScript文件，之后发送CSS文件和HTML文件，最后发送图像。不强制服务器遵循客户端优先级。

除优先级外，HTTP/2提供了可以控制同时交换的数据量。客户端和服务器可以指定这两者可以以每连接为单位以及以每流为单位缓冲多大的数据量。这与TCP拥塞控制相同：将指定可用缓冲器大小的窗大小初始化为给定值；每次发射器发送数据时，窗大小递减；发射器必须停止发送数据，使得窗大小不会变为零以下。接收器接收到数据并且发送用以确认从缓冲器接收到数据并且从缓冲器移除了该数据的消息；该消息包含从缓冲器移除的数据量；然后窗大小从给定值开始增加并且发射器可以重新开始发送数据。

有鉴于上述，似乎DASH基于如下假设：由于客户端为了其正进行的应用程序的目的而通常可以选择内容的最佳表现，因此客户端引导流传输。例如，客户端可以基于其尺寸规格和屏幕分辨率而知晓要请求高清晰度内容还是小清晰度内容。

通常使用RTP来进行基于服务器的流传输。与DASH相反，RTP不使用HTTP，并且无法直接受益于web基础设施、特别是代理和高速缓存。基于web套接字的媒体流传输存在相同的缺陷。利用HTTP/1.1，由于服务器通常仅可以对客户端请求进行回答，因此无法容易地实现基于服务器的流传输。利用HTTP/2，特别是随着推送特征的引入，基于DASH的服务器可以引导流传输。因而，服务器可以使用与这些服务器正在进行流传输的内容的特性有关的知识来优化用户体验。例如，服务器可以将影片作为SD(由于有限带宽) 进行推送但将广告作为HD进行推送，这是因为广告占用附加的有限量的带宽。另一示例是服务器以低分辨率视频开始进行快速启动，并且一旦良好地估计出带宽，就切换为可能的最佳表现。

为了使得服务器能够引导流传输，一个方法是令服务器按优选方式推送数据(特别是DASH数据)。然后，客户端使用任何可用数据以显示视频。服务器通常一次通报多个片段的推送。然后，服务器并行地或连续地发送这些片段。

发生的问题是客户端和服务器可能并不知晓是否将在期望时间发送并接收所承诺的数据，即，客户端可能并不知晓将何时按何顺序发送视频片段。

此外，服务器所推送或通报的所承诺的数据可能与客户端需求不匹配，由此导致特别是在服务器端的资源浪费。

因而，特别是在基于DASH的通信的背景下需要使流传输增强。

发明内容

本发明存在于该背景下。

根据本发明的与服务器的角度相对应的第一方面，一种用于利用服务器装置将媒体数据流传输至客户端装置的方法，所述方法包括以下步骤：

-从所述客户端装置接收与第一媒体数据有关的请求；

-识别要发送至所述客户端装置的未被请求的第二媒体数据；以及

-响应于所述请求，将与所述第一媒体数据有关的数据发送至所述客户端装置，并且准备分别标识出具有视图的所述第二媒体数据的至少一个通报消息，以将一个或多个所述通报消息发送至所述客户端装置，

其中，所述方法还包括以下步骤：将与所述客户端装置共享的推送策略用于所述服务器装置，以推动非请求的所述第二媒体数据的识别或者非请求的所述第二媒体数据向所述客户端装置的发送。

根据本发明的与客户端的角度相对应的第二方面，一种用于利用客户端装置访问由服务器装置进行流传输的媒体数据的方法，所述方法包括以下步骤：

-将与第一媒体数据有关的请求发送至所述服务器装置；以及

-响应于所述请求，从所述服务器装置接收与所述第一媒体数据有关的数据，

其中，所述方法还包括以下步骤：将与所述服务器装置共享的推送策略用于所述客户端装置，以确定所述服务器装置要发送的未被所述客户端装置请求的第二媒体数据、或者确定所述服务器装置所进行的所述第二媒体数据的传输顺序。

特别地，所共享的推送策略可以定义如何确定第二媒体数据，以供装置确定所述服务器装置要发送至所述客户端装置的非请求的所述第二媒体数据。

由于该方法，因此可以减少服务器针对要推送的媒体数据的决定和客户端的需求之间的不匹配，因而可以节省资源。

这通过使用使得客户端可以预期服务器的行为、并由此预期将要推送的第二媒体数据的共享推送策略来实现。由于共享推送策略可用于多个客户端的后续请求，因此客户端甚至可以在向服务器发送请求之前预期服务器的行为。

作为该预期的结果，客户端可以针对服务器所进行的通报以预期方式准备并请求取消不需要的这种第二媒体数据。

与第一媒体数据有关的请求可以涉及第一媒体数据和/或与该第一媒体数据有关的其它数据。

例如利用服务器装置，第二媒体数据可以与所述第一媒体数据相关联。

本发明的实施例提供针对服务器引导型流传输的轻量型机制。可以在DASH网络的背景下实现实施例。

服务器装置可以向客户端装置进行内容推荐。此外，服务器装置可以优化网络使用。

本发明的实施例与现有的HTTP/2特征兼容。这些特征可以有利地用于实现本发明的实施例。

总体提高了网络性能。

结果，本发明还考虑一种服务器装置，用于将媒体数据流传输至客户端装置，所述服务器装置包括：

-接收器，用于从所述客户端装置接收与第一媒体数据有关的请求；

-控制单元，用于识别要发送至所述客户端装置的未被请求的第二媒体数据；以及

-发送器，用于响应于所述请求，将与所述第一媒体数据有关的数据发送至所述客户端装置，并且准备分别标识出具有视图的所述第二媒体数据的至少一个通报消息，以将一个或多个所述通报消息发送至所述客户端装置，

其中，所述控制单元还使用与所述客户端装置共享的推送策略，以推动非请求的所述第二媒体数据的识别或者非请求的所述第二媒体数据向所述客户端装置的发送。

本发明还考虑一种客户端装置，用于访问由服务器装置进行流传输的媒体数据，所述客户端装置包括：

-发送器，用于将与第一媒体数据有关的请求发送至所述服务器装置；以及

-接收器，用于响应于所述请求，从所述服务器装置接收与所述第一媒体数据有关的数据，

其中，所述客户端装置使用与所述服务器装置共享的推送策略，以确定所述服务器装置要发送的未被所述客户端装置请求的第二媒体数据、或者确定所述服务器装置所进行的所述第二媒体数据的传输顺序。

服务器和客户端装置具有与如上所述的相应方法相同的优点。

在从属权利要求中定义了方法和装置的可选特征。以下针对方法来说明这些特征中的一部分特征。然而，这些特征还可适用于相应的装置。

在以下称为显式方法的一些实施例中，从服务器的角度的方法还包括以下步骤：

利用所述服务器装置确定推送策略；以及

从所述服务器装置向所述客户端装置发送描述所确定的推送策略的推送策略信息，以与所述客户端装置共享所述推送策略。

相应地，在客户端侧，所述方法还可以包括：从所述服务器装置接收描述所共享的推送策略的推送策略信息。

如以下在一些示例中所述，将描述所共享的推送策略的推送策略信息插入从所述服务器装置发送至所述客户端装置的描述文件中，所述描述文件包含与包括所述第一媒体数据的媒体数据有关的描述信息，所述方法还包括以下步骤：使用所共享的推送策略来基于所述描述文件确定非请求的所述第二媒体数据。

在特定实施例中，所述描述文件使用多个媒体数据属性级别来描述所述媒体数据，并且以所述描述文件的各个级别定义各种共享的推送策略。

在其它示例中，将描述所共享的推送策略的推送策略信息嵌入在从所述服务器装置发送至所述客户端装置的HTTP帧的头部中。

根据特定特征，所述方法还包括以下步骤：在所述服务器装置处，从所述客户端装置接收嵌入在HTTP帧的头部中的推送策略更新信息，并且在根据所述客户端装置所请求的其它媒体数据确定非请求的媒体数据之前，相应地更新所共享的推送策略。

相应地，所述方法还可以包括以下步骤：在所述客户端装置处，将嵌入在HTTP帧的头部中的推送策略更新信息发送至所述服务器装置。

根据混合方法，描述所共享的推送策略的推送策略信息由第一推送策略部分和第二推送策略部分来定义，所述第一推送策略部分插入在从所述服务器装置发送至所述客户端装置的描述文件中，所述描述文件包含与包括所述第一媒体数据的媒体数据有关的描述信息，所述方法还包括以下步骤：使用所共享的推送策略来基于所述描述文件确定非请求的所述第二媒体数据，以及所述第二推送策略部分嵌入在从所述服务器装置发送至所述客户端装置的HTTP帧的头部中。

例如，所述第二推送策略部分包括所述第一推送策略部分中所定义的一个或多个关联变量的一个或多个值。

此外，所述描述文件包括多个候选推送策略的描述，并且所述第二推送策略部分包括来自所述多个候选推送策略中的候选推送策略的标识符，其中所述标识符标识候选推送策略，由此形成所述第一推送策略部分。

在其它实施例中，所述推送策略信息包括嵌入在从所述服务器装置发送至所述客户端装置的网页中的JavaScript程序。

在另外其它实施例中，所述方法还包括基于结构化文档(诸如上述的描述文件或以下的示例中所引入的HTML页)确定非请求的所述第二媒体数据，所述结构化文档包含与包括所述第一媒体数据的媒体数据有关的描述信息，以及

所述推送策略信息包括所述结构化文档的树表现上的待评价的XPath表达式，以识别非请求的所述第二媒体数据。

关于推送策略信息的句法，实施例提供了所述推送策略信息包括定义描述文件中要标识的非请求的所述第二媒体数据的量的第一推送属性，

所述描述文件包含与包括所述第一媒体数据的媒体数据有关的描述信息，并且所述方法还包括以下步骤：使用所共享的推送策略来基于所述描述文件确定非请求的所述第二媒体数据。

根据特定特征，所述第一推送属性相对于所述描述文件内所请求的所述第一媒体数据来标识非请求的所述第二媒体数据。

在变形例中，所述第一推送属性是所述描述文件内的特定媒体数据的标识符。

根据特定特征，所述描述文件中的描述信息根据如下所述的至少一个媒体数据属性来描述媒体数据：定义媒体数据所属于的时间段的时间段属性、定义媒体数据的媒体类型的自适应属性、定义媒体数据的编码版本的表现属性(例如，比特率、帧频、帧分辨率、定时信息等)和进行定义的片段属性，以及

所述推送策略信息至少包括定义针对一个或多个所述媒体数据属性的制约的第二推送属性，以标识非请求的所述第二媒体数据。

这样使得可以在整个描述文件中具有非常具有选择性的推送策略。

特别地，一个或多个所述推送属性可以相对于所述描述文件内的所述第一媒体数据的相应的一个或多个媒体数据属性来定义非请求的所述第二媒体数据的一个或多个媒体数据属性。

可选地，一个或多个所述推送属性可以标识出所述描述文件中的节点，其中必须在所述节点中检索非请求的所述第二媒体数据。

在一些实施例中，所述描述文件中的描述信息包括与媒体数据相关联的优先级属性，其中针对各媒体数据存在一个优先级属性，并且所述第二媒体数据的传输顺序基于所关联的优先级属性。这是为了定义推送数据的传输顺序。

在实施例中，所共享的推送策略根据所请求的第一媒体数据来识别所述第二媒体数据。

在以下称为显式方法的实施例中，所共享的推送策略是在所述服务器装置和所述客户端装置这两者处使用相同的第二媒体数据确定算法所实现的，其中所述第二媒体数据确定算法使得所述服务器装置和所述客户端装置能够根据所请求的第一媒体数据来确定相同的第二媒体数据。

在适用于显式方法和混合方法这两者的一些实施例中，在所识别出的第二媒体数据包括各自需要通报消息的多个媒体片段的情况下，所述方法还包括以下步骤：将相应的多个通报消息合并成单个通报消息，以发送至所述客户端装置。这是为了由于将发送较少的通报消息因此减少带宽消耗。

为了实际利用共享推送策略以及客户端装置所进行的推送的结果预期，所述方法还可以包括以下步骤：从所述客户端装置接收请求取消非请求的所述第二媒体数据的一部分的发送的取消请求，使得所述服务器装置不发送所准备的相应通报消息。

相应地，在客户端处，所述方法还可以包括以下步骤：将请求取消非请求的所述第二媒体数据的一部分的发送的取消请求发送至所述服务器装置，以推动所述服务器装置不发送标识出非请求的所述第二媒体数据的该部分的通报消息。

在本发明的实施例中，非请求的所述第二媒体数据是由所述客户端装置独立于至少一个通报消息所确定的，其中所述至少一个通报消息是所述服务器装置所准备的(以及可能从所述服务器装置所接收到的)，并且标识出所述服务器装置意图发送至所述客户端装置的未被请求的非请求的第二媒体数据。这里，“独立”是指客户端装置能够在无需知晓专用于向客户端装置通报第二非请求的数据的将来发送的通报消息(即，PUSH_PROMISE)的情况下，能够对这种非请求的数据进行判断。

在本发明的其它实施例中，使用相同的所共享的推送策略来根据与各个第一媒体数据有关的多个请求确定各个非请求媒体数据。通过使用随时间的经过并且针对连续请求使用同一推送策略，客户端甚至能够高效地预期服务器所进行的无用数据的发送，由此能够高效地取消这些发送以及相应的通报消息的发送。

关于从服务器向客户端的推送数据的传输顺序的通知，一种用于利用服务器装置向客户端装置流传输媒体数据的方法，可以包括以下步骤：

-从所述客户端装置接收与第一媒体数据有关的请求；

-识别要发送至所述客户端装置的未被请求的第二媒体数据；

-响应于所述请求，将与所述第一媒体数据有关的数据和分别标识出所述第二媒体数据的至少一个通报消息传输至所述客户端装置，以及

其中，所述方法还包括以下步骤：

-利用所述服务器装置来定义所述第二媒体数据的传输顺序(这构成所共享的推送策略的全部或一部分)，

-利用所述通报消息来发送与所述传输顺序有关的信息，所述信息使得所述客户端装置能够确定所述服务器所定义的传输顺序。

例如，所述第二媒体数据的传输顺序是根据所述客户端装置基于优先级值所定义的，其中首先发送优先级值最高的媒体数据。

所述优先级值是根据HTTP/2协议所定义的。

根据实施例，至少一个优先级值与网络带宽估计机制相关联，所述方法还包括以下步骤：

-将具有与所述机制相关联的优先级值的第二媒体数据发送至所述客户端装置；

-响应于所述第二媒体数据来从所述客户端装置接收至少一个控制流量消息；以及

-基于所接收到的所述至少一个控制流量消息来估计可用带宽。

例如，所述服务器装置根据各自具有不同大小的多个数据帧来发送所述第二媒体数据。

所述方法还可以包括以下步骤：利用所述服务器装置来基于所述带宽估计定义所述第二媒体数据的更新后的传输顺序。

根据实施例，来自所述客户端装置的请求包括用于接收与包括所述第一媒体数据的媒体数据有关的描述文件的请求，所述描述文件包含关于所述第一媒体数据的描述信息，所述方法还包括以下步骤：基于所述描述文件来确定非请求的所述第二媒体数据。

例如，所请求的第一媒体数据是视频片段。

所述流传输是根据DASH标准来进行的。

例如，所述方法还可以包括以下步骤：

-从所述客户端装置接收排序更新请求；

-基于所述排序更新请求来定义所述第二媒体数据的新传输顺序，并且更新与所述第二媒体数据的新传输顺序有关的信息；以及

-根据更新后的与传输顺序有关的信息来将所述第二媒体数据发送至所述客户端装置。

所述方法还可以包括以下步骤：将排序更新确认消息发送至所述客户端装置。

例如，更新后的顺序是针对第二媒体数据所定义的，其中在接收到所述排序更新请求时尚未开始向所述客户端装置发送所述第二媒体数据。

例如，所述排序更新请求包括针对所述第二媒体数据的至少一部分的排序值。

根据实施例，所述第二媒体数据的传输顺序是根据优先级值所定义的，以及在针对第一媒体数据的至少一部分更新了优先级值的情况下，相应地更新针对要发送至所述客户端装置的未被请求的并且与所述第一媒体数据的所述至少一部分相关联的第二媒体数据的至少一部分的优先级值。

例如，所述第一媒体数据和所述第二媒体数据是根据时间关系、空间关系和质量关系中的至少一个而相关联的。

根据实施例：

-所述第二媒体数据包括用于增强所述第一媒体数据的质量的增强数据，以及

-在针对增强层的媒体数据更新优先级值的情况下，针对所述增强层的所有媒体数据更新优先级值。

例如，所述第一媒体数据和所述第二媒体数据包括视频时间片段，以及所述增强媒体数据的开始时间基于与所述第一媒体数据的视频内容有关的信息。

例如，与所述第一媒体数据的视频内容有关的信息存储在所述描述文件中。

例如，所述传输顺序至少基于所述第一媒体数据和所述第二媒体数据之间的解码关系。

例如，所述传输顺序至少基于媒体数据的统计流行度。

例如，所述传输顺序至少基于所述客户端装置端的媒体数据的播放时间。

例如，所述传输顺序至少基于媒体数据的估计传输时间。

例如，所述传输顺序至少基于用户定义的针对媒体数据的兴趣。

所述方法还可以包括以下步骤：

-从所述客户端装置接收控制消息，所述控制消息使得所述服务器装置能够识别当前正播放的媒体数据；

-利用所述服务器装置基于所述控制消息来定义所述第二媒体数据的更新后的传输顺序；以及

-根据所述更新后的传输顺序来将所述第二媒体数据发送至所述客户端装置。

所述方法还可以包括以下步骤：将排序更新确认消息发送至所述客户端装置。

例如，所述控制消息涉及所述客户端装置的缓冲存储器的使用，所述缓冲存储器存储媒体数据以供所述客户端装置播放这些媒体数据。

例如，所述服务器装置保持所发送的所请求的第一媒体数据的记录，以及基于所述缓冲存储器的使用和所述记录来进行所述第二媒体数据的识别。

例如，所述传输顺序的信息是在所述通报消息内发送的。

例如，所述传输顺序的信息是在所述通报消息之后的专用消息内发送的。

从客户端的角度，一种用于利用客户端装置访问服务器装置进行流传输的媒体数据的方法，可以包括以下步骤：

-向所述服务器装置发送与第一媒体数据有关的请求；

-响应于所述请求而从所述服务器装置接收与所述第一媒体数据有关的数据、以及分别标识出要发送至所述客户端装置的未被请求的第二媒体数据的至少一个通报消息，

其中，所述方法还包括以下步骤：

-利用所述通报消息来接收与所述第二媒体数据的传输顺序有关的信息，所述信息(即，共享推送策略)使得所述客户端装置能够确定所述服务器装置所定义的所述第二媒体数据的传输顺序。

所述方法还可以包括以下步骤：利用所述客户端装置来判断所述服务器装置所定义的所述第二媒体数据的传输顺序是否满足所述客户端装置端的流传输制约，并且在不满足所述制约的情况下，将排序更新请求发送至所述服务器装置。

例如，所述第二媒体数据的传输顺序是根据所述客户端装置基于优先级值所定义的，其中首先发送优先级值最高的媒体数据。

例如，所述优先级值是根据HTTP/2协议所定义的。

根据实施例，至少一个优先级值与网络带宽估计机制相关联，所述方法还包括以下步骤：

-从所述服务器装置接收优先级值与所述机制相关联的第二媒体数据；以及

-响应于所述第二媒体数据将至少一个控制流量消息发送至所述服务器装置，由此使得所述服务器装置能够基于所发送来的至少一个控制流量消息来估计可用带宽。

例如，所述客户端装置根据各自具有不同大小的多个数据帧来接收所述第二媒体数据。

例如，所述第二媒体数据的更新后的传输顺序是由所述服务器装置基于所述带宽估计来定义的。

例如，来自所述客户端装置的请求包括用于接收与包括所述第一媒体数据的媒体数据有关的描述文件的请求，所述描述文件包含关于所述第一媒体数据的描述信息，所述方法还包括以下步骤：基于所述描述文件来确定非请求的所述第二媒体数据。

例如，所请求的第一媒体数据是视频片段。

例如，所述流传输是根据DASH标准来进行的。

所述方法还可以包括以下步骤：根据与所述服务器装置所定义的所述第二媒体数据的新传输顺序有关的更新后的信息，来从所述服务器装置接收所述第二媒体数据。

所述方法还可以包括以下步骤：从所述服务器装置接收排序更新确认消息。

根据实施例，更新后的顺序是针对所述第二媒体数据所定义的，在所述服务器装置接收到所述排序更新请求时尚未开始从所述服务器装置发送所述第二媒体数据。

根据实施例，所述排序更新请求包括针对所述第二媒体数据的至少一部分的排序值。

根据实施例，所述第二媒体数据的传输顺序是根据优先级值所定义的，以及在针对第一媒体数据的至少一部分更新了优先级值的情况下，相应地更新针对要发送至所述客户端装置的未被请求的并且与所述第一媒体数据的所述至少一部分相关联的第二媒体数据的至少一部分的优先级值。

例如，所述第一媒体数据和所述第二媒体数据是根据时间关系、空间关系和质量关系中的至少一个而相关的。

根据实施例：

-所述第二媒体数据包括用于增强所述第一媒体数据的质量的增强数据，以及

-在针对增强层的第一媒体数据的至少一部分更新优先级值的情况下，针对所述增强层的所有媒体数据更新优先级值。

例如，所述第一媒体数据和所述第二媒体数据包括视频时间片段，以及所述增强媒体数据的开始时间基于与所述第一媒体数据的视频内容有关的信息。

根据实施例，与所述第一媒体数据的视频内容有关的信息存储在所述描述文件中。

根据实施例，所述传输顺序至少基于所述第一媒体数据和所述第二媒体数据之间的解码关系。

根据实施例，所述传输顺序至少基于媒体数据的统计流行度。

根据实施例，所述传输顺序至少基于所述客户端装置端的媒体数据的播放时间。

根据实施例，所述传输顺序至少基于媒体数据的估计传输时间。

根据实施例，所述传输顺序至少基于用户定义的针对媒体数据的兴趣。

所述方法还可以包括以下步骤：

-将控制消息发送至所述服务器装置，所述控制消息使得所述服务器装置能够识别当前正播放的媒体数据；以及

-根据所述服务器装置基于所述控制消息所定义的更新后的传输顺序，从所述服务器装置接收所述第二媒体数据。

所述方法可以包括以下步骤：从所述服务器装置接收排序更新确认消息。

例如，所述控制消息涉及所述客户端装置的缓冲存储器的使用，所述缓冲存储器存储媒体数据以供所述客户端装置播放这些媒体数据。

根据实施例，所述服务器装置保持所发送的第一媒体数据的记录，以及基于所述缓冲存储器的使用和所述记录来进行当前正播放的媒体的识别。

例如，所述传输顺序的信息是在所述通报消息内发送的。

例如，所述传输顺序的信息是在所述通报消息之后的专用消息内发送的。

仍参考传输顺序，一种用于利用代理服务器管理客户端装置和服务器装置之间的数据交换的方法，所述方法包括以下步骤：

-从实现如上所定义的关于传输顺序的通知的方法的服务器接收要再发送至客户端装置的媒体数据；

-基于所述媒体数据的传输顺序来确定所述媒体数据的再发送优先级；以及

-基于所确定出的再发送优先级来进行所接收到的媒体数据向所述客户端装置的再发送。

所述方法还可以包括以下步骤：基于所确定出的再发送优先级来存储所接收到的媒体数据。

所述方法还可以包括以下步骤：

-从实现根据第二方面所述的方法的客户端装置接收排序更新请求；

-在所述排序更新请求与要再发送的媒体数据有关的情况下，根据所述排序更新请求来更新所述再发送优先级；以及

-根据更新后的再发送优先级来进行所述媒体数据的再发送。

所述方法还可以包括以下步骤：

-从第一客户端装置接收针对媒体数据的向第一服务器装置的请求，其中所述媒体数据由所述代理服务器存储以从第二服务器装置再发送至第二客户端装置；

-利用所述第一服务器装置和所述第二服务器装置确定分别与所述媒体数据相关联的优先级值；

-根据针对所述第一客户端装置和所述第二客户端装置各自的流传输制约来更新所述优先级值；以及

-根据更新后的优先级值将所述媒体数据再发送至所述第一客户端装置和所述第二客户端装置，

其中，所述第一服务器装置和所述第二服务器装置实现根据第一方面所述的方法，并且所述第一客户端装置和所述第二客户端装置实现根据第二方面所述的方法。

所述方法还可以包括以下步骤：将与更新后的优先级值有关的更新通知发送至所述第一服务器装置和所述第二服务器装置。

根据本发明的另一方面，提供一种用于在服务器装置和客户端装置之间对数据进行流传输的方法，所述方法包括以下步骤：

-利用服务器装置进行根据第一方面的方法；以及

-利用客户端装置进行根据第二方面的方法。

根据本发明的还一方面，提供一种包括指令的计算机程序和计算机程序产品，所述指令用于在利用可编程设备的计算机上加载并执行的情况下，实现如上所定义的方法。

根据本发明的还一方面，提供一种服务器装置，其被配置为实现根据第一方面的方法。

根据本发明的还一方面，提供一种客户端装置，其被配置为实现根据第二方面的方法。

提出了用于从服务器向客户端装置进行媒体数据的自适应流传输的解决方法，以特别使发送至客户端装置的数据的类型和数量适应所关注的客户端装置的特征并且适应网络的特性，从而提供服务器和客户端装置之间的连接。

在该背景下，诸如DASH(经由HTTP的动态自适应流传输)标准等的一些解决方案提出了存储多个版本的要分发的资源(或内容)，并且向请求该资源的客户端装置请求包括表现该资源的各种版本的描述的描述文件和指向这些版本的各个指针(例如，URL)。

然后，基于该描述文件，客户端装置可以选择与其需求最匹配的资源的版本并且使用相应的指针来请求该版本。

由于描述文件不包含媒体数据(仅包含指向媒体数据的指针)，因此该解决方案在描述文件为轻量型这一方面是有利的。通过令客户端选择相关版本供其使用而避免了可能会不适合该客户端装置的媒体数据的交换。此外，这适合当前基于HTTP的Web架构并且可以利用已部署的高速缓存机制。

然而，反过来，该解决方案需要在客户端装置处接收到媒体数据之前在客户端装置和服务器之间进行多次交换(或往返)，然后可以进行解码并显示，从而产生启动延迟。

在实施例中，本发明提供一种用于从存储表现媒体项(例如，视频)的数据的服务器提供表现所述媒体项的媒体数据的方法，所述媒体项的至少时间片段由多个版本来表现，所述方法包括所述服务器所实现的以下步骤：

-从客户端装置接收针对描述文件的请求，所述描述文件包括表现时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-从所述描述文件中的所指向的数据集合中选择数据；

-将所述描述文件发送至所述客户端装置；以及

-将所选择的数据推送至所述客户端装置。

通过推送以适当方式选择的数据(即，发送未经客户端装置请求的、而是如以下进一步说明的由服务器所选择的数据)，可以避免一次或多次往返，并且可以如此更快地开始媒体数据的解码和显示。

媒体项例如可以是视频项、或者例如诸如音频轨等的音频项。

可以注意，上述的数据集合包括表现时间片段的版本，而且还可以包括诸如以下所述的初始化数据等的其它数据。

如刚刚所述，所选择的数据还可以包括针对客户端装置的解码器的初始化数据。如此可以在客户端装置不必特意请求该初始化数据的情况下对解码器进行初始化，因而更快。

如上所述，所选择的数据还可以包括表现所述时间片段的版本中的一个版本的至少一部分。

选择数据的步骤可以包括估计要推送的数据(例如，视频数据)的数量，然后可以在决定要选择哪些数据时使用该数量。可以基于描述文件中所定义的缓冲时间和/或服务器所确定的带宽估计来估计该数量。

选择数据的步骤可以基于请求中所包括的至少一个偏好、以及/或者基于根据服务器和客户端装置之间的先前交换所推导出的使用数据、以及/或者基于服务器对描述文件的分析、以及/或者基于服务器中所存储的与描述文件相关联的表来进行。

根据可能的实施例，可以在推送所选择的数据的步骤之前设置发送与所选择的数据的推送有关的推送承诺的步骤。如此可以在实际接收这些数据之前向客户端装置通知要推送的数据。

可以在发送描述文件的步骤之前进行发送推送承诺的步骤，从而使得可以及早通知客户端装置。

推送承诺例如包括所选择的数据的识别。

根据所提出的实施例，服务器确定与所选择的数据相关联的置信度，并且推送承诺包括所确定的置信度。

根据以下给出的具体实施方式部分所述的可能实现，所述服务器可以存储构成所选择的数据的数据块的层级表现。在这种情况下，可以设置以下步骤：

-从所述客户端装置接收不推送数据块的指示；以及

-取消所述数据块的推送、以及所述层级表现中的与所述数据块相连接的数据块的推送。

所提出的方法可以包括以下步骤：

-在所确定的置信度为预定阈值以下的情况下，推送所选择的数据包括：仅推送针对所述客户端装置的解码器的初始化数据；以及

-在所确定的置信度为所述预定阈值以上的情况下，推送所选择的数据包括：推送针对所述客户端装置的解码器的初始化数据以及表现所述时间片段的版本中的一个版本的至少一部分。

本发明的实施例还提供一种用于从存储表现媒体项的数据的服务器接收表现所述媒体项的媒体数据的方法，所述媒体项的至少时间片段由多个版本来表现，所述方法包括客户端装置所实现的以下步骤：

-向所述服务器发送针对描述文件的请求，所述描述文件包括表现所述时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-从所述服务器接收所述描述文件，所述描述文件包含指向数据集合的指针；以及

-从所述服务器接收未经请求数据，其中所述未经请求数据属于所述数据集合。

如上所述，所述未经请求数据包括针对所述客户端装置的解码器的初始化数据(在该情况下，可以提供利用所述未经请求的数据对所述解码器进行初始化的步骤)以及/或者表现所述时间片段的版本中的一个版本的至少一部分(在该情况下，可以提供对所述未经请求的数据的至少一部分进行解码的步骤)。

所述请求包括定义所述客户端装置处的解码的至少一个偏好，从而可以帮助服务器确定要推送的媒体内容。

所述请求包括所述客户端装置接受所推送的数据的指示，其中基于该指示符，服务器可以有效地决定推送数据。

如上所述，在接收未经请求的数据之前接收与未经请求的数据的接收有关的推送承诺。该接收推送承诺的步骤可以在接收描述文件的步骤之前进行。

所述推送承诺可以包括所述未经请求数据的识别。所述推送承诺可以包括所述未经请求的数据的识别以及/或者与所述未经请求的数据相关联的置信度。

可以在客户端装置处所提供以下步骤：

-基于所述推送承诺中所包括的数据来判断是接受还是拒绝该推送承诺；以及

-在拒绝的情况下，发送不推送所述未经请求数据的指示。

还可以使用以下步骤：

-基于所述推送承诺中所包括的与所述未经请求数据相关联的置信度来判断是接受还是拒绝该推送承诺；以及

-在拒绝的情况下，发送不推送所述未经请求数据的指示。

可以使用用于在接收到所述未经请求的数据时、在对这些数据进行解码之前对所述未经请求的数据进行缓冲的步骤。

由于所推送的数据意图仅与初始化数据和/或初始媒体数据相对应，因此可以实现以下步骤：

-基于所述描述文件和所述推送承诺中所包括的数据来确定要请求的数据；以及

-将针对所确定出的数据的请求发送至所述服务器。

本发明的实施例还提出一种用于从存储表现媒体项的数据的服务器将表现所述媒体项的媒体数据流传输至客户端装置的方法，所述媒体项的至少时间片段由多个版本来表现，所述方法包括以下步骤：

-所述客户端装置将针对描述文件的请求发送至所述服务器，所述描述文件包括表现所述时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-所述服务器从所述客户端装置接收所述请求；

-所述服务器从所述描述文件中所指向的数据集合中选择数据；

-所述服务器将所述描述文件发送至所述客户端装置；

-所述服务器将所选择的数据推送至所述客户端装置；

-所述客户端装置从所述服务器接收所述描述文件；以及

-所述客户端装置从所述服务器接收所选择的数据。

本发明的实施例还提供一种用于从存储表现媒体项的数据的服务器提供表现所述媒体项的媒体数据的装置，所述媒体项的至少时间片段由多个版本来表现，所述装置包括：

-接收器，用于从客户端装置接收针对描述文件的请求，所述描述文件包括表现所述时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-选择模块，用于从所述描述文件中所指向的数据集合中选择数据；

-用于将所述描述文件发送至所述客户端装置的模块；以及

-用于将所选择的数据推送至所述客户端装置的模块。

本发明的实施例还提供一种用于从存储表现媒体项的数据的服务器接收表现所述媒体项的媒体数据的装置，所述媒体项的至少时间片段由多个版本来表现，所述装置包括：

-用于将针对描述文件的请求发送至所述服务器的模块，所述描述文件包括表现所述时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-用于从所述服务器接收所述描述文件的模块，其中所述描述文件包含指向数据集合的指针；以及

-用于从所述服务器接收未经请求数据的模块，其中所述未经请求数据属于所述数据集合。

最后，本发明的实施例提供一种系统，其包括服务器和客户端装置，并且用于从存储表现媒体项的数据的所述服务器将表现所述媒体项的媒体数据流传输至所述客户端装置，所述媒体项的至少时间片段由多个版本来表示，

-所述客户端装置包括用于将针对描述文件的请求发送至所述服务器的模块，其中所述描述文件包括表现所述时间片段的版本的描述和指向表现所述时间片段的版本的各个指针；

-所述服务器包括：用于从所述客户端装置接收所述请求的模块；选择模块，用于从所述描述文件中所指向的数据集合中选择数据；用于将所述描述文件发送至所述客户端装置的模块；以及用于将所选择的数据推送至所述客户端装置的模块；以及

-所述客户端装置还包括用于从所述服务器接收所述描述文件的模块和用于从所述服务器接收所选择的数据的模块。

以上针对用于提供媒体数据的方法和用于接收媒体数据的方法所提出的可选特征还适用于用于对媒体数据进行流传输的方法以及刚刚提到的各种装置和系统。

附图说明

通过以下参考附图针对非限制性典型实施例的说明，本发明的其它特征和优点将变得明显，其中，除图1a～6外：

-图7a和7b示出根据实施例的媒体片段重新排序；

-图8是根据实施例的服务器所进行的示例性步骤的流程图；

-图9是根据实施例的客户端所进行的示例性步骤的流程图；

-图10是根据实施例的代理所进行的示例性步骤的流程图；

-图11示出根据实施例的带宽测量；

-图12示出根据实施例的视频播放初始化；

-图13是根据实施例的装置的示意例示；

-图14a使用流程图示出客户端侧的本发明的一般步骤；

-图14b使用流程图示出服务器侧的本发明的一般步骤；

-图15a使用流程图示出用于基于显式方法来确定客户端侧的共享推送策略的步骤；

-图15b使用流程图示出在使用显式方法的情况下确定服务器侧的推送策略的步骤；

-图16示出使用PushPolicy(推送策略)节点来指定服务器所应用的推送策略的MPD文档；

-图17使用流程图示出用于将一些片段识别并标记为准备好要根据共享推送策略“PushPolicy”来推送的步骤；

-图18a示出利用在HTTP“push-policy”头部中所发送的推送策略在服务器和客户端之间的通信的示例；

-图18b示出与客户端的用以改变推送策略的请求相同的示例；

-图19示出MPD 1900和推送承诺1902-1905；

-图20使用流程图示出根据实施例的服务器侧的合并通报消息的处理的步骤；

-图21使用流程图示出在使用HTTP头部来声明推送策略的情况下、服务器侧的处理的步骤；

-图22使用流程图示出在使用HTTP请求声明并共享推送策略的情况下、客户端侧的处理的步骤；

-图23示出使用SupplementalProperty(补充性质)元素来指定服务器在文档层级所应用的推送策略的MPD文档；

-图24示出用作基于XPath的推送策略的示例的MPD文档；

-图25示出在应用推送策略之前、例如网页中的采用优先级树的元素的重新排序；

-图26示出根据本发明实施例的、服务器和客户端装置为了获得DASH快速启动所分别实现的示例性方法；

-图27描述服务器针对DASH快速启动所实现的示例性方法；以及

-图28描述客户端装置针对DASH快速启动所实现的可能方法。

具体实施方式

以下在实现HTTP 2.0协议的基于DASH的网络的背景下描述本发明的实施例。进行流传输的数据例如是视频数据。本发明的实施例不限于DASH网络。

将数据流传输至客户端装置的通信网络的服务器装置实现推送特征，其中根据该推送特征，服务器装置可以在无需来自客户端的针对所传输的数据元素的显式请求的情况下，将数据元素发送至客户端。

服务器和客户端可以共享推动服务器确定推送承诺并实际发送相应数据的推送策略。由于该共享，因此客户端可以预期一些无用数据的推送，以取消这种推送。由于PUSH_PROMISE(推送承诺)帧可以在发送之前被取消，因此这样使得减少了服务器的处理以及网络使用。

在特定实施例中，服务器可以在其推送承诺(利用该推送承诺，服务器通报没有显式请求的数据元素的传输)中指示与服务器计划传输数据元素的顺序有关的排序信息。可以使用优先级值、例如根据HTTP/2的优先级值来定义数据元素的顺序。

在接收到推送承诺时，客户端装置可以预先确定服务器所计划的传输顺序，由此使得在所提出的顺序与客户端装置自身的期望顺序不一致的情况下，该客户端装置能够对该所提出的顺序作出反应。例如，客户端装置可以更新优先级值并且将更新后的优先级值发送至服务器。服务器由此可以基于新的优先级值来改变传输排序，从而更好地匹配客户端的需求。服务器可以使用更新后的优先级来考虑将来的数据传输。

根据实施例，客户端可以向服务器请求数据元素的传输的完全重新排序或部分重新排序。

参考图7a来说明完全重新排序。客户端在步骤700期间向服务器请求媒体呈现描述(以下为MPD)。服务器在步骤701期间检索要发送回至客户端的MPD并且识别要推送的相应数据元素。在图7a的示例中，服务器识别“Data(数据)1.1”、“Data 1.2”和“Data 1.3”作为要推送的数据元素。这些元素例如是数据片段。元素“Data X.1”表示数据X的基本层，元素“Data X.2”表示数据X的增强层，并且元素“Data X.3”表示数据X的附加增强层。服务器定义这些数据元素的特定传输顺序。服务器使各个优先级值与为了通报即将到来的推送数据元素而要发送至客户端的PUSH_PROMISE帧相关联。然后，服务器在步骤702期间发送具有关联的优先级的PUSH_PROMISE帧“P1.1”、“P1.2”和“P1.3”以及MPD。接着，紧挨在发送MPD和推送承诺之后，在步骤703期间，服务器向客户端发送与“Data 1.1”元素相对应的数据帧以及分别与元素“Data2.1”、“Data 2.2”和“Data 2.3”相对应的PUSH_PROMISE消息“P2.1”、“P2.2”和“P2.3”，其中“Data 2.1”、“Data 2.2”和“Data 2.3”是按所定义的传输顺序跟随在“Data 1.1”、“Data 1.2”和“Data 1.3”之后的片段。与步骤703的数据帧和推送承诺的接收并行地，客户端在接收到MPD以及“P1.1”、“P1.2”和“P1.3”PUSH_PROMISE帧之后，决定增强层“Data 1.2”与附加增强层“Data 1.3”相比具有更低的优先级。因而，客户端在步骤704期间发送优先级更新帧以使“Data 1.2”的优先级低。在接收到优先级更新请求时，服务器在步骤705期间改变传输的安排。因而，“Data 1.2”的传输被推迟到“Data 1.3”的传输之后。另外，服务器使用MPD来链接与“Data 1.2”相关联的片段。服务器识别出“Data2.2”并且还降低了其优先级。

参考图7b来说明部分重新排序。图7b的步骤710～714与图7a的步骤700～704基本相同。在接收到优先级更新帧之后，服务器行为与前面所述的步骤705相比有所不同。在步骤715期间，服务器已开始“Data 1.2”的传输并且继续进一步进行传输。对于该片段，优先级没有改变。然而，服务器更新所连接的片段(即，在该示例中的“Data 2.2”)的优先级。为了通报已考虑到优先级改变这一事实，服务器可以发送针对“Data 2.2”的优先级更新消息。如此向客户端通知了该改变。

可以在如下的用例中实现本发明的实施例，其中：服务器可以预先推送足够好的高质量视频部分，使得可以按高质量来播放视频的整个部分。例如，可以将视频分割成按低质量播放的部分1、按高质量播放的部分2和按低质量播放的部分3。客户端和服务器之间的带宽使得能够进行低质量而不是高质量的实时流传输。在这种情况下，服务器可以使部分1与部分2的增强交错。一旦播放了部分1，还可用增强后的部分2，并且服务器将要按高品质播放的部分2的基本层连同同一部分2的增强一起发送。因而，服务器确保了按高品质来播放整个部分2。之后发送部分3。可以缓解干扰用户体验的质量晃动，并且质量切换仅在有限次数的时刻发生。服务器由于知晓视频内容，因此处于知晓要何时切换为不同质量水平的最佳位置。

图8是根据实施例的实现基于推送的DASH媒体流传输的服务器所进行的步骤的流程图。步骤800～812描述一般原则。步骤820～827更具体地应对来自客户端的优先级反馈的管理。

在步骤800期间，服务器从客户端接收到请求R。该请求通常通过参考MPD文件来识别特定媒体。接着，服务器进行包括步骤801～810的迭代处理。该处理包括根据所定义的顺序来发送数据。根据客户端的反馈来更新传输顺序。一旦发送了数据，则客户端接收并播放这些数据。接着，服务器识别新的要发送的数据，并且处理继续进行。

第一次迭代从步骤801开始，其中在该步骤801期间，识别要发送的数据。在第一次进行迭代处理的情况下，可以使用快速启动方法以使得客户端能够尽可能快地开始视频播放。另外，服务器还可以识别媒体向章节的子分割。在服务器知晓客户端通常使用章节进行导航的情况下，服务器实际上不仅可以选择与媒体的开头相对应的片段，而且还可以选择与媒体中的第一章节的开始相对应的片段。在第一次进行迭代之后，服务器还检测到该连接可以支持媒体的更高质量表现的传输。因而，服务器可以识别应何时进行分辨率或质量切换。

一旦服务器识别出要推送的片段的列表，则服务器定义这些片段的传输顺序。在步骤802期间，使用该传输顺序来计算针对各推送片段的初始优先级值。排序可以基于多个参数。

第一个参数可以是不同片段之间的关系：例如，一些片段必须可用于正确地对其它片段进行解码。必须可利用的片段如此被分配了与所述其它片段相比更高的优先级。

第二个参数可以是根据过去的统计数据可以收集到的视频片段的流行度。作为示例，视频中的特定时间可以利用YouTube URL来进行定址。在点击与这些URL相关联的链接时，仅检索到需要在指定时间开始视频播放的视频。另外，如果视频被分章节，则各章节的开头与章节开始之间的片段相比通常更经常由用户检索到。章节开头的片段如此与中间章节片段相比被分配更高的优先级。

第三个参数可以是时间线：更靠近正播放的视频片段的优先级高于要在后面播放的视频片段的优先级。

第四个参数可以是实际传输片段所花费的估计时间。在视频片段大的情况下，该视频片段需要长的时间进行传输，因此传输应尽可能早地开始，即具有高优先级。

在两个片段具有相同优先级的情况下，相应的数据帧在传输期间可以是交错的。

在媒体内容中识别出关注区域的情况下，如果带宽对于高质量表现而言不够大但对于低质量表现而言足够大，则服务器可以仅针对关注区域选择增强层。

一旦计算出优先级，则服务器在步骤803期间发送包含优先级值的PUSH_PROMISE帧。不需要为了开始进行PUSH_PROMISE帧的传输而对所有片段进行识别。在针对要推送的片段要发送MPD的情况下(步骤804)，发送该MPD(步骤805)。在步骤806期间，并行地开始片段传输。

一旦客户端接收到PUSH_PROMISE帧，则服务器可以接收优先级更新改变，然后相应地改变其传输安排(步骤807～808和步骤820～828)。在发送片段时，服务器等待优先级改变消息的接收。在接收到优先级改变消息的情况下(步骤807)，服务器相应地对片段进行重新排序并且继续进行片段传输(步骤808)。一旦发送了所有片段(步骤809-1)，则服务器重新开始迭代处理以继续对媒体进行流传输，直到该媒体的末尾为止。在到达媒体的末尾的情况下(步骤809-2)，服务器检查是否应自动开始对另一媒体进行流传输(步骤810)。在应对另一媒体进行流传输的情况下(“是”)，服务器识别要进行流传输的新媒体(步骤811)并且从步骤801重新开始处理。在没有应进行流传输的新数据的情况下，该处理停止(步骤812)。

针对来自客户端的优先级反馈的管理(即步骤808)从在步骤820期间接收到优先级更新改变消息开始。在客户端取消片段推送的情况(该情况实际可被视为等同于向该片段分配最低优先级)下还可以进行以下步骤。

在接收到优先级更新改变消息时，服务器在步骤821期间识别相关片段。然后，服务器继续对片段传输进行重新排序(步骤822、823)。如果已传输了片段，则该处理结束。如果正传输片段，则根据服务器实现，服务器可能拒绝改变传输(例如，由于太复杂)、或者服务器可能实际重新安排要发送的其余数据。

可以如下进行数据的重新安排。服务器存储要推送的视频片段(和/或正推送的视频片段)的列表。根据服务器所设置的优先级来对该列表进行排序。然后，服务器针对该片段设置新的优先级值。然后对该列表进行重新排序，因而相应的视频片段传输提早或推迟。

一旦对视频片段进行了重新排序，则服务器实际可以决定将该优先级改变应用于其它相关的视频片段。如果客户端使作为增强层的一部分的视频片段的优先级提高，则服务器可以使该增强层的所有片段的优先级均提高。相反，如果客户端使基本视频片段层的优先级降低，则在时间上与该片段有关的所有片段的优先级都可能降低。在步骤824～827中说明该处理。基于MPD和重新安排后的视频片段，服务器识别相关片段的列表(步骤824)。该关系可以是基于时间、空间、质量等的。可以增强MPD以更好地示出潜在关系。特别地，在(播放一个以上的视频片段所需的)初始化片段的优先级降低或提高的情况下，可以重新安排所有相关片段。对于基本层片段和增强片段，同样也是该情况。对于所识别出的各相关片段，服务器测试是否应改变相关片段的传输(步骤825)。在应改变相关片段的传输的情况下，服务器针对各片段计算新的优先级值(步骤826)并且相应地重新安排片段传输(步骤827)。可以通过向旧值添加步骤820期间所接收到的新优先级值和步骤821期间所识别出的片段的初始优先级值之间的差来计算该新优先级值。在测试了各相关片段的情况下，该处理停止(步骤828)。

服务器还可以接收诸如WINDOW_SIZE(窗大小)帧等的控制流消息。这些消息可以使得服务器能够识别客户端当前正播放什么内容。在客户端上还有一些可用附加缓冲器空间的情况下，可以推断出一些数据(通常是最早的数据)已从缓冲器移除。如果服务器保持所发送的数据的历史，则服务器能够识别移除了哪些数据。因而，假定服务器知晓客户端的高速缓存排序，则服务器可以掌握客户端当前正播放哪些视频片段。该排序可以基于使得能够根据时间线对高速缓存数据进行排序的MPD。然后，服务器例如可以检查客户端跳过的时间。服务器可以通过预先快速地发送下一章节的开头来作出反应，使得客户端可以继续跳过视频章节。

应当注意，可以以各种方式进行具有优先级的PUSH_PROMISE帧的发送。PUSH_PROMISE帧必须与用户发起的已打开的流(opened stream)有关。根据实施例，客户端在步骤800期间所进行的初始流可以始终保持打开。根据其它实施例，在服务器所打开的流内发送PUSH_PROMISE帧。在这种情况下，客户端将PUSH_PROMISE帧视为通过父客户端发起的流来发送。因而，客户端可以计算与该特定PUSH_PROMISE帧相对应的虚拟请求的正确头部。

根据其它实施例，可以共同发送优先级消息和PUSH_PROMISE。第一个可能性是将优先级消息作为PUSH_PROMISE帧内的头部进行发送。另一个可能性是发送具有由相应的PUSH_PROMISE帧保留的流ID的PRIORITY帧。第三个可能性是发送PUSH_PROMISE帧，然后发送相应的HEADERS帧(以打开流)，然后发送与该新打开的流有关的PRIORITY帧。

为了进一步控制客户端的缓冲器，服务器可以发送客户端所高速缓存的片段的新表现。在作为该新表现的一部分所发送的头部内，HTTP高速缓存指令可用于请求客户端例如通过将该片段标记为不可高速缓存来实际移除该片段。这样可能使得可以恢复客户端的缓冲器空间。可以使用HTTP/2控制流。然后，服务器可以推送附加数据。

服务器可以发送针对各视频片段的优先级值。服务器还可以发送针对特定片段的优先级值。在服务器没有发送针对当前PUSH_PROMISE帧的优先级值的情况下，客户端可以根据从服务器发送来的最后一个优先级值来计算优先级值。例如，每次接收到没有关联有优先级值的新PUSH_PROMISE帧的情况下，客户端可以使优先级值递增。因而，可以对PUSH_PROMISE帧进行分组，以使得更新特定片段的优先级将同样更新该组的所有片段的优先级。

参考图9来说明客户端侧的处理。

客户端应能够播放在给定时间可用的内容。然而，客户端必须应对潜在的缓冲器限制和处理时间。客户端必须检查服务器所提出的传输排序与客户端的缓冲器中的可用存储器空间以及客户端当前所播放的内容是否匹配。

在第一步骤900期间，客户端连接至服务器并且请求MPD文件。然后，客户端在步骤901期间检索MPD文件并且等待(步骤902)数据的接收。在接收到数据的情况下，客户端检查(步骤903)该数据是否是推送承诺。在接收到了推送承诺的情况下，这意味着服务器正在发送新的视频片段。客户端处理该推送承诺。特别地，客户端在步骤904期间可以验证服务器所提出的优先级值。在客户端希望改变针对当前片段或另一承诺片段的优先级值的情况下(步骤905)，客户端计算新的优先级值并将该新的优先级值发送至服务器(步骤906)。

在客户端接收到视频数据的情况下(步骤907)，客户端使视频片段链接至MPD文件(步骤908)并且存储该视频数据(步骤909)。将视频数据链接至MPD文件使得在MPD文件将进一步用于对视频进行解码的情况下，客户端可以检索该视频片段(步骤911)。例如，在对相连的视频片段进行分组的情况下，这样还可以提供视频数据的高效存储(步骤909)。

缓冲器存储制约可能进一步改变优先级。因而，客户端可以再次检查是否必须改变优先级值，并且在需要改变优先级值的情况下可以与服务器进行通信(步骤905、906)。

一旦客户端准备好开始或继续播放视频(步骤910)，则客户端从其高速缓存中检索下一时隙视频片段(步骤911)并且对该视频进行解码并播放(步骤912)。作为步骤911的一部分，客户端可以在其高速缓存器中进行查询，以知晓哪些视频片段是可用的。默认客户端可以使用所有可用的视频片段、特别是所有的增强片段(在存在的情况下)。客户端可以令服务器选择内容：一般而言，客户端应使用所有的片段。如果一些片段(如音频英语轨和法语轨)无法共同使用，则客户端应首先拒绝未使用的片段。应当注意，并非所有的客户端都可以获得高速缓存器状态：特别是web应用程序通常无权访问web浏览器高速缓存。在这种情况下，服务器可以将所推送的片段的列表直接发送至web应用程序客户端。例如，可以使用web套接字连接来从服务器向客户端交换该信息。

随着对视频进行播放并解码，可以从缓冲器移除相应的视频片段。因而，客户端使用WINDOW_SIZE帧来更新其可用的缓冲器大小。客户端可以保持最近播放的视频片段，以使得用户能够在有限的时间段内使视频倒回。在用户进行快进/时间跳过的情况下，还可以使用流量控制更新机制。客户端可以移除所存储的旧视频内容以针对新内容留出空间，并且使用WINDOW_SIZE帧向服务器通报该改变。在服务器接收到WINDOW_SIZE帧的情况下，如以上所论述的，服务器可能能够计算移除了哪些视频片段，然后识别出客户端正在播放什么内容。

以下更详细地说明步骤904。

客户端保持所有承诺推送的视频片段的列表。该列表是根据在推送承诺帧中发现的优先级信息进行排序的。首先，检查潜在的冻结视频问题。基于针对可用带宽和排序后的视频片段列表的估计，可以估计各片段的传输开始和结束时间。基于这些时间，可以测试各视频片段在应使用该视频来进行视频播放时是否将可用。如果预期到所承诺的视频片段要在其相应的视频播放使用之后才进行传递，则应提高该视频片段的优先级。因而，视频片段在承诺推送的视频片段列表顺序中向上移动。为了计算准确的优先级值，搜索使得可以按时传递视频片段并且最接近当前视频片段位置的视频片段列表中的位置。然后将优先级设置为视频片段新位置之前和之后的列表中的视频片段的优先级之间的值。

客户端还可以使用其它因素来改变视频片段优先级。例如，如果客户端正预期进行一些章节切换，则客户端实际可以提高开始章节的所有视频片段、特别是相应的初始化片段的优先级。

根据实施例，客户端侧流量控制包括禁用针对各流的流量控制并且仅保持针对各连接的流量控制。针对各连接的窗大小定义了客户端在任何给定时间可以实际存储的视频的最大量。客户端和服务器可以在初始化时和连接期间协商，以减小或增大该窗大小。如果服务器想要推送一些HD内容，则服务器可以请求客户端增大窗大小。如果连接带宽低，则服务器可能需要预先良好地预期针对视频的特定部分的HD内容的发送，其中在该情况下，应使缓冲器大小变大。

在缓冲器具有单一大小的情况下，传输顺序可能是重要问题。特别地，随着向缓冲器填充数据，优先级排序变得越来越重要。重要制约是视频从不冻结。只要缓冲器大部分为空，服务器就可以预先大量推送如片段那样的各种视频片段，以提供高效的快进或章节跳过。一旦缓冲器几乎完全充满，则要推送的视频片段应尽可能靠近正播放的视频片段。在服务器具有与客户端缓冲器有关的准确信息的情况下，可以由该服务器进行该推送行为。该推送行为还可以由客户端使用优先级更新机制来实现。

在自动视频切换的情况下，可以通过检测新的MPD的推送作为推送承诺检查(步骤903)的一部分来扩展图9的流程图。在检测到MPD推送的情况下，客户端可以开始接收新视频的片段作为步骤908的一部分。因此，客户端必须识别与视频数据有关的MPD。一旦针对给定MPD完成了视频播放(步骤902)，则可以使用新的MPD来继续视频播放。客户端实际可以刷新(flush)链接至先前的MPD的所有视频片段。

参考图10来说明DASH感知代理(Dash-aware proxy)的行为。在接收到从服务器推送来的片段的情况下，不强制代理将该片段推送至终端客户端。然而在DASH流传输的情况下，强制代理将该片段推送至终端客户端可以被视为良好的实践(或默认行为)。

代理可能能够从优先级处理和要发送的推送数据这两方面调整服务器行为和客户端行为。代理实际可以根据服务器所具有的优先级来独立地处理客户端所具有的优先级。另外，服务器可以推送比给定客户端所需数据更多的数据，并且代理可以检索附加的推送数据以实现来自其它客户端的请求。

服务器可以出于多个原因推送视频片段。例如，在认为视频片段对于最终客户端有用的情况下，可以推送视频片段。在认为可以多次使用视频片段并且值得将该视频片段推送至代理的情况下，也可以推送视频片段。

在第一种情况下，代理通常将视频片段发送至客户端。代理可以推迟其发送以优化客户端或代理网络状态(例如，客户端无线状态)。示例性情况可以是针对快速启动视频播放和带宽估计的片段推送，其中在该情况下，应将数据尽可能快地发送至客户端。在服务器对向代理推送数据感兴趣的情况下，除在代理有办法知晓视频片段对于客户端而言将是有用的情况下外，代理可能不会自动将视频片段发送至客户端。为了使得可以识别出可能不会发送至客户端的视频片段，可以使用特定优先级值。使用优先级值使得可以使代理始终检查优先级值以优化到达的各种帧的处理。

图10包括三个流程图。一个流程图涉及对推送片段进行过滤的处理(步骤1000～1008)。另一流程图涉及在片段已被承诺给客户端时另一客户端请求该片段的情况下所进行的处理(步骤1010～1015)。另一流程图涉及优先级改变的管理(步骤1020～1026)。

对推送片段进行过滤的处理从推送数据事件的接收(步骤1000)开始(通常是在接收到PUSH_PROMISE帧或相关DATA帧时)。代理检查该数据是否具有高优先级(步骤1001)。如果数据的优先级值比传输中的其它片段的优先级值大得多，则这些数据可被视为具有高优先级。如果数据的优先级值具有特殊含义(诸如快速启动或带宽估计等)，则该数据也可被视为具有高优先级。如果数据具有高优先级，则将这些数据尽可能快地发送至客户端(步骤1002)。然后，代理决定是否存储这些数据(步骤1003、1004)。在接收到相应PUSH_PROMISE帧或打开所推送的数据流的相应HEADERS帧的情况下，可以进行一次该决定。该决定还可以基于代理高速缓存状态、视频的设想使用、视频源的流行度或其它标准。如果在一个或多个客户端同时请求片段的情况下推送该片段，则代理存储视频片段。在片段被识别为快速启动的情况下，也可以存储视频片段。

如果数据不具有高优先级，则代理检查该数据是否具有低优先级(步骤1005)。具有低优先级的数据可以是向客户端的传输可能被跳过但被服务器视为如代理那样的网络中介感兴趣的数据。代理首先决定是否要将数据发送至客户端(步骤1006)。在接收到相应PUSH_PROMISE帧或打开所推送的数据流的相应HEADERS帧的情况下，可以进行一次该决定。如果决定要将数据发送至客户端，则代理将相应帧发送至客户端(步骤1002)。然后，在决定是否要存储数据之后，该处理停止。

在服务器和代理之间所协商的优先级值可能不同于在客户端和代理之间所协商的优先级值。因此，在数据具有普通优先级(即，不具有低优先级且不具有高优先级)的情况下，代理检查片段优先级值是否由该代理管理。如图10所示(步骤1020～1026)，代理使用用于安排应传输数据的时间的客户端-代理值，即，代理保持要传输的所有视频相关帧的列表。根据优先级值对这些帧进行排序，之后按照该顺序发送这些帧。

在代理正接收优先级更新帧的情况下(步骤1010)，代理识别相关的视频片段(步骤1011)。如果该相关的视频片段的优先级值不是正在由代理进行管理(步骤1012)，则代理将该优先级更新帧转发至服务器(步骤1013)。否则，代理存储该新的优先级值并且相应地对视频片段传输进行重新排序(步骤1014)。在出现潜在冲突的情况下、特别是在来自服务器的视频片段传送被预期为对于客户端需求而言过迟的情况下，代理则可以将优先级值转发至服务器。

步骤1020～1026涉及从客户端接收到针对已被服务器承诺至另一客户端(步骤1021)的视频片段的请求(步骤1020)的代理的情况。根据赋予至该请求的优先级，代理计算将实现客户端的请求的最小的代理-服务器优先级(步骤1022)。可以通过计算将确保服务器-代理传送时间比代理-客户端预期传送时间早的代理-服务器优先级值来进行该计算。如果所计算出的优先级低于当前设置的优先级，则优先级改变(步骤1023)，其中在该情况下，代理将向服务器发送优先级更新消息(步骤1024)，并且代理将该视频片段优先级标记为由代理进行管理，使得代理将该视频片段在针对其两个客户端的需求而在最佳的时间发送至这两个客户端。与该处理相同，代理可以从多个客户端接收针对同一片段的多个优先级更新，其中在该情况下，代理实际可以发送满足所有客户端的最低优先级值。

参考图11来说明客户端接收到如下的推送数据事件的实施例，其中该推送数据事件的优先级值表示服务器想要使用该推送数据事件来测量带宽。可以通过用于计算往返时间的主动或被动测量使用TCP/IP包来测量带宽。基于往返时间，可以如在Saubhasik等人的文献“Bandwidth Estimation and Rate Control in BitVampire”中所发现的那样计算可用带宽。该计算可以潜在地考虑到HTTP/2控制流量的影响。通过进行与使用一些数据帧来进行可能的带宽估计有关的通知，可以估计没有HTTP/2控制流量的情况下的可用带宽。

处理从步骤1100开始，其中在该步骤1100期间，从服务器接收到推送数据帧。接着，检查流的关联优先级是否表示服务器正在测量带宽(步骤1101)。在这种情况下，使专用缓冲器最大化(步骤1102)。可选地，可以禁用流的流量控制。如果接收节点是代理(步骤1103)，则该接收节点可以转发片段数据。否则，客户端决定是否存储该片段(步骤1104)。客户端存储所推送的片段(步骤1105)。在任何情况下，客户端均针对每个连接窗以WINDOWS_UPDATE的形式向服务器发送确认(步骤1106)。然后，该确认将由服务器用来估计连接带宽。在客户端是代理的情况下，该客户端尽快转发所推送的数据(步骤1108)。在从终端客户端接收到确认的情况下，代理还将该确认转发回服务器(步骤1109、1110)。

为了估计可用带宽，服务器可以使用作为数据帧的发送时间和确认消息的接收时间之间的差所计算出的所发送的数据帧的往返时间，其中该发送时间和接收时间之间的配对例如基于应等于窗大小更新的数据帧大小。可以根据一个或多个视频片段的各种数据帧来计算往返时间。为了提高精度，数据帧必须具有各种大小。可以利用服务器来进行将视频片段分割成大小不同的多个DATA帧。服务器仅需确保网络层将不会将DATA帧分割成多个TCP/IP包(因而不会分割成更小的DATA帧)、或者不会缓冲要发送的内容并将多个DATA帧合并成TCP/IP包。基于这些测量，可以使用标准技术来计算服务器为了实际决定要使用哪个视频表现而可以使用的可用带宽(例如，在上述文献中可以发现示例)。

参考图12来说明初始视频播放的情况。服务器使用快速启动优先级来推送数据。认为数据有可能具有低比特率并且客户端将接收这些数据并向服务器发送确认，以使得服务器可以估计带宽并且切换为最佳表现。在步骤1200～1207中说明客户端侧处理。在步骤1210～1215中说明服务器侧处理。

客户端处理从接收所推送数据的步骤1200开始。然后，客户端检查优先级是否具有快速启动值(步骤1201)。在这种情况下，客户端通常使专用缓冲器最大化(步骤1202)。在接收到所推送数据的PUSH_PROMISE的情况下，进行该最大化。然后存储该数据(步骤1203)，并且客户端使用WINDOW_UPDATE帧来向服务器发送确认(步骤1204)。然后，客户端检查是否存在足够的数据来开始播放视频(步骤1205)。如果存在足够的数据，则视频播放开始(步骤1206)。否则，客户端等待更多数据(步骤1207)，直到存在足够的数据来开始播放数据为止。

服务器处理从步骤1211开始，其中该步骤1211发送具有快速启动优先级的片段数据帧(步骤1210)。然后，服务器接收(步骤1211)将允许计算可用带宽(步骤1212)的确认。一旦获得了足够的测量值，则服务器选择最佳表现(步骤1213)并且开始推送最佳表现片段(步骤1214)。服务器决定何时要切换表现。这具有至少两个益处。首先，服务器可以知晓何时测量值足够准确，并且只要情况如此，就可以从一个分辨率切换为另一分辨率，而客户端将需要应对一些延迟。其次，服务器可以决定在对用户体验的干扰较少的时间从一个分辨率切换为另一分辨率。实际上，服务器知道视频内容。特别地，可以利用与分辨率切换为最佳设想的时间有关的信息使MPD增强。

本发明涉及增强型流传输方法，其中：在服务器侧，从客户端装置接收与第一媒体数据有关的请求；识别出未被请求的、要发送至客户端装置的第二媒体数据；然后，响应于所述请求来将与所述第一媒体数据有关的数据传输至所述客户端装置，并且准备分别标识出所述第二媒体数据的至少一个通报消息，以将该一个或多个通报消息发送至客户端装置。

在客户端侧，将与第一媒体数据有关的请求发送至服务器装置；并且响应于所述请求，从所述服务器装置接收与所述第一媒体数据有关的数据。

增强型流传输方法减少了服务器针对推送一些媒体数据的决定和客户端针对这些数据的需求之间的不匹配。如通过以下所述显而易见，服务器和客户端共享推送策略，使得这两者都根据客户端所请求的任何媒体数据确定出相同的要推送的媒体数据。推送策略定义如何确定要推送的数据，并且可被视为如下的规则，其中该规则用于确定在(GET(获得)请求之后)处理了所请求的数据之后将要推送链接至所请求的数据的哪些资源、以及可能地如何(例如，按何种顺序)推送这些资源。通常，使用例如是诸如MPD文件(在针对多媒体数据的DASH背景下)等的清单文件的一个文档或者HTML文档来确定所链接的资源。

结果，基于共享推送策略，客户端能够预期服务器的行为以避免或者更准确为取消来自该服务器的无用媒体数据的传输。如此减少了客户端和服务器之间的通信网络中的带宽的使用。此外，减少了HTTP请求和PUSH_PROMISE取消的数量，由此降低了特别是针对低延迟实时视频流传输的应用的延迟。

根据本发明，服务器可以使用与客户端装置共享的推送策略以供服务器装置推动第二非请求媒体数据的识别和向客户端装置的传输。特别地，可以使用与客户端装置共享的并且定义如何确定第二媒体数据的推送策略以供服务器装置确定要发送至客户端装置的第二非请求媒体数据。相应地，客户端可以使用与服务器装置共享的并且定义如何确定第二媒体数据的推送策略以供客户端装置确定服务器装置要发送的未被客户端装置请求的第二媒体数据。

图14a使用流程图示出客户端侧的本发明的一般步骤，而图14b使用流程图示出服务器侧的本发明的一般步骤。

与参考图1d和1e所述的处理相比，附加阶段1400和1402使得服务器和客户端分别可以确定与对方共享的推送策略，并由此使用该推送策略。

根据第一实施例，共享推送策略是隐式推送策略，这意味着客户端和服务器不交换用以告知对方要共享哪个推送策略的(显式)策略数据。针对共享推送策略的隐式方法的实现包括在服务器装置和客户端装置这两者处使用被称为“第二媒体数据确定算法”的相同算法，其中该算法使得服务器装置和客户端装置能够根据所请求的第一媒体数据确定出相同的第二媒体数据。

例如，该算法是在客户端和服务器的设置期间或者相对于特定标准而预先确定的。算法的典型示例可以在于按清单文件的解析顺序来在所请求的资源之后推送N个资源，其中N是预定数字(例如，4)。

参考附图，步骤1400和1402在隐式推送策略的情况下在于将用于识别要推送的资源的预定算法加载到存储器中(服务器侧的步骤1403)。

例如在步骤1401中，客户端可以高效地使用如此确定的推送策略来估计所预期的PUSH_PROMISE的数量并且准备针对不想要的推送数据的取消消息。

例如，这将得到服务器从客户端装置接收请求取消第二非请求媒体数据的一部分的传输的取消请求，使得服务器装置不传输所准备的相应通报消息。针对该部分，客户端将由此向服务器装置发送请求取消第二非请求媒体数据的一部分的传输的取消请求，以推动服务器装置不传输识别第二非请求媒体数据的该部分的通报消息。可以理解，这种取消可以在从服务器装置传输了通报消息或者客户端装置接收到通报消息之前发生。该方法例如可用于客户端决定切换为另一版本的媒体的情况。在这种情形下，客户端可以决定取消针对先前版本所推送的片段。

还可以注意到，由于使用算法得知了要推送的资源，因此客户端可以并行地向服务器作出第二请求，以在不必等待来自服务器的相应PUSH_PROMISE的情况下检索后续资源。在DASH的情况下，针对客户端的该可能性使得可以在确保第二请求将不会干扰随后将接收到的PUSH_PROMISE的同时，减少客户端的延迟。

客户端在根据算法的结果判断为不会推送其需要的其它资源的情况下，还可以请求这些所需的其它资源。

根据第二实施例，在客户端和服务器之间的交换中，通过定义整个规则(即，算法或该算法的参数)以显式方式或者使用针对在两侧所预定义的推送策略的参考，来定义共享推送策略。这要求服务器首先确定描述服务器的推送策略的推送策略信息。然后，将该推送策略信息发送至客户端以与该客户端共享该推送策略。相应地，客户端由此从服务器装置接收描述共享推送策略的推送策略信息。

显式方法的一个优点依赖于服务器可以针对各客户端或针对各多媒体呈现(例如，各MPD)使用不同的推送策略，以更好地满足这两者的处理特性。图15a使用流程图示出用于基于显式方法来确定客户端侧的共享推送策略的步骤1400，而图15b使用流程图示出用于在使用显式方法的情况下确定服务器侧的推送策略的步骤1402。

如图15b所示，服务器在步骤1504中生成用以声明推送策略的消息，然后在步骤1505中将该消息发送至客户端，以共享该消息。将声明消息中描述推送策略的信息称为推送策略信息。

以下所述的图16～18给出了与如何声明推送策略并将推送策略发送至客户端有关的示例性详情。

然后，在步骤1403中，利用步骤1504中所生成的推送策略声明消息中所定义的选择算法(或第二媒体数据确定算法)来识别如步骤1402中所确定的要使用推送策略推送的资源。

在如图15a所示的客户端侧，客户端能够通过应用相同的选择算法来预先识别针对给定资源请求所要推送的资源。这样使得客户端可以预先确定服务器将要推送的数据，由此确保了推送数据的高效管理和GET请求的数量的减少(在适当的情况下)。

为了应用相同的选择算法，客户端接收描述服务器所应用的推送策略的推送策略信息。

可以使用各种推送策略声明方法。

在一个实施例中，由于如下的JavaScript程序因而共享了推送策略声明，其中该JavaScript程序采用请求R和与包含要推送的资源的文档(通常为DASH所用的清单文件)相对应的DOM树作为输入参数，并且输出要推送的资源的有序列表。在本实施例中，推送策略信息包括嵌入在从服务器装置发送至客户端装置的网页中的JavaScript程序。

在其它实施例中，在清单文件内描述推送策略，也就是说，将描述该共享推送策略的推送策略信息插入使用共享推送策略从服务器装置发送至客户端装置的描述文件。该描述文件包含与包括第一媒体数据的媒体数据有关的描述信息，并且由服务器装置和客户端装置这两方使用以确定要推送的第二非请求媒体数据。

在DASH中，描述文件例如是MPD文件。以下的描述主要基于DASH和MPD文件。然而，相同的方法还适用于如平滑流传输(Smooth Streaming)或HTTP实时流传输那样的其它基于清单的流传输方法。

根据具体实施例，推送策略信息包括在描述文件中定义要识别的第二非请求媒体数据的量的第一推送属性。这样使得可以指定在从客户端接收到一个请求R之后要推送的片段的数量。

利用示出如下的MPD文档的图16示出该情况，其中在该MPD文档中，PushPolicy(推送策略)节点1600用于指定服务器所应用的推送策略。

在该示例中，PushPolicy节点1600包括用以声明在接收到GET请求之后要推送的片段的数量的推送属性、即“SegmentIdx”。例如，如果客户端在其GET请求中请求片段1601，则该客户端将接收到作为应答的、MPD文档的解析顺序中接下来的两个片段的PUSH_PROMISE帧。在该示例中，第一推送属性相对于描述文件内所请求的第一媒体数据标识出第二非请求媒体数据。更一般地，使用要推送的预定数量K个片段来定义推送策略值。结果，针对客户端所请求的各片段，服务器将推送K个接下来的片段。

尽管图16的示例1600示出单个推送属性，但可能存在多个推送属性。各推送属性可以表示针对DOM(Document Object Model，文档对象模型)树的节点的制约，其中该DOM树表示用于选择要推送的片段的清单。参考前述的图4B的示例，推送策略节点1600可以指代使用如下的媒体数据属性(MPD元素和/或属性)在描述文件(MPD文件)中描述的媒体数据，其中这些媒体数据属性包括指代媒体数据所属于的Period元素的时间段属性“PeriodIdx”、指代媒体数据的AdaptationSet元素的自适应属性“AdaptationSetIdx”、指代Representation元素的表现属性“RepresentationIdx”(即，媒体数据的编码版本(特定编解码器、分辨率或比特率…))以及指代给定Representation中的片段的片段属性“SegmentIdx”。

基于这些现有的媒体数据属性，推送策略信息至少可以包括定义针对一个或多个媒体数据属性的制约的第二推送属性，从而识别第二非请求媒体数据。

例如，除上述的与SegmentIdx属性有关的第一推送属性外，推送属性可以与用以指定针对用于选择要推送的片段的时间段的制约的PeriodIdx属性有关；另一推送属性可以与用以指定针对自适应的制约的AdaptationSetIdx属性有关；另一推送属性可以与用以指定针对表现的制约的RepresentationIdx属性有关。

在不存在推送属性或推送属性为空的情况下，可以将相关的媒体数据属性视为未受制约。

推送属性的值可以使用以下句法：

推送属性＝[operator]operand

其中：“operator(运算符)”是可选的并且取值“+”或“-”以定义要相对于所请求的片段(“+”表示之后并且“-”表示之前)推送的片段；以及“operand(操作数)”是大于或等于0的整数值或者作为通配符参数的“*”。

图17使用流程图示出用于识别一些片段并将这些片段标记为准备要根据共享推送策略“PushPolicy”来推送的步骤。该流程图示出步骤1403。

首先，服务器在步骤1700中识别清单文件中所请求的片段。该请求包括所识别出的该片段的“reqSegIdx”。

针对清单文件MPD中的各节点类型，向各节点赋予索引值属性。该值按各Node(节点)在清单文件中的出现顺序而递增。

接着，通过对整个MPD进行解析直至到达所请求的片段为止，来检索与所请求的片段(即，在GET请求中指定的片段)相对应的Period、AdaptationSet、Representation和SegmentURL(片段URL)的索引。

使用推送策略中所定义的推送属性(在与“+”或“-”运算符相关联的情况下，除定义要推送的片段的量的SegmentIdx属性外)的运算符和操作数的值来识别在哪个节点中定义了要推送的片段。

在没有指定运算符的情况下，操作数的值标识出必须检索要推送的数据的Node的索引。例如，在第一个推送属性“SegmentIdx”不具有运算符的情况下，该推送属性是描述文件内要推送的特定片段的标识符。在一个替代例中，在没有指定运算符的情况下，操作数的值可以标识出范围值，例如“SegmentIdx＝2-5”将返回索引等于2、3、4和5的片段。

否则(在指定了运算符的情况下)，操作数的值表示要应用于所请求的片段的索引(步骤1700中所获得的“reqSegIdx”)的偏移值(命名为“idxOffset”)。在这种情况下，要推送的片段在运算符是“+”的情况下应存在于索引被包括在[reqSegIdx，reqSegIdx+idxOffset]范围内的Node中，并且在运算符是“-”的情况下应存在于索引被包括在[regSegIdx-idxOffset，regSegIdx]范围内的Node中。运算符的使用使得可以相对于描述文件内的第一媒体数据的相应的一个或多个媒体数据属性来定义第二非请求媒体数据的一个或多个媒体数据属性。

例如，考虑以下的推送策略：

1.<PushPolicy Representationldx＝”-1”Segmentldx＝”2”/>

2.<PushPolicy Periodldx＝”+1”Segmentldx＝”+2”/>

3.<PushPolicy Periodldx＝”+0”Segmentldx＝”+2”/>

PushPolicy#1指定服务器将推送所请求的片段的表现节点之前的表现节点中的索引为2的片段。

利用PushPolicy#2，服务器将在当前时间段或下一时间段中推送跟随在所请求的片段之后的两个片段。例如，在请求图24上的片段2401的情况下，将推送片段2405和2402。

PushPolicy#3与PushPolicy#2非常相似，主要不同之处是所请求的片段是Period中的倒数第二个。例如，在请求2401的情况下，(代替推送两个片段)，将仅推送当前Period中的最后一个片段2405。利用PushPolicy#3，PeriodIdx将片段搜索限制于所请求的片段的Period节点，因而仅推送Period的最后一个片段(这是因为所请求的片段是Period中的倒数第二个片段)。相反，利用PushPolicy#2，可以从下一时间段中检索片段。

在替代例中或者作为可选值，操作数的值还可以是“*”(通配符含义)，这意味着应推送任何片段。在该值与运算符“+”(或者“-”)相关联的情况下，这意味着应推送所请求的片段之后(或者之前)的所有片段。

该替代例使得客户端能够仅发送单个HTTP请求，以例如利用以下的PushPolicy检索一个Period的所有片段：<PushPolicy PeriodIdx＝“+0”SegmentIdx＝“+*”>。

在这些示例中，用以相对于所请求的第一媒体数据标识出(要推送的)第二媒体数据的SegmentIdx属性的使用要求第二媒体数据与第一媒体数据邻接。在实施例中，SegmentIdx属性可以包括(除操作数外)要应用于所请求的片段的索引的偏移。这样使参考片段的索引发生偏移，其中必须从该参考片段起推送指定量的片段。作为示例，SegmentIdx的句法可以如下：

推送属性：[operator]operand[,offset]

其中：“offset(偏移)”是应用于所请求的片段索引的不同于0的正整数或负整数。在这种情况下，搜索范围在运算符为“+”的情况下是[reqSegIdx+offset,reqSegIdx+idxOffset+offset]，并且在运算符为“-”的情况下是[reqSegIdx-idxOffset+offset,reqSegIdx+offset]。

推送策略的句法还可以分别包含(非限制性地)如数据的最大大小或推送中的呈现中的时间那样的条件。例如：

<PushPolicy SegmentIdx＝“+*[size<500000]”>定义用以推送不大于500千字节的片段数据的推送策略。

<PushPolicy SegmentIdx＝“+*[time<0:01:30]”>定义用以推送不大于1分30秒的下一片段数据的推送策略。

尽管上述示例示出如何声明确定必须推送哪些片段的推送策略，但可能需要还指定将按哪种优选顺序来推送片段。同样应在客户端和服务器之间共享该信息。

作为示例，如以上参考图7～12所述的所推送的片段的传输顺序的声明也可以适用。

在一个替代实施例中，针对所推送的片段的传输顺序，描述文件中的描述信息包括与媒体数据相关联的优先级属性(针对各媒体数据为一个优先级属性(例如“priorityIdx”))，并且第二媒体数据的传输顺序基于关联的优先级属性。由于描述文件的传输，因此客户端还知晓这些优先级属性所取的值，因而能够确定所计划的传输顺序。

如图16的示例所示，清单文件中所描述的(例如，利用一个SegmentURL Node来标识)各片段包括指定片段的推送顺序的priorityIdx属性(1604)。在图16的示例中，在片段1602之前推送片段1603。在服务器侧的媒体片段准备期间计算这些优先级。可以使用不同的优先级值：(如图16所示的)给定Representation的相对优先级值，或者作为32位数的绝对优先级值，其中在这32位中，4个最高有效位针对Period优先级、接下来的4个MSB针对AdaptationSet优先级值、接下来的8位针对Representation优先级值并且16个最低有效位针对片段优先级。用信号通知绝对优先级值的替代方法是逗号分隔的优先级值列表(针对以上引用的各级别各使用一个逗号)，例如：用以连续地定义Period优先级、AdaptationSet优先级、Representation优先级、然后是片段优先级的priorityIdx＝“1,1,2,1”。以下将(以二进制的形式)给出具有32 位值的第一实施例：

priorityIdx＝“00010001000000100000000000000001”。

使用priorityIdx值的主要优点是使得可以根据不同的Representation(通常是诸如视频的替代视图等的关联表现)来定义片段之间的优先级顺序。这在推送策略在于发送不同的Representation集合的片段的情况下是有用的。典型的用例是用于对来自一层的片段与来自一个或多个其它层的片段会交错存在的分层视频(层是多视图中的视图或可分级视频中的分级层)进行流传输。

返回图17，基于如MPD文件中所定义的推送策略，服务器在步骤1701中确定要推送的片段的数量。该数量是根据SegmentIdx属性值直接推断出的，即，如果在该属性值中没有使用运算符，则该数量等于1；否则(运算符为“-”或“+”)，该数量等于操作数的值，并且在操作数是“*”的情况下假定该数量为无限大(但受到其它制约并且受到现有片段的数量的限制)。

接着，流传输服务器应用包括步骤1702～1705的迭代处理，直到达到要推送的片段的数量为止(测试1702)，来标记要推送的各个片段。

针对各次迭代，服务器在步骤1703中对MPD文件中所定义的遵从PushPolicy制约(Adaptation Set、Representation、Period和Segment制约以及可选条件)的片段的列表进行检索。

如果片段的列表为空或者已标记了该列表中的所有片段(测试1704)，则处理结束，并且服务器开始发送(上述的步骤102)针对客户端的请求的应答。

否则，在步骤1705中将列表中的第一片段标记为要在步骤103(PUSH_PROMISE)和104(所承诺的片段)期间推送。

在声明推送策略的这些基于MPD的示例中，使用PushPolicy元素来定义一个推送策略(参见图16的1600)。

这里需要重申，描述文件使用多个媒体数据属性级别(即，以上所定义的Period元素、AdaptationSet元素和Representation元素)来描述媒体数据。

作为上述的略微变体，可以在描述文件的各个级别定义各种共享推送策略。这样能够根据所关注的级别(Adaptation Set、Representation、Period)来定义各种推送策略，以使推送策略适应于媒体流的内容。

通过图23示出该情况，其中在该图23中，在期望级别(这里为Representation级别)使用例如“SupplementalProperty”描述符来定义推送策略。

使用针对各<MPD>级别的推送策略使得可以遍及媒体具有恒定且相同的推送策略。

使用针对各<Period>级别的推送策略使得可以具有可以随着时间而改变的推送策略。

使用针对各<AdaptationSet>级别的推送策略使得可以具有适应媒体的推送策略。

使用针对各<Representation>级别的推送策略使得可以具有可以适应于媒体特性(带宽等)的推送策略。

在图23的示例中，在Representation级别所指定的推送策略被配置为与高比特率视频(2301)相比、针对低比特率视频片段(2300)推送更多片段，以避免将过多带宽用于推送数据。

注意，以上针对推送属性的句法的说明也可应用于该略微变体。特别地，可以按如下方式在清单中用信号通知推送策略：作为新元素(如图16中那样)、或者使用具有新的schemeIdUri的现有描述符(如图23那样)、或者作为新的描述符(未示出)、或者符合MPDschema或MPD schema扩展点的任何方式。

MPD还可以包含每一个均具有唯一标识符的替代PUSH(推送)策略的列表(关于与该列表有关的更多说明，请参见以下)。

在其它替代实施例中，推送策略可以例如使用以下句法来定义系统地推送针对互补Representation的片段：

<push_policy Segments＝“+complementary”>

或者在使用DASH描述符的情况下值＝“complementary”。

在分层视频的情况下，这意味着针对所请求的视频片段，还将推送同时来自(通常通过不同的Representation之间的MPD信号通知依赖性中的dependencyId属性)声明为互补Representation的所有Representation的各片段。

另一推送策略还可在于推送来自关联Representation的片段，其中该关联Representation是利用@associationId属性或利用角色(role)＝“补充”而以信号通知的。

在完全服务器驱动型流传输的情况下，推送策略可以提供与以下内容有关的信息：服务器行为必须是“积极型(aggressive)”(或“乐观型(optimistic)”)还是“保守型(conservative)”，即分别为试图推送更高质量的片段还是试图以相同的质量水平进行推送(保留带宽)。

在其它实施例中，在被称为“push-policy”头部的专用HTTP头部中传输推送策略。即，将描述共享推送策略的推送策略信息嵌入在从服务器装置发送至客户端装置的HTTP帧的头部中。

由于这些实施例不再依赖于如上述那样的MPD文件的传输、并且客户端和服务器使用HTTP/2协议来进行交换，因此这些实施例使得可以使推送策略随时间的经过而改变。

图18是利用在HTTP“push-policy”头部(头部名称“push-policy”仅是示例)中传输的推送策略在服务器和客户端之间所进行的通信的示例。

push-policy头部包括各自定义针对要推送的数据的制约的推送属性的列表。特别地，可以将上述的PushPolicy的句法转换成HTTP头部句法。

在图18a中，服务器响应于来自客户端的MPD请求(箭头1800)、伴随着MPD的发送来传输HTTP头部中的push-policy(步骤1801)，以共享推送策略。

例如，推送策略指定将推送跟随在所请求的片段之后的片段。结果，在客户端请求(箭头1802)片段Data1.1的情况下，服务器发送(箭头1803)针对片段Data2.1的PUSHPROMISE，然后发送片段Data1.1的数据(箭头1804)。

可以使用任何句法来定义针对后续片段请求将要传输哪些数据：MPD特有句法或基于DOM树节点遍历的更加抽象的句法。

在专门针对动态共享推送策略的特定实施例中，例如如果当前的共享推送策略不适应于客户端需求或者可以改进，则客户端可以请求特定推送策略、即可以更新共享推送策略。

这意味着客户端装置将嵌入在HTTP帧的头部中的推送策略更新信息发送至服务器装置。相应地，服务器装置从客户端装置接收嵌入在HTTP帧的头部中的推送策略更新信息。服务器装置由此可以在确定非请求媒体数据之前，根据客户端装置所请求的其它媒体数据(例如，针对下一请求)相应地更新共享推送策略。

在实施例中，在HTTP头部或命名为“push-policy-request(推送策略请求)”(这里，名称仅是示例)的请求中传送来自客户端的推送策略请求。

图18b示出在客户端请求新的推送策略的情况下的客户端-服务器示例性交换。

这些交换的开头部分与图18a相同。

在接收到片段Data 2.1之后，例如由于可用带宽足够稳定以使得服务器可以响应于片段请求而推送更多片段，因此客户端识别出应修改当前推送策略。

结果，客户端在步骤1805中发送要求服务器针对各新请求推送更多片段(代替1个而推送3个)的push-policy-request。

在步骤1806中，服务器利用OK 200对该推送策略请求作出肯定回答。该肯定回答表示服务器将针对来自同一客户端的任何新请求使用该push-policy-request中所描述的新的push-policy。

如果服务器不想要改变其push-policy，则该服务器返回错误代码回答以向客户端通知该推送策略请求被拒绝。

接着，在客户端在步骤1807中请求下一片段Data 3.1的情况下，服务器在步骤1808中利用针对接下来的三个片段Data 4.1、Data 5.1和Data 6.1的PUSH PROMISE来进行回答。

图21使用流程图示出在使用HTTP请求来共享推送策略的情况下服务器侧的处理的步骤，而图22使用流程图示出在使用HTTP请求来共享推送策略的情况下客户端侧的处理的步骤。

与图14的处理相比，服务器包括用以处理来自客户端的推送策略请求并且还发送初始策略及其更新的新的处理步骤(2100～2105)。

如果服务器所接收到的请求是来自客户端的推送策略请求(测试2100)，则服务器首先在步骤2101中解析该推送策略请求以提取客户端所提出的数据推送的制约。

在该步骤期间，服务器可以决定遵循客户端所请求的推送策略。在这种情况下，服务器更新其内部推送策略(步骤2102)并且在步骤2103中将OK 200应答发送至客户端，以确认所提出的推送策略。

否则，在(例如，由于所提出的策略在资源方面过于昂贵或者不能应用因此)服务器丢弃该推送策略的情况下，步骤2102不修改服务器处的内部推送策略，并且在步骤2103中将错误代码发送至客户端。

根据特定实施例，服务器还可以独立于客户端的请求另外更新该服务器的推送策略。在这种情况下，服务器在步骤1402中确定推送策略，并且可以(例如，通过分析客户端所进行的请求和网络特性)决定改变该推送策略的特性或者注意到所确定的推送策略不同于当前推送策略。在这种情形下，如果客户端并未知晓新的推送策略(测试2104)，则服务器必须与客户端共享该新的推送策略，其中在这种情况下，在步骤2105中在HTTP头部中发送该新的推送策略。

参考图22来说明客户端侧的相应处理。关于服务器处理，与图14的处理相比，添加了新的处理步骤(2200～2204)，以处理推送策略消息并进行推送策略请求。

在步骤1400中确定了当前的共享推送策略(即，服务器的推送策略)之后，客户端可能期望新的推送策略，例如来减少为了检索媒体流的片段而要发送的HTTP请求的数量。因而，在客户端要求新的推送策略的情况下(测试2200)，如前面所述，客户端在步骤2201中利用“push-policy-request”发送HTTP请求。

在步骤2204中处理针对该请求的应答，其中在该步骤2204中，客户端通过返回OK200应答或错误代码来检查服务器是否确认了该请求。

如果服务器返回OK 200应答，则步骤1400中所确定的当前推送策略由所请求的策略替换。否则，当前推送策略保持不变。

除图14的处理外，在客户端从服务器接收到具有新的推送策略的帧的情况下(测试2202)，对该推送策略进行解析并存储(步骤2203)在存储器中，以在下次发生步骤1400时进行检索。

必须注意，在push-policy请求处于还包括其它数据(例如，媒体数据)的帧中的情况下，通过步骤109-111-113-115来处理其它数据。

尽管上述基于HTTP的示例使用HTTP请求来完整地定义要应用的推送策略，但一个特定实施例可以依赖于具有在客户端侧和服务器侧这两者处定义的并且各自具有唯一标识符的相同的预定义推送策略的组。在这种情况下，HTTP请求仅用于从该组中指定要使用的推送策略的标识符。该特定实施例减小了HTTP请求的大小。

在一个实施例中，将推送策略请求作为用于请求服务器资源其中之一的HTTP请求其中之一的附加HEADER来进行发送，即，通常在针对MPD文件的GET请求的“Accept-Push-Policy(接受推送策略)”HTTP头部中发送推送策略请求。

在另一实施例中，客户端在一个HTTP请求中指定多个“Accept-Push-Policy”以表示客户端所支持的(或所需的)推送策略的列表。响应于HTTP请求，服务器可以选择所提出的列表中的推送策略其中之一然后在HTTP应答中指定该推送策略、或者在不支持任何推送策略的情况下利用新的推送策略进行应答。

在又一实施例中，独立于服务器已知的任何资源在专用HTTP请求中发送推送策略请求。例如，GET(或POST(发布))请求是利用与任何网页资源均不对应的URL(例如，http://server/push_policy)以及还利用至少一个Accept-Push-Policy头部所形成的。

在又一特定实施例中，可以在服务器和客户端之间交换的MPD文件中定义各自具有唯一标识符的一组替代推送策略。可以将这些推送策略其中之一标记为服务器所选择的默认推送策略。客户端可以通过发送包括要代替默认推送策略而使用的推送策略的标识符的新的推送策略请求来指定应使用哪个推送策略。

在一个实施例中，定义特定推送策略以表示紧挨在针对快速启动所用的MPD文档的请求之后将推送哪个片段。

在混合方法中，描述共享推送策略的推送策略信息由第一推送策略部分和第二推送策略部分来定义，其中该第一推送策略部分插入在描述文件(MPD)中，并且该第二推送策略部分嵌入在从服务器装置发送至客户端装置的HTTP帧的头部中。

例如，MPD可以定义具有模板实参的推送策略，然后这些模板实参由于push-policy HTTP请求而由服务器定义(或甚至重载)。作为示例，MPD文件中所定义的推送策略可以是<PushPolicy SegmentIdx＝“parameter”/>，并且可以在push-policy HTTP请求中定义变量“parameter”的值。在该示例中，第二推送策略部分(仅)包括针对第一推送策略部分中所定义的一个或多个关联变量的一个或多个值。

使用上述的基于推送策略标识符的方法，描述文件可以包括多个候选推送策略的描述，并且第二推送策略部分由此可以包括来自所述多个候选推送策略的候选推送策略的标识符，其中该标识符标识出候选推送策略，由此形成第一推送策略部分。

在另一实施例中，为了向客户端声明推送策略，推送策略依赖于MPD中所定义的<Role>描述符以指示将选择哪个表现中的推送数据。通常，推送策略可以指定该推送策略将使用具有“替代”或“补充”角色值的Representation中的片段。

在另一实施例中，将例如流传输清单或HTML页面的资源的文档变换成优先级树，其中浏览该优先级树以确定在接收到GET请求之后要推送的资源。由于XPath请求因此可以进行优先级树内的导航。在该方法中，推送策略信息在资源的文档的树表现上包括待评价的XPath表达式，以识别第二非请求媒体数据。

例如，在流传输清单中，可以使用“following[name()＝“SegmentURL”][2]”XPath表达式来选择跟随在客户端在GET请求中所请求的片段之后的接下来的两个片段作为要推送的片段。同样，对于章节切换用例，“((following[name()＝“Period”]//SegmentURL)[2])”XPath表达式使得可以选择下一Period的两个最初片段以预加载各章节的最初两个片段。例如，在客户端请求图24的MPD文件中的片段2401的情况下，服务器还将下一Period的片段2402和2403作为推送数据来发送。

另外，例如可以首先使用XSLT指令对优先级树进行重新排序，以简化针对高级推送策略规则的XPath表达式编写。XSLT指令使得可以在应用推送策略之前重新组织该树。优选例如在一个HTTP头部中将XPath表达式发送至客户端，并且在网页中定义XSLT样式表。这特别适用于HTML文档，例如以将文档中所声明的所有图片和所有CSS资源分组为DOM树的同一层级的连续节点。

例如，图25的树2501表示具有不同类型的不同资源的HTML页面：阴影节点(2511～2514)对应于图像资源，并且素色的节点(2521～2524)是脚本资源(CSS或Javascript)。树2502是针对按类型对资源进行分组(2530中的图像和2540中的脚本资源)的XSLT变换结果的示例。如此可以定义简单的XPath表达式以表示一旦请求了具有给定类型的第一个资源就将推送具有该给定类型的一些资源。

在上述的所有实施例中，在推送策略需要推送多个片段的情况下，服务器很有可能针对各客户端请求利用多个PUSH PROMISE进行回复。

例如，图19的MPD 1900具有表示将推送跟随在所请求的片段之后的三个片段的推送策略(参见<PushPolicy>元素)。结果，如果客户端利用针对字节范围等于0～999的媒体1901的GET请求来请求初始化片段，则服务器将在步骤103期间发送三个PUSH_PROMISE消息1902。

在一个实施例中，如果所识别出的第二媒体数据包括各自要求通报消息(即，PUSH_PROMISE)的多个媒体片段，则可以将相应的多个通报消息合并成单个通报消息以发送至客户端装置。

为了实现该情况，如图20所示，与图14的一般处理相比，优选服务器处的处理包括紧挨在步骤103中发送推送承诺之前的预处理步骤2000。该预处理步骤尝试进行上述的通报消息的合并处理。

在如1902那样、推送承诺包括字节范围请求的情况下，浏览推送承诺的列表1902以生成包含相连字节范围地址的推送承诺的缩并集合1903。接着，推送承诺1902的各集合由相连字节范围等于推送承诺集合中的字节范围的串接的推送承诺的缩并集合1903或者由具有非相连字节范围的列表的单个推送承诺(例如，1905)替换。

例如，三个推送承诺1902由图19所示的单个推送承诺1903替换。

合并推送承诺的该方法使得客户端可以以更加简单的方式并且以更低的带宽和处理成本来取消推送数据的发送。这是因为，代替针对各个未合并的推送承诺关闭多个流，客户端只需要针对单个推送承诺关闭单个流。

在替代例中，即使推送承诺具有不相连的字节范围间隔，所有的推送承诺也可由(连续字节范围间隔已串接)的一系列字节范围替代。

另外，如果推送承诺不包括字节范围间隔而是包括不同的SegmentURL值，则也可以按如下方式串接推送承诺以生成单个推送承诺消息：将生成推送承诺消息的方法定义为MGET(针对多个GET)，并且如1904所示，路径字段是一系列片段URL。与上述实施例相同，客户端必须关闭与所生成的推送承诺相对应的单个流以取消所有片段的推送。

注意，服务器可以在数据中的各片段的末尾包括END_SEGMENT(结束片段)标志然后进行发送，以确保客户端能够解析并识别所推送的各片段。

另外，HTTP/2的SETTINGS帧被扩展为包括使得可以指示针对流传输会话是否允许推送承诺的分组的新的SETTINGS_ENABLE_GROUP_PUSH_PROMISE参数。

由于可以避免一次或多次往返，因此本发明的实施例使得可以进行DASH快速启动。现在参考图26～28来说明本发明的该方面。

DASH快速启动特征可以与以上参考图7～12和14～25的全部或一部分所述的任何通信方法一起使用。

图26示出服务器和客户端装置为了获得DASH快速启动而根据本发明的教导所分别实现的示例性方法。

如刚刚说明的标准处理那样，第一个步骤包括客户端请求描述文件(这里为MPD文件)(步骤2650)。然后，客户端等待服务器的应答(步骤2651)。

同时，如以下所述，服务器特别是为了识别出(步骤2653)将帮助客户端更快速地启动的初始化数据而分析该MPD文件(步骤2652)。以下参考图27来说明针对步骤2653的典型实施例。

一旦服务器识别出初始化数据，该服务器在步骤2654中将PUSH_PROMISE帧发送至客户端，以表示其意图是无需等待客户端的请求而推送初始化数据。

可能地，服务器还用信号通知该服务器还将通过发送包括如下的头部字段的另一PUSH_PROMISE帧来推送初始媒体数据(步骤2656)，其中这些头部字段使得客户端能够识别所关注的资源、即所关注的初始媒体数据，诸如:scheme、:host和:path等。

在初始化数据的PUSH_PROMISE帧和初始媒体数据的PUSH_PROMISE帧这两种情况下，服务器还添加其它头部字段以表示服务器对该服务器已决定推送的数据的置信度有多少：在本实施例中，confidence_level(置信度水平)参数关联至PUSH_PROMISE帧(即，包括在PUSH_PROMISE帧的头部中)。以下参考图27来说明confidence_level参数的确定。服务器还可以插入特定DASH头部以明确地指示该服务器意图推送的片段。

为了使客户端将针对要推送的初始化数据和第一媒体数据作出请求的风险最小，应在应答中的任何内容之前发送PUSH_PROMISE帧，即步骤2654和步骤2656应在将MPD文件从服务器发送至客户端装置的步骤2655之前发生。

因而，在要将PUSH_PROMISE帧发送至客户端装置的情况下，在步骤2655中，服务器将MPD文件发送至客户端装置。

如果与此同时服务器尚未从客户端装置接收到任何CANCEL(取消)或ERROR(错误)消息，则服务器开始推送初始化数据(步骤2657)和第一媒体数据(步骤2658)。

如例如在2013年6月24日出版的文档“Hypertext Transfer Protocolversion2.0,draft-ietf-httpbis-http2-latest”HTTPbis Working Group,Internet-Draft(例如可在http://http2.github.io/http2-spec/处获得)中所述，例如根据在HTTP2.0框架中开发的相应特征来进行PUSH_PROMISE帧和从服务器向客户端装置的数据的推送。

在客户端装置处进行接收时，客户端可以使用初始化数据来对解码器进行设置(步骤2659)，并且对第一媒体数据进行缓冲(步骤2660)，直到足够量的数据可用来进行解码和渲染(例如，显示)而不发生显示冻结为止。

在客户端成功接收到MPD文件的情况下，假定缓冲了足够的数据(步骤2661)，则该客户端解析该MPD文件(步骤2662)并且开始进行解码和显示(步骤2663)。如果不是这种情况、并且客户端装置根据服务器所发送的PUSH_PROMISE帧得知将发送更多的片段(参见步骤2656)，则客户端在步骤2664中等待来自服务器的第一媒体数据的推送的完成。在该空闲的步骤2664期间，如以上已经说明的，客户端装置可以准备将要以标准客户端控制的DASH来发起的、针对后续片段的接下来的请求(步骤2665)。由于客户端装置接收到与相应的PUSH_PROMISE帧中的要推送(或正推送)的初始媒体数据有关的信息(参见上述的步骤2656)、并且由此可以准备针对紧挨在服务器意图推送的最后一个时间片段之后的时间片段的请求，因此上述情形是有可能的。

客户端装置在完整地接收到MPD的情况下，还可以使用与步骤2656中所接收到的初始媒体数据有关的信息来检查该初始媒体数据是否充满缓冲器，并且如果该初始媒体数据没有充满缓冲器，则在步骤2661之前，根据标准客户端控制的DASH处理来发送针对下一媒体数据(例如，与跟随在初始媒体数据所表示的时间片段之后的时间片段相对应的媒体数据)的请求(这与图26所示的所推送的初始媒体数据充满缓冲器的情况相反)。这样使得客户端能够校正来自客户端的针对要推送的第一媒体数据的量的错误估计。

该处理使得与标准的基于清单的流传输的情况相比，流传输客户端能够更早地开始显示媒体。实际上，由于为了获得初始化数据和/或初始媒体数据所进行的网络上的HTTP往返的次数减少，因此启动延迟缩短。

然而，该处理仍然符合当前DASH标准，这是因为：

-没有修改MPD文件：MPD文件的传输保持既轻又快；

-标准DASH客户端(即，不受益于本发明的教导)的行为可以保持不变：这种客户端装置将忽略未识别出的HTTP头部，并且在不接受推送特征的情况下，将只需要进行更多的请求/应答并由此花费更多的时间来开始进行呈现即可。

图27描述从客户端装置请求清单(或描述文件)之后服务器侧所实现的示例性方法。

该方法尝试预先识别要推送的最相关的初始数据，使得客户端可以快速地开始媒体呈现的显示。

在步骤2700中，接收到针对清单的请求。然后，服务器在步骤2701中检查客户端装置是否将一些偏好插入在该请求中。这可以按如下方式经由专用HTTP头部来进行，例如以表示媒体呈现的传输速率和音频流的偏好语言：

GET http://myserver.com/presentation/pres1.mpd\r\n

Prefered-MediaRange:bw＝2000；lang＝FR\r\n\r\n

如果请求包括偏好(测试2701为“真”)，则服务器分析客户端的偏好(步骤2703)并且将服务器的confidence_level参数设置为值“high(高)”(步骤2704)。

如果在该请求中没有提供指示(测试2701中为“假”)，则服务器在步骤2702中检查该服务器是否已登记了针对该客户端的服务使用信息(日志)(即，基于用户或客户端装置与服务器之间的先前交换的统计数据或使用数据)或者来自User-Agent(用户-代理)头部的信息。实际上，User-Agent头部在RFC2616中被定义为HTTP头部(例如，参见http://www.ietf.org/rfc/rfc2616.txt)，并且针对应用程序提供了用以交换信息(例如，操作系统、浏览器类型、应用程序名称等)的方式。例如，DASH服务器可以具有针对能够使用服务之前的客户端的认证方案；在变形例中，可以是有权访问服务之前的用户登录。利用这种方式，服务器可以使媒体参数链接至所连接的用户或装置。

在针对所关注的客户端装置或用户存在先前的使用信息(日志)的情况下(测试2702中为“真”)，通过在步骤2705中解析该日志，服务器可以推断出给定客户端或用户的最常见使用。例如，可以推断出用户或客户端装置始终选择语言为法语的音频流和HD(高清晰度)的视频流。此外，服务器可以知晓请求是否是开放TCP连接中的第一次请求(客户端连接至服务器并且请求第二次媒体呈现)。在这种情况下，带宽估计可以更加准确可靠，并且针对第一次请求，TCP拥塞窗可以更大。这样可能会影响服务器在合适的Representation方面所进行的选择。

通过登记DASH质量度量，服务器可以在其日志中包括用户/客户端经常进行的各种表现之间的变化。据此，服务器根据变化的频率(变化是指无论标准(带宽、分辨率、帧频等)如何都切换为其它Representation)来将经常性行为确定为“积极型”或恒定型(constant)。积极型客户端是在其环境改变时将自动切换为不同表现的DASH客户端。作为示例，在检测带宽或缓冲器占用率的情况下，只要新的Representation与当前Representation相比具有更接近客户端的环境的特性，积极型客户端就将请求占用不同带宽的Representation。相反，恒定型客户端将尽量避免频繁的Representation切换以维持稳定的质量和显示速率。在用户/客户端装置行为在适应性方面相当积极的情况下，服务器则知晓无论选择何种作为初始表现来开始流传输，客户端将试图在接下来的流传输的开头几秒或几分钟内进行适应。

在根据日志来推断偏好的情况下，在步骤2706中服务器将其confidence_level参数设置为值“mid(中)”。实际上，该信息与客户端自身所进行的显式偏好信号通知相比不太相关(测试2701为“真”)。

在日志信息不可用的情况下(测试2702为“假”)，则服务器在步骤2707中将其confidence_level参数设置为最低值“low(低)”。这表示由于服务器不具有要决定的先验信息(priori information)，因此服务器正对其推送的信息进行最佳猜测。以下说明这种情况下的进一步处理(参见步骤2711)。

与该confidence_level参数计算并行地，在步骤2708中，服务器可以解析清单。在清单不容易经常发生改变的情况下(特别是针对与实时服务相反的按需服务而言)，可以通过将各种Representation的描述登记在查找表中来一次性地以离线方式进行清单的解析。该查找表还可以由服务器使用以使客户端的日志链接至媒体呈现的某些部分。这样使得能够进行更快速的日志处理(参见以上所述的步骤2705)以推断某些客户端的偏好。

清单的解析(步骤2708)在(步骤2709中)选择合适的Representation作为用以开始流传输的初始Representation(即，初始媒体数据)时向服务器提供信息。

步骤2703和2705这两者(分别为获得请求中的偏好或者基于来自先前交换的使用数据获得偏好)在于将来自客户端装置/用户的偏好或使用转译成将匹配MPD属性的具体参数。例如，这些参数可以是带宽、视频的宽度和高度、使用中的编解码器的种类、字幕或音频流的语言。然后，根据所获得的这些参数的值，服务器与清单中的值进行比较，以在步骤2709中识别要推送至客户端的最便利Representation。

可以注意，该步骤2709通常是客户端装置以如DASH那样的动态且自适应流传输协议来连续进行的操作。这里，服务器利用MPD解析方法在流传输会话的开头进行相同的步骤。

在2709中无法得出合适的Representation的情况下，测试2710为假并且服务器(在上述的步骤2707中)将其confidence_level参数设置为“low”值。

在(由于无法确定偏好、或者由于无法基于偏好而找到合适的Representation因此)confidence_value参数的值为“low”的情况下，服务器在步骤2711中决定选择最简单的Representation。对于视频而言，例如，最简单的Representation可以是空间分辨率最低且针对最低带宽设计的Representation。

根据可能的互补特征(图27中没有示出)，在不存在针对编解码器的不清楚(即，所有的视频Representation具有相同的编解码器属性值，即使用相同的编解码器(例如，HEVC)对所有的视频Representation进行了编码)的情况下，confidence_level参数可以增大为值“mid”。

步骤2711之后或者在找到了合适的Representation的情况下(测试2710为“真“)的下一步骤在于识别初始化数据(步骤2712)。实际上，在DASH清单(或描述文件)中，可以以不同方式用信号通知初始化信息，即，可以将初始化信息以显式方式放置在提供指向初始化数据的URL的SegmentBase、SegmentList或SegmentTemplate元素的Initialization(初始化)元素中。

在这种情况下，将该URL放置在PUSH_PROMISE帧的头部字段中(参见以上参考图26所述的步骤2654)，其中该头部字段(通过指定变量:scheme、:host和:path并最终指定:Range)将允许客户端识别承诺要推送的资源。

在没有显式描述初始化数据的情况下，这意味着媒体片段是自初始化的。在这种情况下，服务器必须解析片段的开头(例如，采用mp4格式的片段的片段索引信息框)。基于该分析，服务器可以建立具有将作为头部放置在PUSH_PROMISE帧中的具有适当字节范围的相应URL。

一旦被识别出，则立即将初始化数据的PUSH_PROMISE帧发送至客户端(与图26的步骤2654相对应的步骤2713)，紧接着进行初始化数据的推送(与图26的步骤2657相对应的步骤2717a)。在接收到初始化数据的情况下，则客户端可以对其媒体解码器进行初始化(步骤2717b)。

可选地，为了在处理PUSH_PROMISE帧时改进客户端装置所进行的片段信号通知和随后的识别(参见以下所述的步骤2806)，服务器在步骤2713中可以指示：所推送的数据的性质，即初始化或媒体或(自初始化片段的情况下的)这两者；作为图5b的MPD表现树中的路径的URL模板或片段的指示的参数(例如：P2AS21R211S1；即，跟随在标识符之后的元素类型串)。可以注意，这要求客户端装置接收到MPD。然后，服务器可以决定仅将该特定信息添加在该服务器认为在客户端装置接收到MPD之后将处理的PUSH_PROMISE消息中。为了帮助在客户端装置处决定在MPD接收和解析之前是否接受PUSH_PROMISE，代替MPD中的片段路径，服务器可以指示与所推送的片段有关的定性信息(诸如，片段是来自基本层还是来自增强层等)；根据另一示例，服务器可以将所选择的Representation的属性连同所选择的Representation的值一起放置在头部中。

根据可能的实施例(图27上没有示出)，在解析清单(步骤2708)判断为在清单的顶层元素中存在初始化数据的情况下(即，无论Representation如何，初始化数据针对所有的表现共通的；例如，在依赖型Representation的情况下)，由于不存在所推送的数据和客户端将会选择的数据之间存在不一致的风险，因此服务器可以在confidence_level参数被设置为值“high”的情况下立即(即，与步骤2708同时)发送指定了初始化数据的PUSH_PROMISE帧。将confidence_level参数与PUSH_PROMISE帧(例如作为HTTP头部)一起发送的好处是可以帮助客户端装置接受或取消推送承诺(参见以下针对图28的说明)。

由于该特征，客户端甚至将更早接收到设置其解码器所需的初始化数据(这是由于提早发送了PUSH_PROMISE帧)。这在初始化数据针对给定媒体类型而言是唯一的情况下同样适用(例如，无论AdaptationSet中的Representation的数量如何，针对各AdaptationSet存在单一InitializationSegment(初始化片段))。该更快的推送将紧挨在清单的解析(上述的步骤2708)之后到来，由此是在处理日志或偏好(上述的步骤2701、2703和2705)之前到来的。

然后，如果服务器先前确定的confidence_level参数大于或等于“mid”值(测试2714)，则服务器主动推送该服务器认为适合客户端的第一媒体数据。

这在以下两个步骤中迭代进行：首先发送PUSH_PROMISE帧(与图26的步骤2656相对应的步骤2715)，然后在步骤2719中开始第一媒体数据的推送。针对在步骤2709中选择要推送的各第一媒体数据片段重复进行该操作。

根据可能的实施例，在承诺要推送连续的媒体片段(即，针对各媒体片段发送多个PUSH_PROMISE)的情况下，将关联至当前媒体片段的PUSH_PROMISE标记为先前PUSH_PROMISE的子PUSH_PROMISE或跟随PUSH_PROMISE(步骤2716)。该PUSH_PROMISE在服务器不在状态的情况下可作为新的HTTP头部放置在PUSH_PROMISE帧中，或者在服务器有状态的情况下保持在表中。对于对推送承诺进行层级取消(如以下参考图28所述)而言，保持该关系可以是有用的。

数据的各种传输的可能安排如下所述：在实际推送第一媒体数据之前，服务器在上述的步骤2717a中开始推送初始化数据；与发送与第一媒体数据和初始化数据有关的PUSH_PROMISE帧并行地，服务器还在步骤2718中发送MPD文件(清单)，并且使流保持打开，直到完整地发送了所推送的数据为止。

在另一实施例中，无论置信度如何，都可以避免测试2714以推送第一媒体数据。但在将confidence_level参数设置为“low”的情况下，服务器可以在实际推送第一(或初始)媒体数据之前，等待来自客户端的潜在CANCEL。

在推送第一媒体数据的情况下，服务器确定要推送的数据的总量和要使用的速度(流量控制)。

关于第一方面，服务器可以利用诸如清单的开头所述的minBufferTime(最小缓冲时间)属性等的来自清单的信息。使用该属性、考虑步骤2709或2711中所选择的Representation、并且鉴于同样设置在清单中的片段持续时间属性，服务器为了满足minBufferTime制约而容易地确定要推送的片段的数量(即，片段的量，因而形成要推送的初始媒体数据的数据的量)。有利地，在以离线方式进行清单的解析(步骤2708)的情况下，可以将该第一媒体片段的数量以表的形式记录在服务器的存储器中。

关于第二方面，考虑到片段的持续时间和所选择的Representation的带宽，服务器可以获得所需的比特率的估计值。这样主要针对视频片段提供了要使用的传输速率。例如，针对具有持续时间为5秒的片段的、带宽等于1.6Mbits/s的压缩视频表现，各片段将表示1兆字节的要发送的数据。在默认的情况下，HTTP v2.0中的流量控制提供最多等于65535字节的流窗大小。因而，在我们的示例中，这意味着客户端将必须向服务器发送回针对所推送的65536字节的各包的确认，因而在我们的示例中为针对每片段多于15次！由于我们的目的是在根据开发中的HTTP 2.0使用推送特征的情况下减少网络往返和拥塞，因此可以清楚地看出这里需要修改默认行为(实际上是默认拥塞窗大小)以使得能够(通过减少网络通信量)进行DASH快速启动。

在客户端装置发送在其针对清单的请求中所包括的偏好的情况下，还可以表示要紧挨在该请求之后发送SETTINGS帧；该SETTINGS帧例如指定与其缓冲容量一致的初始窗大小(SETTINGS_INITIAL_WINDOW_SIZE)。根据可能的变形，可以在连接设置时发送该SETTINGS帧。另一可能性是客户端装置在确认所推送的第一个数据的情况下，发送大小适当的WINDOW_UPDATE。

图28描述根据本发明的教导的、客户端装置在与执行例如图27所述的方法的服务器交换数据的情况下所实现的可能方法。

根据该方法的可能应用，客户端装置连接至服务器以受益于视频点播服务。客户端和服务器之间的连接建立是传统的。在本示例中，客户端装置和服务器这两者能够使用例如已经说明的文献“Hypertext Transfer Protocol version 2.0,draft-ietf-httpbis-http2-latest”中所描述的HTTP/2.0协议来交换消息。

在某个时刻(例如在客户端装置处的用户选择给定视频的情况下)，客户端装置从服务器获得与描述媒体呈现(这里为用户想要观看的视频)的清单的地址(例如，URL)有关的信息。

然后，客户端装置准备用以下载清单的请求(步骤2800)。在优选实施例中，客户端经由HTTP头部添加与其支持的视频分辨率、编解码器、带宽有关的一些偏好(步骤2801)。然后，客户端装置将其请求发送至服务器(步骤2802)。

在本实施例中，客户端装置随后在步骤2803中发送HTTP/2.0SETTINGS帧以表示与其缓冲容量一致的初始窗大小(SETTINGS_INITIAL_WINDOW_SIZE)(参见上述的文献“Hypertext Transfer Protocol version 2.0,draft-ietf-httpbis-http2-latest”，第3.8.5章节)。

在步骤2804中，客户端装置开始处理各种服务器应答，即，接收形成清单的数据并且解析该数据(步骤2805)，而且还接收服务器所发送的PUSH_PROMISE帧(步骤2806)。

在决定接受或取消PUSH_PROMISE帧中所指定的推送之前，客户端构建服务器意图推送的资源的URL(步骤2806)并且检查(步骤2807)由服务器包括在PUSH_PROMISE帧中的confidence_level参数。

并行地并且在完全接收到清单(或描述文件)的情况下，客户端装置构建(步骤2808)其想要获得的期望媒体片段的列表(即，最适合客户端需求的各片段的版本的列表)并且将当前segment_index(片段索引)变量初始化为0(步骤2809)。处理PUSH_PROMISE的第一步骤在于(步骤2810a)检查confidence_level参数。然后，根据(预定义的)客户端设置或用户偏好，客户端可以决定拒绝置信度低于一定水平的PUSH_PROMISE、例如PUSH_PROMISE帧包括具有“low”值的confidence_level参数的PUSH_PROMISE。

如果客户端可以使PUSH_PROMISE帧中所述的URL与(如刚才在步骤2808中根据清单所推导出的)期望片段的URL相匹配的情况下(步骤2810b)，则客户端使针对与传输状态一起传输的待定片段的列表的表初始化(步骤2811)。如果在步骤2810b中客户端在期望媒体片段的列表中无法识别出服务器意图要推送的片段，则客户端通过将适当的CANCEL指令发送至服务器来取消该推送(步骤2812)。

为了便于步骤2810b的片段识别，客户端可以利用例如所推送的片段的索引那样的附加头部信息作为MPD树表现中的路径(参见图5b)、或者在描述文件(即，MPD文件或清单)依赖于SegmentTemplate的情况下作为URL模板参数。

这里，由于使用服务器在构建PUSH_PROMISE时所插入的层级关系(参见上述的图27的说明)、客户端可以发送将会导致取消当前PUSH_PROMISE和后续PUSH_PROMISE的递归CANCEL，因此这是特定的CANCEL消息(步骤2812)。

根据可能的实施例，在客户端装置无法解释推送承诺的情况下，该客户端装置默认停止与接下来的媒体资源的时间片段相对应的媒体数据的所有推送。

CANCEL指令的该新使用一旦在媒体片段识别方面与服务器不同步，则将避免客户端重复CANCEL消息。在这种情况下，客户端将退回到拉取模式。

在通过从服务器推送要接收的片段与期望片段相对应的情况下(测试2810b为“真”)，客户端随后继续PUSH_PROMISE帧的处理(测试2813并且在步骤2806中循环)。

在处理了所有的PUSH_PROMISE帧的情况下，客户端装置预期并且开始接收并缓冲(步骤2814)与所接受的PUSH_PROMISE相对应的数据。

在客户端的接收缓冲器中接收到足够的媒体片段的情况下(测试2815)，客户端处理这些媒体片段(2816)。然后，利用列表中的第一片段的有序编号来更新当前segment_index变量(步骤2817)。应当注意，并非所有的客户端都有权访问客户端的缓冲器。例如，特别是web应用程序通常无权访问web浏览器高速缓存。在这种情况下，服务器可以将所推送的片段的列表直接发送至web应用程序客户端。例如，可以使用web套接字连接来从服务器向客户端交换该信息。

在处理了所推送的所有媒体片段的情况下，客户端则可以返回至标准的基于拉取的DASH(步骤2818)，从而开始请求与变量segment_index+1所指定的下一片段相对应的数据。并行地，使用所推送的片段数据来开始进行所选择的视频的解码和显示。

图13是根据实施例的装置的示意例示。该装置可以是服务器、客户端或代理。该装置包括RAM存储器1302，其中该RAM存储器1302可用作被配置为实现根据实施例的方法的控制单元1301的工作存储器。例如，控制单元可被配置为执行从ROM存储器1303加载的计算机程序的指令。该程序也可以是从硬盘驱动器1306加载的。例如，计算机程序是基于图8～12、14、15、17、20～22和26～28的流程图以及上述说明所设计的。

该装置还包括可以是单个网络接口的网络接口1304、或者包括一组网络接口(例如，多个无线接口、或者多种有线或无线接口)。该装置可以包括用于向用户显示信息并且用于接收来自用户的输入的用户接口1305。

该装置还可以包括用于相对于外部装置进行数据的接收和/或发送的输入/输出模块1307。

尽管已经在附图和前述说明中详细例示并说明了本发明，但这些例示和说明应被视为说明性或例示性而非限制性的，其中本发明不限于所公开的实施例。本领域技术人员在根据针对附图、公开内容和所附权利要求书的研究实践要求保护的发明时，可以理解并实现所公开的实施例的其它变形例。

在权利要求书中，词语“包括”并未排除其它要素或步骤，并且不定冠词“a”或“an”并未排除多个。单个处理器或其它单元可以实现权利要求书所记载的多个项的功能。在相互不同的从属权利要求中记载不同特征这一事实并不表示无法有利地利用这些特征的组合。权利要求书中的任何附图标记不应被视为为限制本发明的范围。

本申请要求2013年7月12日提交的英国专利申请1312547.1和1312561.2这两者、以及2014年6月12日提交的英国专利申请1410540.7的优先权，在此通过引用包含这三者的全部内容。

Claims (20)

1.一种用于将媒体数据从服务器提供至客户端的方法，所述方法包括以下步骤：

从所述客户端接收媒体呈现描述请求即MPD请求，所述MPD请求用于请求MPD并且包括表示所述客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；

根据来自所述客户端的所述MPD请求中的参数，确定要推送至所述客户端的一个或多个片段；以及

响应于来自所述客户端的所述MPD请求，将所确定的一个或多个片段推送至所述客户端。

2.根据权利要求1所述的方法，其中，在所述确定的步骤中，确定将包含呈现封装在媒体片段中的媒体流所需的元数据的初始化片段推送至所述客户端。

3.根据权利要求1所述的方法，其中，在所述确定的步骤中，确定将一些媒体片段推送至所述客户端。

4.根据权利要求1所述的方法，其中，在所述确定的步骤中，确定将初始化片段和一些媒体片段推送至所述客户端。

5.根据权利要求1所述的方法，还包括：将表示所述服务器意图推送根据所述参数的片段的通知发送至所述客户端。

6.根据权利要求1所述的方法，其中，所述参数包括与视频的高度有关的参数。

7.根据权利要求1所述的方法，其中，所述参数包括与带宽有关的参数。

8.根据权利要求1所述的方法，其中，所述参数表示视频片段的传输速率和音频片段的语言信息至少之一。

9.根据权利要求1所述的方法，还包括：响应于所述MPD请求，将所述MPD发送至所述客户端。

10.一种用于利用客户端从服务器接收媒体数据的方法，所述方法包括以下步骤：

将媒体呈现描述请求即MPD请求发送至所述服务器，所述MPD请求用于请求MPD并且包括表示所述客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；以及

响应于所述MPD请求，接收从所述服务器推送的一个或多个片段，其中所推送的一个或多个片段是由所述服务器根据所述MPD请求中所包括的参数确定的。

11.根据权利要求10所述的方法，其中，在所述接收的步骤中，接收从所述服务器推送来的、包含呈现封装在媒体片段中的媒体流所需的元数据的初始化片段。

12.根据权利要求10所述的方法，其中，在所述接收的步骤中，接收从所述服务器推送来的一些媒体片段。

13.一种用于将媒体数据提供至客户端的装置，所述装置包括：

硬件处理器；以及

存储器，用于存储一个或多个程序，所述一个或多个程序被配置为由所述硬件处理器执行，所述一个或多个程序包括用于进行以下步骤的指令：

从所述客户端接收媒体呈现描述请求即MPD请求，所述MPD请求用于请求MPD并且包括表示所述客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；

根据来自所述客户端的所述MPD请求中的参数，确定要推送至所述客户端的一个或多个片段；以及

响应于来自所述客户端的所述MPD请求，将所确定的一个或多个片段推送至所述客户端。

14.根据权利要求13所述的装置，其中，在所述确定的步骤中，确定将包含呈现封装在媒体片段中的媒体流所需的元数据的初始化片段推送至所述客户端。

15.根据权利要求13所述的装置，其中，在所述确定的步骤中，确定将一些媒体片段推送至所述客户端。

16.一种用于从服务器接收媒体数据的装置，所述装置包括：

硬件处理器；以及

存储器，用于存储一个或多个程序，所述一个或多个程序被配置为由所述硬件处理器执行，所述一个或多个程序包括用于进行以下步骤的指令：

将媒体呈现描述请求即MPD请求发送至所述服务器，所述MPD请求用于请求MPD并且包括表示客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；以及

响应于所述MPD请求，接收从所述服务器推送的一个或多个片段，其中所推送的一个或多个片段是由所述服务器根据所述MPD请求中所包括的参数确定的。

17.根据权利要求16所述的装置，其中，在所述接收的步骤中，接收从所述服务器推送来的、包含呈现封装在媒体片段中的媒体流所需的元数据的初始化片段。

18.根据权利要求16所述的装置，其中，在所述接收的步骤中，接收从所述服务器推送来的一些媒体片段。

19.一种非暂时性计算机可读存储介质，其存储程序，所述程序用于使计算机执行用于将媒体数据提供至客户端的方法，所述方法包括以下步骤：

从所述客户端接收媒体呈现描述请求即MPD请求，所述MPD请求用于请求MPD并且包括表示所述客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；

根据来自所述客户端的所述MPD请求中的参数，确定要推送至所述客户端的一个或多个片段；以及

响应于来自所述客户端的所述MPD请求，将所确定的一个或多个片段推送至所述客户端。

20.一种非暂时性计算机可读存储介质，其存储程序，所述程序用于使计算机执行用于从客户端接收媒体数据的方法，所述方法包括以下步骤：

将媒体呈现描述请求即MPD请求发送至服务器，所述MPD请求用于请求MPD并且包括表示所述客户端对初始化信息和媒体的偏好的参数，其中所述MPD是按MPEG-DASH标准定义的；以及

响应于所述MPD请求，接收从所述服务器推送的一个或多个片段，其中所推送的一个或多个片段是由所述服务器根据所述MPD请求中所包括的参数确定的。