CN104969560A

CN104969560A - 确定对于网络流式传输可用的媒体数据

Info

Publication number: CN104969560A
Application number: CN201380072076.9A
Authority: CN
Inventors: Y·毛; F·乌卢皮纳尔; D·W·吉利斯
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2013-02-04
Filing date: 2013-12-31
Publication date: 2015-10-07
Anticipated expiration: 2033-12-31
Also published as: US20140222962A1; EP2952006A1; JP2016511575A; JP6240224B2; CN104969560B; KR101704619B1; EP2952006B1; US9432426B2; WO2014120377A1; KR20150114997A

Abstract

一种客户端设备包括一个或多个处理器，该一个或多个处理器被配置为向服务器设备发送对媒体数据的区段的多个探测请求，其中，所述服务器设备使用实时流式传输服务提供所述媒体数据；分析对所述多个探测请求的响应，以确定区段可用性窗口的左边沿和右边沿；以及根据所述实时流式传输服务，基于所述区段可用性窗口的被确定的左边沿和被确定的右边沿，发送对所述区段可用性窗口内的区段的请求。

Description

确定对于网络流式传输可用的媒体数据

相关申请的交叉引用

本申请要求享有于2013年2月4日提交的美国临时申请No.61/760,382的优先权，据此通过引用方式将其全部内容并入本文。

技术领域

本公开内容涉及已编码视频数据的传输。

背景技术

数字视频能力可被结合到多种多样的设备中，包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上或台式计算机、数码相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝式或卫星式无线电电话、视频电话会议设备等。数字视频设备实施视频压缩技术，例如那些在由MPEG-2、MPEG-4、ITU-T H.263或ITU-TH.264/MPEG-4第10部分、增强型视频编码(AVC)规定的标准以及这些标准的扩展中描述的视频压缩技术，来更有效地发送和接收数字视频信息。

视频压缩技术执行空间预测和/或时间预测，以减少或消除视频序列中固有的冗余。对于基于块的视频编码，视频帧或视频切片(slice)可被划分成宏块。可进一步划分每一个宏块。对于帧内编码(I)帧或切片中的宏块，使用相对于相邻的宏块的空间预测对其进行编码。对于帧间编码(P或B)帧或切片中的宏块，可使用相对于同一帧或切片中的相邻的宏块的空间预测，或可使用相对于其他基准帧的时间预测。

在对视频数据进行编码后，视频数据可被打包以供传输或存储。视频数据可被组合成符合各种标准中的任意标准的视频文件，这些标准诸如国际标准化组织基媒体文件格式及其扩展，例如AVC。

发明内容

概括来说，本公开描述了用于在对媒体内容的表征体(representation)的实时网络流式传输期间确定该表征体的可用区段(segment)的技术。客户端设备可发送对该表征体的区段序列的多个探测请求(诸如HTTP HEAD请求)并分析对这些请求的响应以确定可用区段与不可用区段之间的边界。该边界可被称为区段可用性窗口的“边沿”。在某些实施例中，客户端设备可响应于对在前请求的多个响应(包括HTTP 404错误)发送这样的探测请求序列。HTTP错误可指的是客户端设备的时钟相对于所通告的该区段的可用性情况(例如，相对于服务器设备的时钟)发生了偏移。探测请求可允许客户端设备确定一个或多个媒体数据区段是否对于检索来说是可用的。

在一种实施例中，检索媒体数据的方法包括：向服务器设备发送对媒体数据的区段的多个探测请求，其中该服务器设备使用实时流式传输服务提供媒体数据；分析对该多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿；以及根据该实时流式传输服务，基于所确定的区段可用性窗口的左边沿与右边沿发送对该区段可用性窗口内的区段的请求。

在另一种实施例中，用于检索媒体数据的设备包括一个或多个处理器，该处理器被配置为：向服务器设备发送对媒体数据的区段的多个探测请求，其中该服务器设备使用实时流式传输服务提供媒体数据；分析对该多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿；以及根据该实时流式传输服务，基于所确定的区段可用性窗口的左边沿与右边沿发送对该区段可用性窗口内的区段的请求。

在另一种实施例中，用于检索媒体数据的设备包括：用于向服务器设备发送对媒体数据的区段的多个探测请求的单元，其中该服务器设备使用实时流式传输服务提供媒体数据；用于分析对该多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿的单元；以及用于根据该实时流式传输服务、基于所确定的区段可用性窗口的左边沿与右边沿发送对该区段可用性窗口内的区段的请求的单元。

在另一种实施例中，计算机可读存储介质在其上存储有指令，该指令在被执行时使得处理器：向服务器设备发送对媒体数据的区段的多个探测请求，其中该服务器设备使用实时流式传输服务提供媒体数据；分析对该多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿；以及根据该实时流式传输服务，基于所确定的区段可用性窗口的左边沿与右边沿发送对该区段可用性窗口内的区段的请求。

将参照附图和下面的说明书说明一个或多个实施例的细节。根据说明书和附图以及权利要求书，其他的特征、对象和优点都将是显而易见的。

附图说明

图1是示出实施用于通过网络流式传输媒体数据的技术的示例系统的框图。

图2是示出示例多媒体内容的元素的概念图。

图3是示出一组区段的示例区段可用性窗口的概念图。

图4是示出可针对其发送探测请求以确定区段可用性窗口的区段的概念图。

图5至图9是示出对图4的探测请求的各个可能响应图案的概念图。

图10是示出非均匀分隔的探测序列的示例的概念图。

图11是示出用于根据被公开的技术确定区段可用窗口的一个或多个边沿的示例方法的流程图。

具体实施方式

概括来说，本公开描述了用于在流式传输媒体数据的环境(例如通过HTTP(DASH)的动态自适应流式传输环境)中确定可用媒体数据的技术。这些技术可以用于支持HTTP实时流式传输(HLS)或其他实时流媒体服务。尽管总体上关于DASH和HLS进行讨论，但本公开的技术可应用于其他网络流媒体协议。在http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip的网址上可访问的2012年4月1日的ISO/IEC 23009-1:2012,“Information technology—Dynamic adaptivestreaming over HTTP(DASH)—Part 1:Media presentation description andsegment formats,”中规定了DASH。

概括来说，本公开的技术涉及确定媒体数据是否对于检索是可用的。在某些实例中，媒体数据可被通告为在某一时间是可用的，但客户端设备的时钟可能并不与通告了媒体数据可被使用的时间的时钟同步。例如，客户端设备的时钟可能偏移为领先或落后于用于指示何时媒体数据可用的时钟(例如，服务器设备的时钟或内容准备实体的时钟)。

客户端设备可被配置为实施本公开的技术以确定客户端设备的时钟是否相对于表征媒体数据何时可用的时钟时间发生偏移，并确定什么媒体数据是当前可用的。根据本公开的技术，客户端设备可被配置为向服务器设备发送多个请求，其中每个请求对应于媒体数据的区段序列中的相应区段。该请求可被格式化为仅检索区段的少量的数据或不检索区段的数据。例如，该请求可包括HTTP HEAD请求或针对较少量的对应区段(例如，100字节)的部分GET请求。即，请求可包括对大幅小于区段全部数据量的区段数据量的请求。然后，服务器设备可以以所请求的数据或以HTTP 404错误来响应这些请求。通过分析这些响应，客户端设备可确定区段序列中的那些区段是可用的、区段序列中的那些区段是不可用的。

通过基于客户端设备的内部时钟与所通告的区段可用的时间来构造多个请求，客户端设备可确定客户端设备的内部时钟是否已相对于服务器的内部时钟发生偏移。以这种方式，基于客户端设备的时钟与服务器设备的时钟之间的偏移，客户端设备可在区段变为可用时请求该区段。

换言之，在(例如，根据DASH的)实时流式传输中，可大致同步客户端设备和服务器设备。然而，在客户端设备的时钟与服务器设备的时钟之间可能存在正或负几秒的时间增量。这可能导致客户端无法检索区段。尽管时移缓冲深度(TSBD)可能有帮助，但其仅在有限的条件下才能提供帮助。当前在客户端设备与服务器设备之间也没有毫秒级精确的时间同步协议。这样的协议很难实现，并且超出了DASH的范围。

本公开的技术提供的一种实用的解决方案包括：客户端设备能够仅基于客户端的行为来估计时间增量，并在之后将时间增量纳入考虑来进行后续请求。当初始区段请求失败后，或一旦新的实时流式传输会话开始时，可触发这样的算法。如在一下所详细说明的，通过使用常规的区段请求来搜索区段可用性窗口的边沿，客户端设备可实现这样的操作。

在HTTP流式传输中，经常性使用的操作包括HEAD、GET和部分GET。HEAD操作检索文件的与给定的统一资源定位符(URL)或统一资源名(URN)相关的报头，而不检索与该URL或URN相关的有效载荷。GET操作检索与给定URL或URN相关的整个文件。部分GET操作接收作为输入参数的字节范围，并检索文件的编号连续的字节，其中该字节编号对应于所接收的字节范围。因此，可为HTTP流式传输提供电影片段，因为部分GET操作可得到一个或多个独立的电影片段。在电影片段中，可能存在不同轨道的多个轨道片段。在HTTP流式传输中，媒体呈现可以是可被客户端访问的结构化的数据集合。客户端可请求并下载媒体数据信息以向用户呈现流式传输服务。

在使用HTTP流式传输来流式传输3GPP数据的例子中，可存在用于多媒体内容的视频和/或音频数据的多个表征体。如下所说明，不同的表征体可对应于不同的编码特性(例如，视频编码标准的不同规范(profile)或级别)、不同编码标准或编码标准的扩展(诸如多重检视和/或可分级扩展)、或不同比特率。可在媒体呈现描述(MPD)数据结构中规定这样的表征体的清单(manifest)。媒体呈现可对应结构化的数据集合，该数据集合可被HTTP流式传输客户端设备访问。HTTP流式传输客户端设备可请求并下载媒体数据信息以将流式传输服务呈现给客户端设备的用户。可在MPD数据结构中描述媒体呈现，其可包括MPD的更新。

媒体呈现可以包含一个或多个周期的序列。可通过MPD中的Period元素规定周期。在MPD中每个周期可以具有属性start。对于每个周期，MPD可包括start属性和availableStartTime属性。对于实时服务，该周期的start属性与MPD属性availableStartTime之和可规定UTC格式中的该周期的可用时间，特别是对应周期中的每个表征体的第一媒体区段。对于点播服务，第一周期的start属性可以为0。对于任何其他周期，start属性可规定对应周期的开始时间相对于第一周期的开始时间的时间偏移。每个周期可延伸直至下一周期的开始，或直至最后的周期情况中的媒体呈现的结束。周期开始时间可以是精确的。周期开始时间可反应播放所有在前周期的媒体所得来的实际时序。

每个周期可包括对同一媒体内容的一个或多个表征体。表征体可以是多个备选的已编码的视频或音频数据版本中的一个。对于视频数据，表征体可通过编码类型(例如，通过比特率、分辨率和/或编解码器)来区分，对于音频数据，表征体可通过比特率、语言和/或编解码器来区分。术语表征体可用于指代已编码音频或视频数据的对应于多媒体内容的特定周期并以特定方式编码的部分。

特定周期的表征体可被分配至由MPD中的属性所指示的组，该属性表示该表征体所属的自适应集。在同一自适应集中的表征体一般被认为是彼此可替换的，以使客户端设备可动态且无缝地在这些表征体之间切换，例如，以进行带宽自适应。例如，特定周期的视频数据的每个表征体可被分配至相同的自适应集，以使得可以选择这些表征体中的任意表征体进行解码，来呈现相应周期的多媒体内容的媒体数据(例如视频数据或音频数据)。在某些实施例中，一个周期内的媒体内容可以由来自0组(如果存在)的一个表征体进行表征，或由来自各个非零组的至多一个表征体的组合进行表征。可以相对于周期的开始时间来表达该周期中的每个表征体的定时数据。

表征体可包括一个或多个区段。每个表征体可包括初始化区段，或表征体的每个区段可以自初始化。当存在初始化区段时，该初始化区段可包括用于访问该表征体的初始化信息。通常，初始化区段并不包括媒体数据。可通过诸如统一资源定位符(URL)、统一资源名(URN)或统一资源标识符(URI)这样的标识符唯一地引用一个区段。MPD可为每个区段提供标识符。在某些例子中，MPD还可以以range属性的形式提供字节范围，该范围可与文件内的可通过所述URL、URN或URI访问的区段相对应。

每个表征体还可包括一个或多个媒体分量，其中每个媒体分量可对应于一个独立媒体类型(例如，音频、视频或同步文本(例如，用于内嵌字幕))的已编码版本。在一个表征体内的连贯媒体区段的边界之间媒体分量可以是时间连续的。

总体来说，DASH客户端设备可以从DASH服务器设备访问和下载MPD。即，DASH客户端设备可以检索MPD以用于初始化实时会话。基于该MPD，对于每个所选的表征体，DASH客户端设备可做出多个决定，包括确定在服务器设备上可用的最新区段是什么、确定下一区段和可能的未来区段的区段可用性开始时间、确定何时并且从区段的那个时间线开始该区段的播放、以及确定何时得到/取得新的MPD。一旦服务被播放，客户端设备可保持追踪实时服务与其自身播放之间的需要被检测和补偿的偏移。

HTTP实时流式传输(HLS)尝试解决以下问题。对于已变得可用的每个区段，服务器设备公布一个新的MPD。客户端设备在加入该服务后，检索该最新的MPD，分析播放列表，并在之后可访问该最新的区段。然后，客户端设备开始播放该区段，并被配置为当从开始播放该区段起，该客户端设备最好能够及时地连续访问下一区段。在取得新的区段(或请求取得一个区段)之前，客户端设备取得提供能够得到最新区段的位置的新的MPD。

SmoothStreaming尝试解决以下问题。对于变为可用的每个区段，服务器设备公布新的MPD。客户端在加入该服务后，检索最新的MPD，通过得到最新S元素的SegmentTimeLine的“r”属性来分析可用的最新区段。这提供了指示从何处得到最新区段的信息。然后，客户端设备开始播放该区段，并被配置为当从开始播放该区段起，只要下一请求不在由上一个请求的时间与区段持续时间相加所得到的时间之前，该客户端设备最好能够及时地访问下一区段。因此，客户端基于最新的SegmentTimeLine.S元素继续构造区段，而不用取得新的MPD，直到客户端得到指示当前MPD不再可用的带内信号。在该时间点(即，响应于当前MPD不再可用的信号)，客户端设备请求新的MPD。

MPEG-DASH使用记录在MPD中的挂钟时间，该挂钟时间设置实时媒体呈现。MPEG-DASH设定的是MPD被生成为使得MPD生成处理必须已访问准确的时钟。这使得通过任何方式与挂钟时间同步的客户端设备能够以与实时边沿(也被称为上升沿)更加接近的方式工作。具体地，当使用基于编号模板的表征体并使用duration属性时，以下信息是可用的：

·MPDavailabilityStartTime:开始时间是挂钟时间的用于MPD的锚点。该值被标示为AST。

·MPDminimumUpdatePeriod:MPD的最小更新周期。该值被标示为MUP。

·MPDsuggestedPresentationDelay:所建议的作为相对于区段可用性开始时间的增量的呈现延迟。该值被标示为SPD。

·MPDminBufferTime:最小缓冲时间，与每个表征体的bandwidth属性结合使用。该值被标示为MBT。

·MPDtimeShiftBufferDepth:媒体呈现的时移缓冲深度。该值被标示为TSB。.

·Periodstart:相对于MPD可用性开始时间的周期开始时间。该值被标示为PS。

·SegmentTemplatestartNumber:周期中的第一区段的编号。改值被标示为SSN。

·SegmentTemplateduration：以时间为单位的区段持续时间。该值除以timescale的值被标示为d。

设定客户端设备确实在取得时间FT已取得MPD。

现设定在客户端的挂钟时间被标示为WT，那么客户端设备可导出以下信息：

·在服务器上可用的最新区段的地址，其需要被标示为LSN的最新区段编号。

·具有编号LSN+1的下一区段以及任意其他区段SN的区段可用性开始时间(被标示为SAST(SN))。注意SN以1开始。

·区段内的与实时边沿同步得最接近的媒体呈现时间，MPTL。

·区段内与其他客户端同步的媒体呈现时间，MPTS。

·基于当前呈现时间的、取得新的MPD的时间。

MPEG-DASH技术的例子说明如下。在该例子中，使得MPD包括以下信息：

进一步设定客户端设备取得MPD并且挂钟时间是NTP＝“2011-12-25T12:30:27”。在该例子中，该值被标示为FT。

然后，客户端设备导出最新区段号。即，客户端设备获得最新周期为AST+PS<＝NTP的周期。如果NTP>＝AST+PS+d，那么该周期中的至少一个区段是可用的，该客户端设备导出在该客户端上可用的最新区段号(LSN)为：

LSN＝floor(NTP-(AST+PS)-d)/d)+SSN＝floor(15/2)+22＝29(1)

因此，在该实施例中，所得的URL被导出为：

http://www.example.com/audio/fr/29.mp4

然后，客户端设备导出具有编号SN的区段的区段可用性开始时间(SAST)为：

SAST(SN)＝AST+PST+(SN-SSN+1)*d (2)

这意味着在该实施例中，对于SN＝30，

SAST(SN＝30)＝2011-12-25T12:30:28

然后，客户端设备基于MPD中的可用信息调度该播放。客户端设备将针对每个表征体的周期中的媒体呈现时间确定为媒体区段中的呈现时间值减去每个表征体的presentationTimeOffset的值(如果存在)。具有区段编号SN的每个区段包括最早呈现时间，通过EPT(SN)标示。

通过在MPEG-DASH中提供MPD，保证了：

1.在该周期中的每个区段在其最早呈现时间之前是可用的，即，对于所有SN，EPT(SN)>＝SAST(SN)-(AST+PST)。

2.如果从SAST(SN)处开始通过比特率等于bandwidth属性的值的恒定比特率信道来递送具有区段编号SN的每个区段，那么最晚在时间PT+(AST+PST)+MBT，每个呈现时间PT在客户端可用。

3.当与其他客户端同步工作时，推荐的对于呈现时间的播放时间MPTS(PT)是MPTS(PT)＝(AST+PST)+PT+SPD。

4.该周期中的每个区段至少可用至SAST(SN)+TSB+d。

使用该信息，客户端设备可以以考虑MPD中的信息以及下载速度的方式开始调度播放。如果属性suggestedPresentationDelay存在，则合适的播放时间是POT(PT)＝MPTS(PT)。如果suggestedPresentationDelay不存在，则合适的播放时间考虑以上的第1、2和4条约束条件，即服务器处的区段可用性时间以及媒体流的比特率变化。

当MPD有效时，客户端设备使用MPD来构造区段。具体地，客户端设备使用MPD构造区段直到媒体时间FT+MUP。即，可构造的最大区段编号(GSN)为：

GSN＝ceil(FT+MUP-(AST+PS)-d)/d)+SSN＝ceil(45/2)+22＝45 (3)

应该理解的是，最新区段可比其他区段短。根据MPEG-DASH，在以上的例子中，在取得区段编号超过45的任何数据之前，客户端设备需要取得新的MPD。

更概括地说，为了利用DASH中的不同的定时和定址方案来使用相同概念，根据ISO/IEC 23009-1引入以下值：

·周期中区段的位置，标示为k，k＝1,2,...

·在位置k的区段的MPD开始时间，称为MST(k)

·在位置k的区段的MPD持续时间，称为MD(k)

现设定在客户端设备处的挂钟时间被标示为WT，客户端设备可导出以下信息：

1.服务器上的最新可用周期，由其周期开始时间PST*标示

2.周期内的位置k处的任意区段的区段可用性开始时间，标示为SAST(k)。

3.在周期内在服务器上可用的最新区段的位置，称为k*

4.在服务器上可用的最新区段的地址

5.基于当前呈现时间取得新MPD的时间，或更具体地，在本周期内可通本MPD构造的最大区段位置k'

6.在该表征体内的与实时边沿同步得最接近的媒体呈现时间，MPTL

7.在该表征体内的与其他客户端同步的媒体呈现时间，MPTS

使用这些时间，客户端可从以上导出以下值：

1.最新周期被获得为PST<＝NTP的周期。

2.区段可用性开始时间被获得为

SAST(k)＝AST+PST+MST(k)+MD(k) (4)

3.在本周期内，客户端设备上可用的最新区段是在得到SAST(k*)最大值并同时小于NTP的位置k*的区段。

4.通过使用位置信息k*获得最新区段的地址，之后可导出该区段地址。该区段地址取决于定址方法。

5.在本周期内，可通过该MPD构造的最大的区段位置k'是得到SAST(k')的最大值并同时小于FT+MUP的区段位置。

客户端设备可使用该数据导出MPD时间。例如，如果duration属性存在并且该值除以timescale的值被标示为d，那么客户端设备使用传统的DASH技术导出MPD时间为：

·MD(k)＝d

·MST(k)＝(k-1)*d

如果区段基信息包含具有N_S个S元素的SegmentTimeline元素，其中该N_S个S元素利用s＝1,...,N_S索引，那么(在根据ISO/IEC 23009-1的DASH中)：

·t[s]是第s个S元素的t的值除以timescale属性的值，

·d[s]是第s个S元素的d的值除以timescale属性的值，

·r[s]是第s个元素的r的值(除非r值是-1——这意味着该值是未知的并且可使用d直到更新的信息可用)。

因此，该客户端设备可以导出该MPD持续时间和开始时间如下：

·k＝0

·for s＝1,...N_S

οk＝k+1

οMST(k)＝t[s]

οMD(k)＝d[s]

οfor j＝1,...,r[s]

■k＝k+1

■MST(k)＝MST(k-1)+d[s]

■MD(k)＝d[s]

在根据ISO/IEC 23009-1的DASH中，定址方法是独立于时间线生成的使用的。startNumber的解译取决于定址方法。如果表征体包含或继承为媒体区段提供显式URL集合的一个或多个SegmentList元素，那么客户端设备使用startNumber确定区段列表中第一区段的位置。区段列表随后提供显式URL。如果表征体包含或继承具有$Number$的SegmentTemplate元素，那么通过在SegmentTemplatemedia字符串中用(k-1)+startNumber替换$Number$标识符来获得在位置k的媒体区段的URL。如果表征体包含或继承具有$Time$的SegmentTemplate元素，那么客户端设备通过在SegmentTemplatemedia字符串中用MST(k)(利用timescale属性的值去归一化)替换$Time$标识符来获得在位置k的媒体区段的URL。

此外，在根据ISO/IEC 23009-1的DASH中，客户端设备基于MPD中的可用信息调度播放。客户端设备将针对每个表征体的周期中的媒体呈现时间确定为媒体区段中的呈现时间值减去每个表征体的presentationTimeOffset的值(如果存在的话)。每个在位置k的区段被分配一最早媒体呈现时间EPT(k)。

通过提供MPD，根据ISO/IEC 23009-1的DASH保证了：

1.本周期中的每个区段在其最早呈现时间及其持续时间之前是可用的，即对于所有k，

SAST(k)<＝EPT(k)+(AST+PST)+MD(k) (5)

2.如果在SAST(k)处开始通过比特率等于bandwidth属性的值的恒定比特率信道来递送具有区段编号k的每个区段，那么最晚在时间PT+(AST+PST)+MBT+MD(k)，每个呈现时间PT在客户端可用。

3.当与其他客户端同步工作时，对于呈现时间推荐的播放时间MPTS(PT)是MPTS(PT)＝(AST+PST)+PT+SPD。

4.该周期中的每个区段至少可用至SAST(k)+TSB+MD(k)。

使用该信息，客户端设备可以以考虑MPD中的信息以及下载速率的方式开始调度播放。如果属性suggestedPresentationDelay存在，则合适的播放时间是POT(PT)＝MPTS(PT)。如果属性suggestedPresentationDelay不存在，则合适的播放时间考虑以上的第1、2和4约束条件，即，服务器处的区段可用性时间以及媒体流的比特率变化。

在根据ISO/IEC 23009-1的DASH中，客户端设备可使用MPD来构造和请求区段，直至媒体时间FT+MUP，并且能够通过该MPD构造的最大区段位置k'是得到SAST(k')的最大值并同时小于FT+MUP的位置。最新区段可以比其他区段短。

如果使用了具有duration的或SegmentTimeline.Sr＝"-1"的模板构造，相比于HLS和SmoothStreaming方法，根据ISO/IEC 23009-1的DASH方法可提供多个优点，诸如：

1.MPD不一定必须在服务器设备上更新，只要区段构造可以继续。只要客户端设备记录MPD的取得时间，则客户端设备可以提前下载用于多个不同的服务的MPD(或将其保存在缓冲器中)。

2.而且，在多播环境中，可仅分配MPD一次，或至少以比每秒一次小得多的频率分配MPD。

3.客户端设备具有确切指示下一区段在服务器设备上可用/或被发布的时间的信息。这使得能够更接近实时边沿进行工作，因为一旦区段变得可用，该客户端设备就请求该区段。

4.客户端设备可精确控制客户端设备下载的第一区段的播放位置。客户端设备甚至可以在区段的中间开始播放，以使得操作更接近实时边沿。

5.客户端设备可以将其播放与其他客户端设备同步。

6.服务器设备操作简单，即，无需专用服务器设备。

虽然当前的说明略去了时间同步问题，但DASH实时流式传输还是设定客户端与服务器时域同步并认为其可由诸如网络时间协议(NTP)这样的协议所解决。然而，在实验室测试中，观察到的是即使当客户端和服务器被初始同步，但它们的时钟可相差几十个毫秒到几秒。这是由于两个原因。第一个原因是NTP并非是被设计为实现毫秒级精度的协议。第二个原因是客户端与服务器上的时钟可能在初始同步后即彼此偏移。探索性实验中，在NTP同步后的24小时持续时间中观察到高达20秒的客户端与服务器的时间增量。

客户端-服务器时间增量的一个潜在弊端是客户端对媒体区段的区段可用性时间窗口的判定(view)可能从服务器的判定偏斜。在客户端的判定明显偏斜的情况下，客户端可能在媒体区段变得可用之前即发出媒体区段请求，或在媒体区段落出可用性时间窗口之外之后才发出媒体区段请求。在这两种情况中，服务器均将以HTTP 404错误码予以响应，客户端无法成功地检索到区段。这样的错误可能导致播放的启动失败或中断。在DASH实时流式传输系统中还存在第三设备——编码系统，该编码系统生成已编码视频区段，将其存储在网络服务器上，并在以后将其移除。即使在客户端与网络服务器之间进行频繁地再同步，在客户端与编码系统之间还是可能发生时钟偏移，当取区段时，这可能导致HTTP 404错误。

本公开描述了基于客户端的方法，该方法估计客户端设备的时钟与服务器设备的时钟和/或编码系统的时钟之间的时间增量。客户端设备可使用所估计的时间增量来调整发出随后的媒体区段请求的时间。因此，实施本公开所描述的技术可得到更具鲁棒性的播放体验。

在一个例子中，客户端设备可被配置为基于时间增量估计算法来估计客户端设备的内部时钟与服务器的内部时钟之间的时间差(也被称为偏移或时间增量)。该时间增量还可(额外或可选地)表征客户端设备的时钟与特定区段变得可用的时间(因此，不一定是相对于服务器设备的时钟所指示的时间)之间的差。在本文中，特定区段(或其他数据单元)变得可用的时间可被称为可用性时间。本公开的相同的时间增量估计算法可应用于任一种情况或同时应用于两种情况。

可在以下设定下使用本公开的时间增量估计算法。第一个设定是客户端与服务器(或区段可用性时间)之间的时间增量被约束在B秒之内。在某些情况中，如果实际时间增量大于设定值B，则该算法可能无法估计时间增量。第二个设定是网络服务器设备支持管线(pipelined)请求。否则，估计过程可能需要修改以获得所设计的精度。第三个设定是客户端与服务器之间的可用带宽超过最小的阈值，例如，50kbps，这大约为拨号连接的速度。非常低的网络速度可能增加估计的不准确性。第四个设定是网络服务器设备能够瞬时(例如，若干分之几秒内)处理来自客户端设备的高达几十个HTTP HEAD请求。

此外，为了实施本公开的技术，客户端可被配置为能够以高达一个区段持续时间的粒度(例如，一秒)来估计客户端设备与服务器设备之间的时间增量。还应在五秒或十个往返时间(RTT)这两者中较大的一个之内生成估计。如果在实际的时间增量超过设计的时间增量限制时，时间增量估计算法能够以降低精度或延长估计时间为代价自动调整内部参数以能够获得该估计，则将是极具优势的。

客户端设备还可被配置为在一开始实现与服务器设备的大致同步。可经由多个时间同步协议之一(例如，网络时间协议(NTP))完成该操作。然而，对客户端设备如何确切实现与服务器设备的初始时间同步并没有限制。本公开引入的时间增量估计的粒度可由区段持续时间和由网络服务器设备导致的所有探测请求的处理延迟来约束。换言之，粒度无需比一个区段持续时间或合计的处理延迟这两者中较大的那个更精细。总体来说，处理延迟被设定为与一个区段时间相比极小或是可忽略的。

图1是示出实施用于在网络上流式传输媒体数据的技术的示例系统10的框图。在该例子中，系统10包括内容准备设备20、服务器设备60、以及客户端设备40。客户端设备40和服务器设备60通过网络74通信耦接网络74可包括互联网。在一些例子中，内容准备设备20和服务器设备60也可通过网络74或其他网络耦接，或可直接通信耦接。在一些例子中，内容准备设备20和服务器设备60可包括同一设备。

在图1的例子中，内容准备设备20包括音频源22和视频源24。音频源22可例如包括麦克风，其产生表征所捕获的将被音频编码器26编码的音频数据的电信号。可选地，音频源22可包括用于存储预先记录的音频数据的存储介质、诸如计算机式合成器之类的音频数据发生器、或其他任何音频数据源。视频源24可包括产生将由视频编码器28编码的视频数据的摄像机、以预先记录的视频数据编码的存储介质、诸如计算机图形源之类的视频数据生成单元、或任意其他视频数据源。内容准备设备20不一定在所有例子中都与服务器设备60通信耦接，而是可将多媒体内容存储至由服务器设备60读取的分立的介质上。

原始的音频和视频数据可包括模拟或数字数据。可在被音频编码器26和/或视频编码器28编码之前将模拟数据数字化。音频源22可在讲话参与者讲话的同时从讲话参与者获得音频数据，而视频源24可同时获得讲话参与者的视频数据。在其他例子中，音频源22可包括包含所存储的音频数据的计算机可读存储介质，视频源可包括包含所存储的视频数据的计算机可读介质。以这种方式，在本公开中描述的技术可应用于实时的流式传输的实时音频和视频数据或已存档的预记录的音频和视频数据。

对应于视频帧的音频帧一般是包含音频数据的音频帧，由音频源22捕获(或生成)该音频数据，与此同时，视频源24捕获(或生成)视频数据，该视频数据包含在视频帧中。例如，在讲话参与者通过讲话产生音频数据时，音频源22捕获音频数据，与此同时，即在音频源22正在捕获音频数据的同时，视频源24捕获该讲话参与者的视频数据。因此，音频帧可在时间上对应于一个或多个特定的视频帧。相应地，对应于视频帧的音频帧通常对应于同时捕获音频数据和视频数据的情况，对于这种情况，音频帧和视频帧分别包括同时捕获的音频数据和视频数据。

在某些实施例中，音频编码器26可对每个已编码音频帧中的时间戳进行编码，该时间戳表征记录已编码音频帧的音频数据的时间，类似地，视频编码器28可对每个已编码视频帧中的时间戳进行编码，该时间戳表征记录已编码视频帧的视频数据的时间。在这样的例子中，对应于视频帧的音频帧可包括包含时间戳的音频帧，视频帧包含相同的时间戳。内容准备设备20可包括内部时钟，根据该内部时钟，音频编码器26和/或视频编码器28可生成时间戳，或者音频源22和视频源24可使用该内部时钟将音频和视频数据分别与时间戳相关联。

在一些例子中，音频源22可对应于音频数据被记录的时间将数据发送至音频编码器26，视频源24可对应于视频数据被记录的时间将数据发送至视频编码器28。在一些例子中，音频编码器26可在已编码音频数据中编码序列标识符，以指示已编码音频数据的相对时间次序，但不一定指示音频数据被记录的绝对时间，类似地，视频编码器28可使用序列标识符指示已编码视频数据的相对时间次序。类似地，在一些例子中，序列标识符可被映射至时间戳或可与时间戳互相关。

音频编码器26通常产生已编码音频数据流，而视频编码器28产生已编码视频数据流。每个独立数据流(无论音频或是视频)可被称为基本流。基本流是表征体的单个的数字编码(可能被压缩的)分量。例如，表征体的编码视频或音频部分可以是基本流。基本流可在被封装到视频文件之前转换为分组化基本流(PES)。在同一表征体内，流ID可用于将属于一个基本流的PES数据包与其他PES数据包区别开。基本流的数据的基本单元是分组化基本流(PES)数据包。因此，编码视频数据通常对应于基本视频流。相似地，音频数据对应一个或多个相应的基本流。

诸如ITU-T H.264/AVC和即将到来的高效视频编码(HEVC)标准之类的多个视频编码标准规定了无差错比特流的语法、语义和解码过程，这几项中的任意项符合特定的规范或级别。视频编码标准一般并不指定编码器，但编码器的任务是保证所生成的比特流是符合解码器的标准的。在视频编码标准的背景下，“规范”对应于算法、特征或工具的子集及其所被施加的限制条件。如由H.264标准所规定的，例如，“规范”是由H.264标准所规定的整个比特流语法的子集。“级别”对应于解码器的资源消耗的限制，诸如，例如，解码器内存和计算，其与图像的分辨率、比特率、和块处理率相关。可以利用profile_idc(规范指示符)值来以信号通知规范，而可利用level_idc(级别指示符)值来以信号通知级别。

例如，H.264标准指出，在由给定的规范的语法所设置的范围内，仍可以根据比特流中的语法元素所采用的值(例如已解码图像的指定尺寸)，要求编码器和解码器的性能发生极大的变化。H.264标准进一步指出，在多个应用中，实施能够应付特定规范中的语法的所有假设使用的解码器是既不实际也不经济的。因此，H.264标准将“级别”规定为对比特流中的语法元素值设置的限制条件的指特定集合。这些限制条件可以是对这些值的简单限制。可选地，这些限制条件可采用对值的算术组合(例如，图像宽度乘以图像高度乘以每秒解码的图像数量)的限制条件的形式。H.264标准进一步规定，单独的实现方式可支持每个被支持规范的不同级别。

符合一种规范的解码器一般支持该规范中所规定的所有特征。例如，作为编码特征，在H.264/AVC的基线规范中并不支持B级图像编码，但在H.264/AVC的其他规范中支持该B级图像编码。符合一种级别的解码器应能够解码并未要求超出该级别所规定的限制条件的资源的任何比特流。规定规范和级别可有助于可解译性。例如，在视频传输期间，可在整个传输会话内协商和约定一对规范和级别规定。更具体地，在H.264/AVC中，级别可规定对需要处理的宏块的数量的限制、已解码图像缓冲器(DPB)大小、已编码图像缓冲器(CPB)大小、垂直运动矢量范围、每两个连续MB的运动矢量的最大数量、以及B块是否可具有少于8x8像素的子宏块分割。以这种方式，解码器可确定该解码器是否能够适当地解码比特流。

在图1的例子中，内容准备设备20的封装单元30从视频编码器28接收包括经编码视频数据的基本流，并从音频编码器26接收包括编码音频数据的基本流。在一些例子中，视频编码器28和音频编码器26可各自包括用于从已编码数据形成PES数据包的打包器。在其他例子中，视频编码器28和音频编码器26可各自与相应的用于从已编码数据形成PES数据包的打包器接口。在另外的例子中，封装单元30可包括用于从已编码音频和视频数据形成PES数据包的打包器。

视频编码器28可以以多种方式对多媒体内容的视频数据进行编码，以多种比特率和不同特性产生多媒体内容的不同的表征体，这些特性诸如像素分辨率、帧速率、对多种编码标准的一致性、对多种编码标准的多种规范和/或规范的级别的一致性、具有一个或多个视图的表征体(例如，用于二维或三维回放)，或其他这样的特性。如本公开中所用，表征体可包括音频数据和视频数据的组合，例如，一个或多个音频基本流和一个或多个视频基本流。每个PES数据包可包括标识PES数据包所属的基本流的stream_id。封装单元30负责将基本流组装为各种表征体的视频文件。

封装单元30从音频编码器26和视频编码器28接收表征体的基本流的PES数据包，并从PES数据包形成对应的网络抽象层(NAL)单元。在H.264/AVC(增强型视频编码)的例子中，已编码视频区段被组织成NAL单元，其提供了“网络友好”的视频表征定址应用，诸如视频电话、存储、广播或流媒体。NAL单元可以被分类为视频编码层(VCL)NAL单元和非VCL-NAL单元。VCL单元可包括核心压缩引擎并包括块、宏块和/或切片级数据。其他NAL单元可以是非VCL-NAL单元。在一些例子中，一个时间点中的编码图像(一般被表示为主编码图片)可被包含在可包括一个或多个NAL单元的访问单元中。

除了其他的之外，非VCL NAL单元可包括参数集NAL单元和SEINAL单元。参数集可包含序列级报头信息(在序列参数集(SPS)中)以及不经常改变的图像级报头信息(在图像参数集(PPS)中)。利用参数集(例如，PPS和SPS)，不需要对每个序列或图像重复不经常改变的信息，从而可提高编码效率。此外，参数集的使用能够实现重要报头信息的带外传输，避免对针对容错性的冗余传输的需要。在带外传输的例子中，可在与其他NAL单元(例如SEI NAL单元)不同的信道上传输参数集NAL单元。

补充增强信息(SEI)可包含对从VCL NAL单元解码已编码图像样本来说并非必需的、但可以协助与解码、显示、容错等其他目的相关的过程的信息。SEI消息可包含在非VCL NAL单元中。SEI消息是某些标准说明书的标准性部分，并因此并不对标准兼容的解码器实现方式总是强制的。SEI消息可以是序列级SEI消息或图像级SEI消息。某些序列级信息可包含在SEI消息中，例如SVC例子中的扩展性信息SEI消息和MVC中的视图扩展性信息SEI消息。这些示例SEI消息可传递关于例如操作点的提取和操作点的特性这样的信息。此外，封装单元30可形成清单文件，例如描述表征体特性的媒体呈现描述符(MPD)。封装单元30可根据可扩展标示语言(XML)来格式化MPD。

封装单元30可向输出接口32提供媒体内容的一个或多个表征的数据，以及清单文件(例如，MPD)。输出接口32可包括网络接口或用于写入存储介质的接口，例如通用串行总线(USB)接口、CD或DVD写入器或烧录机、到磁存储或闪存介质的接口、或其他用于存储或传输媒体数据的接口。封装单元30可向输出接口32提供多媒体内容的每个表征体的数据，输出接口32可经由网络传输或存储介质将该数据发送至服务器设备60。在图1的例子中，服务器设备60包括存储各种多媒体内容64的存储介质62，多媒体内容64各自包括相应的清单文件66和一个或多个表征体68A至68N(表征体68)。在一些例子中，输出接口32还可直接发送数据至网络74.

在一些例子中，表征体68可被分成自适应集。即，表征体68的各个子集可包括相应的特性公共集合，该特性例如编码解码器、规范和级别、分辨率、视图数量、区段的文件格式、可标识与待解码和呈现(例如，通过扬声器)的表征体和/或音频数据一同显示的待显示文本的语言或其他特性的文本类型信息、可描述自适应集中的表征体的场景中的摄像机角度或真实的摄像机视点的摄像机角度信息、描述对特定观众的内容适宜度的评级信息等。

清单文件66可包括指示与特定自适应集相对应的表征体68的子集以及该自适应集的公共特性的数据。清单文件66还可包括表征自适应集的各个表征体的单独特性(例如比特率)的数据。以这种方式，自适应集可提供简化的网络带宽自适应。可使用清单文件66的自适应集元素的子元素来指示自适应子组中的表征体。

服务器设备60包括请求处理单元70和网络接口72。在一些例子中，服务器设备60可包括多个网络接口。此外，服务器设备60的任意或所有特征可被实施在内容递送网络的其他设备上，例如，路由器、网桥、代理设备、交换机或其他设备。在一些例子中，内容递送网络的中间设备可对多媒体内容64的数据进行缓存，并包括基本上与服务器设备60的部件相符合的部件。通常来说，网络接口72被配置为经由网络74发送和接收数据。

请求处理单元70被配置为从客户端设备(诸如客户端设备40)接收对存储介质62的数据的网络请求。例如，请求处理单元70可实施超文本传输协议(HTTP)版本1.1，正如在RFC 2616,“Hypertext Transfer Protocol–HTTP/1.1,”中(由IETF的网络工作组中的R.Fielding等人于1999年6月)描述的。即，请求处理单元70可被配置为接收HTTP GET或部分GET请求，并响应于该请求提供多媒体内容64的数据。该请求可例如使用表征体68中的一个表征体的区段的URL来指定该区段。在一些例子中，请求还可指定该区段的一个或多个字节范围，因此包括部分GET请求。请求处理单元70可被进一步配置为服务HTTP HEAD请求以提供表征体68之一的区段的报头数据。在任何情况中，请求处理单元70可被配置为处理该请求以向请求设备(例如客户端设备40)提供所请求的数据。

此外或可替代地，请求处理单元70可被配置为经有关广播或多播协议(诸如eMBMS)来递送媒体数据。内容准备设备20可以基本以与以上所述相同的方式创建DASH区段和/或子区段，但服务器设备60可使用eMBMS或另一个广播或多播网络传输协议来递送这些区段或子区段。例如，请求处理单元70可被配置为从客户端设备40接收多播组加入请求。即，服务器设备60可向与特定媒体内容(例如，实时事件的广播)相关的客户端设备(包括客户端设备40)通告与多播组相关联的互联网协议(IP)地址。转而，客户端设备40可提交加入多播组的请求。该请求可在整个网络74(例如，组成网络74的路由器)中传播，以使路由器将目的地为与该多播组相关的IP地址的业务指向订阅客户端设备，诸如客户端设备40。

如图1中的例子所示，多媒体内容64包括清单文件66，该清单文件可对应于媒体呈现描述(MPD)。清单文件66可包含对不同可选表征体68(例如，具有不同质量的视频服务)的描述，并且该描述可包括，例如，表征体68的编码解码器信息、规范值、级别值、比特率和其他描述性特性。客户端40可检索媒体呈现的MPD以确定如何访问表征体68的区段。

具体地，检索单元52可检索客户端设备40的配置数据(未示出)以确定视频解码器48的解码能力和视频输出44的表现能力。配置数据还可包括由客户端设备40的用户所选的任意或所有的语言偏好、对应于由客户端设备40的用户设定的深度偏好的一个或多个摄像机视点、和/或由客户端设备40的用户选择的评级偏好。检索单元52可包括，例如，被配置为提交HTTP GET和部分GET请求的网页浏览器或媒体客户端。检索单元52可对应于由客户端设备40的一个或多个处理器或处理单元(未示出)执行的软件指令。在一些例子中，相对于检索单元52描述的所有或部分功能可以以硬件或硬件、软件和/或固件的组合的形式实施，其中可提供必需的硬件以执行软件或固件的指令。

检索单元52可对比客户端设备40的解码或表现能力与由清单文件66的信息所指示的表征体68的特性。检索单元52可初始地检索至少部分清单文件66以确定表征体68的特性。例如，检索单元52可请求根据本公开的技术描述一个或多个自适应集的特性的一部分清单文件66。检索单元52可选择具有可由客户端设备40的编码和表现能力满足的特性的表征体68的子集(例如，自适应集)。然后，检索单元52可确定该自适应集中的表征体的比特率，确定网络带宽的当前可用量，并且检索来自表征体中具有可由网络带宽满足的比特率的一个表征的区段。

通常来说，比特率更高的表征体可产生更高质量的视频回放，而比特率更低的表征体可在可用网络带宽减少时提供足够质量的视频回放。因此，当可用网络带宽相对高，检索单元52可从比特率相对高的表征体检索数据，而当可用网络带宽低时，检索单元52可从比特率相对低的表征体检索数据。在该方式中，客户端设备40可在适应改变网络74的网络带宽可用性的同时，在网络74上流式传输多媒体数据。

此外或可替代地，检索单元52可被配置为根据广播或多播网络协议(例如eMBMS或IP多播)接收数据。在这样的例子中，检索单元52可提交加入与特定媒体内容相关联的多播网络组的请求。在加入该多播组后，检索单元52可接收该多播组的数据而无需向服务器设备60或内容准备设备20发布进一步的请求。当不再需要多播组的数据(例如，停止回放或改变信道至不同的多播组)时，检索单元52可提交离开多播组的请求。

网络接口54可接收并向检索单元52提供所选的表征体的区段的数据，检索单元52可以转而将区段提供给解封装单元50。解封装单元50可将视频文件的元素解封装为成分PES流、将该PES流拆包以检索已编码数据，并根据已编码数据是音频流还是视频流的一部分(例如，由该数据流的PES分组报头所指示的)，将已编码的数据发送至音频解码器46或视频解码器48。音频解码器46解码已编码音频数据并将已解码音频数据发送至音频输出42，而视频解码器48解码已编码视频数据并将已解码视频数据(可包括数据流的多个视图)发送至视频输出44。

视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、检索单元52和解封装单元50，如可应用地，各自可被实施为各种合适的处理电路中的任意一种，例如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散式逻辑电路、软件、硬件、固件或其任意组合。视频编码器28和视频解码器48中的每一个可被包括在一个或多个编码器或解码器中，这些编码器或解码器可被集成为组合式视频编码器/解码器(CODEC)的一部分。同样地，每个音频编码器26和音频解码器46可被包括在一个或多个编码器或解码器中，这些编码器或解码器可被集成为组合式CODEC的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、检索单元52和/或解封装单元50的装置可包括集成电路、微处理器和/或无线通信设备(例如蜂窝式电话)。

客户端设备40、服务器设备60和/或内容准备设备20可被配置为根据本公开的技术进行工作。出于示例的目的，本公开相对于客户端设备40和服务器设备60来描述这些技术。然而，应理解的是，内容准备设备20可被配置为执行这些技术，来替代服务器设备60。

封装单元30可形成NAL单元，该NAL单元包括标识NAL单元所属的节目的报头、以及有效载荷，例如，音频数据、视频数据或描述NAL单元对应的传输或节目流的数据。例如，在H.264/AVC中，NAL单元包括1字节的报头和大小变化的有效载荷。在其有效载荷中包括视频数据的NAL单元可包括多种粒度级别的视频数据。例如，NAL单元可包括视频数据块、多个块、视频数据切片或视频数据的整个图像。封装单元30可以以基本流的PES数据包的形式从视频编码器28接收已编码数据。封装单元30可将每个基本流与对应节目相关联。

封装单元30还可从多个NAL单元组合访问单元。通常来说，访问单元可包括一个或多个NAL单元以用于表征视频数据帧以及对应于该帧的音频数据(当这样的音频数据可用时)。访问单元通常包括用于一个输出时间点的所有NAL单元，例如，一个时间点的所有音频和视频数据。例如，如果每个视图具有每秒20帧(20fps)的帧速率，那么每个时间点可对应于0.05秒的时间间隔。在该时间间隔期间，可同时表现同一访问单元(同一时间间隔)的所有视图的特定帧。在一个例子中，访问单元在一个时间点中可包括一个已编码图像，该已编码图像可被呈现为主编码图像。因此，访问单元可包括通用时间点的所有音频和视频帧，例如，对应于时间X的所有视图。本公开还将特定视图的已编码图像称为“视图分量”。即，视图分量可包括在特定时间的特定视图的已编码图像(或帧)。因此，访问单元可被规定成包括通用时间点的所有视图分量。访问单元的解码顺序不一定需要与输出或显示顺序相同。

媒体呈现可包括媒体呈现描述(MPD)，该媒体呈现描述可包含不同可选表征体(例如，具有不同质量的视频服务)的描述，该描述可包括例如，解码编码器信息、规范值和级别值。MPD是诸如清单文件66的清单文件的一个例子。客户端设备40可检索媒体呈现的MPD以确定如何访问各个呈现的电影片段。电影片段可位于视频文件的电影片段区(moof区)中。

清单文件66(其可包括例如MPD)可通告表征体68的区段的可用性。即，MPD可包括指示表征体68之一的第一区段变得可用的挂钟时间的信息，以及指示表征体68内的区段的持续时间的信息。以这种方式，客户端设备40的检索单元52可基于开始时间以及在特定区段之前的区段的持续时间来确定每个区段何时可用。检索单元52可初始地将客户端设备40的内部时钟与服务器设备60(或内容准备设备20)的时钟同步，之后，一旦来自一个或多个表征体68的区段变得可用，则请求该区段(例如，由于自适应)。

然而，在某些情况中，客户端设备40的内部时钟可相对于服务器设备60的时钟发生偏移。检索单元52可被配置为使用本公开的技术来同步客户端设备40的时钟以应对这样的偏移。以这种方式，检索单元52可以使用重新同步的客户端设备40的时钟以及清单文件66的数据以确定一个或多个表征体68的特定文件对于检索来说是否可用。

总体来说，本公开的技术涉及发出多个探测请求(例如，对媒体区段的HTTP HEAD请求)以检测区段可用性窗口的任一个或两个“边沿”的客户端设备40。区段可用性窗口可对应于当前对于检索来说可用的区段集合。“最老”的边沿(有时也被称为“左”边沿)可对应于区段可用性窗口的最早区段的开始，而“最新”边沿(有时也被称为“右边沿”)可对应于区段可用性窗口的最新区段的末端。基于这些边沿，客户端设备40的检索单元52可推断客户端设备40的时钟与服务器设备60的时钟之间的时间增量。换言之，检索单元52可基于对服务器设备60提供的探测请求的响应，确定区段可用性窗口的左边沿和右边沿。这些对探测请求的响应可基于对服务器设备60的区段可用性窗口的理解。

一般来说，区段可用性窗口的右边沿可被认为是更有用的，因为右边沿由实时视频生成延迟所限制。估计右边沿可有助于实现成功检索区段与最小化不必要的端对端时延之间良好的折衷。区段可用性窗口的左边沿由可用性开始时间和时移缓冲深度(TSBD)两者所控制。TSBD是MPD(例如，清单文件66)中的可选属性。对于“动态”MPD类型，当MPD中没有TSBD，则TSBD应被解译为无限大。当TSBD是无限大的，只要区段请求时间在区段可用性开始时间之后，区段应是始终可用的。

时间增量估计算法可包括多个部分，诸如启动触发逻辑，当在区段检索期间在启动时间发生多次失败时，该启动触发逻辑可触发反向探测法。反向探测法被设计为检测区段可用性窗口的右边沿。另一方法被称为前向探测法，当反向探测获得不确定的响应时，或当检测到区段可用性窗口的右边沿并且客户端设备40的检索单元52需要随着时间保持对右边沿的追踪时，可使用前向探测法。

与区段可用性窗口相关的一些概念可能有助于更好的理解本公开的技术。在DASH实时流式传输中，当针对给定区段的媒体生成(例如，通过内容准备设备20)完成并且媒体区段被存储在服务器设备60上时，区段变得可用。通过使用来自MPD(图1的实施例中的清单文件66)的信息进行区段时间线计算，客户端设备40的检索单元52可计算区段变得可用的最早时间。这被称为区段可用性开始时间。此外，通过时移缓冲器，检索单元52可确定从可用开始时间开始该区段将可用多长时间。基于流式传输应用的要求，检索单元52可被配置为一旦区段变得可用就检索该区段，或在时间上从最新的可用区段开始反向些许来检索区段。

这两种策略可能各自具有优点和缺点。前者尝试尽可能向观看者呈现最新的实时内容，却同时部分牺牲了视频递送的稳定性，特别是当面临视频生成和递送处理中的时序抖动时。后者通常可实现整体更好的用户体验，但可能是以更高的端对端时延作为代价。使用区段时间线和TSBD，检索单元52可在任何给定的挂钟时间确定哪个区段可用。下面相对于图3来说明区段可用性窗口的例子。

出于多种原因，检索单元52可被配置为确定区段可用性窗口(或至少区段可用性窗口的一个边沿)。例如，检索单元52可被配置为初始地确定区段可用性窗口以开始特定的实时流。此外或可选地，检索单元52可被配置为在从服务器设备60接收到一定数量(或百分比)的错误消息(例如，HTTP 404错误消息)后确定区段可用性窗口。

当客户端设备40的时钟从服务器设备60的时钟(或从所通告的可用性时间)偏离时，可发生这样的错误。即，响应于这样的时钟偏移，客户端设备40将无法精确地确定区段可用性时间线。在一种情况中，客户端设备40的时钟可领先于服务器设备60的时钟。当客户端设备40的时钟领先于服务器设备60的时钟，如果一旦检索单元52(使用客户端设备40的时钟和区段可用性开始时间)确定区段变得可用，检索单元52就尝试检索媒体区段，则响应于媒体区段请求，客户端将接收到HTTP 404非可用错误消息。如果检索单元52使用保守启动策略，检索单元52可从TSBD(即，区段可用性窗口)的左边沿开始请求媒体区段，并因此可以成功地进行区段检索。但即使在这种情况中，时钟增量可导致检索单元52无法建立期望量的媒体缓冲。

区段请求失败触发机制可用于发起区段可用性窗口确定过程。可在视频回放开始并且客户端设备40重复地接收到对于媒体区段请求的404错误消息之后激活区段请求失败触发。客户端40可保持对所发送的连续的媒体区段请求的数量和针对这些请求获得的404错误消息响应的数量的运行计数。如果对于最新的Nr个媒体区段请求，客户端接收到Nf或更多个的404响应码，则触发该探测方法，其中，Nf是定义具有404错误码的响应的数量的可配置参数，Nr是定义所发送的连贯媒体区段请求的数量的可配置参数。在某些实施例中，Nr的值可为5，Nf的值可为2。

额外的控制参数——最小时间间隔(MTI)可用于控制进行探测测试的频度。MTI可描述探测请求集合之间的最小时间间隔。该参数可用于确保探测将不会被执行得太频繁而导致高开销。MTI的一个示例初始值是1分钟。可基于接收到的错误的频度使用其他的MTI的值作为例如初始值或动态调整值。

在检索单元52获得探测结果之后，检索单元52可基于所估计的时钟差来调整检索行为。可执行各种动作，并且这些动作可基于引起原始探测的触发。

在某些实例中，开始回放失败可引起探测。如果一开始由视频数据的开始回放失败引起了探测，或如果客户端设备40已经在探测算法结束之前停止行动，则客户端设备40的DASH客户端(其可对应于检索单元52)可被认为处于闲置状态。在这种情况中，检索单元52可将时间增量施加在客户端设备40的本地时钟上，以确定调整后的服务器时间。使用该调整后的服务器时间，检索单元52可从确定的时间点开始下载。这可涉及检索单元52在最新的可用区段之后在时间上提前几秒钟请求区段(以便建立合理的缓冲)。

作为另一实施例，具有不精确客户时钟的成功的回放可激活探测。当客户端设备40已经回放视频流，客户端设备40可通过使用时间增量估计算法确定在客户端设备40的本地时钟域服务器设备60的时钟之间存在时间增量。在这种情况下，客户端设备40可以以下三种方式之一进行动作。根据以下实施例描述这些客户端动作。设定客户端40尝试通过从最新可用区段提前10秒请求媒体内容以建立10秒的缓冲并得到10秒的时延，来实现媒体缓冲与端对端时延之间的优化的折衷。然而，在第一种情况中，客户端设备40的本地时钟领先服务器设备60的时钟5秒。因此，客户端设备40仅可建立最大5秒的媒体缓冲，并具有最大5秒的时延。在第二种情况中，客户端设备40的本地时钟比服务器设备60的时钟落后5秒。因此，客户端设备40将能够建立15秒的缓冲，代价是具有15秒的时延。

在一个例子中，客户端设备40可通过不采取特定动作来响应成功的回放。响应于检测到时间增量，客户端设备40可决定不执行任何额外的操作，因为客户端设备40的实际媒体缓冲和时延从最优折衷偏差了5秒。在某些实例中，客户端设备40中的不同的媒体缓冲可导致速率选择算法中的不同程度的进取度(aggressiveness)。因此，一旦时间增量(无论客户端设备40的本地时钟是比服务器设备60的时钟领先还是落后)和校正信息被提供至速率切换算法，速率切换算法可自然地调整速率决定进取度的内部参数。

在另一例子中，客户端设备40可对媒体数据回放执行干预式(intrusive)调整。例如，为了实现更优化的10秒媒体缓冲和10秒时延的折衷，客户端设备40可以以临时降低观看体验为代价大幅地进行动作。在第一种情况中，当客户端设备40的本地时钟领先，客户端设备40可停止视频回放5秒钟，并建立目标为10秒的缓冲。一旦缓冲水平达到10秒，客户端设备40可恢复回放以使缓冲水平和时延处于目标值。在客户端设备40的本地时钟落后的情况中，客户端设备40可略过5秒钟视频内容，并跳过呈现时间5秒以到达目标呈现时间(t-10)。以这种方式，客户端设备40可实现更低的时延。总的来说，无论是停顿还是略过都得到并不良好的用户体验。但如果出于减少更进一步的停顿或提供接近于实时观看体验的目的，而仅进行一次这样的操作，该大幅度的操作也是合乎情理的。

以这种方式，当客户端设备40的本地时钟域服务器设备60的时钟之间的时间差指示本地时钟领先于服务器设备60的时钟，那么客户端设备40可停止媒体回放一段时间，该一段时间等于该时间差。另一方面，当客户端设备40的本地时钟与服务器设备60的时钟之间的时间差指示本地时钟比服务器设备60的时钟落后，则客户端设备40可略过一段时间的媒体回放，该一段时间等于该时间差。

在又一种实施例中，客户端设备40可进行对媒体数据的回放进行非干预式调整。例如，取代使用诸如引入上述的停止或略过这样的干预式指令，更精细的客户端可使用非干预式操作以实现相同的目标。当客户端设备40的本地时钟在时间上领先时，客户设备40可轻微地减慢回放速率，以使每一秒的已编码媒体将被播放(1+α)秒，其中，α是诸如0.03这样的小型值。通过减慢回放速率，客户端设备40可逐渐地建立更长的媒体缓冲并增加时延。相似地，客户端设备40的本地时钟在时间上比服务器设备60的时钟落后时，客户端设备40可轻微地加快回放的速率。通过这样做，客户端可逐渐消耗媒体缓冲并减少时延。一旦客户端设备40达到目标的媒体缓冲和时延水平，客户端设备40可切换回正常的播放速率来保持缓冲水平和时延。该实施例的有益效果在于观看者甚至将不知道客户端所采取的调整。因此，只要客户端设备40可支持这样的复杂操作，就可提供更好的用户体验。

以这样的方式，当时间差指示客户端设备40的本地时钟领先于服务器设备60的时钟时，客户端设备40可以以稍微高于正常回放速率的速率播放媒体数据，直到时间差为零。在另一方面，当时间差指示客户端设备40的本地时钟比服务器设备60的时钟落后时，客户端设备40可以以稍微低于正常回放速率的速率播放媒体数据，直到时间差为零。

视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、解封装单元50，如可应用地，可以各自被实施为各种合适的处理电路中的任意一种，诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散式逻辑电路、软件、硬件、固件或其任意组合。每个视频编码器28和视频解码器48可被包括入一个或多个编码器或解码器，这些编码器或解码器可被集成为组合式视频编码器/解码器(CODEC)的一部分。同样地，每个音频编码器26和音频解码器46可被包括入一个或多个编码器或解码器，这些编码器或解码器可被集成为组合式CODEC的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、和/或封装单元30和/或解封装单元50的装置可包括集成电路、微处理器和/或无线通信设备(例如蜂窝式电话)。

在封装单元30基于所接收的数据将NAL单元和/或访问单元组合成视频文件之后，封装单元30可将视频文件传递至输出接口32以用于输出。在某些实施例中，封装单元30可本地地存储视频文件或经由输出接口32将视频文件发送至远程服务器，而非将视频文件直接发送给客户端设备40。输出接口32可包括，例如，发射机、收发机、用于将数据写入计算机可读介质的设备，该设备例如光学驱动器、磁介质驱动器(例如，闪存驱动器)、通用串行总线(USB)端口、网络接口、或其他输出接口。输出接口32输出视频文件至计算机可读介质34，例如，传输信号、磁介质、光介质、内存、闪存驱动器或其他计算机可读介质。

网络接口54可经由网络74接收NAL单元或访问单元，并经由检索单元52向解封装单元50提供该NAL单元或访问单元。解封装单元50可将视频文件的元素解封装为成分PES流、将该PES流拆包以检索已编码数据，根据已编码数据是音频流还是视频流的一部分(例如，由该数据流的PES分组报头所指示的)，将已编码的数据发送至音频解码器46或视频解码器48。音频解码器46解码已编码音频数据并将已解码音频数据发送至音频输出42，而视频解码器48解码已编码的视频数据并将已解码视频数据(可包括数据流的多个视图)发送至视频输出44。

以这种方式，客户端设备40表征用于检索媒体数据的设备的例子，该设备包括一个或多个处理器，该处理器被配置为向服务器设备发送对媒体数据的区段的多个探测请求，其中，服务器设备使用实时流式传输服务提供媒体数据，分析对多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿，并根据实时流式传输服务，基于区段可用性窗口的所确定的左边沿和所确定的右边沿，在区段可用性窗口内发送对区段的请求。

图2是示出示例多媒体内容102的元素的概念图。多媒体内容102可对应于多媒体内容64(图1)，或其他存储在存储介质62中的多媒体内容。在图2的例子中，多媒体内容102包括介质呈现描述(MPD)104和多个表征体110至120。表征体110包括可选报头数据112和区段114A至114N(区段114)，而表征体120包括可选报头数据122和区段124A至124N(区段124)。出于方便，字母N用于标出表征体110和120中的每一个中的最后的电影片段。在某些实施例中，表征体110与表征体120之间可能存在不同数量的电影片段。

MPD 104可包括与表征体110至120分离的数据结构。MPD 104可对应于图1的清单文件66。同样，表征体110至120可对应于图1的表征体68。总体而言，MPD 104可包括总体描述表征体110至120的特性的数据，诸如编码和表现特性、自适应集、MPD 104与之对应的规范、文本类型信息、摄像机角度信息、评级信息、特技模式信息(例如，指示包括时域子序列的表征体的信息)和/或用于检索远程周期的信息(例如，用于在回放期间向媒体内容的目标广告插入)。根据本公开的技术，MPD 104可包括UTC时序信息，正如以上相对于图1进行讨论的那样。

当存在报头数据112时，其可描述区段114的特性，例如，随机访问点的时间位置(RAP，也被称为流访问点(SAP))(区段114的该流访问点包括随机访问点)、对区段114内的随机访问点的字节偏移、区段114的统一资源定位符(URL)、或区段114的其他方面。当存在报头数据122时，其可描述用于区段124的类似的参数。此外或可选地，这样的特性可被完全包括在MPD 104内。

区段114和124包括一个或多个已编码视频采样，每个采样可包括视频数据的帧或切片。区段114的每个已编码视频采样可具有相似的特性，例如，高度、宽度和带宽要求。这样的特性可由MPD 104的数据描述，尽管这样的数据并未在图2的实施例中示出。MPD 104可包括由3GPP规格描述的特性，其中附加了部分或所有的本公开描述的以信号通知的信息。

区段114、124中的每一个可与唯一的统一资源定位符(URL)相关联。因此，可使用流式传输网络协议(例如DASH)来独立检索区段114、124中的每一个。以这种方式，诸如客户端40这样的目的地设备可使用HTTP GET请求来检索区段114或124。在一些例子中，客户端设备40可使用HTTP部分GET请求来检索区段114或124的特定字节范围。

如以上所说明，MPD 104可进一步包括通告表征体110、120各自的第一区段何时可用的信息。在该例子中，MPD 104可包括指示区段114A、124A何时首次变得可用的信息。因此，诸如客户端设备40之类的客户端设备可在所指示的时间检索区段114A、124A中的任一个。此外，MPD 104可包括依据回放时间指示区段114、124的持续时间的区段的信息。因此客户端设备40可基于区段114A、124A变得可用的时间(如由MPD 104所指示的)以及区段114A、124A的持续时间(也由MPD 104所指示)来确定区段114B、124B变得可用的时间。区段114、124可具有相同的持续时间(依据回放时间)，在这种情况下，MPD 104可指示单个持续时间值或不同的持续时间，在不同的持续时间情况下，MPD 104可为区段114、124中的每一个指示独立的持续时间值。可选地，设定区段114、124是时域对准的，并且具有不同的持续时间，MPD 104可以信号通知对应的区段的单独的持续时间值(例如，可应用于区段114A、114B的持续时间值、可应用于区段114B、124B的其他持续时间值等等)。

此外，如果多媒体内容102是流式直播，区段114、124中的某些区段可仅在某个时间量之后(特别是，在数据的记录、编码和封装之后)才变得可用。客户端设备40可使用本公开的技术来确定区段可用性窗口，在多种例子中，该区段可用性窗口可包括区段114、124的任意序列。即，可以基于区段何时变得实际可用(如由对区段的请求的响应所指示)，而非严格基于所通告的可用性时间和时钟同步性，来确定区段可用性窗口。将在以下相对于图3至9更详细地说明这些技术。

图3是示出区段集合150的示例性区段可用性窗口152的概念图。在图3中，区段可被表示为三角。在该示例中，使得时移缓冲深度(TSBD)具有W个区段的宽度。此外，基于挂钟时间t，设定客户端设备40已确定最新可用区段对应于图3中被标记为“i”的区段。基于这些设定，图3示出了可用区段，即区段可用性窗口152的快照。具体地，区段可用性窗口包括以在i-W+1(i–(W–1))位置的区段开始的左边沿154，以及以当前区段i结束的右边沿156。在图3中，使用虚线轮廓示出定义左边沿154的区段(即在位置i-W+1的区段)。

换言之，客户端设备40可发送对于媒体区段的探测请求，诸如HTTPHEAD请求。具体地，客户端设备40可基本上同时从最新的可用区段(如根据客户端设备40的时钟所确定)开始在时间上提前发送W个探测请求。由这些探测请求覆盖的时间跨度可以是W*D，其中D是区段的持续时间——设定区段具有相等的持续时间(依据回放时间)。本公开认识到，DASH中绝大多数HTTP 404错误是由客户端设备的时钟比服务器设备的时钟领先所造成的。以这种方式在时间上后向探测可用于找出TSBD窗口的右边沿。

作为一种可选的方式，客户端设备40可仅在时间上前向探测。这与后向探测相似，但可用于解决客户端设备40的时钟比服务器设备60的时钟落后得多于TSBD持续时间的问题。可通过某些模式(例如，如下面的图6和7所示)来发现TSBD的左边沿。作为又一个例子，如图4中所示，可发送前向和后向探测请求两者，这将在以下做更详细的讨论。

图4是示出可为之发送探测请求以确定区段可用性窗口的区段的概念图。如以上所提到的，客户端设备40的检索单元52可被配置为发起基于各种标准确定区段可用性窗口的过程，该各种标准诸如从服务器设备60接收到一定数量的404错误消息或处于流启动阶段。无论如何，检索单元52可根据本公开的技术发送指向多个连贯区段的探测请求序列。在图4的实施例中，检索单元52发送对以区段i为中心的区段的探测请求(例如，HTTP HEAD请求)，根据客户端设备40的时钟，区段i是最新可用区段。在该实施例中，探测请求的序列包括对于从i-N到i+N的区段中的每个区段的独立的请求，其中N是整数值。然而，在其他实施例中，探测请求的序列可包括对从i-M到i+N的区段的独立的请求，M和N可以相等或不等，并且无论是M或是N均可以是0。

换言之，一旦启动该探测方法，客户端设备40可一个接着一个地(管线式)发出对媒体区段的多个探测请求。在一些例子中，探测请求是针对给定媒体区段的HTTP HEAD请求，目的在于检测区段的可用性。在其他例子中，可使用其他类型的请求，例如针对相对少量的数据(例如，100字节)的HTTP部分GET请求。在时间t，客户端设备40的检索单元52可基于客户端设备40的时钟计算最新的可用区段号i。在通过启动触发开关发起探测请求方法的情况中，客户端设备40可预测到对于区段i的请求将会很有可能失败。所以检索单元52可发出(2N+1)个对区段i及其相邻区段(范围从区段(i-N)到区段(i+N))的探测请求。由于这些请求是非常小的HTTP请求，同时在响应消息体内的数据极少或没有，所以可预见的是所有请求将被服务器在相对短的时间量(例如，一秒的区间)内接收，并且可预见所有响应将被客户端设备40在相对短的时间量(例如，一秒的区间)内接收。换言之，响应的聚合可被视为是对区段可用性窗口的服务器设备60判定的快照。

客户端设备40的检索单元52可使用对探测请求的响应来确定区段可用性窗口的左边沿和/或右边沿。此外或可选地，检索单元52可确定客户端设备40的时钟域服务器设备60的时钟之间的差(也被称为时间增量)。具体地，可基于服务器设备60对探测请求的响应模式来推测客户端设备40与服务器设备60之间的时间增量。

图5至9是示出对图4中的由检索单元52发出的探测请求的各种可能的响应模式的概念图。在图5至9中，黑色阴影三角表征可用区段，即对其的探测请求得到的是无错误响应(例如，HTTP 200响应)的区段。在图5至9中，非阴影三角表示不可用的区段，即，对其的探测请求得到的是错误响应(例如，HTTP 404响应)的区段。

图5表征当客户端设备40的时钟偏移得比服务器设备的时钟60(或更一般地，所通告的区段i的可用时间)领先时的示例性错误模式。在该例子中，客户端设备40的时钟指示区段i可用。即，客户端设备40的时钟等于或超过所通告的区段i的可用时间(例如在诸如清单文件66的MPD中通告)。然而，响应模式指示至多仅到区段i–k–1的区段是可用的。即，对区段(i–k)到区段i的请求的响应指示HTTP 404错误。因此，区段i–k–1表征区段可用性窗口的右边沿。基于成功响应与失败响应之间的边界，客户端设备40的检索单元52可估计客户端设备40的时钟与服务器40的时钟之间的时间增量。如果对于区段i到区段(i-k)，响应是404错误代码，但从(i-k-1)到(i-N)，响应是200代码，则检索单元52可根据以下公式(6)估计时间增量：

D(j)：区段j的持续时间 (6)

当区段具有相等的持续时间D，所估计的时间增量可简单地是(k+1)*D。

图6表征当客户端设备40的时钟落后于服务器设备60的时钟(或更一般地，所通告的区段i的可用时间)时的示例性的错误模式。当客户端设备40的时钟落后于所通告的区段i的可用时间(例如，落后于服务器设备60的时钟)并且该时间差引起区段请求失败时，这一般是因为客户端设备40的时钟落后于服务器设备60的时钟如此远以至于区段请求时间落出了TSBD(即，区段可用性窗口)的左边沿。在该实施例中，客户端设备40的时钟指示区段i可用。即，客户端设备40的时钟可指示：等于或大于所通告的区段i的可用时间、但小于区段i被通告从区段可用性窗口移出的时间的时间。然而，图6的响应模式指示仅在区段i+k之后的区段是可用的。

当响应模式从区段i到区段(i+k)显示404错误代码，从区段(i+k+1)开始之后显示成功代码，成功响应代码与失败响应代码之间(即，(1+k)与(i+k+1)之间)的边界被认为是TSBD(即，区段可用性窗口)的左边沿。客户端设备40的检索单元52可根据以下公式(7)推测客户端设备40的时钟与服务器设备60的时钟之间的增量：

t i m e_d e l t a \approx Σ_{j = i}^{i + k} D (j) + T S B D

D(j)：区段j的持续时间 (7)

图7表征当客户端设备40的时钟在区段可用性窗口内、但并未完全与服务器设备60(或更一般地，所通告的区段i的可用时间)同步的示例性错误模式。如以上所提到的，发起探测请求过程的触发开关是可选的。因此，检索单元52可以在没有失败响应触发开关的情况下发起探测请求过程，检索单元52可进一步执行时间增量估计，而无需由初始的失败区段请求来触发。这指的是当客户端设备40可成功地检索媒体区段时的情况。当客户端所请求的媒体区段落入TSBD(即区段可用性窗口)中、但在客户端设备40的时钟与区段实际变得可用(例如，由服务器设备60所指示)的时间之间仍存在时间增量时可发生这样的情况。

假设客户端接收到如图7所示的探测请求的响应。在区段(i-g)与区段(i+k)之间，响应码是成功(例如，HTTP代码200)。在这个范围之外，响应码是HTTP 404“不可用”。在该情况中，客户端设备40的检索单元52可得出结论：区段(i-g)到区段(i+k)的范围内的区段对应于TSBD(即，可用性窗口)。检索单元52可确定客户端设备40的时钟落后于服务器设备60的时钟，并根据以下公式(8)估计时间增量：

t i m e_d e l t a \approx Σ_{j = i}^{i + k} D (j) + \underset{5}{T S B D}

D(j)：区段j的持续时间 (8)

图8和9表示用于估计时间增量的非确定性错误模式的示例。诸如图8和图9所示的各种响应模式被认为是不确定的，并可要求发送额外的探测请求或可指示除了客户端设备40与服务器设备60之间的时钟不同步之外的错误。

具体地，图8示出混合的成功与失败响应的示例。在这种情况中，响应模式具有交错在一起的成功和失败。这就指示失败响应的原因并不完全是基于时钟同步和区段请求时间。例如，失败响应的至少一部分可能是由于编码器或服务器处的错误、或在沿着服务器与客户端之间的网络路径上的设备处的错误。当出现这样的模式时，客户端不一定能够仅仅基于响应来估计时间增量。只要能够检索到足够的区段，客户端可仍能够保持流式传输实时视频。

图9表示对探测请求的所有响应均是404错误的示例。在这种情况中，TSBD(即，区段可用性窗口)的左边沿或右边沿均无法找到。因此，检索单元52无法仅基于这些探测请求估计时间增量。该响应模式可能是由客户端时钟与服务器时钟具有极大偏移量的不同步所引起的。全404响应模式并非终端失败。这只是意味着由探测请求集合覆盖的时间跨度不够大，从而无法找到TSBD的边沿。当出现这样的响应模式时，检索单元52可调整相邻探测请求的间隔，以使探测请求集合将以较粗糙的粒度覆盖更大的时间宽度。下面描述分层搜索方法，不过实施复杂度将高于基本估计方案。

在本例中设定区段持续时间D对于所有区段来说是固定的。分层搜索可以以等于D的探测区段间隔开始。下面的伪代码描述分级搜索的一个例子。

初始化:探测间隔PI＝D,最大探测间隔＝M*D(M＝2^k且M*D<TSBD)

主程序:

while(PI<M*D)

{

基于当前客户端时间t与探测间隔D形成探测请求

利用探测请求集合运行基本增量估计方案

If找到TSBD边沿, break out of loop; else PI=PI*2

}

If(找到TSBD边沿){

While(PI>D){

将客户端的时钟调整为以新估计的TSBD边沿为中心

重新运行时间增量估计以获得更精确的TSBD边沿估计

PI=PI/2

}

else {

声明搜索失败

}

一旦检索单元52估计出时间增量，检索单元52可以记录时间增量值以使用调整后的时间来发出媒体区段请求。以下实施例概括了这样的过程。设定周期开始时间是15:30:00并且实时媒体区段使用基于区段号的模板，其中每个媒体区段是1秒钟长度（依据回放持续时间）。基于MPD，第一媒体区段的可用性开始时间是15:30:01。然而，DASH客户端（例如，检索单元52）无法基于其本地时钟在该启动时间成功地检索媒体区段。那么，DASH客户端运行时间增量估计算法并估计到其时钟比服务器时钟（或所请求的区段实际可用的时间）领先3秒。考虑到当前的客户端时钟是15:30:35。客户端首先使用所估计的时间增量来计算对服务器时钟的估计，即15:30:32。之后，基于区段可用性时间线，客户端计算最新可用区段号为区段#32（而非基于客户端本地时钟的#35）。在这之后，客户端将发出对媒体区段#32的请求并且服务器返回200代码及区段数据。

在获得时间增量估计之后，检索单元52可保持对TSBD（即，区段可用性窗口）的右边沿的追踪并避免以后的时钟偏移。检索单元52可实施各种技术以保持对TSBD的右边沿的追踪。在一个实施例中，检索单元52可周期性地（例如每分钟）发送探测请求并如上所述地进行时间增量估计。在初始的时间增量估计之后，客户端具有了对TSBD右边沿的充分近似值。随后的探测请求可以以对TSBD右边沿的之前的估计为中心。这将几乎确保随后的时间增量估计的成功并减少所发送的探测请求的数量。在绝大多数情况中，随后的时间差估计或将重新确定之前的估计，或将之前的估计值调整微小的值。该方法相对来说易于实现，因为其要求DASH客户端(例如，检索单元52)维护最小量的状态(之前的时间增量)。但该方法不一定改善时间增量估计的精确性，因为粒度仍受到区段持续时间的限制。

另一种方法用于检索单元52在检测TSBD的确切边沿(例如，TSBD的确切的右边沿)方面能够有所突破。假设客户端设备40的时钟指示挂钟时间t，初始时间增量估计结果是增量值d。为了有所突破，客户端可引入新的状态变量p，其是对所估计的服务器时间的微小的时间偏移量。取代使用服务器时间(t+d)作为服务器时间的估计，客户端可使用估计服务器时间(t+d+p)。如下所说明，该突破性方法可以多个阶段进行。

在该突破性方法的初始化阶段，检索单元52根据初始时间增量估计使用d，设定p等于0，设定u等于100毫秒(其中u是p在每个步长的固定的增量值)，并设定D为区段持续时间值。在加法递增偏移量p的阶段中(利用每个成功的媒体区段请求发起)，检索单元52设定p＝p+u并确定所估计的服务器设备60的时间是t+d+p。在指数递减偏移量p的阶段(通过每个失败的媒体区段请求发起)，检索单元52设定p＝p/2,直到p<u，在p<u时，时间检索单元52可重新估计d。为了重新估计时间增量d(例如，当在指数递减偏移量p的阶段期间触发重新估计时)，检索单元52可如上所述地(使用探测请求)进行完整的时间增量估计过程。探测请求可以以之前的对TSBD右边沿的估计为中心。这将几乎确保产生成功的估计。新估计的时间增量d’取代之前的时间增量d。该方法有能力以增加的客户端侧复杂度为代价以更高的精度来精细微调时间增量估计。具体地，在该例中，客户端设备40维持更多的状态信息。

检索单元52可对这些技术单独或组合式实施一个或多个优化。例如，检索单元52可维持发送到服务器设备60的探测请求的特定顺序。由于客户端以顺序方式一个接着一个地发出探测请求，重要的是应注意绝大多数媒体检索失败是由客户端设备40的时钟领先于服务器设备60的时钟(或领先于区段变为可用的时间)而导致的。因此，客户端设备40可从时间上的后向到时间上的前向发出探测请求，例如，从对区段(i-N)的探测请求开始到对区段(i+N)的探测请求。即使服务器仅可及时地处理有限个探测请求，这样的请求顺序也可提高成功估计的可能性，因为时间增量的估计的设定是基于对临近于TSBD(即区段可用性窗口)边沿的探测请求的处理时间几乎相同。

作为另一个实施例，检索单元52可以对响应模式特征化。特征化对探测请求的响应模式的一种实际的方法是从对后向最早(backward-most)的请求的响应开始，并对响应消息类型改变的次数进行计数。例如，在图5、6和7中，响应码的改变次数分别是1次、1次和2次。然而，在图8和图9中，响应码的改变次数分别是6次和0次。可以看出，仅当响应码改变次数是1或2时，响应模式才可被用来推测TSBD的边沿。

作为另一个实施例，可根据“提前一区段”原则来配置检索单元52。即，由于时间增量估计具有一个区段持续时间的粒度，可建议在以时间增量调整客户端设备40的时钟之后，检索单元52应该请求的最优先媒体区段是在最新可用媒体之前已可用的媒体区段。换句话说，检索单元52可被配置为并不追求TSBD的右边沿，而是后退一个区段以适应时间增量估计的任何不精确性。

以上讨论的变量N可通过配置进行修改。在某些实施例中，N对应于在从被检索单元52确定为最新可用区段i的位置开始的每个方向(后向和前向)上发出的探测请求的数量。实证式测验示出，在客户端设备与服务器设备之间的NTP同步之后，在一个小时之内，客户端设备的时钟可从服务器设备时钟偏移高达几秒，在24小时的周期内，高达20秒。因此，参数N可取决于从客户端设备与网络时间源的最后同步开始已流逝的时间。例如，检索单元52可被配置为使用根据下面表1的数据，以基于从与服务器设备60的最后一次同步开始流逝的时间来确定N的值。客户端设备40可周期性地和/或以某预定次数(例如，每天(或24小时周期)一次)、在流式传输会话的开始、和/或在流式传输会话期间周期性地(例如，每隔几分钟))与服务器设备60重新同步。

表1

从最后一次同步以来的时间	N的值
		≤1分钟	10

>1分钟但≤10分钟	15
		>10分钟但≤1小时	20
>1小时	25

图10是示出非均匀分隔的探测序列的实施例的概念图。探测序列既可以是均匀分隔的，也可以是非均匀分隔的，在均匀分隔中，相邻的探测包以相隔固定数量区段的两个区段为目标，在非均匀分隔中，只要关于呈现时间的区段的间隔小于TSBD(即，区段可用性窗口)，相邻探测包可以以相隔为可变数量区段的两个区段为目标。在图10的实施例中示出非均匀分隔探测序列的一个图案。在探测序列的中心，探测包的目标区段之间的间隔较小。随着探测包远离中心移动，在目标区段之间的间隔增大。这样的设计可以有助于实现探测序列的大的时间覆盖，同时在探测序列的中心维持良好的时间粒度。

图11是示出用于根据本公开的技术来确定区段可用性窗口的一个或多个边沿的的示例性方法的流程图。图11的方法被示出为通过客户端设备(例如，客户端设备40)和服务器设备(例如，服务器设备60)进行。尽管相对于图1中的客户端设备40和服务器设备60进行描述，但应理解的是其他设备可被配置为执行基本上与图11方法相似的方法。此外，应理解的是在与图11方法相一致的方法中可执行额外或替代步骤。

假定在客户端设备40已从服务器设备60接收到针对特定媒体内容的MPD或其他清单文件后执行图11的方法。此外，MPD可包括规定媒体内容的区段将可用于检索的时间的数据。可相对于服务器设备60的时钟或相对于另一个设备或实体(诸如内容准备设备20)的时钟来通告这些时间。因此，客户端设备40可确定媒体内容的区段将可用于检索的时间以及该区段不再可用于检索的时间。

MPD可进一步包括规定不同表征体特性的信息，诸如自适应集内的表征体和自适应集内的表征体的带宽。客户端设备40可基于例如自适应集的特性、可用表征体的比特率和当前所估计的可用带宽来选择表征体(200)中的一个。客户端设备40还可从本地时钟(即客户端设备40的时钟)确定当前时间(202)。例如，客户端设备40可将由本地时钟所指示的当前时间与区段被通告变得可用的时间做对比。然后，客户端设备40可确定具有最新可用时间的区段i，该最新可用时间即是小于或等于本地时钟所指示的当前时间但大于所选的表征体的所有其他区段的时间的可用时间。如客户端设备40的本地时钟所指示，该区段i可被称为最新可用区段。

基于该确定，客户端设备40可发送对来自服务器设备60的最新可用区段(例如，区段i)的请求(204)。该请求可对应于例如HTTP GET或部分GET请求。服务器设备60可从客户端设备40接收该区段请求(206)。然而，假如客户端设备40的本地时钟已相对于区段变得可用的实际时间(例如，相对于服务器设备60、内容准备设备20或其他这样的设备的时钟)发生偏移，则区段i可能实际上还并不可用。在图11的例子中，假设区段i在服务器设备60接收该请求的时间并不可用，因此，服务器设备60确定所请求的区段不可用(208)并向客户端设备40发送错误(210)，例如HTTP404错误。

客户端设备40可接收该错误(212)并基于该错误确定客户端设备40的本地时钟已经相对于区段i将变为(或已变为)可用的实际时间发生偏移。因此，根据本公开的技术，客户端设备40可发送探测请求至服务器设备60(214)。探测请求可对应于对非常少量的数据(例如，至多100字节的数据)的HTTP HEAD请求或部分GET请求。客户端设备40可如关于图4所讨论的那样发送探测请求。例如，客户端设备40可发送探测请求以使一个或多个探测请求指向比区段i更早的区段，并且一个或多个探测请求指向比区段i更晚的区段。

之后，服务器设备60可接收这些请求(216)并发送对这些请求的响应(218)。如果探测请求是HTTP HEAD请求，对于当前可用的那些区段，服务器设备60可发送报头信息(以下被称为“成功”探测响应)，对于当且不可用的那些区段，服务器设备60可发送错误消息(例如，HTTP 404错误)。

客户端设备40可接收响应(220)并分析这些响应以确定区段可用性窗口(222)的一个或多个边沿。例如，如果成功的探测响应和错误消息的模式组成如上所讨论的图5所示的模式，则客户端设备40可将具有成功探测响应的最新区段(例如，区段i–k–1)识别为区段可用性窗口的右边沿。此外，为了避免随后对区段的请求的错误响应，客户端设备40可确定区段i与区段可用性窗口的右边沿之间的时间增量(在该情况中，k+1)以确定施加于本地时钟的偏移量。在本例中，如上所讨论的，客户端设备40可使用公式(6)确定时间增量。

作为另一个例子，如果成功的探测响应和错误消息的模式组成图6所示的模式，客户端设备40可确定区段可用性窗口的左边沿。在该实施例中，客户端设备40还可使用如上所讨论的公式(7)来计算时间增量。作为又一个例子，如果成功的探测响应和错误消息的模式组成如图7所示的模式，则客户端设备40可确定区段可用性窗口的左边沿和右边沿两者。在该例子中，客户端设备40还可使用如上所讨论的公式(8)来计算时间增量。在成功的探测响应与错误消息组成如图9所示的模式的情况中，客户端设备40可进行分层搜索法来识别区段可用性窗口的左边沿和/或右边沿。此外，如果仅发现了左边沿或右边沿中的一个，客户端设备40可发送额外的探测包以发现区段可用性窗口的另一边沿(尽管未在图11中示出)。

在任意情况中，在确定区段可用性窗口的至少一个边沿之后，客户端设备40可发送对区段可用性窗口内的区段的请求(224)。例如，在上面所讨论的实施例中，客户端设备40可发送对区段i-k-1的请求。之后，服务器设备60可接收请求(226)并发送所请求的区段至客户端设备40(228)。

应理解的是，响应于各种触发条件(诸如当对于区段(例如，连续地)接收到一个或多个错误时、响应于初始开始流式传输会话、从发送最后一组探测包开始流逝的时间量(其还可影响待发送的探测包的数量))、这些触发条件的任意组合、以及其他或可选触发条件，客户端设备40可执行图11所描述的探测包法。

以这种方式，图11的方法表征检索媒体数据的方法的一个实施例，该方法包括向服务器设备发送多个对媒体数据的区段的探测请求，其中，服务器设备使用实时流式传输服务提供媒体数据，分析对该多个探测请求的响应以确定区段可用性窗口的左边沿和右边沿，并根据实时流式传输服务，基于区段可用性窗口的被确定的左边沿和被确定的右边沿发送对区段可用性窗口内的区段的请求。

在一个或多个实施例中，可以以硬件、软件、固件或其组合的形式实施所描述的功能。如果以软件实施，功能可作为一条或多条指令或代码被存储在计算机可读介质上或通过其进行传输，并由基于硬件的处理单元所执行。计算机可读介质可包括计算机可读存储介质或通信介质，计算机可读介质对应于有形的介质，诸如数据存储介质，通信介质包括例如根据通信协议促进计算机程序从一个地点传递到另一个地点的介质。以这种方式，计算机可读介质通常可对应于(1)非临时的有形计算机可读存储介质或(2)诸如信号或载波这样的通信介质。数据存储介质可以是能够由一个或多个计算机或一个或多个处理器访问以检索用于实施本公开所描述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可包括计算机可读介质。

通过示例的方式而不是限制的方式，这种计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储介质或其它磁存储设备、闪存、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质。此外，任何连接可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字用户线(DSL)或者诸如红外线、无线和微波之类的无线技术从网站、服务器或其它远程源传输的，那么同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所述介质的定义中。不过，应理解的是计算机可读存储介质和数据存储介质并不包括连接、载波、信号或其他临时介质，而是针对非临时的有形存储介质。如本申请所使用的，磁盘(disk)和光盘(disc)包括压缩光盘(CD)、激光光盘、光盘、数字通用光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。

可通过一个或多个处理器执行指令，诸如一个或多个数据信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等价的集成或离散逻辑电路。因此，如在本文中所用，术语“处理器”可指的是任意前述结构或适于实施本文所描述技术的其他结构。此外，在某些方面，可在被配置为用于编码和解码的专用硬件和/或软件模块内提供本文所描述的功能，或可将其并入组合式编码解码器中。而且，可以以一个或多个电路或逻辑元件的形式完整实施该技术。

可以以多种多样的设备或装置实施本公开的技术，包括无线手持设备、集成电路(IC)或一组IC(例如，芯片组)。本公开中描述了各种部件、模块或单元以强调被配置为执行本公开技术的设备的功能性方面，但不一定需要以不同的硬件单元实现。而是，如上所描述的，结合合适的软件和/或固件，各种单元可以结合在编码解码器硬件中或通过联合操作的硬件单元(包括如上所描述的一个或多个处理器)的集合提供。

已描述了各种实施例。这些或其他的实施例均在所附权利要求的范围内。

Claims

1.一种检索媒体数据的方法，所述方法包括：

向服务器设备发送对媒体数据的区段的多个探测请求，其中，所述服务器设备使用实时流式传输服务来提供所述媒体数据；

分析对所述多个探测请求的响应，以确定区段可用性窗口的左边沿和右边沿；以及

根据所述实时流式传输服务，基于所述区段可用性窗口的所确定的左边沿和所确定的右边沿，来发送对所述区段可用性窗口内的区段的请求。

2.根据权利要求1所述的方法，其中，所述探测请求包括对大幅小于所述区段的全部数据量的、所述区段的数据量的请求。

3.根据权利要求1所述的方法，其中，所述探测请求包括HTTP HEAD请求。

4.根据权利要求1所述的方法，其中，所述探测请求包括HTTP部分GET请求。

5.根据权利要求1所述的方法，还包括确定对在前请求的响应包括的HTTP 404错误的数量，其中，发送所述多个探测请求包括基于对所述在前请求的所述响应中的所述HTTP 404错误的数量来发送所述多个探测请求。

6.根据权利要求1所述的方法，其中，发送所述多个探测请求包括在发起用于检索所述媒体数据的HTTP流式传输会话时发送所述多个探测请求。

7.根据权利要求1所述的方法，其中，分析所述响应包括：

确定对在先区段的请求的响应指示成功和对在后区段的请求的响应指示失败；以及

基于对于所述对所述在先区段的请求的响应指示成功和所述对所述在后区段的请求的响应指示失败的所述确定，确定所述区段可用性窗口的所述右边沿在所述响应指示成功的所指区段与所述响应指示失败的所指区段之间。

8.根据权利要求7所述的方法，还包括根据下式来计算时间增量值：

t i m e_d e l t a \approx Σ_{j = i - k}^{i} D (j)

其中，D(j)定义区段j的持续时间，其中i表示基于客户端设备的时钟的估计的可用区段，k表示在区段i与所述响应指示成功的最新区段之间的区段的数量。

9.根据权利要求1所述的方法，其中，分析所述响应包括：

确定对在后区段的请求的响应指示成功和对在先区段的请求的响应指示失败；以及

基于所述确定，确定所述区段可用性窗口的所述左边沿在所述响应指示成功的所指区段与所述响应指示失败的所指区段之间。

10.根据权利要求9所述的方法，还包括根据下式来计算时间增量值：

t i m e_d e l t a \approx Σ_{j = i}^{i + k} D (j) + T S B D

其中，D(j)定义区段j的持续时间，其中i表示基于客户端设备的时钟的估计的可用区段，TSBD表示时移缓冲深度，而k表示在区段i与所述响应指示成功的最早区段之间的区段的数量。

11.根据权利要求1所述的方法，其中，分析所述响应包括：

确定对在先区段的请求的响应指示失败、对在后区段的请求的响应指示失败和对所述在先区段与所述在后区段之间的中间区段的请求的响应指示成功；以及

基于所述确定，确定所述区段可用性窗口的所述左边沿在所述在先区段与所述中间区段之间，所述区段可用性窗口的所述右边沿在所述中间区段与所述在后区段之间。

12.根据权利要求11所述的方法，还包括根据下式来计算时间增量值：

t i m e_d e l t a \approx Σ_{j = i + 1}^{i + k} D (j)

其中，D(j)定义区段j的持续时间，其中i表示基于客户端设备的时钟的估计的可用区段，而k表示在区段i与所述响应指示成功的最新区段之间的区段的数量。

13.根据权利要求1所述的方法，其中，所述多个探测请求包括第二多个探测请求，所述方法还包括：

在发送所述第二多个探测请求之前，发送覆盖第一回放时间量的第一多个探测请求，其中，发送所述第二多个探测请求包括在确定对所述第一多个探测请求的响应指示失败后，发送所述第二多个探测请求，并且其中，所述第二多个探测请求覆盖大于所述第一回放时间量的第二回放时间量。

14.根据权利要求13所述的方法，还包括：使用分层搜索方法来确定在所述第二多个探测请求中所包括的探测数量。

15.根据权利要求1所述的方法，还包括：

确定表示区段实际可用的时间与客户端设备的时钟指示所述区段可用的时间之间的差的时间增量；以及

基于所述时间增量来请求一个或多个区段。

16.根据权利要求15所述的方法，还包括使用随后的多个探测包来周期性地更新所述时间增量。

17.根据权利要求15所述的方法，还包括以一个或多个小的增量来增加所述时间增量，以尝试确定所述区段可用性窗口的精确的右边沿。

18.根据权利要求1所述的方法，其中，发送所述多个探测请求包括发送所述多个探测请求，以使得在先探测请求对应于在先区段，在后探测请求对应于在后区段。

19.根据权利要求1所述的方法，其中，分析所述响应包括计算指示成功的响应序列与指示失败的响应序列之间的转换数量。

20.根据权利要求19所述的方法，还包括仅当所述转换数量等于1或2时才推测所述区段可用性窗口的所述边沿。

21.根据权利要求1所述的方法，其中，发送对所述区段的所述请求包括发送对落后于所述右边沿一个区段的区段的请求。

22.根据权利要求1所述的方法，还包括基于从与所述服务器设备最后一次时间同步开始流逝的时间量，来确定所述多个探测请求中包括的探测请求的数量。

23.根据权利要求22所述的方法，其中，确定所述探测请求的数量包括：当所述流逝的时间量小于或等于1分钟时，确定所述探测请求的数量等于10；当所述流逝的时间量大于1分钟且小于或等于10分钟时，确定所述探测请求的数量等于15；当所述流逝的时间量大于10分钟且小于或等于1小时时，确定所述探测请求的数量等于20；以及当所述流逝的时间量大于一小时时，确定所述探测请求的数量等于25。

24.根据权利要求1所述的方法，还包括在发起用于请求所述媒体数据的流式传输会话之前，将客户端设备的时钟与所述服务器设备同步。

25.根据权利要求24所述的方法，其中，同步包括使用网络时间协议(NTP)进行同步。

26.根据权利要求1所述的方法，还包括周期性地将客户端设备的时钟与所述服务器设备同步。

27.根据权利要求26所述的方法，其中，周期性地同步包括每N分钟将所述客户端设备的时钟与所述服务器设备同步。

28.根据权利要求1所述的方法，其中，发送所述请求包括根据实时HTTP动态自适应流式传输(DASH)来发送所述请求。

29.根据权利要求1所述的方法，其中，发送所述多个探测请求包括在发送对所述媒体数据的请求之后，响应于回放所述媒体数据失败，发送所述多个探测请求，所述方法还包括：

至少部分地基于所确定的左边沿和所确定的右边沿，来确定客户端设备的本地时钟与服务器设备的时钟之间的时间差；以及

基于所确定的时间差来调整所述本地时钟，

其中，发送所述请求包括基于调整后的本地时钟来发送所述请求。

30.根据权利要求1所述的方法，还包括至少部分地基于所确定的左边沿和所确定的右边沿来确定客户端设备的本地时钟与服务器设备的时钟之间的时间差。

31.根据权利要求30所述的方法，其中，所述时间差指示所述本地时钟领先于所述服务器设备的时钟，所述方法还包括停止媒体回放一段时间，该一段时间等于所述时间差。

32.根据权利要求30所述的方法，其中，所述时间差指示所述本地时钟落后于所述服务器设备的时钟，所述方法还包括略过一段时间的媒体回放，该一段时间等于所述时间差。

33.根据权利要求30所述的方法，其中，所述时间差指示所述本地时钟领先于所述服务器设备的时钟，所述方法还包括以略高于正常回放速率的速率播放所述媒体数据，直到所述时间差等于0。

34.根据权利要求30所述的方法，其中，所述时间差指示所述本地时钟落后于所述服务器设备的时钟，所述方法还包括以略低于正常回放速率的速率播放所述媒体数据，直到所述时间差等于0。

35.一种用于检索媒体数据的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置为：

36.根据权利要求35所述的设备，其中，所述探测请求包括HTTP HEAD请求与HTTP部分GET请求之一。

37.根据权利要求35所述的设备，其中，所述一个或多个处理器被配置为：基于确定对在前请求的响应包括的HTTP 404错误的数量与发起HTTP流式传输会话中的至少一个来发送所述多个探测请求。

38.根据权利要求35所述的设备，其中，为了分析所述响应，所述一个或多个处理器被配置为：

确定对在先区段的请求的响应指示失败、对在后区段的请求的响应指示失败和对所述在先区段与所述在后区段之间的中间区段的请求的响应指示成功，以及

39.根据权利要求38所述的设备，其中，所述一个或多个处理器被配置为根据下式来计算时间增量值：

t i m e_d e l t a \approx Σ_{j = i + 1}^{i + k} D (j)

40.根据权利要求35所述的设备，其中，所述多个探测请求包括第二多个探测请求，并且其中，所述一个或多个处理器被配置为：

在发送所述第二多个探测请求之前，发送包括比所述第二多个探测请求少的探测请求的第一多个探测请求，并在确定对所述第一多个探测请求的响应指示失败后，发送所述第二多个探测请求。

41.根据权利要求35所述的设备，其中，所述一个或多个处理器被配置为：

基于所述时间增量来请求一个或多个区段。

42.一种用于检索媒体数据的设备，所述设备包括：

用于向服务器设备发送对媒体数据的区段的多个探测请求的单元，其中，所述服务器设备使用实时流式传输服务来提供所述媒体数据；

用于分析对所述多个探测请求的响应，以确定区段可用性窗口的左边沿和右边沿的单元；以及

用于根据所述实时流式传输服务、基于所述区段可用性窗口的所确定的左边沿和所确定的右边沿来发送对所述区段可用性窗口内的区段的请求的单元。

43.根据权利要求42所述的设备，其中，所述探测请求包括HTTP HEAD请求与HTTP部分GET请求之一。

44.根据权利要求42所述的设备，其中，所述用于发送所述多个探测请求的单元包括：

用于基于响应于在前请求而接收到的HTTP 404错误的数量来发送所述多个探测请求的单元与用于基于发起HTTP流式传输会话来发送所述多个探测请求的单元中的至少一个。

45.根据权利要求42所述的设备，其中，所述用于分析所述响应的单元包括：

用于确定对在先区段的请求的响应指示失败、对在后区段的请求的响应指示失败和对所述在先区段与所述在后区段之间的中间区段的请求的响应指示成功的单元；以及

用于基于所述确定来确定所述区段可用性窗口的所述左边沿在所述在先区段与所述中间区段之间、所述区段可用性窗口的所述右边沿在所述中间区段与所述在后区段之间的单元。

46.根据权利要求45所述的设备，还包括用于根据下式来计算时间增量值的单元：

t i m e_d e l t a \approx Σ_{j = i + 1}^{i + k} D (j)

47.根据权利要求42所述的设备，其中，所述多个探测请求包括第二多个探测请求，所述设备还包括：

用于在发送所述第二多个探测请求之前发送包括比所述第二多个探测请求少的探测请求的第一多个探测请求的单元，其中，用于发送所述第二多个探测请求的单元包括用于在确定对所述第一多个探测请求的响应指示失败后发送所述第二多个探测请求的单元。

48.根据权利要求42所述的设备，还包括：

用于确定表示区段实际可用的时间与客户端设备的时钟指示所述区段可用的时间之间的差的时间增量的单元；以及

用于基于所述时间增量来请求一个或多个区段的单元。

49.一种其上存储有指令的计算机可读存储介质，该指令在被执行时，使得处理器：

50.根据权利要求49所述的计算机可读存储介质，其中，所述探测请求包括HTTP HEAD请求与HTTP部分GET请求之一。

51.根据权利要求49所述的计算机可读存储介质，其中，使得所述处理器发送所述多个探测请求的所述指令包括：使得所述处理器基于响应于在前请求而接收到的HTTP 404错误的数量与发起HTTP流式传输会话中的至少一个来发送所述多个探测请求的指令。

52.根据权利要求49所述的计算机可读存储介质，其中，使得所述处理器分析所述响应的所述指令包括使得所述处理器进行以下操作的指令：

53.根据权利要求52所述的计算机可读存储介质，还包括使得所述处理器根据下式来计算时间增量值的指令：

t i m e_d e l t a \approx Σ_{j = i + 1}^{i + k} D (j)

54.根据权利要求49所述的计算机可读存储介质，其中，所述多个探测请求包括第二多个探测请求，所述计算机可读存储介质还包括使得所述处理器在发送所述第二多个探测请求之前发送包括比所述第二多个探测请求少的探测请求的第一多个探测请求的指令，其中，使得所述处理器发送所述第二多个探测请求的所述指令包括使得所述处理器在确定对所述第一多个探测请求的响应指示失败后发送所述第二多个探测请求的指令。

55.根据权利要求49所述的计算机可读存储介质，还包括使得所述处理器进行以下操作的指令：

基于所述时间增量来请求一个或多个区段。