使用块划分或请求控制以获得改善的客户端侧处置的增强型块请求流送

摘要

一种块请求流送系统典型地使用摄取系统来提供此类系统的用户体验和带宽效率的改善，该摄取系统生成将由常规文件服务器(例如，HTTP、FTP或类似服务器)供应的形式的数据，其中该摄取系统摄入内容并将其制备为要由该文件服务器供应的文件或数据元素。客户端设备可适配成利用摄取过程。客户端设备可被配置成在有来自摄取系统的信息可为其所用的前提下优化对资源的使用。这可包括配置成基于对缓冲器大小和缓冲器大小变化率的监视来决定块请求的顺序、时基和构造，使用可变大小请求，将块请求映射到底层传输连接，请求的灵活管线化，和/或基于统计考量使用全文件请求。

说明书

相关申请的交叉引用

本申请是要求以下临时申请的权益的非临时专利申请，这些临时申请皆署 名Michael G.Luby等且皆题为“Enhanced Block-Request Streaming System(增 强型块请求流送系统)”：

于2009年9月22日提交的美国临时专利申请No.61/244,767，

于2009年11月3日提交的美国临时专利申请No.61/257,719，

于2009年11月4日提交的美国临时专利申请No.61/258,088，

于2009年12月11日提交的美国临时专利申请No.61/285,779，以及

于2010年1月20日提交的美国临时专利申请No.61/296,725。

本申请还要求于2010年8月10日提交的、署名Ying Chen等且题为“HTTP  Streaming Extensions(HTTP流送扩展)”的美国临时专利申请No.61/372,399 的权益。

以上引用的每个临时申请藉此通过援引通用地纳入于此。本公开还通过援 引如在本文档中完整阐述一样通用地纳入以下共同受让的申请/专利：

授予Luby的美国专利No.6,307,487(下文称为“Luby I”)；

授予Shokrollahi等人的美国专利No.7,068,729(下文称为“Shokrollahi I”)；

于2006年6月9日提交且题为“Forward Error Correcting(FEC)Coding and  Streaming(前向纠错(FEC)编码和流送)”、署名Luby等的美国专利申请 No.11/423,391(下文称为“Luby II”)；

于2008年4月15日提交的题为“Dynamic Stream Interleaving and  Sub-Stream Based Delivery(动态流交织和基于子流的投递)”、署名Luby等 的美国专利申请No.12/103,605(下文称为“Luby III”)；

于2010年2月12日提交的题为“Block Partitioning for a Data Stream(数 据流的块划分)”、署名Pakzad等的美国专利申请No.12/705,202(下文称为 “Pakzad”)；以及

于2010年8月18日提交的题为“Methods and Apparatus Employing FEC  Codes with Permanent Inactivation of Symbols for Encoding and Decoding  Processes(将FEC码与码元永久灭活联用来进行编码和解码过程的方法和装 置)”、署名Luby等的美国专利申请No.12/859,161(下文称为“Luby IV”)。

发明领域

本发明涉及改善的媒体流送系统和方法，尤其涉及自适应于网络和缓冲条 件以使流送媒体的呈现最优化并允许对流送媒体数据进行高效的并发或时间 分布式投递的系统和方法。

发明背景

流送媒体投递可能变得日益重要，因为在诸如因特网、蜂窝和无线网络、 输电线网络、以及其他类型的网络之类的基于分组的网络上投递高质量音频和 视频变得越来越常见。所投递的流送媒体能被呈现出的质量可取决于数种因 素，包括原始内容的分辨率(或其他属性)、原始内容的编码质量、接收设备 解码和呈现媒体的能力、在接收机处接收到的信号的及时性和质量等。为了产 生感知到的良好的流送媒体体验，在接收机处接收到的信号的传输和及时性可 能尤其重要。良好的传输可以提供在接收机处接收到的流相对于发送方发送的 流的保真度，而及时性可以代表接收机在初始请求内容之后多快就能开始播出 该内容。

媒体投递系统可表征为具有媒体源、媒体目的地、以及将源和目的地分开 的(时间和/或空间上的)信道的系统。典型地，源包括能访问可电子地管理的 形式的媒体的发射机、以及有能力电子地控制对媒体(或其近似物)的接收并 将其提供给媒体消费者(例如，具有以某种方式耦合到该接收机、存储设备或 元件、另一信道等的显示设备的用户)的接收机。

虽然有许多变型是可能的，但在常见的示例中，媒体投递系统具有能访问 电子形式的媒体内容的一个或更多个服务器，并且一个或更多个客户端系统或 设备向服务器作出对媒体的请求，而服务器使用作为该服务器的一部分的向客 户端处的接收机进行传送的发射机来输送该媒体，从而收到的媒体能由该客户 端以某种方式消费。在简单的示例中，对于给定的请求和响应而言有一个服务 器和一个客户端，但并非必需如此。

按传统，媒体投递系统可表征为“下载”模型或“流送”模型。“下载” 模型可由媒体数据的投递与该媒体向用户或接收方设备的播出之间的时基独 立性来表征。

作为示例，媒体在被需要或将被使用之前被下载得足够多，并且在该媒体 被使用时，在接收方处已有所需那么多的媒体可用。在下载的上下文中的投递 往往是使用诸如HTTP、FTP或单向传输上的文件投递(FLUTE)之类的文件 传输协议来执行的，且投递速率可由下层的流量和/或拥塞控制协议(诸如 TCP/IP)来决定。该流量或拥塞控制协议的操作可独立于媒体向用户或目的地 设备的播出，而播出可与下载并发地发生或在其他某个时间发生。

“流送”模式可由媒体数据的投递与该媒体向用户或接收方设备的播出的 时基之间的紧耦合来表征。在该上下文中的投递往往是使用流送协议来执行 的，诸如用于控制的实时流送协议(RTSP)和用于媒体数据的实时传输协议 (RTP)。投递速率可由流送服务器决定，通常与数据的播出速率匹配。

“下载”模型的一些缺点可能在于，由于投递与播出之间的时基独立性， 要么在需要媒体数据供播出时该媒体数据可能不可用(例如，由于可用带宽小 于媒体数据率)，导致播出暂时停止(“停滞”)，而这造成不良的用户体验； 要么可能要求提前在播出之前很久就下载媒体数据(例如，由于可用带宽大于 媒体数据率)，从而消费掉接收设备上可能稀缺的存储资源，并且消费宝贵的 网络资源进行投递，而这在内容最终没有被播出或以其他方式使用的情况下会 被浪费掉。

“下载”模型的优点可在于执行此类下载所需的技术(例如，HTTP)非 常成熟、被广泛部署且全面适用于很广范围的应用。用于实现此类文件下载的 大规模可伸缩性的下载服务器和解决方案(例如，HTTP Web服务器和内容投 递网络)可能是现成可用的，从而使得基于该技术的服务部署简单且成本低廉。

“流送”模型的一些缺点可能在于，一般而言，媒体数据的投递速率并不 适配于从服务器到客户端的连接上的可用带宽，且需要提供带宽和延迟担保的 专门的流送服务器或更复杂的网络架构。尽管存在支持根据可用带宽来变化投 递数据率的流送系统(例如，Adobe Flash自适应流送)，但是这些系统在利 用所有可用带宽方面一般不如诸如TCP之类的下载传输流量控制协议那么高 效。

最近，已开发和部署了基于“流送”和“下载”模型的组合的新型媒体投 递系统。此类模型的示例在本文中被称为“块请求流送”模型，其中媒体客户 端使用诸如HTTP之类的下载协议来向服务基础设施请求媒体数据块。此类系 统中的关注点可能是开始播出流的能力，例如使用个人计算机来解码和渲染收 到的音频和视频流并在计算机屏幕上显示该视频以及通过内置扬声器来播放 该音频，或者作为另一示例，使用机顶盒来解码和渲染收到的音频和视频流并 在电视显示设备上显示该视频以及通过立体声系统来播放该音频。

诸如能够足够快地解码源块以跟上源流送速率、使解码等待时间最小化以 及减少对可用CPU资源的使用之类的其他关注点也是问题所在。另一关注点 是提供稳健和可伸缩的流送投递解决方案，其允许系统的组件发生故障而不会 不利地影响投递给接收机的流的质量。基于在呈现正被分发时关于该呈现的快 速改变的信息，可能发生其他问题。因此，希望具有改善的过程和装置。

发明简要概述

一种块请求流送系统典型地使用摄取系统来提供此类系统的用户体验和 带宽效率的改善，该摄取系统生成将由常规文件服务器(例如，HTTP、FTP 或类似服务器)供应的形式的数据，其中该摄取系统摄入内容并将其制备为将 由可包括或可不包括高速缓存的该文件服务器来供应的文件或数据元素。客户 端设备可适配成利用摄取过程并且包括促成独立于该摄取过程的更好呈现的 改进。客户端设备可被配置成在有来自摄取系统的信息可为其所用的前提下优 化对资源的使用。这可包括配置成基于高级缓冲器管理技术基于对缓冲器大小 和缓冲器大小变化率的监视来决定块请求的顺序、时基和构造。

在一些实施例中，提供了对基于诸如缓冲器状态之类的条件作出可变大小 请求的方法的新颖改进。在一些实施例中，提供了对用于将块请求映射到底层 文件下载协议传输连接的方法的新颖改进，包括请求的灵活管线化。在一些实 施例中，提供了服务器选择的新颖方法以及基于统计考量对全文件请求的使 用。

以下详细描述连同附图将提供对本发明的本质和优点的更好理解。

附图简述

图1描绘了根据本发明的实施例的块请求流送系统的元素。

图2解说图1的块请求流送系统，示出了耦合到块供应基础设施(“BSI”) 以接收由内容摄取系统处理的数据的客户端系统的元素中的更多细节。

图3解说了摄取系统的硬件/软件实现。

图4解说了客户端系统的硬件/软件实现。

图5解说了图1中所示的内容存储的可能结构，包括段和媒体呈现描述符 (“MPD”)文件，以及MPD文件内的段分解、时基和其他结构。

图6解说了如可存储在图1和5中解说的内容存储中的典型源段的细节。

图7a和7b解说了文件内的简单索引和阶层式索引。

图8(a)解说了在媒体流的多个版本上具有对准的查找点的可变块大小控 制。

图8(b)解说了在媒体流的多个版本上具有非对准的查找点的可变块大小 控制。

图9(a)解说了元数据表。

图9(b)解说了从服务器向客户端传输块和元数据表。

图10解说了独立于RAP边界的块。

图11解说了跨段的连续时基和不连续时基。

图12是示出可伸缩块的一方面的图。

图13描绘了块请求流送系统内的某些变量随时间演进的图形表示。

图14描绘了块请求流送系统内的某些变量随时间演进的另一图形表示。

图15描述了作为阈值的函数的状态的单元栅格。

图16是可在接收机中执行的每请求能请求单个块以及多个块的过程的流 程图。

图17是灵活管线过程的流程图。

图18解说了在某个时间的一组候选请求、其优先级、以及在哪些连接上 能发出这些请求的示例。

图19解说了已随时间变迁而演进的一组候选请求、其优先级、以及在哪 些连接上能发出这些请求的示例。

图20是基于文件标识符的一致性高速缓存服务器代理选择的流程图。

图21解说了对合适的表达式语言的句法定义。

图22解说了合适的散列函数的示例。

图23解说了文件标识符构造规则的示例。

图24(a)-(e)解说了TCP连接的带宽波动。

图25解说了对源数据和修复数据的多个HTTP请求。

图26解说了带FEC和不带FEC的示例频道换台时间。

图27解说了作为图1中所示的摄取系统一部分的从源段和控制参数生成 修复段的修复段生成器的详情。

图28解说了源块与修复块之间的关系。

图29解说了在客户端处不同时间的实况服务的规程。

在附图中，相似的项目用相似的标号来引述且在括号中提供副标以指示相 似或相同项目的多个实例。除非另行指出，否则最后的副标(例如，“N”或 “M”)并非意在限定于任何特定值，且一个项目的实例数目可与另一项目的 实例数目不同，即使在解说了相同的标号且重复使用了副标时亦然。

发明详细描述

如本文中所描述的，流送系统的目标是将媒体从其存储位置(或正生成该 媒体的位置)移到正消费该媒体的位置，即呈现给用户或以其他方式被人类或 电子消费者“用尽”。理想情况下，流送系统可在接收端提供不间断的回放(或 更一般而言，不间断的“消费”)，且在用户请求了流或流集合之后不久就能 开始播放这个或这些流。出于效率原因，还希望每个流在一旦用户指示不再需 要该流时，诸如当用户正从一个流切换到另一个流或者其服从例如“字幕”流 之类的流的呈现时就被停下。若诸如视频之类的媒体分量继续被呈现，但选择 了不同的流来呈现该媒体分量，则往往优选令新的流占用有限的带宽并停止旧 的流。

根据本文中描述的实施例的块请求流送系统提供许多益处。应理解，可行 的系统无需包括本文中描述的所有特征，因为一些应用可用不足本文中描述的 特征全体的特征来提供令人满意程度适宜的体验。

HTTP流送

HTTP流送是一种具体的流送类型。在HTTP流送下，源可以是标准web 服务器和内容投递网络(CDN)并且可使用标准HTTP。该技术可涉及流分段 以及使用多个流，所有这些皆落在标准化HTTP请求的上下文中。诸如视频之 类的媒体可以用多个比特率来编码以构成不同的版本或表示。术语“版本”和 “表示”在本文中同义地使用。每个版本或表示可被分解成较小的片以构成段， 片可能在几秒的量级。每个段随后可作为单独的文件被存储在web服务器或 CDN上。

在客户端一侧，随后可使用HTTP作出对个体段的请求，这些个体段由客 户端无缝地拼接在一起。客户端可基于可用带宽切换到不同的数据率。客户端 还可请求多个表示，每个表示呈现不同的媒体分量，并且可联合且同步地呈现 这些表示中的媒体。切换的触发可包括例如缓冲器占用率和网络测量。当在稳 态下操作时，客户端可调整向服务器请求的步调以维持目标缓冲器占用率。

HTTP流送的优点可包括比特率自适应、快速启动和查找、以及最小程度 的不必要投递。这些优点源于将投递控制成仅比播出提前很短时间、对可用带 宽作出最大程度的使用(通过可变比特率媒体)、以及优化流分段和智能客户 端规程。

媒体呈现描述可被提供给HTTP流送客户端，以使得客户端能使用文件 (例如以3GPP规定的格式，在本文中称为3gp段)的集合来向用户提供流送 服务。媒体呈现描述以及可能还有该媒体呈现描述的更新描述了实为结构化的 段集合的媒体呈现，每个段包含媒体分量以使得客户端能以同步方式呈现所包 括的媒体并且能提供高级特征，诸如查找、切换比特率、以及联合呈现不同表 示中的媒体分量。客户端可按不同方式使用媒体呈现描述信息来得到服务的供 给。具体而言，根据媒体呈现描述，HTTP流送客户端可确定能访问该集合中 的哪些段，从而流送服务内的数据对于客户端能力以及用户而言是有用的。

在一些实施例中，媒体呈现描述可以是静态的，但段可以是动态地创建的。 媒体呈现描述可以尽可能紧凑以使该服务的访问和下载时间最小化。其他专用 服务器连通性可被最小化，例如客户端与服务器之间常规或频繁的时基同步。

可以将媒体呈现构造成允许被具有不同能力——诸如接入不同的接入网 类型、不同的当前网络条件、显示器大小、访问比特率和编解码器支持——的 终端访问。客户端随后可提取恰适的信息以向用户提供流送服务。

媒体呈现描述还可根据要求允许部署灵活性以及紧凑性。

在最简单的情形中，每个替换表示可被存储在单个3GP文件中，即遵照 如3GPP TS26.244中的定义的文件、或遵照如ISO/IEC 14496-12或衍生规范中 定义的ISO基媒体文件格式(诸如3GPP技术规范26.244中描述的3GP文件 格式)的任何其他文件。在本文档的其余部分中，在引述3GP文件时，应理解 ISO/IEC 14496-12和衍生规范可将所有所描述的特征映射到如ISO/IEC 14496-12或任何衍生规范中定义的更一般性的ISO基媒体文件格式。客户端随 后可请求文件的初始部分以获悉媒体元数据(其典型地被存储在也被称为 “moov”包的电影头部包中)连同电影片断时间和字节偏移量。客户端随后可 发出HTTP部分获取请求以获得所要求的电影片断。

在一些实施例中，可能希望将每个表示拆分成若干段，其中这些段。在段 格式基于3GP文件格式的情形中，则段包含电影片断的非交迭时间片，称为“按 时间拆分”。这些段中的每一个可包含多个电影片断且每个段本身可以是有效 3GP文件。在另一实施例中，表示被拆分成包含元数据的初始段(典型情况下 为电影头部“moov”包)以及一组媒体段，每个媒体段包含媒体数据，并且初 始段与任何媒体段的级联构成有效的3GP文件，而且一个表示的初始段和所有 媒体段的级联也构成有效的3GP文件。通过依次播出每个段、根据每个表示的 起始时间将文件内的局部时戳映射到全局呈现时间便可构成整个呈现。

应注意，贯穿本说明书对“段”的引述应被理解为包括作为文件下载协议 请求(包括例如HTTP请求)的结果完全或部分地从存储介质构造或读取或者 以其他方式获得的任何数据对象。例如，在HTTP的情形中，数据对象可被存 储在驻留于连接到HTTP服务器或构成HTTP服务器一部分的盘或其他存储介 质上的实际文件中，或者数据对象可由响应于HTTP请求而执行的CGI脚本或 其他动态地执行的程序来构造。除非另行指出，否则术语“文件”和“段”在 本文中同义地使用。在HTTP的情形中，段可被视为HTTP请求响应的实体主 体。

术语“呈现”和“内容项”在本文中同义地使用。在许多示例中，呈现是 具有定义的“播出”时间的音频、视频或其他媒体呈现，但其他变型也是可能 的。

除非另行指出，否则术语“块”和“片断”在本文中同义地使用且一般指 代有索引的最小的数据聚集。基于可用的索引法，客户端可在不同的HTTP请 求中请求片断的不同部分，或者可在一个HTTP请求中请求一个或更多个连贯 片断或片断部分。在其中使用基于ISO基媒体文件格式的段或基于3GP文件 格式的段的情形中，片断典型地指代定义为电影片断头部(‘moof’)包和媒 体数据(‘mdat’)包的组合的电影片断。

在本文中，为了简化本文中的描述而假定携带数据的网络是基于分组的， 在阅读本公开之后应认识到，本领域技术人员能将本文中描述的本发明的实施 例应用于其他类型的传输网络，诸如连续比特流网络。

在本文中，为了简化本文中的描述而假定由FEC码提供对抗数据投递时 间长且可变这一问题的保护，在阅读本公开之后应认识到，本领域技术人员能 将本发明的实施例应用于其他类型的数据传输问题，诸如数据的比特翻转讹 误。例如，在没有FEC的情况下，若所请求片断的最后部分比该片断的先前 部分晚到很久或者其抵达时间有很大变动，则内容换台时间可能是长且可变 的，而在使用FEC和并行请求的情况下，仅需要针对片断所请求的数据的大 半抵达后就能恢复该片断，藉此减少了内容换台时间以及内容换台时间上的可 变性。在本描述中，可假定待编码数据(即，源数据)已被分解成可以具有有 任何长度(小至单个比特)的等长“码元”，但对于数据的不同部分而言，码 元可以具有不同长度，例如，可对不同的数据块使用不同的码元大小。

在本描述中，为了简化本文中的描述，假定每次向数据“块”或“片断” 应用FEC，即“块”是用于FEC编码和解码目的的“源块”。客户端设备可 使用本文中描述的段索引法来帮助确定段的源块结构。本领域技术人员可将本 发明的实施例应用于其他类型的源块结构，例如源块可以是片断的一部分，或 者可涵盖一个或更多个片断或片断部分。

考虑与块请求流送联用的FEC码典型情况下是系统FEC码，即源块的源 码元可作为该源块的编码的一部分被包括，并且因此源码元被传送。如本领域 技术人员将认识到的，本文中描述的实施例也等同地适用于非系统的FEC码。 系统FEC编码器从由源码元构成的源块生成一定数目的修复码元，且源码元 和修复码元中的至少一些的组合便是在信道上发送的表示源块的经编码码元。 一些FEC码对于高效地生成如所需的那么多的修复码元而言可能是有用的， 诸如“信息加性码”或“喷泉码”，且这些码的示例包括“链式反应码”和“多 级链式反应码”。诸如Reed-Solomon码之类的其他FEC码可能实际上仅为每 个源块生成有限数目的修复码元。

在这些示例中的许多示例中假定客户端耦合到媒体服务器或多个媒体服 务器，且客户端在信道或多个信道上向该媒体服务器或该多个媒体服务器请求 流送媒体。然而，更复杂的安排也是可能的。

益处示例

通过块请求流送，媒体客户端维护这些块请求的时基与向用户进行媒体播 出的时基之间的耦合。该模型可留存以上描述的“下载”模型的优点，同时避 免源于媒体播出与媒体投递之间通常为解耦的一些缺点。该块请求流送模型利 用诸如TCP之类的传输协议中可用的速率和拥塞控制机制来确保最大可用带 宽被用于媒体数据。另外，将媒体呈现分成块允许从一组多种可用编码中选择 每个经编码媒体数据块。

该选择可基于任何数目个准则，包括媒体数据率与可用带宽的匹配——即 使在可用带宽随时间改变时亦然，媒体分辨率或解码复杂性与客户端能力或配 置的匹配，或者与诸如语言之类的用户偏好的匹配。该选择还可包括对辅助分 量的下载和呈现，诸如可访问性分量、隐藏字幕、字幕、手语视频等。使用块 请求流送模型的现有系统的示例包括移动网络(Move Network^TM)、微软流畅 流送(Microsoft Smooth Streaming)以及苹果iPhone^TM流送协议。

通常，每个媒体数据块可作为个体文件存储在服务器上，且随后使用诸如 HTTP之类的协议协同在服务器上执行的HTTP服务器软件将该文件作为单位 来请求。典型地，向客户端提供元数据文件，元数据文件例如可以为可扩展标 记语言(XML)格式或播放列表文本格式或二进制格式，元数据文件描述了在 本文档中通常称为“表示”的媒体呈现的特征，诸如可用编码(例如，要求的 带宽、分辨率、编码参数、媒体类型、语言)，以及将编码划分成块的方式。 例如，元数据可包括每个块的统一资源定位符(URL)。URL本身可提供诸如 以串“http://”来前缀以指示将用于访问此记载的资源的协议是HTTP的方案。 另一示例是“ftp://”以指示将使用的协议是FTP。

在其他系统中，例如可由服务器响应于来自客户端的以时间指示媒体呈现 中被请求的部分的请求“在运行中”构造媒体块。例如，在使用方案“http://” 的HTTP情形中，对该URL的请求的执行提供请求响应，在该请求响应的实 体主体中包含一些特定数据。在网络中关于如何生成该请求响应的实现可能是 十分不同的，这取决于服务此类请求的服务器的实现。

典型地，每个块可以是能独立解码的。例如，在视频媒体的情形中，每个 块可始于“查找点”。在一些编码方案中，查找点被称为“随机访问点”或即 “RAP”，尽管并非所有RAP都会被指定为查找点。类似地，在其他编码方 案中，查找点在H.264视频编码的情形中始于“独立数据刷新”帧或即“IDR”， 尽管并非所有IDR都会被指定为查找点。查找点是视频(或其他)媒体中解码 器不需要关于先前帧或数据或样本的任何数据就能开始解码的位置，而正被解 码的帧或样本不是以自立方式而是例如作为当前帧与先前帧之间的差异来编 码的情形可能就是需要关于先前帧或数据或样本的数据的情形。

此类系统中的关注点可能是开始播出流的能力，例如使用个人计算机来解 码和渲染收到的音频和视频流并在计算机屏幕上显示该视频以及通过内置扬 声器播放该音频，或者作为另一示例，使用机顶盒来解码和渲染收到的音频和 视频流并在电视显示设备上显示该视频以及通过立体声系统播放该音频。主要 关注点可能是使在用户决定观看作为流来投递的新内容并采取表达该决定的 行动(例如，用户点击浏览器窗口内的链接或遥控设备上的播放按钮)的时间 与内容开始在用户的屏幕上播放的时间之间的延迟(下文中称为“内容换台时 间”)最小化。这些关注点中的每一个均可由本文中描述的增强型系统的元素 来解决。

内容换台的示例是用户正观看经由第一流来投递的第一内容，并且随后该 用户决定观看经由第二流来投递的第二内容并发起开始观看第二内容的行动。 第二流可以是从与第一流相同或不同的一组服务器发送的。内容换台的另一示 例是用户正访问网站并通过点击浏览器窗口内的链接来决定开始观看经由第 一流投递的第一内容。以类似方式，用户可能决定并非从头，而是从流内的某 个时间开始播放内容。用户指示其客户端设备查找时间位置并且用户可能期望 所选择的时间被立刻渲染。使内容换台时间最小化对于视频观看而言是重要 的，其允许用户在搜索和取样很广范围的可用内容时获得高质量的快速内容冲 浪体验。

近期，考虑使用前向纠错(FEC)码在传输期间保护流送媒体已成为惯例。 当在分组网络(其示例包括因特网和诸如由诸如3GPP、3GPP2和DVB之类的 群体标准化的那些无线网络)上发送时，源流在被生成或变为可用时被放入分 组中，且因此这些分组可用来将源或内容流按其被生成或变为可用的次序携至 接收机。

在向这些类型的场景应用FEC码的典型情形中，编码器可使用FEC码来 创建修复分组，随后将这些修复分组作为包含源流的原始源分组的补充来发 送。修复分组具有以下性质：当发生源分组丢失时，可使用接收到的修复分组 来恢复丢失的源分组中包含的数据。修复分组可被用来恢复完全丢失的丢失源 分组的内容，但也可被用来从部分分组丢失中恢复，这些恢复或者是从完全接 收到的修复分组或者甚至是从部分接收到的修复分组来进行的。因此，可以使 用整体或部分接收到的修复分组来恢复整体或部分丢失的源分组。

在其他示例中，所发送的数据可能发生其他类型的讹误，例如比特值可能 翻转，并且因此修复分组可被用来纠正此类讹误并提供对源分组尽可能准确的 恢复。在其他示例中，源流不一定以分立的分组来发送，而是可代之以例如作 为连续比特流来发送。

存在可用于提供对源流的保护的FEC码的许多示例。Reed-Solomon码是 公知的用于在通信系统中进行差错和擦除纠正的码。对于例如分组数据网络上 的擦除纠正，Reed-Solomon码的公知高效实现使用如在L.Rizzo的“Effective  Erasure Codes for Reliable Computer Communication Protocols(用于可靠的计算 机通信协议的有效擦除码)”，计算机通信评论27(2)：24-36(1997年4月)(下 文称为“Rizzo”)以及Bloemer等人的“An XOR-Based Erasure-Resilient Coding  Scheme(基于异或的擦除回弹编码方案)”，技术报告TR-95-48，国际计算 机科学协会，加利福尼亚州伯克利市(1995年)(下文称为 “XOR-Reed-Solomon”)中或别处描述的柯西(Cauchy)或范德蒙 (Vandermonde)矩阵。

FEC码的其他示例包括LDPC码、诸如Luby I中描述的那些之类的链式 反应码、以及诸如Shokrollahi I中的多级链式反应码。

用于Reed-Solomon码的变体的FEC解码过程的示例在Rizzo和 XOR-Reed-Solomon中描述。在那些示例中，解码可在已接收到充分的源数据 分组和修复数据分组之后应用。解码过程可能是计算密集的，且取决于可用的 CPU资源，解码过程可能要花费与块中的媒体所跨越的时间长度成比例的相当 多的时间来完成。接收机在演算开始接收媒体流与播出该媒体之间所需的延迟 时可以计及解码所需的该时间长度。由于解码造成的该延迟被用户感知为其对 特定媒体流的请求与开始回放之间的延迟。因此希望使该延迟最小化。

在许多应用中，分组可被进一步细分成对其应用FEC过程的码元。分组 可包含一个或更多个码元(或者不足一个码元，但通常码元不会被跨分组群拆 分，除非已知分组群之间的差错条件是高度相关的)。码元可具有任何大小， 但码元的大小往往至多等于分组的大小。源码元是编码要传送的数据的那些码 元。修复码元是直接或间接地从源码元生成的作为源码元的补充的码元(即， 若全部源码元都可用且没有任何修复码元可用，也能完全恢复出要传送的数 据)。

一些FEC码可以是基于块的，因为编码操作取决于块中的码元并且可独 立于不在该块中的码元。通过基于块的编码，FEC编码器可从块中的源码元生 成该块的修复码元，随后继续前往下一个块且无需参考除了正被编码的当前块 的源码元以外的其他源码元。在传输中，包括源码元的源块可由包括经编码码 元(其可以是一些源码元、一些修复码元或两者)的经编码块来表示。在存在 修复码元的情况下，在每个经编码块中，并非所有源码元都是需要的。

对于一些FEC码，特别是Reed-Solomon码，编码和解码时间可能会随着 每源块的经编码码元数目的增长而增长到不切实际的地步。因此，在实践中， 每源块能生成的经编码码元总数往往存在切合实际的上限(255是一些应用的 大致的切合实际的上限)，尤其是在由定制硬件执行Reed-Solomon编码或解 码过程的典型情形中，例如，使用作为DVB-H标准的一部分被包括的 Reed-Solomon码来保护流以对抗分组丢失的MPE-FEC过程是在蜂窝电话内的 专门硬件中实现的，其限于每源块总共有255个Reed-Solomon经编码码元。 由于往往要求将码元放入分开的分组有效载荷中，因此这对正被编码的源块的 最大长度设置了切合实际的上限。例如，若分组有效载荷限于1024字节或更 少且每个分组携带一个经编码码元，则经编码源块可至多为255千字节，并且 这对于源块本身的大小当然也是上限。

诸如能够足够快地解码源块以跟上源流送速率、使由FEC解码引入的解 码等待时间最小化、以及在FEC解码期间的任何时间点仅使用接收设备上可 用CPU的一小部分等其他关注点由本文中描述的元素来解决和应付。

需要提供稳健和可伸缩的流送投递解决方案，其允许系统的组件发生故障 而不会不利地影响投递给接收机的流的质量。

块请求流送系统需要支持对呈现的结构或元数据的改变，例如对可用媒体 编码的数目的改变或是对媒体编码的参数(诸如比特率、分辨率、纵横比、音 频或视频编解码器或编解码参数)的改变，或是对诸如URL之类的与内容文 件相关联的其他元数据的改变。此类改变可能是出于多个原因而必需的，包括 将较大呈现的诸如广告或不同段之类的来自不同源的内容编辑在一起，作为例 如由于配置改变、装备故障或从装备故障恢复或其他原因造成的服务基础设施 改变的结果而变得必要的对URL或其他参数的修改。

存在可由持续更新的播放列表文件来控制呈现的方法。由于该文件被持续 更新，因此以上描述的至少一些改变能在这些更新中作出。常规方法的缺点在 于客户端设备必须不断地检索(也称为“轮询”)播放列表文件，从而对服务 基础设施造成负荷，并且该文件可能没有被高速缓存得比更新间隔更久，从而 使得服务基础设施的任务困难得多。这由本文中的元素来解决，从而在无需由 客户端对元数据文件进行不断轮询的情况下提供以上描述的这种的更新。

典型地从广播分发中知晓的尤其存在于实况服务中的另一问题是缺乏供 用户观看在比用户加入节目的时间早时广播的内容的能力。典型地，本地个人 录制消耗不必要的本地存储，或者在客户端没有调谐到该节目或受到内容保护 条例禁止时不可能进行本地个人录制。网络录制和时移观看是优选的，但要求 用户与服务器的个体连接以及与实况服务分开的投递协议和基础设施，从而造 成重复的基础设施和显著的服务器成本。这也由本文中描述的元素来解决。

系统概览

参照图1描述本发明的一个实施例，图1示出了实施本发明的块请求流送 系统的简化图。

在图1中，解说了块流送系统100，其包括块供应基础设施(“BSI”) 101，BSI 101又包括摄取系统103，其用于摄取内容102、制备该内容并将其 打包以通过将其存储在摄取系统103和HTTP流送服务器104两者均可访问的 内容存储110中来由HTTP流送服务器104供应。如图所示，系统100还可包 括HTTP高速缓存106。在操作中，诸如HTTP流送客户端之类的客户端108 向HTTP流送服务器104发送请求112并从HTTP流送服务器104或HTTP高 速缓存106接收响应114。在每种情形中，图1中所示的元素可至少部分地在 软件中实现，其中包括在处理器或其他电子器件上执行的程序代码。

内容可包括电影、音频、2D平面视频、3D视频、其他类型的视频、图像、 定时文本、定时元数据或类似物。一些内容可涉及要以定时方式呈现或消费的 数据，诸如用于随正被播出的其他媒体一起呈现辅助信息(台标识、广告、股 价、Flash^TM序列等)的数据。也可以使用组合其他媒体和/或超越仅音频和视 频的其他混合呈现。

如图2中所示，媒体块可被存储在块供应基础设施101(1)内，其可以是例 如HTTP服务器、内容投递网络设备、HTTP代理、FTP代理或服务器、或其 他某种媒体服务器或系统。块供应基础设施101(1)连接到网络122，网络122 可以是例如诸如因特网之类的网际协议(“IP”)网络。块请求流送系统客户 端被示为具有6个功能组件，即：块选择器123，其被提供以上描述的元数据 并执行从由该元数据指示的多个可用块之中选择要请求的块或部分块的功能； 块请求器124，其接收来自块选择器123的请求指令并执行在网络122上向块 供应基础设施101(1)发送对指定块、块的部分、或多个块的请求以及接收包括 该块的数据作为回复所必要的操作；以及块缓冲器125；缓冲监视器126；媒 体解码器127；以及促成媒体消费的一个或更多个媒体换能器128。

由块请求器124接收到的块数据被传递到存储媒体数据的块缓冲器125 进行临时存储。替换地，接收到的块数据可如图1中所示地被直接存储到块缓 冲器125中。媒体解码器127由块缓冲器125来提供媒体数据并对该数据执行 向媒体换能器128提供合适的输入所必要的变换，媒体换能器128以适合用户 或其他消费的形式来渲染该媒体。媒体换能器的示例包括诸如存在于移动电 话、计算机系统或电视中的那些之类的视觉显示设备，并且还可包括诸如扬声 器或头戴式送受话器之类的音频渲染设备。

媒体解码器的示例可以是将在H.264视频编码标准中描述的格式的数据 变换成视频帧的模拟或数字表示(诸如每一帧或样本有相关联的呈现时戳的 YUV格式像素映射)的功能。

缓冲监视器126接收关于块缓冲器125的内容的信息，并且基于该信息以 及可能还有其他信息向块选择器123提供输入，该输入被用来确定对要请求的 块的选择，如本文中所描述的。

在本文中使用的术语中，每个块具有“播出时间”或“历时”，其表示接 收机以正常速度播放该块中所包括的媒体要花的时间量。在一些情形中，块内 的媒体的播出可能依赖于已接收到来自先前块的数据。在罕见的情形中，块中 的一些媒体的播出可能依赖于后续块，在这种情形中，块的播出时间是参照该 块内不参照后续块就能播出的媒体来定义的，且后续块的播出时间增大该块内 只能在已接收到该后续块之后才能播出的媒体的播出时间。由于在块中包括依 赖于后续块的媒体是罕见的情形，因此在本公开的其余部分中，假定一个块中 的媒体不依赖于后续块，但是应注意，本领域技术人员将认识到这种变形可被 轻易地添加到以下描述的实施例。

接收机可具有诸如“暂停”、“快进”、“倒退”等控制，这些控制可导 致块通过以不同速率播放来被消费，但是若接收机能获得并解码每个连贯的块 序列的集总时间等于或少于排除该序列中的最末块情况下的集总播放时间，则 接收机能不停滞地向用户呈现该媒体。在本文中的一些描述中，媒体流中的特 定位置被称为该媒体中的特定“时间”，其对应于媒体播出的开始与到达视频 流中的该特定位置的时间之间会流逝的时间。媒体流中的时间或位置是常规概 念。例如，在视频流包括24帧每秒的场合，第一帧可以被称为具有t＝0.0秒的 位置或时间，且第241帧可被称为具有t＝10.0秒的位置或时间。自然，在基于 帧的视频流中，位置或时间无需是连续的，因为该流中从第241帧的第一比特 直至第242帧的第一比特之前的每个比特可以全都具有相同的时间值。

采用以上术语，块请求流送系统(BRSS)包括向一个或更多个内容服务 器(例如，HTTP服务器、FTP服务器等)作出请求的一个或更多个客户端。 摄取系统包括一个或更多个摄取处理器，其中摄取处理器(实时地或非实时地) 接收内容，处理该内容以供BRSS使用并将该内容以及可能还连同由摄取处理 器生成的元数据一起存储在内容服务器可访问的存储中。

BRSS还可包含与内容服务器协作的内容高速缓存。内容服务器和内容高 速缓存可以是常规的HTTP服务器和HTTP高速缓存，它们接收包括URL的 HTTP请求形式的对文件或段的请求，并且这些请求还可包括字节范围以请求 不足由该URL指示的文件或段的全部。客户端可包括常规的HTTP客户端， 其作出对HTTP服务器的请求并且处置对这些请求的响应，其中HTTP客户端 由编制请求、将它们传递给HTTP客户端、获取来自HTTP客户端的响应并处 理这些响应(或存储、变换等)以将它们提供给呈现播放器供客户端设备播出 的新颖客户端系统驱动。典型地，客户端系统事先并不知道将需要什么媒体(因 为该需要可能取决于用户输入、用户输入的改变等)，因此其被称为“流送” 系统，因为媒体是一旦被接收到或此后不久就被“消费”的。结果，响应延迟 和带宽约束可能导致呈现的延迟，诸如当流追赶用户正消费该呈现时所在之处 时造成呈现的暂停。

为了提供被感知为有良好质量的呈现，可在BRSS中在客户端或在摄取端 或在这两者处实现多个细节。在一些情形中，所实现的细节是考虑并为应对网 络上的客户端-服务器接口来进行的。在一些实施例中，客户端系统和摄取系 统两者皆知晓该增强，而在其他实施例中，仅一侧知晓该增强。在此类实施例 中，即使一侧并不知晓该增强，整个系统也会受益于该增强，而在其他实施例 中，该效益仅在两侧皆知晓该增强的情况下才发生，但在一侧不知晓时，其仍 无故障地操作。

如图3中解说的，根据各种实施例，摄取系统可实现为硬件与软件组件的 组合。摄取系统可包括可被执行以导致系统执行本文中讨论的任何一种或更多 种方法的指令集。该系统可实现为计算机形式的专门机器。该系统可以是服务 器计算机、个人计算机(PC)、或能够执行指定要由该系统采取的行动的指令 集(顺序或以其他方式)的任何系统。此外，虽然仅示出了单个系统，但是术 语“系统”还应被视为包括任何系统集合，这些系统个体地或联合地执行指令 集(或多个指令集)以执行本文中所讨论的任何一种或更多种方法。

摄取系统可包括摄取处理器302(例如，中央处理单元(CPU))、可存 储执行期间的程序代码的存储器304、以及盘存储306，所有这些均经由总线 300彼此通信。该系统可进一步包括视频显示单元308(例如，液晶显示器(LCD) 或阴极射线管(CRT))。该系统还可包括字母数字输入设备310(例如，键 盘)、以及用于接收内容源并投递内容存储的网络接口设备312。

盘存储单元306可包括其上可存储实施本文中所描述的任何一个或更多 个方法或功能的一个或更多个指令集(例如，软件)的机器可读介质。这些指 令在其被系统执行期间还可完全或至少部分地驻留在存储器304内和/或摄取 处理器302内，其中存储器304和摄取处理器302也构成机器可读介质。

如图4中解说的，根据各种实施例，客户端系统可实现为硬件与软件组件 的组合。客户端系统可包括能被执行以导致系统执行本文中讨论的任何一种或 更多种方法的指令集。该系统可实现为计算机形式的专门机器。该系统可以是 服务器计算机、个人计算机(PC)、或能够执行指定要由该系统采取的行动的 指令集(顺序或以其他方式)的任何系统。此外，虽然仅示出了单个系统，但 是术语“系统”还应被视为包括任何系统集合，这些系统个体地或联合地执行 指令集(或多个指令集)以执行本文中所讨论的任何一种或更多种方法。

客户端系统可包括客户端处理器402(例如，中央处理单元(CPU))、 可存储执行期间的程序代码的存储器404、以及盘存储406，所有这些均经由 总线400彼此通信。该系统可进一步包括视频显示单元408(例如，液晶显示 器(LCD)或阴极射线管(CRT))。该系统还可包括字母数字输入设备410 (例如，键盘)、以及用于发送请求并接收响应的网络接口设备412。

盘存储单元406可包括其上可存储实施本文中所描述的任何一个或更多 个方法或功能的一个或更多个指令集(例如，软件)的机器可读介质。这些指 令在其被系统执行期间还可完全或至少部分地驻留在存储器404内和/或客户 端处理器402内，其中存储器404和客户端处理器402也构成机器可读介质。

3GPP文件格式的使用

3GPP文件格式或基于ISO基媒体文件格式(诸如MP4文件格式或3GPP2 文件格式)的任何其他文件可被用作具有以下特征的用于HTTP流送的容器格 式。每个段中可包括段索引以信令通知时间偏移量和字节范围，以使得客户端 能下载如所需的恰适文件片或媒体段。整个媒体呈现的全局呈现时基和每个 3GP文件或媒体段内的局部时基可准确地对准。一个3GP文件或媒体段内的 各个轨迹可被准确地对准。跨各个表示的各个轨迹也可通过将它们之中的每个 指派到全局时间线来对准，以使得跨表示的切换可以是无缝的，并且不同表示 中的媒体分量的联合呈现可以同步。

文件格式可包含具有以下性质的用于自适应流送的简档。所有电影数据可 被包含在电影片断中——“moov”包可以不包含任何样本信息。音频和视频样 本数据可以按与如TS26.244中规定的对渐进式下载简档的要求类似的要求来 被交织。“moov”包可被放在文件开头处，继之以也被称为段索引的片断偏移 量数据，其包含该包容段中的每个片断或者至少片断子集的时间偏移量信息以 及字节范围。

还有可能使媒体呈现描述引用跟随在存在的渐进式下载简档之后的文件。 在这种情形中，客户端可使用媒体呈现描述简单地从多个可用版本之中选择恰 适的替换版本。客户端也可对顺应于渐进式下载简档的文件使用HTTP部分获 取请求以请求每个替换版本的子集并藉此实现效率略低的形式的自适应流送。 在这种情形中，包含渐进式下载简档中的媒体的不同表示仍可遵守共同的全局 时间线以使得能够进行跨表示的无缝切换。

高级方法概览

在以下小节中，描述了用于改进的块请求流送系统的方法。应理解，这些 改进中的一些改进可在有或没有这些改进中的其他改进的情况下使用，这取决 于应用的需要。在一般操作中，接收机向服务器或其他发射机作出对特定数据 块或数据块部分的请求。也被称为段的文件可包含多个块并且与媒体呈现的一 个表示相关联。

优选地，生成也被称为“段索引”或“段映射”的索引信息，其提供从播 出或解码时间至段内相应的块或片断的字节偏移量的映射。该段索引可被包括 在段内，典型地在段开头处(至少一些段映射在开头处)且往往很小。段索引 也可被设在单独的索引段或文件中。尤其是在段索引被包含在该段中的情形 中，接收机可迅速下载此段映射的一些或全部，并随后将其用来确定时间偏移 量与文件内同这些时间偏移量相关联的片断的相应字节位置之间的映射。

接收机可使用字节偏移量来请求来自与特定时间偏移量相关联的片断的 数据，而不必下载与同感兴趣的时间偏移量无关联的其他片断相关联的全部数 据。以此方式，段映射或段索引能极大地增进接收机直接访问段中与感兴趣的 当前时间偏移量有关的部分的能力，其效益包括改善的内容换台时间、在网络 条件变化时从一个表示迅速换到另一表示的能力、以及减少浪费网络资源来下 载没有在接收机处播出的媒体。

在考虑从一个表示(本文中称为“切换自”的表示)切换到另一表示(本 文中称为“切换到”的表示)的情形中，还可使用段索引来标识“切换到”的 表示中的随机访问点的开始时间，从而标识在“切换自”的表示中要请求以确 保无缝切换的数据量，此无缝切换的意义是指“切换自”的表示中的媒体被下 载到直至使得对“切换到”的表示的播出能从该随机访问点无缝地开始的呈现 时间。

这些块代表请求方接收机为了生成给该接收机的用户的输出所需要的视 频媒体或其他媒体的段。媒体的接收机可以是客户端设备，诸如当接收机从传 送内容的服务器接收内容时。示例包括机顶盒、计算机、游戏机、特殊装备的 电视、手持设备、特殊装备的移动电话、或其他客户端接收机。

本文中描述了许多高级的缓冲管理方法。例如，缓冲管理方法使得客户端 能请求可及时接收以连续播出的具有最高媒体质量的块。可变块大小特征提高 了压缩效率。具有多个连接以用于向请求方设备传送块而同时限制请求频度的 能力提供了改善的传输性能。部分收到的数据块可被用来继续媒体呈现。可以 为多个块重用连接而不必在一开始就承诺由该连接负责特定的一组块。改善了 由多个客户端从多个可能的服务器之中选择服务器的一致性，这减少了近旁服 务器中内容重复的频度并且提高了服务器包含整个文件的概率。客户端可基于 嵌入在关于包含媒体块的文件的URL中的元数据(诸如可用媒体编码)来请 求这些媒体块。系统可提供对在能开始内容播而不会在媒体播出中招致后续暂 停之前所需的缓冲时间量的演算和最小化。可以在多个媒体块之间共享可用带 宽，随着每个块的播出时间逼近而进行调节，从而在必要的情况下较大份额的 可用带宽可有倾向性地被分配给具有最接近播出时间的块。

HTTP流送可采用元数据。呈现级元数据包括例如流历时、可用编码(比 特率、编解码器、空间分辨率、帧率、语言、媒体类型)、指向每种编码的流 元数据的指针、以及内容保护(数字版权管理(DRM)信息)。流元数据可以 是关于段文件的URL。

段元数据可包括字节范围对时间信息以用于段内请求以及标识随机访问 点(RAP)或其他查找点，其中该信息中的一些或全部可以是段索引或段映射 的一部分。

流可包括对相同内容的多种编码。每种包括随后可被分解成段，其中每一 段对应于存储单位或文件。在HTTP的情形中，段典型地是能由URL引用的 资源，并且对此类URL的请求导致返回该段作为请求响应消息的实体主体。 段可包括多个画面群(GoP)。每个GoP可进一步包括多个片断，其中段索引 提供关于每个片断的时间/字节偏移量信息，即索引的单位是片断。

可通过并行的TCP连接来请求片断或片断部分以提高吞吐量。这可以缓 解在共享瓶颈链路上的连接时或者在连接由于拥塞而丢失时产生的问题，由此 提高投递的总体速度和可靠性，这能明显改善内容换台时间的速度和可靠性。 可以藉由过度请求用带宽换等待时间，但是应注意避免作出对太远的将来的请 求，这会增加匮乏风险。

对相同服务器上的段的多个请求可被管线化(在当前请求完成之前作出下 一请求)以避免反复的TCP启动延迟。对连贯片断的请求可被聚集成一个请 求。

一些CDN偏好大文件并且可在首次看到范围请求时触发从原始服务器来 后台取回整个文件。然而，绝大多数CDN将从高速缓存来服务范围请求—— 若数据可用。因此，使客户端请求的某个部分针对整个段文件可能是有利的。 若有必要，这些请求可在以后被取消。

有效切换点可以是目标流中的查找点，具体而言例如是RAP。不同的实 现是可能的，诸如固定GoP结构或跨流的RAP对准(基于媒体的开头或基于 GoP)。

在一个实施例中，段和GoP可跨不同速率的流对准。在该实施例中，GoP 可具有可变大小并且可包含多个片断，但片断在这些不同速率的流之间并不对 准。

在一些实施例中，可有利地采用文件冗余性。在这些实施例中，对每个片 断应用擦除码以生成该数据的冗余版本。优选地，源格式化不因使用FEC而 改变，且可作为摄取系统中的附加步骤生成包含FEC修复数据的例如作为源 表示的从属表示的附加修复段并使其可用。仅使用片断的源数据就能够重构该 片断的客户端可仅向服务器请求该段内的该片断的源数据。若服务器不可用或 者与服务器的连接较慢——这可能是在请求源数据之前或之后确定的，则可请 求来自修复段的关于该片断的附加修复数据，这减少了用于可靠地投递足以恢 复该片断的数据的时间，从而有可能使用FEC解码以使用收到的源数据和修 复数据的组合来恢复该片断的源数据。此外，若片断变得紧急，即其播出时间 变得迫近，则可以请求附加修复数据以允许恢复该片断，这增加了链路上用于 该片断的数据份额，但比关掉该链路上的其他连接以释放带宽更高效。这还可 以缓解由于使用并行连接造成的匮乏风险。

片断格式可以是存储着的具有通过实时传输控制协议RTCP达成的音频/ 视频同步的实时传输协议(RTP)分组流。

段格式也可以是存储着的具有通过MPEG-2 TS内部时基达成的音频/视频 同步的MPEG-2 TS分组流。

使用信令和/或块创建来使流送更高效

在块请求流送系统中可以使用或不使用数种特征以提供改善的性能。性能 可涉及不停滞地播出呈现、在带宽约束内获得媒体数据、和/或在客户端、服务 器和/或摄取系统处有限的处理器资源内这样做的能力。现在将描述这些特征中 的一些。

段内的索引

为了编制对电影片断的部分获取请求，可向客户端告知文件或段内的片断 中所包含的所有媒体分量在解码或呈现时间的字节偏移量和开始时间、以及还 有哪些片断始于或包含随机访问点(且因此适合用作替换表示之间的切换点)， 其中该信息往往被称为段索引或段映射。在解码或呈现时间的开始时间可直接 表达或者可表达为相对于参考时间的Δ。

该时间和字节偏移量索引信息可能每电影片断需要至少8字节数据。作为 示例，对于具有500ms电影片断的单个文件内所包含的2小时电影，这将会是 总共约112千字节数据。在开始呈现时下载该数据的全部可能导致显著的附加 启动延迟。然而，该时间和字节偏移量数据可被阶层式编码，从而客户端能迅 速找到与呈现中希望开始的点有关的小时间块和偏移量数据。该信息也可分布 在段内，以使得对段索引的某种细化可与媒体数据交织地放置。

注意，若表示是按时间分段成多个段的，则使用该阶层式编码可能是不必 要的，因为每个段的完整的时间和偏移量数据可能已经十分小。例如，若段是 一分钟而非以上示例中的2小时，则时间-字节偏移量索引信息约为1千字节 数据，其通常可装进单个TCP/IP分组内。

有不同选项可能用于向3GPP文件添加片断时间和字节偏移量数据：

首先，可出于此目的使用电影片断随机访问包(“MFRA”)。MFRA提 供表，其可辅助读者使用电影片断来寻找文件中的随机访问点。为支持该功能， MFRA顺带地包含带有随机访问点的MFRA包的字节偏移量。MFRA可被放 在文件末尾处或附近，但并非必需如此。通过从文件末尾扫描电影片断随机访 问偏移量包并使用其中的大小信息，就能够定位到电影片断随机访问包的开 头。然而，将MFRA放在末尾来进行HTTP流送典型地需要至少3到4个HTTP 请求来访问合意数据：至少一个用于从文件末尾请求MFRA，一个用于获得 MFRA并且最后一个用于获得该文件中的合意片断。因此，放在开头可能是可 取的，因为这样就可在单个请求中与第一媒体数据一起下载mfra。另外，对 HTTP流送使用MFRA可能是效率不高的，因为“MFRA”中除了时间和moof_ 偏移量以外的其他任何信息都是不需要的，且指定偏移量而非长度可能需要更 多比特。

其次，可以使用项定位包(ILOC)。“ILOC”通过定位元数据资源的包 容文件、它们在该文件内的偏移量及其长度来提供该文件或其他文件中的元数 据资源的目录。例如，系统可将所有被外部引用的元数据资源整合到一个文件 中，相应地重新调整文件偏移量和文件引用。然而，“ILOC”旨在给出元数 据的位置，因此可能很难使其与真正的元数据共存。

最后且可能最适合的是规定称为时间索引包(“TIDX”)的新包，其专 用于以高效方式提供确切的片断时间或历时以及字节偏移量。这在下节中更详 细地描述。具有相同功能性的替换包可以是段索引包(“SIDX”)。在本文 中，除非另行指出，否则这两者可以是可互换的，因为两种包皆提供了以高效 方式提供确切的片断时间或历时以及字节偏移量的能力。以下提供TIDX与 SIDX之间的差异。如何互换TIDX包和SIDX包应当是明显的，因为这两种 包均实现段索引。

段索引

段具有标识出的开始时间和标识出的字节数。多个片断可被级联成单个 段，且客户端可发出标识该段内与所请求的片断或片断子集相对应的具体字节 范围的请求。例如，在使用HTTP作为请求协议时，HTTP范围头部可用于此 目的。该办法要求客户端能访问该段的“段索引”，其指定不同片断在该段内 的位置。该“段索引”可作为元数据的一部分来提供。该办法具有以下结果： 与在每个块被保持在单独的文件中的办法相比，需要创建和管理的文件少得 多。对创建、传递和存储非常大量的文件(比如说对于1小时呈现，其可延伸 到好几千个文件)的管理可能是复杂的且容易出错，因此减少文件数量代表着 优点。

若客户端仅知晓段的较小部分的合意开始时间，则它可请求整个文件，随 后从头至尾读取该文件以确定恰适的播出起始位置。为了提高带宽利用率，段 可包括索引文件作为元数据，其中索引文件映射个体块的字节范围与这些块所 对应的时间范围，称为段索引或段映射。该元数据可被格式化为XML数据或 者它们可以是二进制的，例如遵循3GPP文件格式的原子和包结构。索引可以 是简单的，其中每个块的时间和字节范围相对于文件的开始是绝对的，或者它 们可以是阶层式的，其中一些块被编组成父块(且这些父块被编组成祖父块， 等等)且给定块的时间和字节范围是相对于该块的父块的时间和/或字节范围来 表达的。

示例索引映射结构

在一个实施例中，媒体流的一个表示的原始源数据可被包含在一个或更多 个在本文中被称为“媒体段”的媒体文件中，其中每个媒体段包含用于回放该 媒体的连续时间段的媒体数据，例如5分钟的媒体回放。

图6示出了媒体段的示例整体结构。在每个段内，在源段开头或遍布整个 源段，还可存在包括时间/字节偏移量段映射的索引信息。一个实施例中的时间 /字节偏移量段映射可以是时间/字节偏移量对的列表(T(0)，B(0))、(T(1)， B(1))、...、(T(i)，B(i))、...、(T(n)，B(n))，其中T(i-1)代表该段内相对于该媒体 在所有媒体段中的初始开始时间用于回放第i个媒体片断的开始时间，T(i)代 表第i个片断的结束时间(且因此代表下一片断的开始时间)，并且字节偏移 量B(i-1)是该源段内相对于该源段开头第i个媒体片断开始之处的数据的开头 的相应字节索引，且B(i)是第i个片断的相应结束字节索引(且因此是下一片 断的首个字节的索引)。若段包含多个媒体分量，则可以绝对方式为该段中的 每个分量提供T(i)和B(i)，或者它们可相对于用作参考媒体分量的另一媒体分 量来表达。

在该实施例中，源段中的片断数目为n，其中n在段与段之间可有所不同。

在另一实施例中，段索引中关于每个片断的时间偏移量可以用第一片断的 绝对开始时间以及每个片断的历时来确定。在这种情形中，段索引可以记载第 一片断的开始时间以及该段中所包括的所有片断的历时。段索引还可以仅记载 片断子集。在该情形中，段索引记载被定义为一个或更多个连贯片断的子段的 历时，该子段在包容段的末尾或在下一子段的开头处结束。

对于每个片断，还可以有指示该片断是否始于或包含查找点的值，即在某 点处，该点之后的媒体皆不依赖于该点之前的任何媒体，且因此自该片断前行 的媒体能独立于先前片断地播出。查找点一般而言是媒体中能独立于所有先前 的媒体地开始播出之处的点。图6还示出了源段的可能段索引的简单示例。在 该示例中，时间偏移量值以毫秒为单位，且因此该源段的首个片断自该媒体开 头20秒处开始，且首个片断具有485毫秒的播出时间。首个片断的开始的字 节偏移量为0，且首个片断的末尾/第二片断的开始的字节偏移量为50,245，且 因此首个片断的大小为50,245字节。若片断或子段并非始于随机访问点，但该 片断或子段中包含随机访问点，则可以给出开始时间与实际RAP时间之间的 解码时间或呈现时间差。这使得在切换到该媒体段的情形中客户端能准确地知 晓“切换自”的表示需要一直被呈现到的时间。

补充地或代替地，可以使用简单的或阶层式的索引、雏菊链索引和/或混 合索引。

由于不同轨迹的样本历时可能不是相同的(例如，视频样本可能播放33 ms，而音频样本可能持续80ms)，因此电影片断中的不同轨迹可能不是在正 好相同的时间开始和结束的，即，音频可能比视频略早或略迟开始，而在前一 片断中可能正好是相反情形以作为补偿。为避免多义性，在时间和字节偏移量 数据中指定的时戳可相对于特定轨迹来指定，且此轨迹对于每个表示可以是相 同的轨迹。通常这将是视频轨迹。这允许客户端在切换表示时能确切地标识下 一视频帧。

尽管有上述问题，但在呈现期间可注意维持轨迹时标与呈现时间之间的严 格关系，以确保流畅播出以及维持音频/视频同步。

图7解说了一些示例，诸如简单索引700和阶层式索引702。

以下提供包含段映射的包的两个具体示例，一个称为时间索引包 (‘TIDX’’)且一个称为(‘SIDX’’)。该定义遵循根据ISO基媒体文件 格式的包结构。用于此类包以定义类似句法且具有相同语义和功能性的其他设 计对于读者应当是明显的。

时间索引包

定义

包类型：‘tidx’

容器：文件

强制性的：否

数量：任何数目0或1

时间索引包可提供将文件的某些区域与呈现的某些时间区间相关联的一 组时间和字节偏移量索引。时间索引包可包括目标类型(targettype)字段，其 指示所引用的数据的类型。例如，具有目标类型“moof”的时间索引包提供在 时间和字节偏移量两者意义上对文件中所包含的媒体片断的索引。具有目标类 型“时间索引包(Time Index Box)”的时间索引包可被用来构造阶层式时间 索引，从而允许文件的用户迅速导航至该索引的所需部分。

段索引可例如包含以下句法：

语义

targettype(目标类型)：为该时间索引包引用的包数据的类型。它可以是 电影片断头部(“moof”)或时间索引包(“tidx”)。

time-reference_track_id(时间参考轨迹id)：指示指定该索引中的时间偏 移量时参照的轨迹。

number_of_elements(元素数目)：由该时间索引包索引的元素的数目。

first_element_offset(首个元素偏移量)：首个被索引的元素自该文件的开 始起的字节偏移量。

first_element_time(首个元素时间)：首个被索引的元素的开始时间，使 用由“时间参考轨迹id”标识的轨迹的媒体头部包中指定的时标。

random_access_flag(随机访问标志)：若元素的开始时间是随机访问点 则为1。否则为0。

length(长度)：被索引的元素以字节计的长度。

deltaT(ΔT)：该元素的开始时间与下一元素的开始时间之间的差量，该 时间差是由“时间参考轨迹id”标识的轨迹的媒体头部包中指定的时标的形式。

段索引包

段索引包(‘sidx’)提供对段中的电影片断和其他段索引包的紧凑索引。 段索引包中有两个循环结构。第一循环记载子段的第一样本，即由第二循环引 用的第一电影片断中的样本。第二循环提供该子段的索引。‘sidx’包的容器 是该文件或直接是段。

句法

语义：

reference_track_ID(参考轨迹ID)提供参考轨迹的轨迹ID。

track_count(轨迹计数)：接下来的循环中被索引的轨迹的数目(1或更 大)；

reference_count(参考计数)：由第二循环索引的元素的数目(1或更大)；

track_ID(轨迹ID)：其轨迹片断被包括在由该索引标识的首个电影片断 中的那个轨迹的ID；该循环中有恰好一个“轨迹ID”等于“参考轨迹ID”。

decoding_time(解码时间)：由第二循环中的第一项引用的电影片断中由 “轨迹ID”标识的轨迹中的首个样本的解码时间，以该轨迹的时标来表达(如 在该轨迹的媒体头部包的时标字段中记载的)；

reference_type(引用类型)：在设为0时指示该引用是对电影片断(‘moof’) 包的引用；在设为1时指示该引用是对段索引(‘sidx’)包的引用；

reference_offset(引用偏移量)：从继包容段索引包之后的首个字节至被 引用包的首个字节的以字节计的距离；

subsegment_duration(子段历时)：当引用是对段索引包的引用时，该字 段携带该包的第二循环中的“子段历时”字段的总和；当引用是对电影片断的 引用时，该字段携带参考轨迹中、所指示的电影片断以及直至该循环中的下一 条目记载的首个电影片断或该子段末尾(取较早者)的后续电影片断中的样本 的样本历时总和；该历时以该轨迹的时标来表达(如在该轨迹的媒体头部包的 时标字段中记载的)；

contains_RAP(包含RAP)：当引用是对电影片断的引用时，则若该电影 片断内“轨迹ID”等于“参考轨迹ID”的那个轨迹的的轨迹片断包含至少一 个随机访问点，那么该比特可为1，否则该比特设为0；当引用是对段索引的 引用时，则仅在该段索引中的任何引用的该比特被设为1时该比特才被设为1， 否则设为0；

RAP_delta_time(RAPΔ时间)：若“包含RAP”为1，则提供随机访问 点(RAP)的呈现(合成)时间，；若“包含RAP”为0则保留值0。该时间 表达为在由该条目记载的子段的首个样本的解码时间与“轨迹ID”等于“参 考轨迹ID”的轨迹中随机访问点的呈现(合成)时间之间的差量。

TIDX与SIDX之间的差异

SIDX和SIDX就索引而言提供相同的功能性。SIDX的第一循环作为补充 还提供首个电影片断的全局时基，但该全局时基也可被包含在该电影片断自身 中，其或者是绝对的或者是相对于参考轨迹的。

SIDX的第二循环实现TIDX的功能性。具体地，SIDX准许具有由“引用 类型”所指的每个索引的引用的目标的混合，而TIDX仅仅是要么只引用IDX 要么只引用MOOF。TIDX中的“元素数目”对应于SIDX中的“引用计数”， TIDX中的“时间参考轨迹ID”对应于SIDX中的“参考轨迹ID”，TIDX中 的“首个元素偏移量”对应于第二循环的首个条目中的“引用偏移量”，TIDX 中的“首个元素时间”对应于第一循环中的“参考轨迹”的“解码时间”，TIDX 中的“随机访问标志”对应于SIDX中的“包含RAP”，后者还具有额外的自 由——在SIDX中，RAP可以不一定要放在片断开始处，且因此需要“RAP_Δ 时间”，TIDX中的“长度”对应于SIDX中的“引用偏移量”，并且最后TIDX 中的ΔT对应于SIDX中的“子段历时”。因此，这两个包的功能性是等效的。

可变块大小控制和子GoP块

对于视频媒体而言，视频编码结构与供请求的块结构之间的关系可能是重 要的。例如，若每个块始于诸如随机访问点(“RAP”)之类的查找点且每个 块代表相等的视频时间段，则视频媒体中的至少一些查找点的定位是固定的且 查找点在视频编码内将以有规律的间隔出现。如视频编码领域中的技术人员公 知的，若查找点是根据视频帧之间的关系来放置的，并且具体而言若它们被放 置在与先前帧几乎没有多少共性的帧处，则压缩效率可得以提高。由此要各块 代表等量时间的要求对视频编码构成了约束，从而使得压缩可能是未臻最优 的。

希望允许视频呈现内的查找点的位置由视频编码系统来选取，而非要求查 找点位于固定位置。允许视频编码系统选取查找点得到改善的视频压缩，并且 因此使用给定的可用带宽能提供更高的视频媒体质量，从而得到改善的用户体 验。当前的块请求流送系统可能要求所有块具有相同的历时(以视频时间计)， 且每个块必须始于查找点且这因此是现有系统的缺点。

现在描述提供胜于上述系统的优点的新颖的块请求流送系统。在一个实施 例中，视频分量的第一版本的视频编码过程可被配置成选取查找点的位置以力 图优化压缩效率，但要求对查找点之间的历时有最大限度。后一个要求的确限 制了编码过程对查找点的选取且因此降低了压缩效率。然而，倘若查找点之间 的历时的最大限度不是太小(例如，大于约1秒)，则压缩效率的降低与假如 查找点要求有规律的固定位置所招致的压缩效率降低相比是微小的。此外，若 对查找点之间的历时的最大限度是几秒，则该压缩效率的降低与查找点的完全 自由定位相比一般是微乎其微的。

在包括本实施例的许多实施例中，可能有一些RAP不是查找点，即可能 有帧是两个连贯查找点之间的没有被选取为查找点的RAP，例如由于该RAP 在时间上太接近周围的查找点，或者由于该RAP之前或之后的查找点与该RAP 之间的媒体数据量太少。

媒体呈现的所有其他版本内的查找点的位置可被约束成与第一(例如，最 高媒体数据率)版本中的查找点相同。与允许编码器自由选取查找点相比，这 的确降低了这些其他版本的压缩效率。

使用查找点典型地要求帧是能独立解码的，这一般导致该帧的低压缩效 率。不被要求能独立解码的帧可参考其他帧中的数据来编码，这一般而言将使 该帧的压缩效率提高达取决于待编码帧与参考帧之间的共性量的量。对查找点 定位的高效选取优先选取与先前帧具有低共性的帧作为查找点帧，并藉此使得 由于以能独立解码的方式编码该帧招致的压缩效率惩罚最小化。

然而，帧与潜在可能的参考帧之间的共性的程度是跨该内容的不同表示而 高度相关的，因为原始内容是相同的。因此，令其他变体中的查找点与第一变 体中的查找点具有相同位置的约束对于压缩效率而言并没有带来很大差别。

查找点结构优选被用来决定块结构。优选地，每个查找点决定块的开始， 且可能存在涵盖两个连贯查找点之间的数据的一个或更多个块。由于为以良好 压缩进行编码的目的使得查找点之间的历时不是固定的，因此不要求所有块都 具有相同的播出历时。在一些实施例中，块在内容的各版本之间是对准的—— 即，若在内容的一个版本中有跨越特定帧群的块，则在该内容的另一版本中也 有跨越相同的帧群的块。内容的给定版本的各块不交迭，且内容的每个帧被包 含在每个版本的恰好一个块内。

使得能允许高效利用查找点之间的可变历时以及因此的可变历时GoP的 特征是可被包括在段中或通过其他手段提供给客户端的段索引或段映射，即， 这是可被提供的与该表示中的此段相关联的包括该呈现的每个块的开始时间 和历时的元数据。当用户已请求该呈现在段内的特定点开始时，客户端可在确 定要在哪个块开始该呈现时使用该段索引数据。若没有提供此类元数据，则呈 现仅能在内容开头或在接近合意点的随机或近似点开始(例如，通过将所请求 的起始点(以时间计)除以平均块历时以给出起始块的索引来选取起始块)。

在一个实施例中，每个块可作为单独的文件来提供。在另一个实施例中， 多个连贯块可被聚集成单个文件以构成段。在该第二实施例中，可以提供每个 版本的元数据，其包括每个块的开始时间和历时以及该块在此文件内开始处的 字节偏移量。该元数据可响应于初始协议请求而提供，即可与段或文件分开地 获得，或者可被包含在与块本身相同的文件或段内，例如位于文件开头处。如 对于本领域技术人员将清楚的，该元数据可以诸如gzip或Δ编码之类的压缩形 式或以二进制形式来编码，以减少向客户端传输该元数据所需的网络资源。

图6示出了段索引的示例，其中块具有可变大小，且其中块的范畴是部分 GoP，即一个RAP与下一个RAP之间的媒体数据的部分量。在该示例中，查 找点由RAP指示符来指示，其中RAP指示符值1指示该块始于或包含RAP 或查找点，并且其中RAP指示符0指示该块不包含RAP或查找点。在该示例 中，头三个块即字节0到157,033构成第一GoP，其具有1.623秒的呈现历时， 其呈现时间从进入内容中的20秒走到21.623秒。在该示例中，头三个块中的 第一块包括0.485秒的呈现时间，且包括该段中的媒体数据的头50,245字节。 在该示例中，块4、5和6构成第二GoP，块7和8构成第三GoP，并且块9、 10和11构成第四GoP。注意，媒体数据中可能存在没有被指定为查找点、且 因此在段映射中没有作为RAP被信令的其他RAP。

再次参照图6，若客户端或接收机想要访问始于进入媒体呈现中约22秒 的时间偏移量处的内容，则客户端可首先使用诸如以下更详细地描述的MPD 之类的其他信息来首先确定该相关媒体数据的确在该段内。客户端可例如使用 HTTP字节范围请求来下载该段的第一部分以获得段索引，其在本例中只有几 个字节。使用该段索引，客户端可确定自己应当下载的第一块是时间偏移量至 多为22秒且始于RAP、即实为查找点的首个块。在该示例中，尽管块5具有 小于22秒的时间偏移量，即其时间偏移量为21.965秒，但段索引指示块5并 非始于RAP，且由此基于段索引，客户端改为选择下载块4，因为其开始时间 至多为22秒，即其时间偏移量为21.623秒，且其始于RAP。因此，基于段索 引，客户端将作出始于字节偏移量157,034的HTTP范围请求。

假使段索引不可用，则客户端可能不得不在下载该数据之前先下载所有之 前的157,034字节的数据，导致启动时间或频道换台时间长得多，以及浪费地 下载了无用的数据。替换地，假使段索引不可用，则客户端可近似出合意数据 在该段内的开始之处，但该近似可能是不良的并且它可能错过恰适的时间且随 后需要后退，这再次增加了启动延迟。

一般而言，每个块涵盖媒体数据的一部分，该部分连同先前各块一起可由 媒体播放器播出。因此，这种成块结构以及向客户端信令通知段索引成块结构 (无论包含在段内还是通过其他手段提供给客户端)的机制能显著改善客户端 提供快速频道换台、以及在面临网络变动和中断时的无缝播出的能力。如由段 索引实现的对可变历时块以及仅涵盖GoP的部分的块的支持能显著改善流送 体验。例如，再次参照图6以及以上描述的其中客户端想要在进入呈现中约22 秒处开始播出的示例，客户端可通过一个或更多个请求来请求块4内的数据并 随后一旦该块可用就将其馈送给媒体播放器以开始回放。因此，在该示例中， 一旦在客户端处接收到块4的42,011字节，播出就开始，由此实现快速的频道 换台时间。若相反在播放将要起动之前需要客户端先请求整个GoP，则频道换 台时间将较长，因为有144,211字节的数据。

在其他实施例中，RAP或查找点也可出现在块当中，且段索引中可以有 指示该RAP或查找点在块或片断内何处的数据。在其他实施例中，时间偏移 量可以是块内的第一帧的解码时间，而非块内的第一帧的呈现时间。

图8(a)和8(b)解说了对跨多个版本或表示对准的查找点结构的可变块大小 控制的示例；图8(a)解说了在媒体流的多个版本上有对准的查找点的可变块大 小控制，而图8(b)解说了在媒体流的多个版本上有非对准的查找点的可变块大 小控制。

跨顶部以秒示出时间，且这两个表示的两个段的块和查找点以其相对于该 时间线的时基的形式从左到右示出，并且因此所示的每个块的长度与其播出时 间成比例而不是与块中的字节数目成比例。在该示例中，这两个表示的两个段 的段索引对于查找点将具有相同的时间偏移量，但查找点之间具有潜在不同数 目的块或片断，且由于每个块中的媒体数据量不同，因此块有不同的字节偏移 量。在该示例中，若客户端想要在约23秒的呈现时间处从表示1切换到表示2， 则客户端可请求直至表示1的段中的块1.2，并自块2.2起开始请求表示2的段， 且因此切换将发生在与表示1中的查找点1.2重合的呈现处，其与表示2中的 查找点2.2位于相同的时间。

如从前述内容应当清楚的，所描述的块请求流送系统并不约束视频编码要 将查找点放置在内容内的特定位置处，并且这缓解了现有系统的问题之一。

在以上描述的实施例中，组织成使得相同内容呈现的各种表示的查找点被 对准。然而，在许多情形中，优选放宽该对准要求。例如，有时是这种情形： 已使用编码工具生成不具有生成查找点对准的表示的能力的表示。作为另一示 例，内容呈现可被独立地编码成不同的表示，而不同的表示之间没有查找点对 准。作为另一示例，表示在其具有低速率且更普遍需要切换或者在其包含切换 点以支持诸如快进或倒带或快速查找之类的特技模式时可包含较多查找点。因 此，希望提供使得块请求流送系统能高效且无缝地应对跨内容呈现的各种表示 非对准的查找点的方法。

在该实施例中，跨表示的查找点的位置可能并不对准。块被构造成使得新 块始于每个查找点，且因此在呈现的不同版本的块之间可能没有对准。此类不 同表示之间非对准的查找点结构的示例在图8(b)中示出。跨顶部以秒示出时间， 且这两个表示的两个段的块和查找点以其相对于该时间线的时基的形式从左 到右示出，且因此所示的每个块的长度与其播出时间成比例而不是与块中的字 节数目成比例。在该示例中，这两个表示的两个段的段索引对于查找点将具有 潜在不同的时间偏移量，并且查找点之间也具有潜在不同数目的块或片断，且 由于每个块中的媒体数据量不同，因此块有不同的字节偏移量。在该示例中， 若客户端想要在约25秒的呈现时间处从表示1切换到表示2，则客户端可请求 直至表示1的段中的块1.3，并自块2.3起开始请求表示2的段，且因此切换将 发生在与表示2中的查找点2.3重合的呈现处，其位于表示1中块1.3的播出 当中，且因此块1.2的媒体中的一些将不被播出(尽管块1.3的没被播出的帧 的媒体数据可能已被加载到接收机缓冲器中以用于块1.3的其他被播出的帧的 解码)。

在该实施例中，块选择器123的操作可被修改以使得每当它被要求从不同 于先前所选版本的表示选择块时，其第一帧不晚于上次所选块的最末帧之后的 帧的最晚块被选取。

该最近描述的实施例可消除约束除第一版本以外的其他版本内的查找点 位置的要求，且因此提高了这些版本的压缩效率，从而对于给定的可用带宽得 到更高质量的呈现并且这是改善的用户体验。进一步的考虑是执行跨内容的多 个编码(版本)的查找点对准功能的视频编码工具可能并非普遍可用，因此该 最近描述的实施例的优点在于可以使用目前可用的视频编码工具。另一优点在 于内容的不同版本的编码可并行进行而完全无需不同版本的编码过程之间的 协调。另一优点在于内容的附加版本可在稍后的时间被编码并被添加到呈现， 而不必向编码工具提供具体查找点位置的列表。

一般而言，在画面被编码为画面群(GoP)的场合，序列中的第一画面可 以是查找点，但并非总是必需如此。

最优块划分

块请求流送系统中的一个关注问题是例如视频媒体之类的经编码媒体的 结构与用于块请求的块结构之间的交互。如视频编码领域中的技术人员将知晓 的，往往是这种情形：每个视频帧的经编码表示所需的比特数目有时实际上逐 帧变化。因此，收到数据量与由该数据编码的媒体历时之间的关系可能不是直 截了当的。此外，在块请求流送系统内将媒体数据分成块增加了进一维的复杂 性。具体而言，在一些系统中，块的媒体数据可能在整个块被接收到之前不会 被播出，例如，使用擦除码的块内的媒体数据布局或者块内的媒体样本之间的 依存性就可能导致这种性质。由于块大小与块历时之间的这些复杂交互以及可 能需要在开始播出之前接收整个块，因此客户端系统通常采纳保守办法，其中 在播出开始之前缓冲媒体数据。此类缓冲导致频道换台时间很长并且因此用户 体验不良。

Pakzad描述了“块划分方法”，这些方法是基于数据流的底层结构来决 定如何将数据流划分成毗连块的新颖且高效的方法，且Pakzad进一步描述了 这些方法在流送系统的上下文中的若干优点。现在描述本发明将Pakzad的块 划分方法应用于块请求流送系统的进一步实施例。该方法可包括将待呈现媒体 数据安排成大致的呈现时间次序，以使得媒体数据的任何给定元素(例如，视 频帧或音频样本)的播出时间与任何毗邻媒体数据元素的播出时间相差小于所 设阈值。如此排序的媒体数据按Pakzad的话来说可被视为数据流，且应用于 该数据流的任何Pakzad方法标识该数据流的块边界。任一对毗邻块边界之间 的数据按本公开的话来说被视为“块”，且本公开的方法被应用以提供该媒体 数据在块请求流送系统内的呈现。如本领域技术人员在阅读本公开之际将清楚 的，Pakzad中公开的方法的若干优点由此可在块请求流送系统的上下文中实 现。

如Pakzad中描述的，对段的块结构(包括涵盖部分GoP或涵盖一个以上 GoP的部分的块)的确定会影响客户端实现快速频道换台时间的能力。在 Pakzad中，提供了在给出目标启动时间的情况下将提供块结构和目标下载速率 的方法，该块结构和目标下载速率将确保若客户端在任何查找点开始下载表示 并在该目标启动时间已流逝之后开始播出，则只要在每个时间点该客户端已下 载的数据量至少为目标下载速率乘以自下载开始以来流逝的时间，那么播出就 将无缝地继续。有利的是使客户端能访问目标启动时间和目标下载速率，因为 这向客户端提供了确定何时开始在最早的时间点播出该表示的手段，并且只要 下载满足上述条件就允许客户端继续播出该表示。因此，稍后描述的方法提供 了用于在媒体呈现描述内包括目标启动时间和目标下载速率的手段，从而其可 被用于上述目的。

媒体呈现数据模型

图5解说了图1中所示的内容存储的可能结构，包括段和媒体呈现描述 (“MPD”)文件，以及MPD文件内的段分解、时基和其他结构。现在将描 述MPD结构或文件的可能实现的细节。在许多示例中，MPD被描述为文件， 但也可以使用非文件结构。

如其中解说的，内容存储110装有多个源段510、MPD 500和修复段512。 MPD可包括时段记录501，时段记录501又可包括表示记录502，表示记录502 包含诸如对初始化段504和媒体段505的引用之类的段信息503。

图9(a)解说了示例元数据表900，而图9(b)解说了HTTP流送客户端902 如何在与HTTP流送服务器906的连接上获得元数据表900和媒体块904的示 例。

在本文中描述的方法中，提供包括关于客户端可用的媒体呈现的表示的信 息的“媒体呈现描述”。表示可以是替换性的，替换性的意义是指客户端选出 不同替换项之一，或者它们可以是互补性的，互补性的意义是指客户端选择其 中若干个表示、每个表示可能也来自一组替换项，并且联合地呈现这些表示。 表示可有利地被指派到群，其中客户端被编程或配置成理解：对于一群中的表 示，它们各自是彼此的替换项，而来自不同群的表示使得能联合地呈现一个以 上表示。换言之，若群中有一个以上表示，则客户端从该群挑选一个表示，从 下一群挑选一个表示等等以构成呈现。

描述表示的信息可有利地包括所应用的媒体编解码器的详情，包括解码该 表示所需的那些编解码器的简档和等级、视频帧率、视频分辨率以及数据率。 接收媒体呈现描述的客户端可使用该信息来事先确定表示是否适合解码或呈 现。这代表了优点，因为若区别信息将仅被包含在表示的二进制数据中，则将 必需请求来自所有表示的二进制数据并解析和提取相关信息才能发现关于其 适用性的信息。这多个请求以及对数据的解析并附提取可能要花一些时间，这 会导致启动时间很长并且因此用户体验不良。

此外，媒体呈现描述可包括基于时辰来限制客户端请求的信息。例如对于 实况服务，客户端可被限于请求呈现中接近“当前广播时间”的部分。这代表 了优点，因为对于实况广播，可能希望从服务基础设施中清空比当前广播时间 早所设阈值以上广播的内容的数据。这对于服务基础设施内的存储资源的重复 使用而言是可取的。这还可能取决于所提供的服务类型而变为可取的，例如， 在一些情形中，由于接收客户端设备的某个订阅模型，可使得呈现仅有实况可 用，而可使得其他媒体呈现有实况和点播可用，并可使得其他呈现对于第一类 客户端设备仅有实况可用，对于第二类客户端设备仅有点播可用，以及对于第 三类客户端设备有实况或点播的组合可用。(下文)“媒体呈现数据模型”小 节中描述的方法允许向客户端通知此类策略，从而客户端对于服务基础设施中 可能不可用的数据可避免作出请求并调节对用户的供应。作为替换方案，例如， 客户端可向用户呈现该数据不可用的通知。

在本发明的进一步实施例中，媒体段可顺应于ISO/IEC 14496-12或衍生规 范中描述的ISO基媒体文件格式(诸如3GPP技术规范26.244中描述的3GP 文件格式)。(上文)“3GPP文件格式的使用”这一小节描述了对ISO基媒 体文件格式的新颖增强，从而准许在块请求流送系统内高效地使用该文件格式 的数据结构。如该参考文献中描述的，可在文件内提供信息从而准许媒体呈现 的时间段与文件内的字节范围之间快速且高效的映射。媒体数据本身可根据 ISO/IEC14496-12中定义的电影片断构造来结构化。提供时间和字节偏移量的 该信息可被阶层式地结构化或被结构化为单个信息块。该信息可在文件开始处 提供。使用如“3GPP文件格式的使用”这一小节中描述的高效编码来提供该 信息导致客户端能迅速检索该信息，例如在块请求流送系统使用的文件下载协 议是HTTP的情形中使用HTTP部分获取请求来迅速检索该信息，这导致很短 的启动、查找或流切换时间且因此导致改善的用户体验。

媒体呈现中的表示是同步在全局时间线上的，以确保跨表示(典型地为替 换项)的无缝切换，并且确保两个或更多个表示的同步呈现。因此，自适应 HTTP流送媒体呈现内的各表示中所包含的媒体的样本时基可跨多个段与连续 的全局时间线相关。

包含多种类型的媒体(例如，音频和视频)的经编码媒体块对于不同类型 的媒体可具有不同的呈现结束时间。在块请求流送系统中，此类媒体块可按使 每种媒体类型被连续地播放的方式来连贯播出，且因此来自一个块的一种类型 的媒体样本可能在前一块的另一类型的媒体样本之前播出，这在本文中被称为 “连续块拼接”。作为替换，此类媒体块可按以下方式播放：一个块的任何类 型的最早样本在前一块的任何类型的最晚样本之后播放，这在本文中被称为 “非连续块拼接”。当这两个块包含来自相同内容项和相同表示的按顺序编码 的媒体时或在其他情形中，连续块拼接可能是恰适的。典型地，在一个表示内， 在拼接两个块时可以应用连续块拼接。这是有利的，因为可以应用现有编码， 且可以在无需使媒体轨迹在块边界处对准的情况下进行分段。这在图10中解 说，其中视频流1000包括块1202和其他块，带有诸如RAP 1204之类的RAP。

媒体呈现描述

媒体呈现可被视为HTTP流送服务器上的结构化的文件集合。HTTP流送 客户端可下载充分的信息以向用户呈现流送服务。替换表示可包括一个或更多 个3GP文件或3GP文件的部分，其中这些3GP文件遵循3GPP文件格式或至 少遵照一组定义明确的能容易地转换自或转换成3GP文件的数据结构。

媒体呈现可由媒体呈现描述来描述。媒体呈现描述(MPD)可包含元数 据，客户端能使用该元数据来构造恰适的文件请求，例如HTTP获取请求，以 在恰适的时间访问处该数据并向用户提供流送服务。媒体呈现描述可提供充分 的信息以供HTTP流送客户端选择恰适的3GPP文件和文件片。信令通知客户 端可访问的单位被称为段。

媒体呈现描述尤其可包含如下元素和属性等。

媒体呈现描述(MediaPresentationDescription)元素

封装供HTTP流送客户端用来向最终用户提供流送服务的元数据的元素。 “媒体呈现描述”元素可包含以下属性和元素中的一个或更多个。

版本：协议的版本号以确保可扩展性。

呈现标识符(PresentationIdentifier)：使得该呈现可在其他呈现之中被唯 一性地标识出来的信息。也可包含私有字段或名称。

更新频率(UpdateFrequency)：媒体呈现描述的更新频率，即客户端可多 频繁地重新加载实际的媒体呈现描述。若该元素不出现，则媒体呈现可以是静 态的。更新媒体呈现可意味着媒体呈现不能被高速缓存。

媒体呈现描述URI(MediaPresentationDescriptionURL)：用于约定媒体 呈现描述的URI。

流(Stream)：描述流或媒体呈现的类型：视频、音频或文本。视频流类 型可包含音频并且可包含文本。

服务(Service)：描述具有附加属性的服务类型。服务类型可以是实况或 点播。这可以用来通知客户端超出某个当前时间的查找和访问是不被准许的。

最大客户端预缓冲时间(MaximumClientPreBufferTime)：客户端可预缓 冲媒体流的最大时间量。该时基可将流送与客户端被限于下载超出该最大预缓 冲时间的渐进式下载区别开。该值可以不出现，指示没有预缓冲意义上的限制 可应用。

安全保护区间实况服务(SafetyGuardIntervalLiveService)：关于服务器上 的实况服务的最大周转时间的信息。向客户端提供了在当前时间有哪些信息已 可访问的指示。若预期客户端和服务器按UTC时间操作且不提供紧密的时间 同步，则该信息可能是必需的。

时移缓冲器深度(TimeShiftBufferDepth)：关于客户端在实况服务中ke1 相对于当前时间回移多远的信息。藉由该深度的扩展，无需在服务供应中作出 特定改变也可准许时移观看和追看服务。

准许本地高速缓存(LocalCachingPermitted)：该标志指示HTTP客户端 在已播放所下载的数据之后是否能本地高速缓存该数据。

实况呈现区间(LivePresentationInverval)：通过指定开始时间(StartTimes) 和结束时间(EndTimes)来包含其间呈现可用的时间区间。“开始时间”指示 服务的开始时间而“结束时间”指示服务的结束时间。若没有指定结束时间， 则结束时间在当前时间是未知的，且“更新频率”可确保客户端能在服务的实 际结束时间之前访问到结束时间。

点播可用性区间(OnDemandAvailabilityInterval)：该呈现区间指示该服 务在网络上的可用性。可以提供多个呈现区间。HTTP客户端在任何指定时间 窗以外可能不能访问该服务。通过提供“点播区间”，可指定额外的时移观看。 对于实况服务，该属性也可出现。倘若对于实况服务该属性出现，则服务器可 确保在所有所提供的可用性区间期间，客户端能以点播服务的形式来访问该服 务。因此，“实况呈现区间”不可与任何“点播可用性区间”交迭。

MPD文件信息动态(MPDFileInfoDynamic)：描述媒体呈现中的文件的 默认动态构造。更多细节在下文中提供。若对若干或所有替换表示使用相同规 则，则在MPD等级上的默认指定可以节省不必要的重复。

MPD编解码器描述(MPDCodecDescription)：描述媒体呈现中的主默认 编解码器。更多细节在下文中提供。若对若干或所有表示使用相同的编解码器， 则在MPD等级上的默认指定可以节省不必要的重复。

MPD移动包头部大小不变(MPDMoveBoxHeaderSizeDoexNotChange)： 指示移动包头部的大小在整个媒体呈现内各个体文件之间是否改变的标志。该 标志可用来优化下载并且可以仅在特定段格式(尤其是其段包含moov头部的 那些段格式)的情形中才出现。

FileURI模式(FileURIPattern)：客户端用来生成对媒体呈现内的文件的 请求消息的模式。不同属性准许为媒体呈现内的每个文件生成唯一性的URI。 基URI可以是HTTP URI。

替换表示：描述表示列表。

“替换表示(AlternativeRepresentation)”元素：

封装一个表示的所有元数据的XML元素。“替换表示”元素可包含以下 属性和元素。

表示ID(RepresentationID)：媒体呈现内该特定替换表示的唯一性ID。

静态文件信息(FilesInfoStatic)：提供一个替换呈现的所有文件的起始时 间和URI的显式列表。文件列表的该静态提供可提供对媒体呈现有确切时基描 述的优点，但可能不够紧凑，尤其是如果替换表示包含许多文件。另外，这些 文件名称可具有任意的名称。

动态文件信息(FilesInfoDynamic)：提供构造一个替换呈现的起始时间 和URI的列表的隐式方式。该文件列表的动态提供可提供具有更紧凑表示的优 点。若仅提供了起始时间序列，则此处时基优点也成立，但文件名称将基于文 件模式URI(FilePatternURI)来动态地构造。若仅提供每个段的历时，则表示 是紧凑的并且可适合用在实况服务内，但文件的生成可由全局时基来掌管。

AP移动包头部大小不变(APMoveBoxHeaderSizeDoesNotChange)：指示 移动包头部的大小在替换描述内各个体文件之间是否改变的标志。该标志可用 来优化下载并且可以仅在特定段格式(尤其是其段包含moov头部的那些段格 式)的情形中才出现。

AP编解码器描述(APCodecDescription)：描述替换呈现中的文件的主编 解码器。

媒体描述元素

媒体描述(MediaDescription)：可封装该表示中所包含的媒体的所有元 数据的元素。具体而言，它可包含关于该替换呈现中的轨迹以及推荐的轨迹编 组(若适用)的信息。“媒体描述”属性包含以下属性：

轨迹描述(TrackDescription)：封装该表示中所包含的媒体的所有元数据 的XML属性。“轨迹描述”属性包含以下属性：

轨迹ID(TrackID)：替换表示内的轨迹的唯一性ID。这可以用在轨迹是 编组描述的一部分的情形中。

比特率(Bitrate)：轨迹的比特率。

轨迹编解码器描述(TrackCodecDescription)：包含关于该轨迹中使用的 编解码器的所有属性的XML属性。“轨迹编解码器描述”属性包含以下属性：

媒体名称(MediaName)：定义媒体类型的属性。媒体类型包括“音频”、 “视频”、“文本”、“应用”和“消息”。

编解码器(Codec)：包括简档和等级的编解码器类型。

语言标记(LanguageTag)：语言标记(若适用)。

最大宽度(MaxWidth)、最大高度(MaxHeight)：对于视频而言，是指 被包含的视频以像素计的高度和宽度。

采样率(SamplingRate)：对于音频而言的采样率。

群描述(GroupDescription)：基于不同参数向客户端提供对恰适编组的 推荐的属性。

群类型(GroupType)：基于该类型，客户端可决定如何编组轨迹。

媒体呈现描述中的信息有利地被HTTP流送客户端用来在恰适的时间执 行对文件/段或其部分的请求，以选择来自例如在接入带宽、显示能力、编解码 器能力等等以及诸如语言等用户偏好的意义上匹配其能力的胜任表示的段。此 外，由于“媒体呈现描述”描述了时间对准且被映射到全局时间线的表示，因 此客户端在正在进行的媒体呈现期间还可以使用MPD中的信息来发起恰适的 行动以跨表示进行切换、联合地呈现各表示、或在媒体呈现内进行查找。

信令通知段开始时间

表示可按时间被拆分成多个段。一个段的最后片断与下一段的下一片断之 间存在轨迹间时基问题。此外，在使用有恒定历时的段的情形中，存在另一个 时基问题。

对每个段使用相同历时可具有MPD既紧凑又呈静态的优点。然而，每个 段可能仍始于随机访问点。因此，要么可将视频编码约束成在这些特定点提供 随机访问点，要么实际的段历时可能没有像在MPD中指定的那样精确。可能 希望流送系统对视频编码过程不施加不必要的限制，且因此第二选项可能是优 选的。

具体而言，若在MPD中将文件历时指定为d秒，则第n个文件可始于时 间(n-1)d处或紧随其后的随机访问点。

在该办法中，每个文件可包括关于该段的在全局呈现时间意义上的确切开 始时间的信息。信令通知这一点的三种可能方式包括：

(1)第一，将每个段的开始时间限制成如在MPD中指定的确切时基。但 由此媒体编码器对于IDR帧的放置可能不具有任何灵活性且文件流送可能要 求特殊编码。

(2)第二，为每个段向MPD添加确切开始时间。对于点播情形，MPD的 紧凑性可能降低。对于实况情形，这可能要求对MPD的定期更新，这会降低 可伸缩性。

(3)第三，在MPD中向段添加全局时间或相对于该表示的宣称开始时间 或该段的宣称开始时间的确切开始时间，向段添加的意义是指段包含该信息。 它可被添加至专用于自适应流送的新包。该包还可包括如由“TIDX”或“SIDX” 包所提供的信息。该第三办法的结果是在查找这些段之一的开头附近的特定位 置时，客户端可以基于MPD来选取包含所请求的查找点的那个段的后续段。 该情形中的简单反应可以是将查找点前向移至检索到的段的开始(即，移至查 找点之后的下一个随机访问点)。通常，至少每几秒就提供随机访问点(且使 得它们更不频繁往往几乎获得不到多少编码增益)且因此在最差情形中，查找 点可被移到比指定处晚几秒。替换地，客户端在检索该段的头部信息时可确定 所请求查找点实际上是在前一段中并改为请求该段。这可能导致不时地增加执 行查找操作所需的时间。

可访问段的列表

媒体呈现包括一组表示，每个表示提供对原始媒体内容的某个不同版本的 编码。这些表示本身有利地包含关于该表示相比于其他参数的区别参数的信 息。它们还显式地或隐式地包含可访问段的列表。

段可被区别为仅包含元数据的不受时间影响的段和主要包含媒体数据的 媒体段。媒体呈现描述(“MPD”)有利地标识每个段并向每个段指派不同的 属性，要么隐式地要么显式地进行。有利地指派给每个段的属性包括期间段可 访问的时段、藉以可访问段的资源和协议。此外，媒体段被有利地指派诸如该 段在媒体呈现中的开始时间、以及该段在媒体呈现中的历时之类的属性。

在媒体呈现如有利地由媒体呈现描述中的属性(诸如点播可用性区间)指 示的那样为“点播”类型的场合，则媒体呈现描述典型地描述整个段并且还提 供这些段何时可访问以及这些段何时不可访问的指示。段的开始时间有利地相 对于媒体呈现的开始来表达，以使得在不同时间开始回放相同媒体呈现的两个 客户端能使用相同的媒体呈现描述以及相同的媒体段。这有利地提高了高速缓 存这些段的能力。

在媒体呈现如有利地由媒体呈现描述中的属性(诸如“服务”属性)指示 的那样为“实况”类型的场合，则包括媒体呈现的超出实际时辰的部分的段一 般不被生成或者至少不可访问，尽管这些段在MPD中作了完整描述。然而， 有了媒体呈现服务为“实况”类型的指示，客户端可基于MPD中包含的信息 以及MPD的下载时间来产生对以壁钟时间计的客户端内部时间“现在”而言 可访问的段连同时基属性的列表。服务器有利地在使得资源可访问从而在壁钟 时间“现在”用MPD的实例操作的参考客户端能访问该资源的意义上操作。

具体地，参考客户端基于MPD中包含的信息以及MPD的下载时间产生 对以壁钟时间计的客户端内部时间“现在”而言可访问的段连同时基属性的列 表。随着时间前进，客户端将使用相同的MPD并且将创建能用来连续地播出 该媒体呈现的新的可访问段列表。因此，服务器可在段实际上能访问之前在 MPD中宣告这些段。这是有利的，因为其减少了对MPD的频繁更新和下载。

假定通过诸如“静态文件信息”之类的元素中的播放列表显式地描述了或 者通过使用诸如“动态文件信息”之类的元素隐式地描述了各自具有开始时间 tS的段的列表。以下描述使用“动态文件信息”来生成段列表的有利方法。基 于该构造规则，客户端能访问每个表示r的URI的列表(在本文中称为 FileURI(r，i))以及索引为i的每个段的开始时间tS(r，i)。

使用MPD中的信息来创建段的可访问时间窗可使用以下规则来执行。

对于如有利地由诸如“服务”之类的属性指示的那样类型为“点播”的服 务，若在客户端处的当前壁钟时间“现在”落在如有利地由诸如“点播可用性 区间”之类的MPD元素表达的任何可用性范围内，则该点播呈现的所有被描 述的段皆是可访问的。若在客户端处的当前壁钟时间“现在”落在任何可用性 范围之外，则该点播呈现的被描述段皆是不可访问的。

对于如有利地由诸如“服务”之类的属性指示的那样类型为“实况”的服 务，开始时间tS(r，i)有利地以壁钟时间来表达可用性时间。可用性开始时间可 推导为是事件的实况服务时间与服务器处用于捕捉、编码和发布的一些周转时 间的组合。该过程的时间可例如在MPD中指定，例如使用在MPD中指定为 “安全保护区间实况服务”的安全保护区间tG来指定。这将提供UTC时间与 HTTP流送服务器上的数据可用性之间的最小差异。在另一实施例中，MPD显 式地指定MPD中的段的可用性时间而不提供作为事件实况时间与周转时间之 差的周转时间。在以下描述中，假定任何全局时间被指定为可用性时间。实况 媒体广播领域中的普通技术人员在阅读本描述之后可从媒体呈现描述中的合 适信息推导出该信息。

若在客户端处的当前壁钟时间“现在”落在有利地由诸如“实况呈现区间” 之类的MPD元素表达的实况呈现区间的任何范围之外，则该实况呈现的被描 述的段皆是不可访问的，若在客户端处的当前壁钟时间“现在”落在实况呈现 区间内，则该实况呈现的被描述的段中的至少某些段可能是可访问的。

对可访问段的限制由以下值来掌管：

壁钟时间“现在”(如客户端可用的)。

例如在媒体呈现描述中指定为“时移缓冲器深度”的所准许的时移缓冲器 深度tTSB。

客户端在相对事件时间t1可能仅被允许请求开始时间tS(r，i)落在(现在- tTSB)至“现在”的区间中或者落在使得历时为d的段的结束时间也被包括(从 而得到区间(现在-tTSB-d)至“现在”)的区间中的段。

更新MPD

在一些实施例中，服务器事先并不知道段的文件或段定位符以及开始时 间，因为例如服务器位置将改变，或者媒体呈现包括来自不同服务器的一些广 告，或者媒体呈现的历时是未知的，或者服务器想要混淆后继段的定位符。

在此类实施例中，服务器可能仅描述已经可访问或者在发布了MPD的该 实例之后不久便可访问的段。此外，在一些实施例中，客户端有利地消费接近 MPD中描述的媒体的那些媒体，以使得用户体验到所包含的与媒体内容的生 成尽可能接近的媒体节目。一旦客户端预计自己到达MPD中所描述的媒体段 的末尾，它就有利地在服务器已发布描述新媒体段的新MPD的预期下请求 MPD的新实例以继续连续播出。服务器有利地生成MPD的新实例并更新MPD 以使得客户端能依赖该规程进行连续更新。服务器可使自己的MPD更新规程 连同段生成和发布适配于其行为举止如普通客户端可能的行为举止的参考客 户端的规程。

若MPD的新实例仅描述很短的时间提前量，则客户端需要频繁地请求 MPD的新实例。这可能由于不必要的频繁请求而导致可伸缩性问题以及不必 要的上行链路和下行链路话务。

因此，有关系的是，一方面要描述尽可能远地进入将来的段而不必使它们 已可访问，另一方面要使MPD中未预见的更新能表达新服务器位置、准许插 入诸如广告之类的新内容或提供编解码器参数的改变。

此外，在一些实施例中，媒体段的历时可能很小，诸如在几秒的范围中。 媒体段的历时有利地是灵活的，以便调节到可针对投递或高速缓存性质来优化 的合适段大小、补偿实况服务中的端对端延迟或应对段存储或投递的其他方 面、或出于其他原因。尤其是在段与媒体呈现历时相比很小的情形中，则需要 在媒体呈现描述中描述显著量的媒体段资源和开始时间。结果，媒体呈现描述 的大小可能很大，这会不利地影响媒体呈现描述的下载时间且因此影响媒体呈 现的启动延迟以及还有接入链路上的带宽使用。因此，有利的是不仅准许使用 播放列表来描述媒体段列表，且还准许通过使用模板或URL构造规则来进行 描述。模板和URL规则规则在本描述中同义地使用。

此外，模板可有利地被用来在实况情形中描述超出当前时间的段定位符。 在此类情形中，对MPD的更新本身不是必需的，因为定位符以及段列表是由 模板描述的。然而，可能仍会发生未预见的事件，这要求对表示或段的描述进 行改变。当来自多个不同源的内容被拼接在一起时，例如在插入了广告时，可 能需要自适应HTTP流送媒体呈现描述上的改变。来自不同源的内容可能在各 种方面有所不同。实况呈现期间的另一个原因在于可能有必要改变用于内容文 件的URL以提供从一个实况发源服务器故障转移到另一个。

在一些实施例中，有利的是若MPD被更新，则对MPD的更新被执行以 使得经更新的MPD与先前MPD兼容，兼容的意义是指：对于直至先前MPD 的有效时间为止的任何时间，参考客户端以及因此任何所实现的客户端从经更 新的MPD生成的可访问段列表与其从MPD的该先前实例会生成的可访问段 列表等同地起效。该要求确保了(a)客户端可立即开始使用新MPD而无需与 旧MPD同步，因为新MPD在更新时间之前就与旧MPD兼容；以及(b)更新 时间无需与对MPD的实际改变发生的时间同步。换言之，对MPD的更新可 事先被广告，并且一旦有新信息可用，服务器就能替换掉MPD的旧实例而不 必维护MPD的不同版本。

对跨用于一组表示或所有表示的MPD更新的媒体时基可存在两种可能 性。(a)现有全局时间线跨该MPD更新而延续(在本文中被称为“连续MPD 更新”)，或(b)当前时间线结束并且新时间线从继该改变之后的段开始(在 本文中被称为“非连续MPD更新”)。

在考虑到媒体片断的轨迹以及因此段的轨迹由于跨各轨迹的样本粒度有 所不同故而一般并不在相同的时间开始和结束的情况下，这些选项之间的差异 可能是明显的。在正常呈现期间，片断的一个轨迹的样本可能在先前片断的另 一轨迹的一些样本之前被渲染，即片断之间可能存在某种交迭，尽管单个轨迹 内可能没有交迭。

(a)与(b)之间的差异在于是否可允许跨MPD更新实现此类交迭。当MPD 更新是由于完全分开的内容的拼接时，此类交迭一般是难以达成的，因为新内 容需要新编码才能与先前内容拼接。因此有利的是提供通过为某些段重启时间 线来非连续地更新媒体呈现、以及有可能还在更新之后定义一组新的表示的能 力。而且，若内容已被独立地编码和分段，则还避免要将时戳调节成拟合在先 前内容片的全局时间线内。

在更新是出于次要原因，诸如仅仅是向所描述媒体段的列表添加新媒体段 时，或者若URL的位置被改变，则交迭和连续更新可被允许。

在非连续MPD更新的情形中，先前表示的最末段的时间线在该段中任何 样本的最晚呈现结束时间处结束。下一表示的时间线(或更准确而言，媒体呈 现的新部分的第一个媒体段的首次呈现时间，也被称为新时段)典型地且有利 地始于与上一时段的呈现的结束相同的该时刻，以确保无缝和连续播出。

这两种情形在图11中解说。

优选且有利的是将MPD更新限制于段边界。将此类改变或更新限制于段 边界的基本原理如下。首先，对每个表示的二进制元数据(典型情况下为电影 头部)的改变至少可在段边界处发生。其次，媒体呈现描述可包含指向段的指 针(URL)。在某种意义上，MPD是将与媒体呈现相关联的所有段文件编组 在一起的“伞”数据结构。为了维护该包容关系，每个段可被单个MPD引用， 且当该MPD被更新时，有利的是仅在段边界处更新该MPD。

一般不要求段边界对准，然而对于从不同源拼接的内容的情形以及普遍对 于非连续MPD更新，使段边界对准是有意义的(具体而言，每个表示的最末 段可在相同的视频帧结束并且不可包含呈现开始时间晚于该帧的呈现时间的 音频样本)。非连续更新随后可在共同的时刻(称为时段)开始一组新的表示。 该组新的表示的有效性的开始时间例如由时段开始时间来提供。每个表示的相 对开始时间被复位为0且该时段的开始时间将该新时段中的该组表示放在全局 媒体呈现时间线中。

对于连续MPD更新，不要求段边界对准。每个替换表示的每个段可由单 个媒体呈现描述来掌管，且因此对该媒体呈现描述的新实例的更新请求(其一 般因预计没有更多的媒体段在此工作MPD中被描述而被触发)取决于所消费 的这一组表示可发生在不同时间，其中该组表示包括预计要消非的这组表示。

为了支持更一般化情形中MPD元素和属性的更新，不仅是表示或一组表 示，而是可将任何元素与有效性时间相关联。因此，若MDP的某些元素需要 更新，例如在表示的数目改变了或URL构造规则改变了的场合，则通过为元 素的多个副本提供不相交的有效性时间，这些元素各自可在指定时间被分别更 新。

有效性有利地与全局媒体时间相关联，以使得与有效性时间相关联的被描 述元素在媒体呈现的全局时间线的时段里有效。

如以上所讨论的，在一个实施例中，有效性时间仅被添加到全组表示。每 个全组则构成时段。有效性时间随后构成该时段的开始时间。换言之，在使用 有效性元素的具体情形中，全组表示可在由一组表示的全局有效性时间指示的 时间段里有效。一组表示的有效性时间被称为时段。在新时段的开始，前一组 表示的有效性过期且新一组表示有效。再次注意，有效性时间段优选是不相交 的。

如上所述，对媒体呈现描述的改变发生在段边界处，且因此对于每个表示， 元素改变实际上发生在下一段边界处。客户端随后可构成有效MPD，其包括 媒体的呈现时间内的每个时刻的段列表。

在其中块包含来自不同表示或来自不同内容(例如，来自内容段和广告) 的媒体数据的情形中或在其他情形中，非连续块拼接可能是恰适的。在块请求 流送系统中可能要求对呈现元数据的改变仅发生在块边界处。这出于实现原因 可能是有利的，因为在块内更新媒体解码器参数可能比仅在块之间更新这些参 数更加复杂。在该情形中，可有利地指定如上所描述的有效性区间可被解释成 近似的，以使得元素被视为从不早于所指定的有效性区间的开始的第一个块边 界至不早于所指定的有效性区间的末尾的第一个块边界是有效的。

以上描述的对块请求流送系统的新颖增强的示例实施例在稍后给出的为 “对媒体呈现的改变”的小节中描述。

段历时信令

非连续更新有效地将呈现分成一系列不相交的称为时段的区间。每个时段 具有其自己的时间线用于媒体样本时基。时段内的表示的媒体时基可有利地通 过指定每个时段或时段中的每个表示的段历时的单独的紧凑列表来指示。

与MPD内的元素相关联的例如称为时段开始时间之类的属性可指定媒体 呈现时间内的某些元素的有效性时间。该属性可被添加到MPD的任何元素(可 对元素换上可被指派有效性的属性)。

对于非连续MPD更新，所有表示的段可在非连续点结束。这一般至少意 味着该非连续点之前的最末段与先前各段具有不同历时。信令通知段历时可涉 及指示所有段具有相同的历时或者为每个段指示单独的历时。可能希望具有关 于段历时列表的紧凑表示，这在有许多段具有相同历时的情形中是高效的。

一个表示或一组表示中的每个段的历时可有利地用单个串来实现，该串指 定了从非连续更新的开始(即该时段的开始)直至MPD中描述的最末媒体段 为止的单个区间的所有段历时。在一个实施例中，该元素的格式是与包含段历 时条目列表的产生式相符的文本串，其中每个条目包含历时属性dur以及该属 性的可任选的乘数mult，该乘数指示该表示包含第一条目的<mult>个其历时为 第一条目的<dur>的段，随后是第二条目的<mult>个其历时为第二条目的<dur> 的段，依此类推。

每个历时条目指定一个或更多个段的历时。若<dur>值后面跟有“*”字符 和数字，则该数字指定具有该历时(以秒计)的连贯段的数目。若不存在乘数 符号“*”，则段数目为1。若存在“*”而没有后继数字，则所有后续段具有 所指定的历时且该列表中可能没有进一步的条目。例如，串“30*”意味着所 有段具有30秒的历时。串“30*12 10.5”指示有12个历时30秒的段，继以一 个历时为10.5秒的段。

若针对每个替换表示分开地指定段历时，则每个区间内的段历时的总和对 于每个表示而言可以是相同的。在视频轨迹的情形中，该区间在每个替换表示 中可结束于相同的帧。

本领域普通技术人员在阅读本公开之际可发现以紧凑方式来表达段历时 的类似和等效途径。

在另一实施例中，由信号“历时属性<历时>”来信令通知除了最后一个 段以外，对于该表示中的所有段而言段的历时是恒定的。非连续更新之前的最 末段的历时可以较短，只要提供了下一非连续更新的开始点或新时段的开始即 可，而这则意味着最末段的历时延及下一时段的开始。

对表示元数据的改变和更新

指示诸如电影头部“moov”改变之类的经二进制编码的表示元数据的改 变可按不同方式来完成：(a)在MPD中引用的单独文件中可以对所有表示有一 个moov包，(b)在每个替换表示中引用的单独文件中可以对每个替换表示有 一个moov包，(c)每个段可包含moov包且因此是自含式的，(d)在与MPD 一起的一个3GP文件中可以有用于所有表示的moov包。

注意在(a)和(b)的情形中，可有利地将单个“moov”与来自上文的有效性 概念相组合，组合的意义是指在MPD中可以引用更多的“moov”包，只要其 有效性不相交即可。例如，有了时段边界的定义，旧时段中的‘moov’的有效 性可随着新时段的开始而过期。

在选项(a)的情形中，对单个moov包的引用可被指派有效性元素。可允许 多个呈现头部，但每个时间仅可有一个呈现头部有效。在另一实施例中，如以 上定义的时段中的整组表示或整个时段的有效性时间可被用作该表示元数据 的有效性时间，典型地作为moov头部来提供。

在选项(b)的情形中，对每个表示的moov包的引用可被指派有效性元素。 可允许多个表示头部，但每个时间仅可有一个表示头部有效。在另一实施例中， 如以上定义的整个表示或整个时段的有效性时间可被用作该表示元数据的有 效性时间，典型地作为moov头部来提供。

在选项(c)的情形中，可以不在MPD中添加信令，但可在媒体流中添加附 加信令以指示moov包对于任何即将到来的段是否将改变。这在下文“信令通 知段元数据内的更新”这一小节的上下文中进一步解释。

信令通知段元数据内的更新

为了避免频繁更新媒体呈现描述以获得关于潜在更新的知识，有利的是连 同媒体段一起信令通知任何此类更新。在媒体段本身内可提供附加的一个或多 个元素，其可指示有经更新的元数据(诸如媒体呈现描述)可用并且必须在某 个时间量内被访问才能成功地继续创建可访问段列表。此外，对于经更新的元 数据文件，此类元素可提供文件标识符(诸如URL)或可用来构造文件标识符 的信息。经更新元数据文件可包括等于将与该呈现的原始元数据文件中提供的 元数据修改成指示有效性区间的元数据、连同也伴随着有效性区间的附加元数 据。此类指示可在媒体呈现的所有可用表示的媒体段中提供。访问块请求流送 系统的客户端在检测到媒体块内的此类指示之际可使用文件下载协议或其他 手段来检索经更新元数据文件。藉此为客户端提供了关于媒体呈现描述中的改 变以及这些改变将发生或已发生的时间的信息。有利地，每个客户端仅在此类 改变发生时请求经更新媒体呈现描述一次，而非“轮询”并接收该文件许多次 以获得可能的更新或改变。

改变的示例包括表示的添加或移除，对一个或更多个表示的改变，诸如比 特率、分辨率、纵横比、所包括的轨迹或编解码器参数的改变，以及对URL 构造规则的改变，例如用于广告的不同发源服务器。一些改变可能仅影响与表 示相关联的初始化段，诸如电影头部(“moov”)原子，而其他改变可能影响 媒体呈现描述(MPD)。

在点播内容的情形中，这些改变及其时基可以事先知晓且可在媒体呈现描 述中信令通知。

对于实况内容，改变可能在它们发生的时间点之前是未知的。一个解决方 案是允许在特定URL处可用的媒体呈现描述被动态地更新并且要求客户端定 期地请求该MPD以便检测改变。该解决方案在可伸缩性(发源服务器负荷以 及高速缓存效率)意义上有缺点。在具有大量观众的场景中，高速缓存可能在 MPD的先前版本已从高速缓存过期之后并在新版本被接收到之前接收到许多 对MPD的请求，且所有这些请求可能被转发给发源服务器。发源服务器可能 需要不断地处理来自高速缓存的对MPD的每个经更新版本的请求。而且，这 些更新可能不容易与媒体呈现中的改变在时间上对准。

由于HTTP流送的优点之一在于利用标准web基础设施和服务以获得可 伸缩性的能力，因此优选的解决方案可仅涉及“静态”(即，可高速缓存的) 文件而不依赖于客户端“轮询”文件以查看它们是否已改变。

讨论并提议了用于解决包括媒体呈现描述和二进制表示元数据(诸如自适 应HTTP流送媒体呈现中的“moov”原子)的元数据的更新的解决方案。

对于实况内容的情形，在构造MPD时可能不知道MPD或“moov”可能 发生改变的时间点。由于出于带宽和可伸缩性原因一般应当避免频繁“轮询” MPD以检查更新，因此对MPD的更新可在段文件自身中“带内”地指示，即 每个媒体段可具有指示更新的选项。取决于上文的段格式(a)到(c)，可信令通知 不同的更新。

一般而言，可有利地在段内的信号中提供以下指示：MPD可能在请求该 表示内的下一段或其开始时间大于当前段的开始时间的任何下一段之前被更 新的指示符。更新可事先被宣告，以指示该更新只需要在晚于该下一段的任何 段发生。在媒体段的定位符改变了的情形中，该MPD更新还可用来更新二进 制表示元数据，诸如电影头部。另一信号可指示在该段完成时，不应再请求更 多将时间提前的段。

在段是根据段格式(c)来格式化，即每个媒体段可包含诸如电影头部之类的 自初始化元数据的情形中，则可添加另一信号，以指示后续段包含经更新的电 影头部(moov)。这有利地允许将电影头部包括在段中，但该电影头部仅在若 先前段指示电影头部更新的情况下或在当切换表示时进行查找或随机访问的 情形中才需要被客户端请求。在其他情形中，客户端可发出对段的字节范围请 求，其排除电影头部的下载，因此有利地节省了带宽。

在另一实施例中，若信令通知了MPD更新指示，则该信号还可包含关于 经更新的媒体呈现描述的诸如URL之类的定位符。在非连续更新的情形中， 经更新的MPD可使用诸如新时段和旧时段之类的有效性属性来描述更新前后 的呈现。这可以有利地被用来准许如以下进一步描述的时移观看，但还有利地 允许MPD更新在其所包含的改变生效之前任何时间被信令通知。客户端可立 即下载新MPD并将其应用于正在进行的呈现。

在具体实现中，对媒体呈现描述、moov头部或呈现结束的任何改变的信 令通知可被包含在遵循使用ISO基媒体文件格式的包结构的段格式的规则来 格式化的流送信息包中。该包可为任何不同更新提供专门信号。

流送信息包

定义

包类型：‘sinf

容器：无

强制性的：否

数量：0或1。

流送信息包包含关于文件是哪个流送呈现的一部分的信息。

句法

语义

streaming_information_flags(流送信息标志)包含以下各项中的0个或更 多个的逻辑或：

0x00000001后续有电影头部更新

0x00000002呈现描述更新

0x00000004呈现结束

当且仅当呈现描述更新(Presentation Description update)标志被置位时 mpd_location(mpd位置)出现，并且其提供关于新的媒体呈现描述的统一资 源定位符。

实况服务的MPD更新的示例使用情形

假设服务提供方想要使用本文中描述的增强型块请求流送来提供实况足 球比赛。或许几百万用户可能想要访问该比赛的呈现。该实况事件被请求暂停 时的休息或该行动中的其他间歇偶发地打断，在此期间可加插广告。典型情况 下，对于休息的确切时基完全或几乎没有事先通知。

服务提供方可能需要提供冗余的基础设施(例如，编码器和服务器)以在 实况比赛期间有任何组件故障情形中能进行无缝转切。

假设用户Anna在公交车上用她的移动设备访问该服务并且该服务立即可 用。她旁边坐着另一用户Paul，Paul在他的膝上型设备上观看该比赛。进了球 且两个人在相同的时间庆祝该事件。Paul告诉Anna该比赛中的第一个球甚至 更激动人心并且Anna使用该服务从而她能回看30分钟前的比赛。在看了该进 球之后，她回到实况比赛。

为了解决该使用情形，服务提供方应当能够更新MPD，向客户端信令通 知有经更新的MPD可用，并准许客户端访问流送服务以使得其能接近实时地 呈现该数据。

按与段投递异步的方式对MPD进行更新是可行的，如本文中别处所解释 的。服务器可向接收机提供MPD在一定时间里不更新的担保。服务器可依赖 于当前MPD。然而，当MPD在某个最小更新期之前就被更新时无需任何显式 信令。

完全同步的播出是几乎难以达成的，因为客户端可能在对不同的MPD更 新实例进行操作因此客户端可能有漂移。使用MPD更新，服务器可传达改变 并且客户端可被提醒有改变，即使在呈现期间亦然。逐段基础上的带内信令可 被用来指示MPD的更新，因此更新可能被限于段边界，但在绝大多数应用中 这应当是可接受的。

可以添加如下的MPD元素，其提供MPD的以壁钟时间计的发布时间以 及添加在段开头以信令通知要求MPD更新的可任选MPD更新包。该更新可 如同MPD那样阶层式地进行。

MPD“发布时间”提供MPD的唯一性标识符以及MPD何时发出。它还 提供用于更新规程的锚。

MPD更新包可存在于MPD中的“styp”包之后，并且由包类型＝“mupe” 定义，不需要容器、不是强制性的且具有数量0或1。MPD更新包包含关于段 是哪个媒体呈现的一部分的信息。

示例句法如下：

MPDUpdateBox(MPD更新包)类的各种对象的语义可如下：

mpd_information_flags(mpd信息标志)：以下各项中的0个或更多个的 逻辑或：

0x00现在的媒体呈现描述更新

0x01将来的媒体呈现描述更新

0x02呈现结束

0x030x07保留

new_location flag(新位置标志)：若置为1，则在mpd_location(mpd位 置)中指定的新位置处有新的媒体呈现描述可用。

latest_mpd_update time(最新mpd更新时间)：指定相对于最新MPD的 MPD发出时间最晚必需进行MPD更新的时间(以ms计)。客户端可选择在 其与现在之间的任何时间更新MPD。

mpd_location(mpd位置)：当且仅当“新位置标志”被置位时出现， 且若如此，则“mpd位置”提供关于新的媒体呈现描述的统一资源定位符。

若更新所使用的带宽成问题，则服务器可供应针对某些设备能力的MPD 以使得只有这些部分被更新。

时移观看和网络PVR

在时移观看得到支持时，可能在该会话的寿命时间里碰巧有两个或更多个 MPD或电影头部是有效的。在这种情形中，通过在必要时更新MPD，但添加 有效性机制或时段概念，便可对整个时间窗都有有效的MPD存在。这意味着 服务器可确保任何MPD和电影头部在落在用于时移观看的有效时间窗内的任 何时间段上都是被宣告的。由客户端来确保其当前呈现时间的可用MPD和元 数据是有效的。还可支持仅使用少量的MPD更新来将实况会话迁移到网络 PVR会话。

特殊媒体段

当在块请求流送系统内使用ISO/IEC 14496-12的文件格式时的问题在于， 如上文描述的，将呈现的单个版本的媒体数据存储在按连贯时间段安排的多个 文件中可能是有利的。此外，将每个文件安排成始于随机访问点可能是有利的。 此外，可能有利的是在视频编码过程期间选取查找点的位置并基于在编码过程 期间作出的对查找点的选取来将呈现分段成各自始于查找点的多个文件，其中 每个随机访问点可以置于文件开头也可以不置于文件开头，但其中每个文件始 于随机访问点。在具有上述性质的一个实施例中，呈现元数据或媒体呈现描述 可包含每个文件的确切历时，其中历时例如被认为表示文件的视频媒体的开始 时间与下一文件的视频媒体的开始时间之差。基于呈现元数据中的该信息，客 户端能够构造媒体呈现的全局时间线与每个文件内的媒体的局部时间线之间 的映射。

在另一实施例中，通过改为指定每个文件或段具有相同历时可有利地减小 呈现元数据的大小。然而，在这种情形中并且在根据上述方法来构造媒体文件 的场合，每个文件的历时可能并不严格等于在媒体呈现描述中指定的历时，因 为在自该文件开始起恰好过了该指定历时的点处可能并无随机访问点存在。

现在描述本发明的又一实施例，用于在即使有以上提及的矛盾的情况下也 能实现块请求流送系统的正确操作。在该方法中，可在每个文件内提供如下的 元素，该元素指定该文件内的媒体的局部时间线(其指根据ISO/IEC 14496-12 的从时戳0开始的、可供对照着来指定该文件中的媒体样本的解码和合成时戳 的时间线)向全局呈现时间线的映射。该映射信息可包括全局呈现时间中的与 局部文件时间线中的0时戳相对应的单个时戳。该映射信息可替换地包括偏移 值，其根据呈现元数据中提供的信息来指定与局部文件时间线中的0时戳相对 应的全局呈现时间与同文件开始相对应的全局呈现时间之间的差量。

此类包的示例可例如是轨迹片断解码时间(‘tfdt’)包或轨迹片断调整 包(‘tfad’)连同轨迹片断媒体调整(‘tfma’)包。

包括段列表生成的示例客户端

现在将描述示例客户端。它可被用作服务器用来确保MPD的恰当生成和 更新的参考客户端。

HTTP流送客户端由MPD中提供的信息来指导。假定客户端能访问其在 时间T(即它能成功接收MPD的时间)接收到的MPD。确定成功接收可包括 客户端获得经更新的MPD或客户端验证出该MPD自先前的成功接收以来尚 未被更新过。

以下介绍示例客户端行为。为了向用户提供连续流送服务，客户端首先解 析MPD并且在计及如以下详述的可能使用播放列表或使用URL构造规则的段 列表生成规程的情况下为每个表示创建在当前系统时间的客户端本地时间可 访问的段的列表。随后，客户端基于表示属性中的信息以及其他信息(例如可 用带宽和客户端能力)选择一个或多个表示。取决于编组，表示可自立呈现或 与其他表示联合呈现。

对于每个表示，客户端获取诸如该表示的“moov”头部之类的二进制元 数据(若有)、以及所选表示的媒体段。客户端通过可能使用段列表之类以请 求段或段的字节范围来访问媒体内容。客户端可在开始该呈现之前初始地缓冲 媒体，并且一旦该呈现已开始，客户端就通过在计及MPD更新规程的情况下 不断请求段或段部分来继续消费该媒体内容。

客户端可在计及经更新的MPD信息和/或来自其环境的经更新信息(例 如，可用带宽的改变)的情况下切换表示。以对包含随机访问点的媒体段的任 何请求，客户端就可切换到不同的表示。在前移，即当前系统时间(称为“现 在时间”，用于表示相对于呈现的时间)前进时，客户端消费可访问的段。随 着“现在时间”中的每次前进，客户端有可能根据本文中指定的规程扩展每个 表示的可访问段的列表。

若尚未到达媒体呈现结束且若当前回放时间落在客户端预计会用尽任何 正在消费或将要消费的表示的MPD中所描述的媒体中的媒体的阈值以内，则 客户端可请求MPD的更新，其带有新的取回时间“接收时间T”。一旦接收 到，客户端随后计及有可能经更新的MPD和新时间T来生成可访问段列表。 图29解说了在客户端处不同时间的实况服务的规程。

可访问段列表生成

假定HTTP流送客户端能访问MPD并且可能想要生成对于壁钟时间“现 在”而言可访问的段的列表。客户端以某个精度同步到全局时间基准，但有利 地不要求直接同步到HTTP流送服务器。

每个表示的可访问段列表优选定义为段开始时间和段定位符的列表对，其 中不失一般性，段开始时间可定义为是相对于表示的开始而言的。表示的开始 可与时段的开始对准(若应用该概念)。否则，表示开始可在媒体呈现的开始 处。

客户端使用例如本文中进一步定义的URL构造规则和时基。一旦获得了 所描述段的列表，该列表被进一步限于可访问的段，它们可以是完整媒体呈现 的段的子集。该构造由时钟在客户端“现在”时间的当前值来掌管。一般而言， 段仅在一组可用性时间以内的任何“现在”时间可用。对于落在该窗口以外的 “现在”时间，则没有段可用。此外，对于实况服务，假定某个时间“检查时 间(checktime)”提供关于将此媒体描述到进入将来多远的信息。“检查时间” 是在MPD记载的媒体时间轴上定义的；当客户端的回放时间到达检查时间时， 其有利地请求新MPD。

；当客户端的回放时间到达检查时间时，其有利地请求新MPD。

随后，段列表由检查时间连同MPD属性TimeShiftBufferDepth(时移缓冲 器深度)进一步限制，以使得可用媒体段仅有媒体段的开始时间与表示开始时 间之和落入“现在”减去时移缓冲器深度减去上个被描述的段的历时与检查时 间或“现在”中的较小值之间的区间的那些段。

可伸缩块

有时，可用带宽下降得如此之低，从而接收机处当前正在接收的一个或多 个块变得不大可能被及时完全接收以供不暂停呈现地播出。接收机可能事先检 测到此类情形。例如，接收机可确定自己正在接收每6单位的时间编码5单位 的媒体的块，并且具有4单位的媒体的缓冲器，因此接收机可能预期不得不将 该呈现停滞或暂停到大约24单位的时间以后。在充分注意到此点的情况下， 接收机可通过例如放弃当前的块流之类来对此类情形作出反应并开始请求来 自该内容的不同表示(诸如每单位播出时间使用较少带宽的表示)的一个或多 个块。例如，若接收机切换到其中对于相同大小的块而言，块所编码的视频时 间至少多了20％的表示，则接收机可能能够消除停滞直至带宽情形得到改善的 需要。

然而，使接收机完全丢弃已从被放弃的表示接收到的数据可能是浪费的。 在本文中描述的块流送系统的实施例中，每个块内的数据可按以下方式来编码 和安排：块内的数据的某些前缀可被用来在尚未接收到该块的其余部分的情况 下继续该呈现。例如，可使用可伸缩视频编码的公知技术。此类视频编码方法 的示例包括H.264可伸缩视频编码(SVC)或H.264高级视频编码(AVC)的 时间可伸缩性。有利地，该方法允许呈现基于块中已接收到的部分来继续进行， 即使对一个或多个块的接收例如由于可用带宽的改变而可能被放弃。另一优点 在于单个数据文件可被用作该内容的多个不同表示的源。这是可能的，例如通 过利用选择块中与所要求的表示相对应的子集的HTTP部分获取请求来实现。

本文中详述的一种改进是增强型段：可伸缩段映射。该可伸缩段映射包含 段中不同层的位置，以使得客户端能相应地访问这些段的各部分并提取各层。 在另一实施例中，段中的媒体数据被排序，以使得在从段开头逐渐下载数据的 同时段的质量也在提高。在另一实施例中，质量的逐渐提高被应用于段中包含 的每个块或片断，以使得能进行片断请求来解决可伸缩办法。

图12是示出可伸缩块的一方面的图。在该图中，发射机1200输出元数据 1202、可伸缩层1(1204)、可伸缩层2(1206)、以及可伸缩层3(1208)， 其中后者被延误了。接收机1210随后可使用元数据1202、可伸缩层1(1204) 和可伸缩层2(1206)来呈现媒体呈现1212。

独立可伸缩性层

如以上所解释的，不希望块请求流送系统在接收机不能及时接收到媒体数 据的特定表示的所请求块供其播出时不得不停滞，因为这往往造成不良用户体 验。通过将所选取的表示的数据率限制成比可用带宽小得多以使该呈现不太可 能有任何给定部分不会被及时接收到，就能够避免、减少或缓解停滞，但该策 略具有媒体质量必然比可用带宽原则上能支持的媒体质量低得多。比可能达到 的质量低的呈现也可能被解释为不良用户体验。因此，块请求流送系统的设计 者在设计客户端规程、客户端编程或硬件配置时面临着以下选择：要么请求具 有比可用带宽低得多的数据率的内容版本，在这种情形中用户可能遭受不良媒 体质量；要么请求具有接近可用带宽的数据率的内容版本，在这种情形中用户 在呈现期间随着可用带宽改变有高概率会遭受暂停。

为了处置此类情形，本文中描述的块流送系统可被配置成独立地处置多个 可伸缩性层，以使得接收机能作出分层请求并且发射机能响应于分层请求。

在此类实施例中，每个块的经编码媒体数据可被划分成多个不相交的片 (在本文中被称为“层”)，以使得层组合构成块的整个媒体数据并且使得已 接收到这些层的某些子集的客户端可执行对该内容的表示的解码和呈现。在该 办法中，流中的数据的排序使得毗连范围在质量上呈递增且元数据反映这一 点。

可用来生成具有上述性质的层的技术的示例是例如ITU-T标准 H.264/SVC中描述的可伸缩视频编码技术。可用来生成具有上述性质的层的技 术的另一示例是如ITU-T标准H.264/AVC中提供的时间可伸缩性层技术。

在这些实施例中，元数据可在MPD中或在段自身中提供，从而使得能构 造对任何给定块的个体层和/或层组合和/或多个块的给定层和/或多个块的层 组合的请求。例如，构成块的层可被存储在单个文件内且可提供指定该文件内 与个体层相对应的字节范围的元数据。

能够指定字节范围的文件下载协议(例如HTTP 1.1)可被用来请求个体 层或多个层。此外，如本领域技术人员在查阅本公开之际将清楚的，以上描述 的涉及可变大小的块及可变的块组合的构造、请求和下载的技术也可应用于本 上下文。

组合

现在描述数个实施例，它们可有利地由块请求流送客户端采用以通过使用 如以上描述地划分成层的媒体数据来达成相比于现有技术在用户体验上的改 善和/或在服务基础设施容量要求上的减少。

在第一实施例中，可应用块请求流送系统的已知技术，其修改在于内容的 不同版本在一些情形中层的不同组合所取代。这就是说在现有系统可提供内容 的两种相异表示的场合，此处描述的增强型系统便可提供两个层，其中现有系 统中内容的一个表示在比特率、质量以及可能还有其他度量方面类似于增强型 系统中的第一层，而现有系统中内容的第二表示在比特率、质量以及可能还有 其他度量方面类似于增强型系统中这两个层的组合。因此，该增强型系统内要 求的存储容量相比于现有系统中要求的存储容量得以减小。此外，现有系统的 客户端可发出对一个表示或另一表示的块的请求，而该增强型系统的客户端可 发出对块的第一层或两层的请求。因此，这两个系统中的用户体验是相似的。 此外，提供了改善的高速缓存，因为即使是对于不同的质量，使用的也是共用 的段，由此段被高速缓存的似然性更高。

在第二实施例中，采用现在描述的层方法的增强型块请求流送系统中的客 户端可为媒体编码的若干层中的每一层维护分开的数据缓冲器。如对于客户端 设备内的数据管理的领域中的技术人员而言将清楚的，这些“分开的”缓冲器 可通过为这些分开的缓冲器分配物理上或逻辑上分开的存储器区域或通过其 他技术来实现，其中所缓冲的数据被存储在单个或多个存储器区域中且来自不 同层的数据的分开是通过使用包含对来自分开的层的数据的存储位置的引用 的数据结构来逻辑地达成的，且因此在下文中，术语“分开的缓冲器”应当被 理解为包括其中相异层的数据可被分开标识的任何方法。客户端基于每个缓冲 器的占用率发出对每个块的个体层的请求，例如这些层可按优先级次序排序以 使得对来自一个层的数据的请求在优先级次序上较低的层的任何缓冲器的占 用率低于该较低层的阈值的情况下不会被发出。在该方法中，对接收来自优先 级次序上较低的层的数据给予优先，以使得若可用带宽降至比还接收优先级次 序上较高的层所要求的带宽低，则仅请求这些较低层。此外，与不同层相关联 的阈值可以不同，以使得例如较低层具有较高阈值。在可用带宽改变以使得较 高层的数据不能在块的播出时间之前被接收到的情形中，那么较低层的数据将 必然已被接收到且因此呈现能单单用这些较低层来继续进行。缓冲器占用率的 阈值可按数据字节、缓冲器中包含的数据的播出历时、块数目或任何其他合适 的度量的形式来定义。

在第三实施例中，第一和第二实施例的方法可被组合以使得提供多个媒体 表示，每个媒体表示包括层的子集(如同第一实施例中一样)并且第二实施例 被应用于表示内的层的子集。

在第四实施例中，第一、第二和/或第三实施例的方法可与其中提供内容 的多个独立表示的实施例相组合，以使得例如这些独立表示中的至少一个独立 表示包括应用第一、第二和/或第三实施例的技术的多个层。

高级缓冲管理器

与缓冲监视器126(参见图2)相组合，可使用高级缓冲管理器来优化客 户端方的缓冲器。块请求流送系统想要确保媒体播出能迅速开始并平滑地继 续，与此同时向用户或目的地设备提供最大程度的媒体质量。这可能要求客户 端请求具有最高媒体质量、但也能迅速开始并在此后被及时接收以便在不会迫 使呈现中发生暂停的情况下播出的块。

在使用高级缓冲管理器的实施例中，该管理器决定要请求媒体数据的哪些 块以及何时作出这些请求。可例如向高级缓冲管理器提供要呈现的内容的元数 据集，该元数据包括内容可用的表示列表以及每个表示的元数据。表示的元数 据可包括关于表示的数据率以及其他参数的信息，诸如视频、音频或其他编解 码器和编解码参数、视频分辨率、解码复杂性、音频语言以及会影响客户端处 对表示的选取的任何其他参数。

表示的元数据还可包括该表示已被分段成的块的标识符，这些标识符提供 客户端请求块所需的信息。例如，在请求协议是HTTP的场合，该标识符可以 是HTTP URL可能还连同附加信息，该附加信息标识由该URL所标识的文件 内的字节范围或时间跨度，该字节范围或时间跨度标识由该URL所标识的文 件内的特定块。

在具体实现中，高级缓冲管理器决定接收机何时作出对新块的请求并且其 自身可能处置该请求的发送。在新颖的方面，高级缓冲管理器根据在使用过多 带宽与流送播出期间用尽媒体之间进行平衡的平衡比的值来对新块作出请求。

缓冲监视器126从块缓冲器125接收到的信息可包括对何时接收到媒体数 据、已接收到多少、对媒体数据的播出何时已开始或停止、以及媒体播出的速 度等的每个事件的指示。基于该信息，缓冲监视器126可演算代表当前缓冲器 大小的变量B_当前。在这些示例中，B_当前代表客户端或其他一个或多个设备缓冲 器中包含的媒体量并且可以时间单位来度量，从而B_当前代表假使不再接收更多 的块或部分块那么播出该一个或多个缓冲器中所存储的块或部分块所表示的 所有媒体将花费的时间量。因此，B_当前代表客户端处可用但尚未播放的媒体数 据按正常播出速度的“播出历时”。

随着时间流逝，B_当前的值将随着媒体被播出而减小并且会在每次接收到块 的新数据时增大。注意，出于本解释的目的，假定块是在该块的全部数据在块 请求器124处可用时被接收的，但也可以改为使用其他措施以例如计及部分块 的接收。在实践中，对块的接收可发生在时段上。

图13解说了在媒体被播出并且块被接收时B_当前的值随时间的变化。如图 13中所示，对于小于t₀的时间，B_当前的值为0，指示尚未接收到数据。在t₀， 第一块被接收并且B_当前的值增大到等于所接收的块的播放历时。此时，播出尚 未开始且因此B_当前的值保持恒定直至时间t₁，此时第二块抵达并且B_当前增大该 第二块的大小。此时，播出开始并且B_当前的值开始线性减小直至时间t₂，此时 第三块抵达。

B_当前的累进以此“锯齿”方式继续，每次接收到块时阶跃地增大(在时间 t₂、t₃、t₄、t₅和t₆)并在其间随着数据被播出而平滑地减小。注意，在该示例 中，播出是以该内容的正常播出速率来进行的，并且因此块接收之间的曲线斜 率恰好为-1，意味着对于流逝的每一秒真正时间，有一秒的媒体数据被播放。 在基于帧的媒体以给定帧数每秒(例如24帧每秒)播出时，斜率-1将由指示 每个个体数据帧的播出的小阶跃函数来近似，例如每帧播出时-1/24秒的步长。

图14示出了B_当前随时间演进的另一个示例。在该示例中，第一块在t₀抵 达并且播出立即开始。块抵达和播出继续直至时间t₃，此时B_当前的值到达0。 在这种情况发生时，没有更多媒体数据可供播出，从而迫使媒体呈现暂停。在 时间t₄，第四块被接收并且播放可恢复。该示例因此示出了其中对第四块的接 收晚于所需从而导致播出暂停以及因此导致不良用户体验的情形。因此，高级 缓冲管理器及其他特征的目标是降低该事件的概率，与此同时维持高媒体质 量。

缓冲监视器126还可演算另一度量B_比率(t)，其为给定时间段中接收到的媒 体与该时间段的长度之比。更具体而言，B_比率(t)等于T_收到/(T_现在-t)，其中T _收到是在自t直至当前时间T_现在的该时间段中接收到的媒体量(以其播出时间来 度量)，t是比的当前时间早的某个时间。

B_比率(t)可用于衡量B_当前的变化率。B_比率(t)＝0是其中自时间t起尚未接收到 数据的情形；假定媒体正在播出，则B_当前自该时间起将减少了(T_现在-t)。B_比率(t)＝1是其中对于时间(T_现在-t)而言接收到的媒体的量与正在播出的量相同的 情形；B_当前在时间T_现在将具有与时间t时相同的值。B_比率(t)＞1是其中对于时间 (T_现在-t)而言接收到的数据比播出所需的多的情形；B_当前从时间t到时间T_现在将有所增大。

缓冲监视器126进一步演算“State(状态)”值，其可取离散数目个值。 缓冲监视器126进一步装备有函数NewState(B_当前，B_比率)，在给定B_当前的当前值 和B_比率对于t＜T_现在的值的情况下该函数提供新“状态”值作为输出。每当B_当前和B_比率导致该函数返回不同于“状态”的当前值的值时，该新值就被指派给 “状态”并且向块选择器123指示该新状态值。

函数NewState可参照(B_当前，B_比率(T_现在-T_x))对的所有可能值的空间来求值， 其中T_x可以是固定(配置)值，或者可例如由从B_当前的值映射到T_x的值的配 置表从B_当前推导出，或者可取决于“状态”的先前值。向缓冲监视器126供应 该空间的一个或更多个划分，其中每个划分包括不相交区域的集合，每个区域 用“状态”值来标注。对函数“NewState”的求值由此包括标识划分并确定(B _当前，B_比率(T_现在-T_x))对所落在的区域的操作。返回值由此是与该区域相关联的标 注。在简单情形中，只提供一个划分。在更复杂的情形中，划分可取决于前一 次对NewState函数求值时的(B_当前，B_比率(T_现在-T_x))对或取决于其他因素。

在具体实施例中，以上描述的划分可基于包含B_当前的数个阈值以及B_比率的数个阈值的配置表。具体而言，令B_当前的阈值为B_阈(0)＝0、B_阈(1)、...、B _阈(n₁)、B_阈(n₁+1)＝∞，其中n₁是B_当前的非零阈值的数目。令B_比率的阈值为B_比率阈(0)＝0、B_比率阈(1)、...、B_比率阈(n₂)、B_比率阈(n₂+1)＝∞，其中n₂是B_比率的阈值的 数目。这些阈值定义了包括(n₁+1)x(n₂+1)的单元栅格的划分，其中第j行的第 i个单元对应于其中B_阈(i-1)＜＝B_当前＜B_阈(i)且B_比率阈(j-1)＜＝B_比率＜B_比率阈(j)的 区域。以上描述的栅格的每个单元格诸如通过与存储在存储器中的特定值相关 联之类而被标注以状态值，并且函数NewState(新状态)随后返回与由值B_当前和B_比率(T_现在-T_x)指示的单元格相关联的状态值。

在另一实施例中，可令迟滞值与每个阈值相关联。在该增强型方法中，对 函数NewState的求值可基于使用一组临时修改的阈值如下构造的临时划分。 对于小于与在对NewState的上次求值时所选取的单元格相对应的B_当前范围的 每个B_当前阈值，通过减去与该阈值相关联的迟滞值来减小该阈值。对于大于与 在对NewState的上次求值时所选取的单元格相对应的B_当前范围的每个B_当前阈 值，通过加上与该阈值相关联的迟滞值来增大该阈值。对于小于与在对 NewState的上次求值时所选取的单元格相对应的B_比率范围的每个B_比率阈值， 通过减去与该阈值相关联的迟滞值来减小该阈值。对于大于与在对NewState 的上次求值时所选取的单元格相对应的B_比率范围的每个B_比率阈值，通过加上与 该阈值相关联的迟滞值来增大该阈值。经修改的阈值被用来对NewState的值 进行求值并且随后这些阈值返回其原始值。

在阅读本公开之际，定义空间的划分的其他方式对于本领域技术人员将变 得明显。例如，划分可通过使用基于B_比率和B_当前的线性组合的不等式，例如 α0、α1和α2为实数值的α1·B_比率+α2·B_当前≤α0形式的线性不等式阈值来定 义，以定义整个空间内的半空间以及将每个不相交集合定义为数个此类半空间 的交集。

以上描述是为了解说基本过程。如实时编程领域的技术人员在阅读本公开 之际将清楚的，高效实现是可能的。例如，每次将新信息提供给缓冲监视器126 时，就有可能演算若例如不接收块的进一步的数据则NewState将转移到新值 的将来时间。随后为该时间设置定时器并且在没有进一步的输入的情况下，该 定时器的期满将导致新的状态值被发送给块选择器123。因此，只需要在有新 信息被提供给缓冲监视器126时或者在定时器期满时执行计算，而无需连续地 执行。

状态的合适值可为“低”、“稳定”和“满”。合适的阈值集合和所得单 元栅格的示例在图15中示出。

在图15中，B_当前阈值以毫秒在横轴上示出，迟滞值在其下方以“+/-值” 形式示出。B_比率阈值以千分率(即，乘以1000)在纵轴上示出，迟滞值在其下 方以“+/-值”形式示出。“低”、“稳定”和“满”状态值分别在栅格单元中 被标注为“L”、“S”和“F”。

每当有机会请求新块时，块选择器123就接收到来自块请求器124的通知。 如以上所描述的，向块选择器123提供关于可用的这多个块的信息以及这些块 的元数据，包括例如关于每个块的媒体数据率的信息。

关于块的媒体数据率的信息可包括该特定块的实际媒体数据率(即，以字 节计的块大小除以以秒计的播出时间)、块所属的表示的平均媒体数据率、或 为了不暂停地播出该块所属的表示在维系的基础上需要的可用带宽的度量、或 以上的组合。

块选择器123基于缓冲监视器126最新指示的状态值来选择块。在该状态 值为“稳定”时，块选择器123从与先前所选块相同的表示选择块。所选择的 块是包含该呈现中先前未曾请求过其媒体数据的时段的媒体数据的第一块(按 播出次序)。

在该状态值为“低”时，块选择器123从具有比先前所选块的媒体数据率 低的媒体数据率的表示选择块。数个因素会影响该情形中对表示的确切选取。 例如，块选择器123可被提供对传入数据的聚集速率的指示并且可选取具有小 于该值的媒体数据率的表示。

在该状态值为“满”时，块选择器123从具有比先前所选块的媒体数据率 高的媒体数据率的表示选择块。数个因素会影响该情形中对表示的确切选取。 例如，块选择器123可被提供对传入数据的聚集速率的指示并且可选取具有不 高于该值的媒体数据率的表示。

数个附加因素可能进一步影响块选择器123的操作。具体而言，可限制增 大所选块的媒体数据率的频度，即使缓冲监视器126持续指示“满”状态亦然。 此外，块选择器123有可能接收到“满”状态指示但没有更高媒体数据率的块 可用(例如，由于上次所选的块已经对应最高可用媒体数据率)。在这种情形 中，块选择器123可将下一块的选择延迟某个时间，该时间被选取为使得在块 缓冲器125中缓冲的媒体数据总量是上有界的。

附加因素可能影响在选择过程期间考虑的块集合。例如，可用块可被限于 来自其编码分辨率落在提供给块选择器123的特定范围以内的那些表示的块。

块选择器123还可接收来自监视系统的其他方面的其他组件的输入，所监 视的方面诸如是用于媒体解码的计算资源的可用性。若此类资源变得稀缺，则 块选择器123可在元数据内指示其解码的计算复杂性较低的块(例如，具有较 低分辨率或帧率的表示一般具有较低解码复杂性)。

以上描述的实施例带来的实质优点在于，在缓冲监视器126内对NewState 函数求值时使用值B_比率与仅考虑B_当前的方法相比允许在呈现开始时质量更快地 上升。在不考虑B_比率的情况下，可能在累积了大量缓冲的数据后系统才能选择 具有更高媒体数据率以及因此具有更高质量的块。然而，当B_比率值很大时，这 指示可用带宽远高于先前接收到的块的媒体数据率且即使缓冲的数据相对较 少(即，B_当前的值很低)，请求有更高媒体数据率以及因此有更高质量的块仍 是安全的。同样地，若B_比率值很低(例如＜1)，这指示可用带宽已降至先前所 请求的块的媒体数据率之下且因此即使B_当前很高，系统仍将切换到较低的媒体 数据率以及因此较低的质量，以例如避免到达B_当前＝0且媒体的播出停滞的点。 这种改善的行为在其中网络条件以及因此投递速度可能快速且动态地变化(例 如用户向移动设备流送)的环境中可能尤其重要。

使用配置数据来指定(B_当前，B_比率)的值空间的划分带来了另一优点。此类配 置数据可作为呈现元数据的一部分或通过其他动态手段被提供给缓冲监视器 126。在实践部署中，由于用户网络连接的行为在各用户之间以及对于单个用 户而言随时间推移而可能高度可变，因此可能很难预测对于所有用户都将工作 良好的划分。动态地向用户提供此类配置信息的可能性允许随时间推移根据累 积的经验来开发良好的配置设置。

可变请求大小控制

若每个请求针对单个块且若每个块编码短媒体段，则可能需要高频度的请 求。若媒体块很短，则视频播出迅速地在块间移动，这为接收机提供了更频繁 的通过改变表示来调整或改变其所选数据率的机会，从而提高了播出能不停滞 地继续的可能性。然而，高频度的请求的不利方面在于它们在其中客户端至服 务器网络中的可用带宽受约束的某些网络上可能是不能维系的，例如在诸如 3G和4G无线WAN之类的无线WAN网络中，其中从客户端至网络的数据链 路的容量是受限制的或者会由于无线电条件的改变而变为在或短或长的时间 段上受限制。

高频度的请求还意味着服务基础设施的高负荷，这带来容量要求方面的关 联成本。因此，将希望有高频度请求的一些效益而没有所有这些缺点。

在块流送系统的一些实施例中，将高请求频度的灵活性与低频度请求相组 合。在该实施例中，块可以如上所描述地构造并且同样如以上所描述地被聚集 成包含多个块的段。在呈现的开头，应用以上所描述的其中每个请求引用单个 块或者作出多个并发请求以请求块的各部分的过程以确保在呈现的开始有快 速的频道换台时间并且因此有良好的用户体验。随后，当满足将在以下描述的 某个条件时，客户端可发出在单个请求中涵盖多个块的请求。这是可能的，因 为这些块已被聚集成较大文件或段并且可使用字节或时间范围来请求。连贯的 字节或时间范围可被聚集成单个较大的字节或时间范围，从而导致单个请求针 对多个块，并且甚至能在一个请求中请求非连续的块。

可由决定是请求单个块(或部分块)还是请求多个连贯块来驱使的一个基 本配置是使该决定基于所请求块是否很可能被播出。例如，若很可能不久将需 要换到另一表示，则客户端最好作出针对单个块即少量媒体数据的请求。此举 的一个原因在于，若在可能即将要切换至另一表示时作出针对多个块的请求， 那么该切换可能在该请求的最后几个块被播出之前作出。因此，对这最后几个 块的下载可能延迟了对所切换到的表示的媒体数据的投递，这可能导致媒体播 出停滞。

然而，针对单个块的请求的确导致更高频度的请求。另一方面，若不大可 能不久将需要换到另一表示，则可能优选作出针对多个块的请求，因为所有这 些块很可能将被播出，并且这导致较低频度的请求，从而可以大量上降低请求 开销，典型地在表示中没有即将来临的改变的情况下尤其如此。

在常规的块聚集系统中，每个请求中所请求的量不是动态地调整的，即典 型地每个请求针对整个文件，或者每个请求针对与表示的文件大致相同的量 (有时以时间度量，有时以字节度量)。因此，若所有请求都较小，则请求开 销较高，而若所有请求都较大，则这增加了媒体停滞事件的机会和/或在选取了 较低质量表示以避免不得不随着网络条件变化而迅速改变表示的情况下增加 了提供较低质量媒体播出的机会。

在被满足时可导致后续请求引用多个块的条件的示例是对缓冲器大小B_当前的阈值。若B_当前低于该阈值，则发出的每个请求引用单个块。若B_当前大于或 等于该阈值，则发出的每个请求引用多个块。若发出引用多个块的请求，则每 单个请求中所请求的块数目可按若干种可能方式之一来决定。例如，该数目可 以是常数，例如2。替换地，单个请求中所请求的块数目可取决于缓冲器状态 并且尤其是取决于B_当前。例如，可以设置数个阈值，其中单个请求中所请求的 块数目是从小于B_当前的多个阈值中的最高阈值来推导的。

在被满足时可导致请求引用多个块的条件的另一示例是以上描述的“状 态”值变量。例如，当状态为“稳定”或“满”时，则可发出针对多个块的请 求，但当状态为“低”时，则所有请求可针对一个块。

另一实施例在图16中示出。在该实施例中，当将发出下一请求时(在步 骤1300中决定)，使用当前状态值和B_当前来决定下一请求的大小。若当前状 态值为“低”、或当前状态值为“满”且当前表示不是最高可用的表示(在步 骤1310中确定，答案为“是”)，则下一请求被选取为短请求，例如仅针对 下一块(在步骤1320中确定块并作出请求)。此举背后的基本原理在于，这 些条件是其中很可能很快将有表示改变的条件。若当前状态值为“稳定”、或 当前状态值为“满”且当前表示是最高可用的表示(在步骤1310中确定，答 案为“否”)，则下一请求中所请求的连贯块的历时对于某个固定的α＜1被 选取为与B_当前的α分数成比例(在步骤1330中确定块，在步骤1340中作出请 求)，例如对于α＝0.4，若B_当前＝5秒，则下一请求可针对约2秒的块，而若 B_当前＝10秒，则下一请求可针对约4秒的块。此举背后的一个基本原理在于 在这些条件下，在与B_当前成比例的时间量里将不大可能作出向新表示的切换。

灵活管线化

块流送系统可使用具有例如TCP/IP之类的特定底层传输协议的文件请求 协议。在TCP/IP或其他传输协议连接的开头，可能要花某个相当长的时间来 达成对全部可用带宽的利用。这可能导致在每次开始新连接时都有“连接启动 惩罚”。例如，在TCP/IP的情形中，连接启动惩罚由于初始TCP握手建立连 接所花的时间以及拥塞控制协议达成对可用带宽的完全利用所花的时间两者 而发生。

在该情形中，可能希望使用单个连接来发出多个请求，以降低招致连接启 动惩罚的频度。然而，例如HTTP之类的一些文件传输协议不提供并非将传输 层连接完全关闭而是取消请求的机制，并且因此在建立新连接来代替旧连接时 招致连接启动惩罚。若确定可用带宽已改变并且改为要求不同的媒体数据率， 即决定切换到不同的表示，则发出的请求可能需要被取消。取消发出的请求的 另一原因可能是用户已请求结束媒体呈现并且开始新呈现(或许是在该呈现的 不同点的相同内容项、或者或许是新内容项)。

如已知的，可通过保持连接打开并对后续请求重用相同的连接来避免连接 启动惩罚，并且如同样已知的，若在相同的连接上同时发出多个请求(在HTTP 的上下文中被称为“管线化”的技术)，则连接可保持充分利用。然而，同时 地或者更一般地以使得连接上有多个请求在先前请求完成之前发出的方式发 出多个请求的缺点可能在于，该连接随后要负责携带对这些请求的响应并且因 此若希望改变应当发出的请求，则该连接可能会被关闭——若需要取消已发出 但不再想要的请求。

所发出的请求需要被取消的概率可部分地取决于发出该请求与所请求块 的播出时间之间的时间区间的历时，部分取决于的意义是指：当该时间区间大 时，所发出的请求需要被取消的概率也高(因为在该区间期间可用带宽很可能 改变了)。

如已知的，一些文件下载协议具有单个底层传输层连接可有利地被用于多 个下载请求的性质。例如，HTTP具有该性质，因为将单个连接重用于多个请 求对于除第一个请求以外的其他请求避免了以上描述的“连接启动惩罚”。然 而，该办法的缺点在于该连接要负责传输每个所发出请求中所请求的数据，且 因此若一个或多个请求需要被取消，则要么该连接可能被关闭，从而在建立取 代连接时招致连接启动惩罚，要么客户端可能等待接收不再需要的数据，从而 在接收后续数据时招致延迟。

现在描述留存连接重用的优点而不招致该缺点并且还附加地提高连接能 被重用的频度的实施例。

本文中描述的块流送系统的实施例被配置成对多个请求重用连接而不必 一开始就承诺由该连接负责特定的一组请求。实质上，在现有连接上的已发出 的请求尚未完成但接近完成时在该连接上发出新请求。不等待直至现有请求完 成的一个原因在于，若先前的请求完成则连接速度可能降级，即，底层TCP 会话可能进入空闲状态或者TCP cwnd变量可能被显著地减小，藉此显著降低 该连接上发出的新请求的初始下载速度。在发出额外请求之前等待直至接近完 成的一个原因在于，因为若新请求是在先前请求完成之前很久就发出的，则新 发出的请求可能甚至在某个很长时间段内不开动，并且有可能在新发出的请求 开动之前的该时间段期间，作出新请求的决定不再有效，例如由于决定切换表 示而导致上述情形。因此，实现该技术的客户端的实施例将在不减慢连接的下 载能力的情况下尽可能晚地在该连接上发出新请求。

该方法包括监视响应于在连接上发出的最晚请求在该连接上接收到的字 节数目并对该数目应用测试。这可以通过使接收机(或发射机，若适用)配置 成进行监视和测试来进行。

若测试通过，则可在该连接上发出另一请求。合适的测试的一个示例是接 收到的字节数目是否大于所请求数据的大小的固定分数。例如，该分数可以为 80％。合适的测试的另一示例基于以下演算，如图17中所解说的。在该演算 中，令R为对该连接的数据率的估计，T为对往返行程时间(“RTT”)的估 计，并且X为例如可以是设为0.5与2之间的值的常数的数值因子，其中对R 和T的估计在定期的基础上更新(在步骤1410中更新)。令S为最晚请求中 所请求的数据的大小，B为所请求的数据中接收到的字节数目(在步骤1420 中演算)。

合适的测试将是使接收机(或发射机，若适用)执行评估不等式(S-B)＜ X·R·T的例程(在步骤1430中测试)，并且若“是”则采取行动。例如，可 作出测试以查看是否有另一个请求准备好要在该连接上发出(在步骤1440中 测试)，并且若“是”则向该连接发出该请求(步骤1450)并且若“否”则本 过程返回步骤1410以继续更新和测试。若步骤1430中的测试的结果是“否”， 则本过程返回步骤1410以继续更新和测试。

步骤1430中的不等式测试(例如由恰适地编程的元件来执行)导致在待 接收的剩余数据量等于X乘以在一个RTT内以当前估计的接收速率能接收的 数据量时发出每个后续请求。数种在步骤1410中估计数据率R的方法是本领 域已知的。例如，数据率可估计为Dt/t，其中Dt是在之前t秒中接收到的比 特数目并且其中t可以是例如1秒或0.5秒或其他某个区间。另一种方法是对 传入数据率的指数加权平均或一阶无限冲激响应(IIR)滤波。数种在步骤1410 中估计RTT “T”的方法是本领域已知的。

步骤1430中的测试可应用于接口上所有活跃连接的聚集，如以下更详细 地解释的。

该方法进一步包括构造候选请求列表，将每个候选请求与可向其作出该请 求的一组合适服务器相关联，并且按优先级次序排序该候选请求列表。候选请 求列表中的一些条目可具有相同的优先级。与每个候选请求相关联的合适服务 器列表中的服务器由主机名来标识。每个主机名对应于可从域名系统获得的一 组网际协议地址，这是公知的。因此，候选请求列表上的每个可能的请求与一 组网际协议地址相关联，具体而言是与该候选请求的关联服务器的关联主机名 的关联的各组网际协议地址的并集相关联。每当连接满足步骤1430中描述的 测试并且该连接上尚未发出新请求时，就选取候选请求列表上与该连接的目的 地的网际协议地址相关联的最高优先级请求，并且在该连接上发出该请求。还 将该请求从候选请求列表中移除。

候选请求可从候选请求列表移除(取消)，具有高于候选列表上的已有请 求的优先级的新请求可被添加到候选列表，并且候选列表上的现有请求的优先 级可改变。有哪些请求在候选请求列表上这一动态本质以及其在候选列表上的 优先级这一动态本质可取决于何时满足步骤1430中描述的类型的测试而更改 接下来可发出哪些请求。

例如，有可能若在某个时间t对步骤1430中描述的测试的回答为“是”， 则发出的下一请求将为请求A，而若对步骤1430中描述的测试的回答并非为 “是”直至某个时间t′＞t，则发出的下一请求将改为是请求B，因为请求A在 时间t与t′之间从候选请求列表被移除，或者由于在时间t与t′之间优先级比请 求A高的请求B被添加到候选请求列表，或者由于请求B在时间t时已在该 候选列表上但优先级比请求A低，并且在时间t与t′之间，请求B的优先级被 改为高于请求A的优先级。

图18解说了候选请求列表上的请求列表的示例。在该示例中，有三个连 接，并且候选列表上有6个请求，标示为A、B、C、D、E和F。候选列表上 的每个请求可在如所指示的连接子集上发出，例如请求A可在连接1上发出， 而请求F可在连接2或连接3上发出。每个请求的优先级也在图18中标示， 并且较低的优先级值指示请求有较高优先级。因此，具有优先级0的请求A和 B是最高优先级请求，而具有优先级值3的请求F是候选列表上的请求中的最 低优先级。

若在该时间点t，连接1通过了步骤1430中描述的测试，则在连接1上发 出请求A或请求B。若改为是连接3在该时间t通过了步骤1430中描述的测 试，则在连接3上发出请求D，因为请求D是能在连接3上发出的具有最高优 先级的请求。

假设对于所有连接，从时间t到某个稍后的时间t′对步骤1430中描述的测 试的答案皆为“否”，并且在时间t与t′之间，请求A的优先级从0改变为5， 请求B从候选列表被移除，并且具有优先级0的新请求G被添加到该候选列 表。随后，在时间t′，新候选列表可如图19中所示。

若在时间t′连接1通过了步骤1430中描述的测试，则在连接1上发出优 先级为4的请求C，因为它是候选列表上在该时间点能在连接1上发出的的最 高优先级请求。

假设在该相同的情形中改为在时间t在连接1上本来发出了请求A(其为 如图18中所示的在时间t对连接1而言两个最高优先级选择之一)。由于从时 间t到某个稍后的时间t′对于所有连接而言步骤1430中描述的测试的答案皆为 “否”，因此连接1仍为在时间t之前发出的请求投递数据直到至少时间t′， 且因此请求A在至少时间t′之前将不会开动。在时间t′发出请求C是比本来在 时间t发出请求A更好的决定，因为请求C在t′之后与请求A本来将开动的时 间相同的时间开动，并且因为截至该时间，请求C比请求A具有更高优先级。

作为另一替换方案，若步骤1430中描述的类型的测试应用于活跃连接的 聚集，则可选取其目的地的网际协议地址与候选请求列表上的第一个请求或同 所述第一个请求具有相同优先级的另一请求相关联的连接。

有数种方法可用于构造候选请求列表。例如，候选列表可包含代表对呈现 的当前表示按时间顺序次序的接下来n个数据部分的请求的n个请求，其中对 最早数据部分的请求具有最高优先级而对最晚数据部分的请求具有最低优先 级。在一些情形中，n可以为1。n的值可取决于缓冲器大小B_当前，或状态变 量或客户端缓冲器占用率的状态的其他度量。例如，可为B_当前设置数个阈，并 且有值与每个阈相关联，随后将n的值取为与小于B_当前的最高阈相关联的值。

以上描述的实施例确保了灵活地将请求分配给连接，从而确保向重用现有 连接给予优待，即使最高优先级请求不适合该连接(因为该连接的目的地IP 地址不是分配给与该请求相关联的任何主机名的那一IP地址)亦然。n对B_当前或客户端缓冲器占用率的状态或其他度量的依存性确保了在客户端亟需发出 和完成与按时间顺序要播出的下一数据部分相关联的请求时，此类“脱离优先 级次序”的请求不被发出。

这些方法可有利地与协作式HTTP和FEC相组合。

一致性的服务器选择

如公知的，将使用文件下载协议来下载的文件通常由包括主机名和文件名 的标识符来标识。例如，HTTP协议就是这种情形，在该情形中，标识符是统 一资源标识符(URI)。主机名可对应于由各网际协议地址标识的多个主机。 例如，这是跨多个物理机器分摊来自多个客户端的请求负荷的常见方法。具体 而言，该办法常被内容投递网络(CDN)采用。在这种情形中，在连接上向任 何物理主机发出的请求预期将成功。已知有多种可供客户端用来从与主机名相 关联的各网际协议地址中进行选择的方法。例如，这些地址通常经由域名系统 提供给客户端并按优先级次序提供。客户端随后可选取最高优先级(第一)网 际协议地址。然而，一般而言，客户端之间就如何作出该选取并没有协调，因 此不同客户端可能向不同服务器请求相同的文件。这可能导致相同的文件被存 储在近旁多个服务器的高速缓存中，这降低了高速缓存基础设施的效率。

这可以由有利地增加请求相同块的两个客户端将向相同服务器请求该块 的概率的系统来处置。此处描述的新颖方法包括以由要请求的文件的标识符来 决定的方式并以使得被呈示了相同或相似的网际协议地址和文件标识符选择 的不同客户端将作出相同选取的方式从可用网际协议地址中进行选择。

参考图20来描述该方法的第一实施例。客户端首先获得一组网际协议地 址IP₁、IP₂、...、IP_n，如步骤1710中所示。若如步骤1720中确定的有要针对 其发出请求的文件，则客户端决定用哪个网际协议地址来发出对该文件的请 求，如步骤1730-1770中所决定的。给定一组网际协议地址和要请求的文件的 标识符，该方法包括以由该文件标识符所决定的方式排序这些网际协议地址。 例如，对于每个网际协议地址，构造出包括该网际协议地址与该文件标识符的 级联的字节串，如步骤1730中所示。向该字节串应用散列函数，如步骤1740 中所示，并且根据固定排序，例如数值升序，来排列所得的散列值，如步骤1750 中所示，从而引起网际协议地址的排序。相同散列函数可被所有客户端使用， 因此保证对于所有客户端的给定输入，该散列函数产生相同的结果。该散列函 数可被静态地配置到客户端集合中的所有客户端中，或者客户端集合中的所有 客户端可在这些客户端获得网际协议地址列表时获得该散列函数的部分或完 整描述，或者客户端集合中的所有客户端可在这些客户端获得文件标识符时获 得该散列函数的部分或完整描述，或者该散列函数可由其他手段确定。该排序 中的首个网际协议地址被选取并且该地址随后被用来建立连接并发出对该文 件的全部或部分的请求，如步骤1760和1770中所示。

以上方法可在建立新连接以请求文件时应用。它还可在有多个建成的连接 可用时应用，并且这些连接中的一个可被选取来发出新请求。

此外，当有建成的连接可用并且可从具有相等优先级的候选请求的集合中 选取请求时，例如通过以上描述的相同的散列值方法引起对候选请求的排序， 并且该排序中首个出现的候选请求被选取。这些方法可被组合以从一组连接和 具有相等优先级的请求中同样通过计算连接与请求的每个组合的散列、根据固 定排序对这些散列值进行排序、并选取对请求与连接的组合的集合引起的排序 中首个出现的组合来选择连接和候选请求两者。

该方法出于以下原因具有优点：诸如图1(BSI 101)或图2(BSI 101)中 所示的块供应基础设施采取的典型办法、尤其是CDN通常采取的办法是提供 多个接收客户端请求的高速缓存代理服务器。高速缓存代理服务器可能并未装 有给定请求中所请求的文件并且在这种情形中，此类服务器典型地将该请求转 发给另一服务器，接收来自该服务器的响应(典型地包括所请求的文件)，并 将该响应转发给客户端。高速缓存代理服务器也可存储(高速缓存)所请求的 文件，从而它能立即响应对该文件的后续请求。以上描述的常用办法具有以下 性质：存储在给定高速缓存代理服务器上的文件集很大程度上是由该高速缓存 代理服务器已接收到的请求集合来决定的。

以上描述的方法具有以下优点。若客户端集合中的所有客户端被提供相同 的网际协议地址列表，则这些客户端将对针对相同文件发出的所有请求使用相 同的网际协议地址。若存在两个不同的网际协议地址列表并且每个客户端被提 供这两个列表之一，则客户端对针对相同文件发出的所有请求将使用至多两个 不同的网际协议地址。一般而言，若提供给客户端的网际协议地址列表是相似 的，则这些客户端将对针对相同文件发出的所有请求使用所提供的网际协议地 址的小集合。由于近程的客户端倾向于被提供相似的网际协议地址列表，因此 很可能近程客户端会向这些客户端可用的高速缓存代理服务器的仅小部分发 出对文件的请求。因此，将只有很小分数的高速缓存代理服务器高速缓存该文 件，这有利地使用于高速缓存该文件的高速缓存资源量最小化。

优选地，散列函数具有以下性质：很小分数的不同输入被映射到相同的输 出，且不同输入被映射到本质上随机的输出，以确保对于给定的网际协议地址 集合，使网际协议地址中给定的一个地址在由步骤1750产生的经分序列表中 为首个地址的文件比例对于该列表中的所有网际协议地址大致相同。另一方 面，重要的是该散列函数是确定性的，确定性的意义是指：对于给定输入，该 散列函数的输出对于所有客户端都相同。

以上描述的方法的另一优点如下。假设客户端集合中的所有客户端被提供 相同的网际协议地址列表。由于该散列函数的刚才描述的这些性质，很可能来 自这些客户端的对不同文件的请求将均匀地跨该组网际协议地址分摊，这进而 意味着这些请求将跨高速缓存代理服务器均匀分摊。因此，用于存储这些文件 的高速缓存资源跨高速缓存代理服务器均匀分摊，且对文件的请求跨这些高速 缓存代理服务器均匀分摊。因此，该方法提供跨高速缓存基础设施的存储平衡 和负荷平衡两者。

以上描述的办法的多种变形为本领域技术人员所知的，并且在许多情形 中，这些变形留存了存储在给定代理上的文件集是至少部分地由该高速缓存代 理服务器已接收到的请求集合决定这一性质。在其中给定主机名解析到多个物 理高速缓存代理服务器的常见情形中，所有这些服务器将最终存储任何被频繁 请求的给定文件的副本将会是很常见的。此类重复可能是不可取的，因为高速 缓存代理服务器上的存储资源是有限的，且因此文件有时可能会从高速缓存被 移除(清空)。此处描述的新颖方法确保了对给定文件的请求以减少这种重复 的方式被定向到高速缓存代理服务器，藉此减少从高速缓存移除文件的需要并 且藉此增大任何给定文件存在于该代理高速缓存中(即，尚未从其清空)的可 能性。

当文件存在于代理高速缓存中时，向客户端发送的响应更快，这具有减少 所请求的文件晚到的概率的优点，所请求文件晚到会导致媒体播出的暂停并且 因此导致不良的用户体验。此外，当文件不存在于代理高速缓存中时，该请求 可被发送给另一服务器，从而既造成服务基础设施上又造成服务器之间的网络 连接上的额外负荷。在许多情形中，请求所发往的服务器可能位于遥远位置并 且从该服务器向高速缓存代理服务器回传该文件可能招致传输成本。因此，此 处描述的新颖方法使得这些传输成本能得以减少。

概率性全文件请求

将HTTP协议与范围请求联用的情形中特别的关注点是通常用来提供服 务基础设施中的可伸缩性的高速缓存服务器的行为。虽然HTTP高速缓存服务 器支持HTTP范围头部可能是常见的，但不同HTTP高速缓存服务器的确切行 为因实现而变化。大多数高速缓存服务器实现在文件在高速缓存中可用的情形 中从该高速缓存来服务范围请求。HTTP高速缓存服务器的常用实现总是将包 含范围头部的下游HTTP请求转发给上游节点，除非该高速缓存服务器具有该 文件的副本(高速缓存服务器或原始服务器)。在一些实现中，对该范围请求 的上游响应是整个文件，并且该整个文件被高速缓存且从该文件提取对下游范 围请求的响应并发送该响应。然而，在至少一种实现中，对范围请求的上游响 应只是范围请求本身中的数据字节，且这些数据字节不被高速缓存而是只作为 对下游范围请求的响应被发送。因此，客户端使用范围头部可能的后果是文件 本身从不被放入高速缓存且网络的可取的可伸缩性性质将会丢失。

在上述内容中，描述了高速缓存代理服务器的操作，并且还描述了从作为 多个块的聚集的文件来请求块的方法。例如，这可以通过使用HTTP范围请求 头部来达成。此类请求在下文被称为“部分请求”。现在描述另一实施例，其 在块供应基础设施101不提供对HTTP范围头部的完全支持的情形中具有优 点。通常，块供应基础设施内的服务器例如内容投递网络支持部分请求，但可 能不在本地存储(高速缓存)中存储对部分请求的响应。此类服务器可通过将 请求转发给另一服务器来履行部分请求，除非完整文件被存储在本地存储中， 在后一种情形中可在不将请求转发给另一服务器的情况下发送响应。

利用以上描述的对块聚集的新颖增强的块请求流送系统在块供应基础设 施显现该行为的情况下可能性能不良，因为实为部分请求的所有请求将被转发 给另一服务器并且没有任何请求将由高速缓存代理服务器来服务，这首先就使 提供高速缓存代理服务器所为的目的落空。在如上描述的块请求流送过程期 间，客户端可能在某个时刻请求处在文件开头的块。

根据此处描述的新颖方法，每当满足某个条件时，便可将此类请求从对文 件中的首个块的请求转换成对整个文件的请求。当高速缓存代理服务器接收到 对整个文件的请求时，该代理服务器通常存储响应。因此，这些请求的使用使 得文件被放入本地高速缓存代理服务器的高速缓存中，以使得后续请求无论是 针对全文件的还是部分请求均可直接由该高速缓存代理服务器来服务。该条件 可以是使得在与给定文件相关联的请求集合(例如由观看所议的内容项的一组 客户端生成的请求的集合)中，该条件至少对于这些请求中的规定的分数而言 将是满足的。

合适条件的示例是随机选取的数字高于所规定的阈值。该阈值可被设置成 使得将单块请求转换成全文件请求的这种转换平均而言对这些请求中规定的 分数发生，例如10个请求里面发生一次(在这种情形中，可从区间[0，1]选取 该随机数并且阈值可为0.9)。合适条件的另一示例是对与块相关联的一些信 息以及与客户端相关联的一些信息演算出的散列函数取所规定的值集合中的 一个值。该方法具有以下优点：对于被频繁请求的文件，该文件将被放入本地 高速缓存代理服务器的高速缓存中，然而块请求流送系统的操作与其中每个请 求针对单个块的标准操作相比没有明显更改。在许多情形中，在发生将请求从 单块请求转换成全文件请求的场合，客户端规程本将接着请求该文件内的其他 块。如果是这种情形，则此类请求可被抑制，因为所议的块无论如何都将作为 全文件请求的结果被接收到。

URL构造以及段列表生成和查找

段列表生成应对客户端在特定的客户端本地时间“现在”如何从MPD来 为始于某个开始时间“starttime”的特定表示生成段列表的问题，其中该开始 时间“starttime”对于点播情形而言是相对于媒体呈现的开始而言的，或者是 以壁钟时间来表达的。段列表可包括定位符，例如指向可任选的初始表示元数 据的URL，以及媒体段列表。每个媒体段可能已被指派开始时间、历时和定位 符。开始时间典型地表达段中所包含媒体的媒体时间的近似，但不一定是样本 准确时间。开始时间被HTTP流送客户端用来在恰适的时间发出下载请求。段 列表(包括每个段的开始时间)的生成可按不同方式进行。URL可作为播放列 表提供，或者URL构造规则可被有利地用于段列表的紧凑表示。

可例如执行基于URL的段列表构造——若MPD通过诸如文件动态信息 (FileDynamicInfo)或等效信号之类的特定属性或元素来信令通知这一点。以 下在“URL构造概览”小节中提供从URL构造创建段列表的普适方式。基于 播放列表的构造可例如由不同信号来信令通知。本上下文中还有利地实现在段 列表中查找以及到达准确的媒体时间的功能。

URL构造器概览

如先前描述的，在本发明的一个实施例中，可提供包含URL构造规则的 元数据文件，这些URL构造规则允许客户端设备构造呈现的块的文件标识符。 现在描述对块请求流送系统的进一步新颖增强，其提供元数据文件的改变，包 括URL构造规则的改变、可用编码的数目的改变、与可用编码相关联的元数 据诸如比特率、纵横比、分辨率、音频或视频编解码器或编解码参数或其他参 数的改变。

在该新颖增强中，可提供与元数据文件的每个元素相关联的指示在整个呈 现内的时间区间的附加数据。在该时间区间内，该元素可被视为有效，而除该 时间区间以外，该元素可被忽略。此外，可增强元数据的句法，以使得先前允 许出现仅一次或至多一次的元素可出现多次。在这种情形中可应用附加限制， 其规定对于此类元素，指定的时间区间必须不相交。在任何给定时刻，仅考虑 其时间区间包含此给定时刻的元素就将得到与原始元数据句法相一致的元数 据文件。将此类时间区间称为有效性区间。该方法因此提供了在单个元数据文 件内信令通知上述种类的改变的手段。有利地，此类方法可用来提供在呈现内 的指定点支持所描述的种类的改变的媒体呈现。

URL构造器

如本文中所描述的，块请求流送系统的常见特征是需要向客户端提供“元 数据”，元数据标识可用媒体编码并提供客户端请求来自这些编码的块所需的 信息。例如，在HTTP的情形中，该信息可包括包含媒体块的文件的URL。可 提供播放列表文件，其列出给定编码的块的URL。提供多个播放列表文件，每 个文件针对一种编码，连同列出与不同编码相对应的播放列表的“关于播放列 表的主播放列表”。该系统的缺点在于元数据可能变得相当大，且因此在客户 端开始流时要花一定时间来请求元数据。该系统的另一缺点在实况内容的情形 中是明显的，此时与媒体数据块相对应的文件是从正被实时地(实况)捕捉的 媒体流(例如实况体育比赛或新闻节目)“在运行中”生成的。在这种情形中， 可在每次有新块可用时(例如，每几秒)更新播放列表文件。客户端设备可重 复地取回该播放列表文件以确定是否有新块可用并获得其URL。这可能对服务 基础设施造成显著负荷，并且尤其意味着元数据文件不能被高速缓存比更新间 隔更久的时间，更新间隔等于通常为几秒的量级的块大小。

块请求流送系统的一个重要方面是用于向客户端通知应当与文件下载协 议一起用来请求块的文件标识符(例如URL)的方法。例如，其中对于呈现的 每个表示都提供播放列表文件的方法，该播放列表文件列出包含媒体数据块的 文件的URL。该方法的缺点在于播放列表文件本身的至少一些需要被下载后播 出才能开始，这增加了频道换台时间并且因此导致不良用户体验。对于具有若 干或许多表示的长媒体呈现，文件URL的列表可能很大，并且因此播放列表 文件可能很大，这进一步增加了频道换台时间。

该方法的另一缺点发生在实况内容的情形中。在这种情形中，不会事先就 有完整的URL列表可用，且播放列表文件随着有新块变为可用而被周期性地 更新，并且客户端周期性地请求该播放列表文件以接收经更新版本。由于该文 件被频繁更新，因此其不能被长时间存储在高速缓存代理服务器内。这意味着 对该文件的很多请求将被转发给其他服务器并最终转发给生成该文件的服务 器。在受欢迎的媒体呈现的情形中，这可能对该服务器以及网络造成高负荷， 进而可能导致响应时间很慢并因此导致频道换台时间很长且用户体验不良。在 最差情形中，服务器变得过载，并且这导致一些用户不能观看该呈现。

在块请求流送系统的设计中希望避免对可使用的文件标识符的形式加以 限制。这是由于多种考虑可能激发使用特定形式的标识符的动机。例如，在块 供应基础设施是内容投递网络的情形中，可能存在与跨网络分布存储或服务负 荷的愿望或其他要求相关的文件命名或存储惯例，这导致在系统设计时不能预 测的特定形式的文件标识符。

现在描述另一实施例，其缓解了上述缺点而同时留存选取恰适文件标识惯 例的灵活性。在该方法中，可为媒体呈现的每个表示提供包括文件标识符构造 规则的元数据。文件标识符构造规则可例如包括文本串。为了确定呈现的给定 块的文件标识符，可提供解读文件标识符构造规则的方法，该方法包括确定输 入参数以及将文件标识构造规则连同这些输入参数一起求值。输入参数可例如 包括要标识的文件的索引，其中第一文件具有索引0，第二文件具有索引1， 第三文件具有索引2，依此类推。例如，在每个文件跨越相同时间历时(或大 致相同的时间历时)的情形中，则与呈现内任何给定时间相关联的文件的索引 可容易地确定。替换地，呈现内由每个文件跨越的时间可在呈现或版本元数据 内提供。

在一个实施例中，文件标识符构造规则可包括文本串，该文本串可包含与 输入参数相对应的某些特殊标识符。文件标识符构造规则的求值方法包括确定 这些特殊标识符在该文本串内的位置，以及用相应的输入参数的值的串表示来 取代每个此类特殊标识符。

在另一实施例中，文件标识符构造规则可包括遵循表达语言的文本串。表 达语言包括该语言的表达可遵循的句法的定义以及用于对遵循该句法的串求 值的规则集。

现在将参照图21及下列等等来描述具体示例。图21中示出对以增广巴科 斯-诺尔范式(Augmented Backus Naur Form)定义的合适表达式语言的句法定 义的示例。用于对遵循图21中的<表达式>产生式的串的规则求值的示例包括 如下将遵循<表达式>产生式的串(<表达式>)递归地变换成遵循<字面>产生 式的串：

遵循<字面>产生式的<表达式>不变。

遵循<变量>产生式的<表达式>用由该<变量>产生式的<令牌>串标识的变 量的值来替代。

遵循<函数>产生式的<表达式>通过如下描述地根据这些规则来对其每个 自变量求值并向这些自变量应用取决于<函数>产生式的<令牌>元素的变换来 求值。

遵循<表达式>产生式的最后选项的<表达式>通过如下描述地对这两个< 表达式>元素求值并向这些自变量应用取决于<表达式>产生式的此最后选项的 <运算符>元素的运算来求值。

在以上描述的方法中，假定求值发生在其中可定义多个变量的上下文中。 变量是(名称，值)对，其中“名称”是遵循<令牌>产生式的串，而“值”是遵 循<字面>产生式的串。一些变量可在求值开始前在求值过程外部定义。其他变 量可在求值过程本身内部定义。所有变量都是“全局”的，“全局”的意义是 指对于每个可能的“名称”仅存在一个变量。

函数的示例是“printf”函数。该函数接受一个或更多个自变量。第一自 变量可遵循<串>产生式(下文称为“串”)。printf函数求值得到其第一自变 量的经变换版本。所应用的变换与C标准库的“printf”函数相同，其中<函数 >产生式中包括的附加自变量供应C标准库printf函数预期的附加自变量。

函数的另一示例是“hash(散列)”函数。该函数接受两个自变量，其中 第一个自变量可以是串，而第二个自变量可遵循<数字>产生式(下文称为“数 字”)。“hash”函数向第一自变量应用散列算法并返回为小于第二自变量的 非负整数结果。合适散列函数的示例在图22中所示的C函数中给出，其自变 量为输入串(排除包封的引号)以及数值输入值。散列函数的其他示例对本领 域技术人员是公知的。

函数的另一示例是取一个、两个或三个串自变量的“Subst”函数。在供 应一个自变量的情形中，“Subst”函数的结果是第一自变量。在供应两个自变 量的情形中，则“Subst”函数的结果通过在第一自变量内擦除第二自变量(排 除包封的引号)的任何出现并返回经如此修改的第一自变量来计算。在供应三 个自变量的情形中，则“Subst”函数的结果通过在第一自变量内用第三自变量 (排除包封的引号)来替代第二自变量(排除包封的引号)的任何出现并返回 经如此修改的第一自变量来计算。

运算符的一些示例是加、减、除、乘和模运算符，分别由<运算符>产生 式‘+’、‘-’、‘/’、‘*’、‘％’标识。这些运算符要求<运算符>产生 式任一侧的<表达式>产生式求值均得到数字。运算符的求值包括以常规方式向 这两个数字应用恰适的算术运算(分别为加、减、除、乘和模)并返回遵循< 数字>产生式的形式的结果。

运算符的另一示例是赋值运算符，由<运算符>产生式‘＝’标识。该运算 符要求左边的自变量求值得到串，其内容遵循<令牌>产生式。串的内容被定义 为包封的引号内的字符串。等于运算符导致其名称为等于左边自变量的内容的 <令牌>的变量被赋于等于对右边自变量求值的结果的值。该值也是对该运算符 表达式求值的结果。

运算符的另一示例是顺序运算符，由<运算符>产生式‘；’标识。对该运 算符求值的结果是右边的自变量。注意，与所有运算符一样，两个自变量均被 求值并且左边的自变量先被求值。

在本发明的一个实施例中，文件的标识符可通过根据以上规则用标识所要 求的文件的特定的一组输入变量对文件标识符构造规则求值来获得。输入变量 的示例是名称为“index(索引)”且值等于该文件在呈现内的数值索引的变量。 输入变量的另一示例是名称为“bitrate(比特率)”且值等于呈现的所要求版 本的平均比特率的变量。

图23解说了文件标识符构造规则的一些示例，其中输入变量是给出想要 的呈现的表示的标识符的“id”以及给出文件的序列号的“seq”。

如本领域技术人员在阅读本公开之际将清楚的，以上方法的许多变形是可 能的。例如，可以并非提供以上描述的函数和运算符的全部，或者可提供外加 的函数或运算符。

URL构造规则和时基

本节提供基本URI构造规则，以指派文件或段URI以及每个段在表示和 媒体呈现内的开始时间。

对于本条，假定客户端处有媒体呈现描述可用。

假定HTTP流送客户端正在播出在媒体呈现内下载的媒体。HTTP客户端 的实际呈现时间可用呈现时间相对于呈现开始在何处来定义。在初始化时，可 假定呈现时间t＝0。

在任何点t，HTTP客户端可下载播放时间tP(也是相对于呈现的开始而 言的)比实际呈现时间t提前至多“MaximumClientPreBufferTime(最大客户 端预缓冲时间)”的任何数据、以及由于用户交互(例如，查找、快进等)而 需要的任何数据。在一些实施例中，“最大客户端预缓冲时间”甚至可以不被 指定，不被指定的意义是指客户端能无限制地下载比当前播放时间提前(tP) 的数据。

HTTP客户端可避免下载不必要的数据，例如，来自预期不会播出的表示 的任何段可能典型地不被下载。

提供流送服务的基本过程可以是通过生成下载整个文件/段或文件/段子集 的恰适请求，例如通过使用HTTP获取请求或HTTP部分获取请求来下载数据。 本描述解决了如何访问特定播出时间tP的数据，但一般而言，客户端可下载 更大时间范围的播放时间的数据以避免低效率请求。HTTP客户端可使得在提 供流送服务时的HTTP请求的数目/频度最小化。

为了访问特定表示中在播放时间tP或至少接近播放时间tP的媒体数据， 客户端确定指向包含该播放时间的文件的URL并且另外确定该文件中用于访 问该播放时间的字节范围。

媒体呈现描述可例如通过使用RepresentationID(表示ID)属性向每个表 示指派表示id“r”。换言之，MPD的该内容在由摄取系统写时或在被客户端 读时将被解读成存在指派。为了下载id为r的特定表示的特定播放时间tP的 数据，客户端可构造针对文件的恰适URI。

媒体呈现描述可向每个表示r的每个文件或段指派以下属性：

(a)表示r内的文件的序号i，其中i＝1，2，...，Nr，(b)表示id为r且文件索 引为i的文件相对于呈现时间而言的相对开始时间，定义为ts(r，i)，(c)表示id 为r且文件索引为i的文件/段的文件URI，记为FileURI(r，i)。

在一个实施例中，可显式地为表示提供文件的开始时间和文件URI。在另 一实施例中，可显式地提供文件URI列表，其中每个文件URI根据在该列表 中的位置被固有地指派索引i，并且段的开始时间是作为从1到i-1的段的所有 段历时之和来推导的。每个段的历时可根据以上讨论的任何规则来提供。例如， 懂基础数学的任何人员可使用其他方法来推导用于从单个元素或属性以及文 件URI在表示中的位置/索引来容易地推导开始时间的方法。

若MPD中提供动态URI构造规则，则每个文件的开始时间以及每个文件 URI可通过使用构造规则、所请求的文件的索引、以及潜在可能还使用在媒体 呈现描述中提供的一些附加参数来动态地构造。该信息例如可在诸如文件URI 模式(FileURIPattern)和动态文件信息(FileInfoDynamic)等MPD属性及元 素中提供。文件URI模式提供关于如何基于文件索引序号i和表示ID r来构造 URI的信息。文件URI格式(FileURIFormat)构造为：

文件URI格式＝sprintf(“％s％s％s％s％s.％s”，基URI，基文件名称，

表示ID格式，分隔符格式，

文件序列ID格式，文件扩展名)；

并且FileURI(r，i)构造为：

FileURI(r，i)＝sprintf(文件URI格式，r，i)；

每个文件/段的相对开始时间ts(r，i)可由MPD中包含的描述该表示中的段 的历时的某个属性来推导，例如“动态文件信息”属性。MPD还可包含对媒 体呈现中的所有表示或以如上指定的相同方式至少在时段中对所有表示而言 为全局的“动态文件信息”属性序列。若表示r中的特定播放时间tP的媒体数 据被请求，则相应的索引i(r，tP)可被推导为i(r，t_p)，以使得该索引的播放时间 落在开始时间ts(r，i(r，tP))与ts(r，i(r，tP)+1)的区间中。段访问可进一步被以上情 形限制，例如段是不可访问的。

一旦获得相应段的索引和URI，访问确切的播放时间tP就取决于实际段 格式。在该示例中，不失一般性，假定媒体段具有始于0的局部时间线。为了 访问和呈现播放时间tP的数据，客户端可从能通过其中i＝i(r，t_p)的URI FileURI(r，i)访问的文件/段下载与局部时间相对应的数据。

一般而言，客户端可下载整个文件并且随后可访问播放时间tP。然而，不 一定3GP文件的所有信息都需要被下载，因为3GP文件提供将局部时基映射 到字节范围的结构。因此，只要有充分的随机访问信息可用，仅访问播放时间 tP的特定字节范围就足以播放媒体。同样，在段的初始部分中可例如使用段索 引之类来提供关于媒体段的字节范围和局部时基的结构和映射的充分信息。通 过能访问段的初始的例如1200个字节，客户端就可具有充分的信息以直接访 问播放时间tP所需的字节范围。

在另一示例中，假定段索引(可能在下文指定为“tidx”包)可被用于标 识所要求的一个或多个片断的字节偏移量。可针对所要求的一个或多个片断形 成部分获取请求。还存在其他替换方案，例如，客户端可发出对文件的标准请 求并在已接收到第一个“tidx”包时取消该请求。

查找

客户端可尝试查找到表示中的特定呈现时间tp。基于MPD，客户端能访 问表示中的每个段的媒体段开始时间和媒体段URL。客户端可获取开始时间 tS(r，i)小于或等于呈现时间tp的最大段索引i作为最有可能包含呈现时间tp的 媒体样本的段的段索引segment_index，即段索引＝max{i|tS(r，i)＜＝tp}。获 得段URL为FileURI(r，i)。

注意，由于与随机访问点的放置、媒体轨迹的对准以及媒体时基漂移有关 的问题，MPD中的时基信息可能是近似的。因此，由以上规程所标识出的段 可能始于比tp稍晚的时间，并且呈现时间tp的媒体数据可能位于先前媒体段 中。在查找的情形中，可将查找时间更新成等于检索到的文件的首个样本时间， 或者可代之以检索前一文件。然而应注意，在连续播出期间，包括在替换表示 /版本之间切换的情形中，tp与检索到的段的开始之间的时间的媒体数据仍是 可用的。

为了准确地查找到呈现时间tp，HTTP流送客户端需要访问随机访问点 (RAP)。为了在3GPP自适应HTTP流送的情形中确定媒体段中的随机访问 点，客户端可例如使用‘tidx’或‘sidx’包(若存在)中的信息来定位媒体呈 现中的随机访问点以及相应的呈现时间。在段为3GPP电影片断的情形中，也 可能由客户端使用‘moof’和‘mdat’包内的信息来例如定位RAP并从电影 片断中的信息和从MPD推导出的段开始时间来获得必需的呈现时间。若没有 呈现时间在所请求的呈现时间tp之前的RAP可用，则客户端可访问先前段或 者可仅仅使用首个随机访问点作为查找结果。当媒体段始于RAP时，这些规 程是简单的。

同样应注意，媒体段的所有信息未必都需要被下载才能访问呈现时间tp。 客户端可以例如首先使用字节范围请求从媒体段的开头请求‘tidx’或‘sidx’ 包。通过使用‘tidx’或‘sidx’包，段时基可被映射到段的字节范围。通过连 续使用部分HTTP请求，仅媒体段中有关系的部分需要被访问，从而得到改善 的用户体验以及低启动延迟。

段列表生成

如本文中所描述的，如何实现使用由MPD提供的信息来为具有信令通知 的大致段历时dur的表示创建段列表的简单直接的HTTP流送客户端应当是明 了的。在一些实施例中，客户端可向表示内的媒体段指派连贯索引i＝1，2，3，...， 即第一个媒体段被指派索引i＝1，第二个媒体段被指派索引i＝2，依此类推。那 么，具有段索引i的媒体段的列表被指派startTime[i](开始时间[i])，并且例 如如下生成URL[i]。首先，将索引i设为1。获得第一个媒体段的开始时间为 0，即startTime[1]＝0。获得媒体段i的URL即URL[i]为FileURI(r，i)。该过程 针对具有索引i的所有被描述的媒体段继续，并且获得媒体段i的startTime[i] 为(i-1)*dur，并且获得URL[i]为FileURI(r，i)。

并发HTTP/TCP请求

块请求流送系统中一关注点是希望总是请求能被及时地完整接收以供播 出的最高质量块。然而，数据抵达率可能不是事先已知的，且因此可能碰巧所 请求的块没有及时抵达以供播出。这导致需要暂停媒体播出，从而导致不良用 户体验。该问题可通过对要请求的块的选择采取保守办法的客户端算法来缓 解，此保守办法请求更有可能即便在块的接收期间数据抵达率下降亦能被及时 接收到的较低质量(因此有较小大小)的块。然而，该保守办法具有可能向用 户或目的地设备投递较低质量播出这一缺点，这也是不良用户体验。当同时使 用多个HTTP连接来下载不同块时该问题可能放大，如以下所描述的，因为可 用网络资源跨连接被共享，且因此被同时用于具有不同播出时间的块。

客户端并发地发出对多个块的请求可能是有利的，其中在本上下文中， “并发地”表示对请求的响应发生在交迭的时间区间中，且这些请求不一定是 在精确或甚至大致相同的时间作出的。在HTTP协议的情形中，该办法由于 TCP协议的行为(这是公知的)故而可改善对可用带宽的利用率。这对于改善 内容换台时间可能是尤为重要的，因为在新内容首次被请求时，藉以请求这些 块的数据的相应HTTP/TCP连接可能起动很慢，并且因此在此时使用若干 HTTP/TCP连接能极大地加速第一批块的数据投递时间。然而，在不同 HTTP/TCP连接上请求不同块或片断也可能导致性能降级，因为对将要先播出 的块的请求正在与对后续块的请求竞争，竞争的各HTTP/TCP下载在其投递速 度方面大为不同，并且因此该请求的完成时间可能高度可变，且一般不可能控 制哪些HTTP/TCP连接将迅速完成而哪些将较慢，因此很有可能至少一些时候 头几个块的HTTP/TCP下载将最后完成，因此导致很大且可变的频道换台时 间。

假设段的每个块或片断是在单独的HTTP/TCP连接上下载的，并且并行连 接的数量为n且每个块的播出历时为t秒，并且与该段相关联的内容的流送率 为S。当客户端最初开始流送该内容时，可发出对头n个块的请求，这代表n*t 秒的媒体数据。

如本领域技术人员已知的，TCP连接的数据率有很大变动。然而，为了简 化本讨论，假设理想情况下所有连接都并行地进行，从而第一个块将在与其他 n-1个请求的块大约相同的时间被完全接收。为了进一步简化本讨论，假设这 n个下载连接所利用的聚集带宽在该下载的整个历时期间固定为值B，并且流 送率S在整个表示期间是恒定的。进一步假设媒体数据结构使得块的播出在整 个块在客户端处可用时才能进行，即块的播出只能在接收到整个块之后开始， 例如由于底层视频编码的结构或者由于采用了加密来单独加密每个片断或块， 且因此整个片断或块需要先被接收到才能被解密。因此，为了简化以下的讨论， 假定在块的任何部分能被播出之前，需要接收到整个块。那么，在第一个块抵 达并且能被播出之前所需的时间约为n*t*S/B。

由于希望使内容换台时间最小化，因此使n*t*S/B最小化是可取的。t的 值可由诸如底层视频编码结构以及如何利用摄取方法等因素决定，且因此t可 以适度地小，但非常小的t值导致过度复杂的段映射，并且可能与高效视频编 码和解密(若使用)不兼容。n的值也可能影响B的值，即B对于较大的连接 数量n可能较大，且因此减少连接数量n具有潜在地减少所利用的可用带宽量 B的负面效应，因此对于达成减少内容换台时间的目标可能不是有效的。S的 值取决于选取下载和播出哪个表示，且理想情况下S应当尽可能接近B以使给 定网络条件下媒体的播出质量最大化。因此，为了简化本讨论，假定S约等于 B。那么，频道换台时间与n*t成比例。因此，若各连接利用的聚集带宽与连 接数量呈亚线性比例(通常就是这种情形)，则利用较多连接来下载不同片断 会使频道换台时间降级。

作为示例，假设t＝1秒，且n＝1时B的值＝500Kbps，n＝2时B的值 ＝700Kbps，且n＝3时B的值＝800Kbps。假设选取了S＝700Kbps的表示。 那么，在n＝1时，第一块的下载时间为1*700/500＝1.4秒，在n＝2时，第一 块的下载时间为2*700/700＝2秒，在n＝3时，第一块的下载时间为3*700/800 ＝2.625秒，此外，随着连接数量增加，各连接的个体下载速度的可变性很可 能增加(尽管即使在一个连接的情况下，也很可能有某个明显的可变性)。因 此，在该示例中，频道换台时间和频道换台时间可变性随连接数量的增加而增 加。直观上，正被投递的块具有不同优先级，即第一个块具有最早投递期限， 第二个块具有次最早期限等等，而正藉以投递这些块的各下载连接正在投递期 间竞争网络资源，且因此具有最早期限的块随着有越来越多的竞争块被请求而 越加延迟。另一方面，即使在该情形中，最终使用一个以上下载连接也允许支 持可维系的较高流送率，例如在三个连接的情况下，在该示例中能支持最高达 800Kbps的流送率，而在一个连接的情况下仅能支持500Kbps的流。

在实践中，如上所述，连接的数据率在相同连接内随着时间推移以及在不 同连接之间都可能高度可变，并且因此，n个所请求的块一般不在同时完成， 且事实上通常可能是一个块可能在另一块的一半时间里就完成了。该效应导致 不可预测的行为，因为在一些情形中，第一个块可能比其他块完成得快得多， 而在其他情形中，第一个块可能比其他块完成得晚得多，且因此播出的开始在 一些情形中可能相对迅速地发生而在其他情形中可能发生得很慢。这种不可预 测的行为对于用户来说可能是令人沮丧的，并且因此可能被视为不良用户体 验。

因此，需要能利用多个TCP连接来改善频道换台时间和频道换台时间可 变性而同时支持可能的良好质量流送率的方法。还需要允许随着块的播出时间 的逼近调节分配给每个块的可用带宽的份额、从而在必要的情况下较大份额的 可用带宽能有倾向性地被分配给具有最迫近的播放时间的块的方法。

协作式HTTP/TCP请求

现在描述以协作式方式使用并发HTTP/TCP请求的方法。接收机可采用多 个并发的协作式HTTP/TCP请求，例如使用多个HTTP字节范围请求，其中每 个此类请求针对源段中的片断的一部分、或源段的片断的全部、或修复段的一 部分或修复片断、或针对修复段的修复片段的全部。

协作式HTTP/TCP请求连同使用FEC修复数据的优点对于提供一贯快速 的频道换台时间可能尤为重要。例如，在频道换台时间，TCP连接很可能刚刚 起动或者已空闲了一段时间，在这种情形中拥塞窗cwnd对于这些连接位于其 最小值，且因此这些TCP连接的投递速度将花若干往返行程时间(RTT)来斜 坡上升，且在该斜坡上升时间期间不同TCP连接上的投递速度将具有高度可 变性。

现在描述无FEC方法的概览，无FEC方法是协作式HTTP/TCP请求方法， 其中使用多个并发HTTP/TCP连接来仅请求源块的媒体数据，即不请求FEC 修复数据。通过该无FEC方法，在不同连接上请求相同片断的各部分，例如 使用针对该片断的各部分的HTTP字节范围请求，且因此例如每个HTTP字节 范围请求针对该片断的段映射中指示的字节范围的一部分。可能是这种情形： 个体HTTP/TCP的投递速度在若干RTT(往返行程时间)上斜坡上升以完全利 用可用带宽，且因此在相对长的时间段里投递速度小于可用带宽，因此若使用 单个HTTP/TCP连接来下载例如要播出的内容的第一个片断，则频道换台时间 可能很大。使用无FEC方法，在不同HTTP/TCP连接上下载相同片断的不同 部分就能显著减小频道换台时间。

现在描述FEC方法的概览，FEC方法是协作式HTTP/TCP请求方法，其 中使用多个并发HTTP/TCP连接来请求源段的媒体数据以及从该媒体数据生 成的FEC修复数据。通过该FEC方法，使用针对片断的各部分的HTTP字节 范围请求在不同连接上请求相同片断的各部分以及从该片断生成的FEC修复 数据，且因此例如每个HTTP字节范围请求针对该片断的段映射中指示的字节 范围的一部分。可能是这种情形：个体HTTP/TCP请求的投递速度在若干RTT (往返行程时间)上斜坡上升以完全利用可用带宽，因此在相对长的时间段里 投递速度小于可用带宽，因此若使用单个HTTP/TCP连接来下载例如要播出的 内容的第一个片断，则频道换台时间可能很大。使用FEC方法具有与无FEC 方法相同的优点，且具有并非所有所请求数据都需要在能恢复该片断之前抵达 的额外优点，因此进一步减小了频道换台时间以及频道换台时间可变性。通过 在不同TCP连接上作出请求、以及在其中至少一条连接上还请求FEC修复数 据的溢额请求，投递例如足以恢复使得媒体播出能开始的第一个所请求片断的 数据量要花的时间量可被极大地减少，并能使之比不使用协作式TCP连接和 FEC修复数据的情况下更加一致。

图24(a)-(e)示出在从仿真的演进数据优化(EVDO)网络上的相同HTTP web服务器至相同客户端的相同链路上运行的5个TCP连接的投递率波动的示 例。在图24(a)-(e)中，X轴示出以秒计的时间，并且Y轴示出客户端处在这5 个TCP连接中的每一个连接上接收比特的速率，每个连接上的速率是针在1 秒的区间上测量的。在该特定仿真中，在该链路上总共有12个TCP连接在运 行，且因此网络在所示时间期间是相对有负荷的，这在有一个以上客户端正在 移动网络的相同蜂窝小区内进行流送时是典型的。注意，尽管投递率随着时间 推移来看在一定程度上是相关的，但这5个连接的投递率在许多时间点是有巨 大差异的。

图25示出针对大小为250,000比特(约为31.25千字节)的片断的可能请 求结构，其中对该片断的不同部分并行地作出4个HTTP字节范围请求，即第 一HTTP连接请求头50,000比特，第二HTTP连接请求接下来的50,000比特， 第三HTTP连接请求接下来的50,000比特，而第四HTTP连接请求接下来的 50,000比特。若不使用FEC，即无FEC方法，则在该示例中对该片断只有4 个请求。若使用FEC，即FEC方法，则在该示例中，有一个附加的HTTP请 求，用于请求从该片断生成的修复段的额外50,000比特FEC修复数据。

图26是图24(a)-(e)中所示的5个TCP连接的头几秒的放大，其中在图 26中，X轴以100毫秒的间隔示出时间，并且Y轴示出客户端处在这5个TCP 连接中的每一个连接上接收比特的速率，该速率是在100毫秒区间上测量的。 一条线示出在客户端处已从头4个HTTP连接(排除藉以请求FEC数据的那 个HTTP连接)为该片断接收到的聚集比特量，即，使用无FEC方法抵达的 聚集比特量。另一条线示出在客户端出已从所有这5个HTTP连接(包括藉以 请求FEC数据的那个HTTP连接)为该片断接收到的聚集比特量，即，使用 FEC方法抵达的聚集比特量。对于FEC方法，假定该片断从接收到250,000个 所请求比特中的任何200,000比特时起能被FEC解码，这在例如使用 Reed-Solomon FEC码的情况下就能实现，且在例如使用Luby IV中描述的 RaptorQ码的情况下则本质上能实现。对于该示例中的FEC方法，在1秒后接 收到足以使用FEC解码来恢复该片断的数据，从而允许1秒的频道换台时间 (假定在第一个片断被完全播出之前能请求并接收后续片断的数据)。对于该 示例中的无FEC方法，在能恢复该片断之前不得不接收这4个请求的所有数 据，这在1.7秒之后发生，从而得到1.7秒的频道换台时间。因此，在图26中 所示的示例中，无FEC方法在频道换台时间的意义上比FEC方法差70％。该 示例中的FEC方法表现出的优点的一个原因在于，对于FEC方法，接收到所 请求的数据中的任何80％就允许恢复该片断，而对于无FEC方法，要求接收 到所请求的数据的100％。因此，无FEC方法不得不等待最慢的TCP连接完成 投递，且由于TCP投递率的自然变动，最慢TCP连接的投递速度与平均TCP 连接相比可能动辄有很大方差。在该示例中的FEC方法下，一个慢TCP连接 不会决定该片断何时能恢复。相反，对于FEC方法，足够数据的投递更多地 取决于平均TCP投递率而非最差情形TCP投递率。

存在以上描述的无FEC方法和FEC方法的许多变形。例如，协作式 HTTP/TCP请求可被用于发生频道换台后的仅头几个片断，且此后仅使用单个 HTTP/TCP请求来下载进一步的片断、多个片断或整个段。作为另一示例，所 使用的协作式HTTP/TCP连接的数量可以是正在请求的片断的紧急性(即，这 些片断的播出时间有多迫切)以及当前网络条件的函数。

在一些变形中，可使用多个HTTP连接来请求来自修复段的修复数据。在 其他变形中，可在不同的HTTP连接上请求不同的数据量，例如取决于媒体缓 冲器的当前大小以及客户端处的数据接收速率。在另一变形中，各源表示彼此 并不独立，而是代表分层媒体编码，其中例如增强型源表示可取决于基源表示。 在这种情形中，可以有与基源表示相对应的修复表示、以及与基和增强源表示 的组合相对应的另一修复表示。

附加的全部元件增进了可由以上公开的方法实现的优点。例如，所使用的 HTTP连接的数量可取决于媒体缓冲器中的当前媒体量、和/或向媒体缓冲器中 接收的速率而变化。在媒体缓冲器相对较空时可进取性地使用利用FEC的协 作式HTTP请求，即以上描述的FEC方法及该方法的变形，例如对第一片断 的不同部分并行地作出较多的协作式HTTP请求，请求源片断的全部以及来自 相应的修复片段的相对大分数的修复数据，并随后随着媒体缓冲器增长，转换 到数量减少的并发HTTP请求，每请求皆请求更大部分的媒体数据，以及请求 较小分数的修复数据，例如，转换到1、2或3个并发HTTP请求，转换到每 请求对满量的片断或多个连贯片断作出请求，以及转换到不请求修复数据。

作为另一示例，FEC修复数据的量可作为媒体缓冲器大小的函数而变化， 即，当媒体缓冲器小时，则可请求较多FEC修复数据，并且随着媒体缓冲器 增长，则可逐渐减少所请求的FEC修复数据的量，以及在媒体缓冲器充分大 时的某个时间点，可以不请求FEC修复数据，仅请求来自源表示的源段的数 据。此类增强型方法的益处在于它们可允许更快和更一致的频道换台时间、以 及更强的抗潜在媒体不流畅或停滞的回弹性，同时通过减少请求消息话务和 FEC修复数据两者使所使用的超过只投递源段中的媒体本应消费的量的额外 带宽量最小化，同时又使得能支持给定网络条件下最高的可能媒体速率。

使用并发HTTP连接时的附加增强

若满足合适的条件则可放弃HTTP/TCP请求并且可作出另一HTTP/TCP 请求以下载可替代在被放弃的请求中所请求的数据的数据，其中第二 HTTP/TCP请求可请求与原始请求中完全相同的数据，例如源数据；或交迭数 据，例如相同源数据和修复数据中在第一请求中尚未请求的一些；或者完全不 相交的数据，例如第一请求中尚未请求的修复数据。合适条件的示例是请求因 在所规定时间内没有来自块服务器基础设施(BSI)的响应、或者在建立与BSI 的传输连接时发生故障、或接收到来自服务器的显式故障消息、或其他故障条 件而失败。

合适条件的另一示例是根据将连接速度的度量(响应于所议请求的数据抵 达率)与预期连接速度、或与在响应中包含的媒体数据的播出时间或取决于该 时间的其他时间之前接收该响应所需的连接速度的估计作比较，数据的接收进 行得异常慢。

该办法在BSI有时显现故障或不良性能的情形中具有优点。在这种情形 中，上述办法提高了即使BSI内有故障或不良性能该客户端仍能继续可靠地播 出媒体数据的概率。注意，在一些情形中，以BSI有时的确显现出此类故障或 不良性能的方式来设计BSI可能存在优点，例如此类设计可具有比不显现出此 类故障或不良性能或不那么频繁地显现出此类故障或不良性能的替换设计低 的成本。在这种情形中，本文中描述的方法具有进一步优点，因为其允许对 BSI利用此类较低成本设计而不会导致用户体验降级的后果。

在另一实施例中，对与给定块相对应的数据发出的请求的数目可取决于是 否满足关于该块的合适条件。若不满足该条件，则假使对该块的所有目前未完 成的数据请求的成功完成将允许以高概率恢复出该块，客户端可被禁止对该块 作出进一步请求。若满足该条件，则可发出对该块的更大量请求，即，以上的 禁止不适用。合适条件的示例是截至该块的调度播出时间为止的时间或取决于 该时间的其他时间落在所规定的阈值之下。该方法具有优点，这是由于对块的 数据的附加请求是在对块的接收因包括该块的媒体数据的播出时间迫近而变 得更急迫之后发出的。在诸如HTTP/TCP之类的常见传输协议的情形中，这些 附加请求具有增加专用于对所议块的接收有贡献的数据的可用带宽的份额的 效应。这减少了完成足以恢复该块的数据的接收所需的时间，并因此减少该块 不能在包括该块的媒体数据的调度播出时间之前被恢复的概率。如以上所描述 的，若该块不能在包括该块的媒体数据的调度播出时间之前被恢复，则播出会 暂停，从而导致不良用户体验，因此这里描述的方法有利地减少了这种不良用 户体验的概率。

应理解，贯穿本说明书对块的调度播出时间的引述是指包括该块的经编码 媒体数据最初可在客户端处可用以达成该呈现的无暂停播出的时间。如对于媒 体呈现系统领域的技术人员将清楚的，该时间实际上比包括该块的媒体出现在 用于播出的物理换能器(屏幕、扬声器等)处的实际时间稍早，因为可能需要 对包括该块的媒体数据应用若干变换功能以实现对该块的实际播出并且这些 功能可能要花一定量的时间来完成。例如，媒体数据一般是以压缩形式传输的 并且可应用解压变换。

用于生成支持协作式HTTP/FEC方法的文件结构的方法

现在描述用于生成可有利地被采用协作式HTTP/FEC方法的客户端使用 的文件结构的实施例。在该实施例中，对于每个源段，存在如下生成的相应修 复段。参数R指示对于源段中的源数据而言平均生成多少FEC修复数据。例 如，R＝0.33指示若源段包含1,000千字节的数据，则相应的修复段包含约330 千字节的修复数据。参数S指示用于FEC编码和解码的以字节计的码元大小。 例如，S＝64指示源数据和修复数据包括各自用于FEC编码和解码目的的大小 为64字节的码元。

可如下为源段生成修复段。源段的每个片断被视为用于FEC编码目的的 源块，且因此每个片断被当作据以生成修复码元的源块的源码元序列。为头i 个片断生成的修复码元总数演算为TNRS(i)＝ceiling(R*B(i)/S)，其中ceiling(x) 是用于输出值至少为x的最小整数的函数。因此，为片断i生成的修复码元数 目为NRS(i)＝TNRS(i)-TNRS(i-1)。

修复段包括关于这些片断的修复码元的级联，其中修复段内的修复码元的 次序按据以生成这些修复码元的片断的次序，且在片断内，修复码元按其编码 码元标识符(ESI)的次序。与源段结构相对应的修复段结构在图27中示出， 包括修复段生成器2700。

注意，通过如上所述地定义关于片断的修复码元数目，关于所有先前片断 的修复码元总数以及因此修复段的字节索引仅取决于R、S、B(i-1)和B(i)，而 不取决于源段内的片断的任何先前或后续结构。这是有利的，因为其允许客户 端仅使用关于据以生成修复块的源段的相应片断的结构的局部信息来迅速计 算修复段内的修复块开始的位置，并且还迅速计算该修复块内的修复码元数 目。因此，若客户端决定从源段中间开始下载和播出片断，则它还能从相应的 修复段内迅速生成和访问相应的修复块。

与片断i相对应的源块中的源码元数目演算为NSS(i)＝ ceiling((B(i)-B(i-1))/S)。若B(i)-B(i-1)不是S的倍数，则最后的源码元出于FEC 编码和解码目的被填充“0”字节，即，最后的源码元被填充“0”字节从而其 大小为S字节以用于FEC编码和解码目的，但这些“0”填充字节不被存储为 源段的一部分。在该实施例中，源码元的ESI为0、1、...、NSS(i)-1，并且修 复码元的ESI为NSS(i)、...、NSS(i)+NRS(i)-1。

在该实施例中，可通过简单地向源段的URL添加后缀“.repair”来从相应 的源段的URL生成修复段的URL。

修复段的修复索引信息和FEC信息由相应的源段的索引信息以及从R和 S的值隐式地定义，如本文中所描述的。时间偏移量和包括修复段的片断结构 由相应的源段的时间偏移量和结构决定。至与片断i相对应的修复段中的修复 码元末尾的字节偏移量可被演算为RB(i)＝S*ceiling(R*B(i)/S)。与片断i相对 应的修复段中的字节数目则为RB(i)-RB(i-1)，且因此与片断i相对应的修复码 元数目被演算为NRS(i)＝(RB(i)-RB(i-1))/S。与片断i相对应的源码元数目可 演算为NSS(i)＝ceiling((B(i)-B(i-1))/S)。因此，在该实施例中，修复段内的修 复块的修复索引信息和相应的FEC信息可从R、S以及相应源段的相应片断的 索引信息隐式地推导出。

作为示例，考虑图28中所示的示例，其示出始于字节偏移量B(1)＝6,410 并止于字节偏移量B(2)＝6,770的片断2。在该示例中，码元大小为S＝64字 节，且虚竖线示出源段内与S的倍数相对应的字节偏移量。作为源段大小的分 数的总修复段大小在该示例中被设为R＝0.5。片断2的源块中的源码元数目演 算为NSS(2)＝ceiling((6,770-6,410)/64)＝ceil(5.625)＝6，且这6个源码元分别 具有ESI 0、...、5，其中第一个源码元为片断2的始于该源段内的字节索引6,410 处的头64个字节，第二个源码元为片断2的始于源段内的字节索引6,474处的 接下来64个字节，等等。与片断2相对应的修复块的末尾字节偏移量演算为 RB(2)＝64*ceiling(0.5*6,770/64)＝64*ceiling(52.89...)＝64*53＝3,392，且与片 断2相对应的修复块的开始字节偏移量演算为RB(1)＝64*ceiling(0.5*6,410/64) ＝64*ceiling(50.07...)＝64*51＝3,264，因此在该示例中，在与片断2相对应的 修复块中具有ESI分别为6和7的两个修复码元，始于修复段内字节偏移量 3,264处并止于字节偏移量3,392。

注意，在图28中所示的示例中，尽管R＝0.5且存在与片断2相对应的6 个源码元，修复码元的数目也不是如简单地使用源码元数目来演算修复码元数 目的情况下可预期的3个，而是根据本文中所描述的方法解出其为2。与简单 地使用片断的源码元数目来确定修复码元数目不同，以上描述的实施例使得能 够单单从与相应源段的相应源块相关联的索引信息来演算修复段内的修复块 的定位。此外，随着源块中源码元数目K增长，相应修复块的修复码元数目 KR紧密近似为K*R，因为一般而言KR至多为ceil(K*R)且KR至少为 floor((K-1)*R)，其中floor(x)是最多为x的最大整数。

存在以上用于生成可有利地被采用协作式HTTP/FEC方法的客户端使用 的文件结构的实施例的许多变形，如本领域技术人员将认识到的。作为替换实 施例的示例，表示的原始段可被划分成N＞1个并行段，其中对于i＝1，...，N， 原始段的指定分数F_i被包含在第i个并行段中，且其中i＝1，...，N的F_i之和等 于1。在该实施例中，可存在被用于推导所有并行段的段映射的一个主段映射， 类似于在以上描述的实施例中如何从源段映射推导出修复段映射。例如，若并 非所有源媒体数据都被划分成并行段而是改为被包含在一个原始段中，则主段 映射可指示片断结构，并且随后第i个并行段的段映射可如下从主段映射推导 出：演算若原始段的片断的第一前缀中的媒体数据量为L字节，则头i个并行 段中该前缀聚集的字节总数为ceil(L*G_i)，其中G_i为F_j在j＝1，...，i上的和。作 为替换实施例的另一示例，段可包括每个段的原始源媒体数据其后紧随着该片 断的修复数据的组合，从而得到包含源媒体数据与使用FEC码从该源媒体数 据生成的修复数据的混合的段。作为替换实施例的另一示例，包含源媒体数据 和修复数据的混合的段可被划分成多个包含源媒体数据和修复数据的混合的 并行段。

本领域普通技术人员在阅读本公开之后可以预见其他实施例。在其他实施 例中，可有利地作出以上所公开的发明的组合或子组合。组件的示例安排是出 于解说目的示出的，应理解，在本发明的替换实施例中构想了组合、添加、重 新安排、及类似方案。因此，尽管本发明是参照示例性实施例描述的，但是本 领域技术人员将意识到许多修改是可能的。

例如，本文中描述的过程可使用硬件组件、软件组件和/或其任何组合来 实现。在这些情形中，软件组件可在有形的非瞬态介质上提供以在设有该介质 或与该介质分开的硬件上执行。因此，本说明书和附图被认为是解说性的而非 限制性的。然而，显然可对其作出各种修改和变更而不会脱离所附权利要求中 所阐述的本发明的更宽泛的精神和范围，且本发明旨在涵盖落在所附权利要求 的范围内的所有修改和等效技术方案。