CN104221390B - 用于处置低等待时间流送的增强型块请求流送系统 - Google Patents

用于处置低等待时间流送的增强型块请求流送系统 Download PDF

Info

Publication number
CN104221390B
CN104221390B CN201380020088.7A CN201380020088A CN104221390B CN 104221390 B CN104221390 B CN 104221390B CN 201380020088 A CN201380020088 A CN 201380020088A CN 104221390 B CN104221390 B CN 104221390B
Authority
CN
China
Prior art keywords
media
time
block
request
segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201380020088.7A
Other languages
English (en)
Other versions
CN104221390A (zh
Inventor
M·G·路比
M·沃森
L·威茨萨诺
P·帕克扎得
B·王
Y·陈
T·斯托克汉姆
J·M·伯兰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/456,474 external-priority patent/US9380096B2/en
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN104221390A publication Critical patent/CN104221390A/zh
Application granted granted Critical
Publication of CN104221390B publication Critical patent/CN104221390B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Television Signal Processing For Recording (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Measuring Or Testing Involving Enzymes Or Micro-Organisms (AREA)

Abstract

一种块请求流送系统提供对媒体呈现的低等待时间流送。根据编码协议生成多个媒体段。每个媒体段包括随机访问点。根据相同的协议编码多个媒体片断。媒体段是从多个媒体片断聚集而成的。

Description

用于处置低等待时间流送的增强型块请求流送系统
发明领域
本发明涉及改善的媒体流送系统和方法，尤其涉及自适应于网络和缓冲条件以使流送媒体的呈现最优化并允许对流送媒体数据进行高效的并发或时间分布式投递的系统和方法。
发明背景
流送媒体投递可能变得日益重要，因为在诸如因特网、蜂窝和无线网络、输电线网络、以及其他类型的网络之类的基于分组的网络上投递高质量音频和视频变得越来越常见。所投递的流送媒体能被呈现出的质量可取决于数种因素，包括原始内容的分辨率(或其他属性)、原始内容的编码质量、接收设备解码和呈现媒体的能力、在接收机处接收到的信号的及时性和质量等。为了产生感知到的良好的流送媒体体验，在接收机处接收到的信号的传输和及时性可能尤其重要。良好的传输可以提供在接收机处接收到的流相对于发送方发送的流的保真度，而及时性可以代表接收机在初始请求内容之后多快就能开始播出该内容。
媒体投递系统可表征为具有媒体源、媒体目的地、以及将源和目的地分开的(时间和/或空间上的)信道的系统。典型地，源包括能访问可电子地管理的形式的媒体的发射机、以及有能力电子地控制对媒体(或其近似物)的接收并将其提供给媒体消费者(例如，具有以某种方式耦合到该接收机、存储设备或元件、另一信道等的显示设备的用户)的接收机。
虽然有许多变型是可能的，但在常见的示例中，媒体投递系统具有能访问电子形式的媒体内容的一个或更多个服务器，并且一个或更多个客户端系统或设备向服务器作出对媒体的请求，而服务器使用作为该服务器的一部分的向客户端处的接收机进行传送的发射机来输送该媒体，从而收到的媒体能由该客户端以某种方式消费。在简单的示例中，对于给定的请求和响应而言有一个服务器和一个客户端，但并非必需如此。
按传统，媒体投递系统可表征为“下载”模型或“流送”模型。“下载”模型可由媒体数据的投递与该媒体向用户或接收方设备的播出之间的时基独立性来表征。
作为示例，媒体在被需要或将被使用之前被下载得足够多，并且在该媒体被使用时，在接收方处已有所需那么多的媒体可用。在下载的上下文中的投递往往是使用诸如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解说了在客户端处不同时间的实况服务的规程。
图30解说了用于低等待时间流送的媒体片断与诸媒体片断之间的关系。
在附图中，相似的项目用相似的标号来引述且在括号中提供副标以指示相似或相同项目的多个实例。除非另行指出，否则最后的副标(例如，“N”或“M”)并非意在限定于任何特定值，且一个项目的实例数目可与另一项目的实例数目不同，即使在解说了相同的标号且重复使用了副标时亦然。
发明详细描述
如本文中所描述的，流送系统的目标是将媒体从其存储位置(或正生成该媒体的位置)移到正消费该媒体的位置，即呈现给用户或以其他方式被人类或电子消费者“用尽”。理想情况下，流送系统可在接收端提供不间断的回放(或更一般而言，不间断的“消费”)，且在用户请求了流或流集合之后不久就能开始播放这个或这些流。出于效率原因，还希望每个流在一旦用户指示不再需要该流时，诸如当用户正从一个流切换到另一个流或者其服从例如“字幕”流之类的流的呈现时就被停下。若诸如视频之类的媒体分量继续被呈现，但选择了不同的流来呈现该媒体分量，则往往优选令新的流占用有限的带宽并停止旧的流。
根据本文中描述的实施例的块请求流送系统提供许多益处。应理解，可行的系统无需包括本文中描述的所有特征，因为一些应用可用不足本文中描述的特征全体的特征来提供令人满意程度适宜的体验。
HTTP流送
HTTP流送是一种具体的流送类型。在HTTP流送下，源可以是标准web服务器和内容投递网络(CDN)并且可使用标准HTTP。该技术可涉及流分段以及使用多个流，所有这些皆落在标准化HTTP请求的上下文中。诸如视频之类的媒体可以用多个比特率来编码以构成不同的版本或表示。术语“版本”和“表示”在本文中同义地使用。每个版本或表示可被分解成较小的片以构成段，片可能在几秒的量级。每个段随后可作为单独的文件被存储在web服务器或CDN上。
在客户端一侧，随后可使用HTTP作出对个体段的请求，这些个体段由客户端无缝地拼接在一起。客户端可基于可用带宽切换到不同的数据率。客户端还可请求多个表示，每个表示呈现不同的媒体分量，并且可联合且同步地呈现这些表示中的媒体。切换的触发可包括例如缓冲器占用率和网络测量。当在稳态下操作时，客户端可调整向服务器请求的步调以维持目标缓冲器占用率。
HTTP流送的优点可包括比特率自适应、快速启动和查找、以及最小程度的不必要投递。这些优点源于将投递控制成仅比播出提前很短时间、对可用带宽作出最大程度的使用(通过可变比特率媒体)、以及优化流分段和智能客户端规程。
媒体呈现描述可被提供给HTTP流送客户端，以使得客户端能使用文件(例如以3GPP规定的格式，在本文中称为3gp段)的集合来向用户提供流送服务。媒体呈现描述以及可能还有该媒体呈现描述的更新描述了实为结构化的段集合的媒体呈现，每个段包含媒体分量以使得客户端能以同步方式呈现所包括的媒体并且能提供高级特征，诸如查找、切换比特率、以及联合呈现不同表示中的媒体分量。客户端可按不同方式使用媒体呈现描述信息来得到服务的供给。具体而言，根据媒体呈现描述，HTTP流送客户端可确定能访问该集合中的哪些段，从而流送服务内的数据对于客户端能力以及用户而言是有用的。
在一些实施例中，媒体呈现描述可以是静态的，但段可以是动态地创建的。媒体呈现描述可以尽可能紧凑以使该服务的访问和下载时间最小化。其他专用服务器连通性可被最小化，例如客户端与服务器之间常规或频繁的时基同步。
可以将媒体呈现构造成允许被具有不同能力——诸如接入不同的接入网类型、不同的当前网络条件、显示器大小、访问比特率和编解码器支持——的终端访问。客户端随后可提取恰适的信息以向用户提供流送服务。
媒体呈现描述还可根据要求允许部署灵活性以及紧凑性。
在最简单的情形中，每个替换表示可被存储在单个3GP文件中，即遵照如3GPPTS26.244中的定义的文件、或遵照如ISO/IEC 14496-12或衍生规范中定义的ISO基媒体文件格式(诸如3GPP技术规范26.244中描述的3GP文件格式)的任何其他文件。在本文档的其余部分中，在引述3GP文件时，应理解ISO/IEC 14496-12和衍生规范可将所有所描述的特征映射到如ISO/IEC14496-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 NetworkTM)、微软流畅流送(Microsoft Smooth Streaming)以及苹果iPhoneTM流送协议。
通常，每个媒体数据块可作为个体文件存储在服务器上，且随后使用诸如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 ReliableComputer 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视频、其他类型的视频、图像、定时文本、定时元数据或类似物。一些内容可涉及要以定时方式呈现或消费的数据，诸如用于随正被播出的其他媒体一起呈现辅助信息(台标识、广告、股价、FlashTM序列等)的数据。也可以使用组合其他媒体和/或超越仅音频和视频的其他混合呈现。
如图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-2TS内部时基达成的音频/视频同步的MPEG-2TS分组流。
使用信令和/或块创建来使流送更高效
在块请求流送系统中可以使用或不使用数种特征以提供改善的性能。性能可涉及不停滞地播出呈现、在带宽约束内获得媒体数据、和/或在客户端、服务器和/或摄取系统处有限的处理器资源内这样做的能力。现在将描述这些特征中的一些。
段内的索引
为了编制对电影片断的部分获取请求，可向客户端告知文件或段内的片断中所包含的所有媒体分量在解码或呈现时间的字节偏移量和开始时间、以及还有哪些片断始于或包含随机访问点(且因此适合用作替换表示之间的切换点)，其中该信息往往被称为段索引或段映射。在解码或呈现时间的开始时间可直接表达或者可表达为相对于参考时间的Δ。
该时间和字节偏移量索引信息可能每电影片断需要至少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时间之间的解码时间或呈现时间差。这使得在切换到该媒体段的情形中客户端能准确地知晓“切换自”的表示需要一直被呈现到的时间。
补充地或代替地，可以使用简单的或阶层式的索引、雏菊链索引和/或混合索引。
由于不同轨迹的样本历时可能不是相同的(例如，视频样本可能播放33ms，而音频样本可能持续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之间的差异
TIDX和SIDX就索引而言提供相同的功能性。SIDX的第一循环作为补充还提供首个电影片断的全局时基，但该全局时基也可被包含在该电影片断自身中，其或者是绝对的或者是相对于参考轨迹的。
SIDX的第二循环实现TIDX的功能性。具体地，SIDX准许具有由“引用类型”所指的每个索引的引用的目标的混合，而TIDX仅仅是要么只引用TIDX要么只引用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)：关于客户端在实况服务中可以相对于当前时间回移多远的信息。藉由该深度的扩展，无需在服务供应中作出特定改变也可准许时移观看和追看服务。
准许本地高速缓存(LocalCachingPermitted)：该标志指示HTTP客户端在已播放所下载的数据之后是否能本地高速缓存该数据。
实况呈现区间(LivePresentationInverval)：通过指定开始时间(StartTimes)和结束时间(EndTimes)来包含其间呈现可用的时间区间。“开始时间”指示服务的开始时间而“结束时间”指示服务的结束时间。若没有指定结束时间，则结束时间在当前时间是未知的，且“更新频率”可确保客户端能在服务的实际结束时间之前访问到结束时间。
点播可用性区间(OnDemandAvailabilityInterval)：该呈现区间指示该服务在网络上的可用性。可以提供多个呈现区间。HTTP客户端在任何指定时间窗以外可能不能访问该服务。通过提供“点播区间”，可指定额外的时移观看。对于实况服务，该属性也可出现。倘若对于实况服务该属性出现，则服务器可确保在所有所提供的可用性区间期间，客户端能以点播服务的形式来访问该服务。因此，“实况呈现区间”不可与任何“点播可用性区间”交迭。
MPD文件信息动态(MPDFileInfoDynamic)：描述媒体呈现中的文件的默认动态构造。更多细节在下文中提供。若对若干或所有替换表示使用相同规则，则在MPD等级上的默认指定可以节省不必要的重复。
MPD编解码器描述(MPDCodecDescription)：描述媒体呈现中的主默认编解码器。更多细节在下文中提供。若对若干或所有表示使用相同的编解码器，则在MPD等级上的默认指定可以节省不必要的重复。
MPD移动包头部大小不变(MPDMoveBoxHeaderSizeDoexNotChange)：指示移动包头部的大小在整个媒体呈现内各个体文件之间是否改变的标志。该标志可用来优化下载并且可以仅在特定段格式(尤其是其段包含moov头部的那些段格式)的情形中才出现。
FileURI模式(FileURIPattern)：客户端用来生成对媒体呈现内的文件的请求消息的模式。不同属性准许为媒体呈现内的每个文件生成唯一性的URI。基URI可以是HTTPURI。
替换表示：描述表示列表。
“替换表示(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。
客户端在相对事件时间tl可能仅被允许请求开始时间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*1210.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个或更多个的逻辑或：
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中所示，对于小于t0的时间，B当前的值为0，指示尚未接收到数据。在t0，第一块被接收并且B当前的值增大到等于所接收的块的播放历时。此时，播出尚未开始且因此B当前的值保持恒定直至时间t1，此时第二块抵达并且B当前增大该第二块的大小。此时，播出开始并且B当前的值开始线性减小直至时间t2，此时第三块抵达。
B当前的累进以此“锯齿”方式继续，每次接收到块时阶跃地增大(在时间t2、t3、t4、t5和t6)并在其间随着数据被播出而平滑地减小。注意，在该示例中，播出是以该内容的正常播出速率来进行的，并且因此块接收之间的曲线斜率恰好为-1，意味着对于流逝的每一秒真正时间，有一秒的媒体数据被播放。在基于帧的媒体以给定帧数每秒(例如24帧每秒)播出时，斜率-1将由指示每个个体数据帧的播出的小阶跃函数来近似，例如每帧播出时-1/24秒的步长。
图14示出了B当前随时间演进的另一个示例。在该示例中，第一块在t0抵达并且播出立即开始。块抵达和播出继续直至时间t3，此时B当前的值到达0。在这种情况发生时，没有更多媒体数据可供播出，从而迫使媒体呈现暂停。在时间t4，第四块被接收并且播放可恢复。该示例因此示出了其中对第四块的接收晚于所需从而导致播出暂停以及因此导致不良用户体验的情形。因此，高级缓冲管理器及其他特征的目标是降低该事件的概率，与此同时维持高媒体质量。
缓冲监视器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现在-Tx))对的所有可能值的空间来求值，其中Tx可以是固定(配置)值，或者可例如由从B当前的值映射到Tx的值的配置表从B当前推导出，或者可取决于“状态”的先前值。向缓冲监视器126供应该空间的一个或更多个划分，其中每个划分包括不相交区域的集合，每个区域用“状态”值来标注。对函数“NewState”的求值由此包括标识划分并确定(B当前,B比率(T现在-Tx))对所落在的区域的操作。返回值由此是与该区域相关联的标注。在简单情形中，只提供一个划分。在更复杂的情形中，划分可取决于前一次对NewState函数求值时的(B当前,B比率(T现在-Tx))对或取决于其他因素。
在具体实施例中，以上描述的划分可基于包含B当前的数个阈值以及B比率的数个阈值的配置表。具体而言，令B当前的阈值为B阈(0)＝0、B阈(1)、…、B阈(n1)、B阈(n1+1)＝∞，其中n1是B当前的非零阈值的数目。令B比率的阈值为B比率阈(0)＝0、B比率阈(1)、…、B比率阈(n2)、B比率阈(n2+1)＝∞，其中n2是B比率的阈值的数目。这些阈值定义了包括(n1+1)x(n2+1)的单元栅格的划分，其中第j行的第i个单元对应于其中B阈(i-1)<＝B当前<B阈(i)且B比率阈(j-1)<＝B比率<B比率阈(j)的区域。以上描述的栅格的每个单元格诸如通过与存储在存储器中的特定值相关联之类而被标注以状态值，并且函数NewState随后返回与由值B当前和B比率(T现在-Tx)指示的单元格相关联的状态值。
在另一实施例中，可令迟滞值与每个阈值相关联。在该增强型方法中，对函数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来描述该方法的第一实施例。客户端首先获得一组网际协议地址IP1、IP2、…、IPn，如步骤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,tp)，以使得该索引的播放时间落在开始时间ts(r,i(r,tP))与ts(r,i(r,tP)+1)的区间中。段访问可进一步被以上情形限制，例如段是不可访问的。
一旦获得相应段的索引和URI，访问确切的播放时间tP就取决于实际段格式。在该示例中，不失一般性，假定媒体段具有始于0的局部时间线。为了访问和呈现播放时间tP的数据，客户端可从能通过其中i＝i(r,tp)的URIFileURI(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)网络上的相同HTTPweb服务器至相同客户端的相同链路上运行的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，原始段的指定分数Fi被包含在第i个并行段中，且其中i＝1,…,N的Fi之和等于1。在该实施例中，可存在被用于推导所有并行段的段映射的一个主段映射，类似于在以上描述的实施例中如何从源段映射推导出修复段映射。例如，若并非所有源媒体数据都被划分成并行段而是改为被包含在一个原始段中，则主段映射可指示片断结构，并且随后第i个并行段的段映射可如下从主段映射推导出：演算若原始段的片断的第一前缀中的媒体数据量为L字节，则头i个并行段中该前缀聚集的字节总数为ceil(L*Gi)，其中Gi为Fj在j＝1,…,i上的和。作为替换实施例的另一示例，段可包括每个段的原始源媒体数据其后紧随着该片断的修复数据的组合，从而得到包含源媒体数据与使用FEC码从该源媒体数据生成的修复数据的混合的段。作为替换实施例的另一示例，包含源媒体数据和修复数据的混合的段可被划分成多个包含源媒体数据和修复数据的混合的并行段。
用于处置低等待时间流送的方法
在一些部署情景中，对实况服务的低等待时间流送可能是期望的。例如，在事件(诸如体育比赛或音乐会)的本地场所中分发的情形中，期望实况活动与该实况服务在客户端上的呈现之间的延迟尽可能短。例如，可能期望最大延迟为1秒。
如上所述，将存储媒体呈现的段的每个文件安排成始于随机访问点(RAP)可能是有利的。一些简档(尤其是ISO基媒体文件格式实况简档)要求每个媒体段始于RAP。
然而，在其中需要低的端到端等待时间递送的环境中，每个段的历时必须较短以使实况活动与该实况事件在客户端上的呈现之间的延迟最小化。期望避免在将用于低等待时间流送的每个段中插入RAP。例如，视频中的RAP通常由IDR帧来实现。通过避免在期望用于低等待时间流送的短段内使用IDR帧，编码效率可得到改善。
根据一实施例，生成媒体呈现的顺应于实况简档的表示和低等待时间表示。顺应于实况简档的表示具有相对较大的媒体段历时。顺应于实况简档的表示的每个媒体段在该媒体段的开始处具有RAP。低等待时间表示具有相对较短的段(其可被称为“媒体片断”)，其可以不包含RAP。支持低等待时间流送的客户端可接收为媒体呈现的低等待时间表示所生成的媒体片断，而不支持低等待时间流送的客户端可以能够接收为媒体呈现的顺应于实况简档的表示所生成的媒体段。
图30解说了用于低等待时间流送的媒体片断与诸媒体片断之间的关系。为实况简档流送所生成的媒体段3002在该媒体数据的开始处包含RAP 3004(“mdat”)。相反，在为低等待时间流送所生成的媒体片断3004、3006和3008中，只有媒体片断3004包含RAP。
这些媒体片断是在运行中生成的，并且可供客户端经由HTTP进行下载。这些媒体片断可被累积成顺应于ISO基媒体文件格式实况简档的媒体段，而无需对这些媒体片断作任何修改。例如，这些媒体片断可被级联成媒体段。
媒体段和媒体片断两者可使用相同的编码过程来创建。以此方式，媒体可被高效地编码以供在需要低的端到端等待时间的环境中操作的客户端以及由使用要求在每个段中有RAP的协议的客户端消费。
在一些实施例中，为每个媒体片断生成段索引(SIDX)。SIDX可包括在媒体段内的呈现时间范围以及媒体段被该媒体片断所占据的相应字节范围。在一些实施例中，SIDX指示片断内是否存在RAP。在图30中，媒体片断3004的SIDX包的“包含_RAP”字段被设为1，指示该媒体片断3004包含RAP。媒体片断3006和3008的SIDX包的“包含_RAP”字段被设为0，指示媒体片断3006和3008不包含RAP。SIDX可进一步指示第一RAP在片断内的呈现时间。
根据一实施例，媒体服务器可生成用于低等待时间流送的片断并将这些片断推送到高速缓存中。该高速缓存可级联这些片断以生成与实况简档兼容的媒体段。在生成媒体段之后，该高速缓存可清空已被级联以生成该媒体段的那些媒体片断。
单个媒体呈现描述(MPD)可存储关于具有媒体呈现的顺应于实况简档的媒体段的第一表示和具有低等待时间流的媒体片断的第二表示的信息。使用媒体段进行时移缓冲以及使用媒体片断来处置在该流的近实况边缘处的观看，可提供时移观看。客户端可在这些表示之间切换，例如，在时移缓冲器中开始并通过跳过该媒体呈现的诸章节而移动至更靠近实况边缘。MPD的每个表示可被指派一属性以表达可用于单个媒体呈现的表示阵列。
在存储关于具有媒体段的第一表示和具有媒体片断的第二表示的信息的MPD中，提供指示第二表示的哪些媒体片断始于RAP的信息可能是有利的。例如，MPD可包括一属性以指示在多个媒体片断内出现RAP的频率。在一个实施例中，MPD包括以片断数目的方式来指示频率的属性(即，每第x个媒体片断包含RAP)。在另一个实施例中，该属性以毗邻RAP之间在时间上的距离的方式来指示频率。
替换地，关于媒体片断的信息可存储在第一MPD中，而关于媒体段的信息可存储在第二MPD中。
在一些实施例中，MPD可发信号通知适用于具体表示的具体参数，诸如表示的媒体段或媒体片断的最大历时。
本领域普通技术人员在阅读本公开之后可以预见其他实施例。在其他实施例中，可有利地作出以上所公开的发明的组合或子组合。组件的示例安排是出于解说目的示出的，应理解，在本发明的替换实施例中构想了组合、添加、重新安排、及类似方案。因此，尽管本发明是参照示例性实施例描述的，但是本领域技术人员将意识到许多修改是可能的。
例如，本文中描述的过程可使用硬件组件、软件组件和/或其任何组合来实现。在这些情形中，软件组件可在有形的非瞬态介质上提供以在设有该介质或与该介质分开的硬件上执行。因此，本说明书和附图被认为是解说性的而非限制性的。然而，显然可对其作出各种修改和变更而不会脱离所附权利要求中所阐述的本发明的更宽泛的精神和范围，且本发明旨在涵盖落在所附权利要求的范围内的所有修改和等效技术方案。

Claims (9)

1.一种用于在媒体服务器中构造内容数据以用于低等待时间流送的方法，包括
获得要供应的内容；
生成表示所述内容并根据编码协议来编码的第一多个媒体段，所述第一多个媒体段包括媒体呈现的编码到每个媒体段中的一个或多个帧，其中所述第一多个媒体段中的至少一些包括随机访问点(RAP)并且所述第一多个媒体段中的至少一些不包括随机访问点；以及
生成根据所述编码协议来编码的多个媒体片断，其中所述多个媒体片断中的至少一些媒体片断包括随机访问点并且至少一些媒体片断不包括随机访问点；
其中媒体段是从多个媒体片断聚集而成的。
2.如权利要求1所述的方法，其特征在于，所述媒体段是通过级联多个媒体片断来生成的。
3.如权利要求2所述的方法，其特征在于，进一步包括在高速缓存中生成所述媒体段，并且其中当在所述高速缓存中生成所述媒体段之后，从所述高速缓存中清空用于生成所述媒体段的所述多个媒体片断。
4.如权利要求1所述的方法，其特征在于，进一步包括为每个媒体片断生成段索引，所述段索引包括在媒体段内的呈现时间范围以及所述媒体段中被所述媒体片断所占据的相应字节范围。
5.如权利要求4所述的方法，其特征在于，所述段索引还包括随机访问点存在性指示符，其指示所述媒体片断内是否存在随机访问点。
6.如权利要求1所述的方法，其特征在于，进一步包括生成单个媒体呈现描述MPD文件，所述MPD文件存储关于所述媒体呈现的包括所述第一多个媒体段的第一表示以及所述媒体呈现的包括所述多个媒体片断的第二表示的信息。
7.如权利要求6所述的方法，其特征在于，所述MPD包括一属性以指示在所述第二表示内出现随机访问点的频率。
8.如权利要求7所述的方法，其特征在于，所述频率是时间段。
9.如权利要求7所述的方法，其特征在于，所述频率是媒体片断数目。
CN201380020088.7A 2012-04-26 2013-04-25 用于处置低等待时间流送的增强型块请求流送系统 Active CN104221390B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/456,474 US9380096B2 (en) 2006-06-09 2012-04-26 Enhanced block-request streaming system for handling low-latency streaming
US13/456,474 2012-04-26
PCT/US2013/038247 WO2013163448A1 (en) 2012-04-26 2013-04-25 Enhanced block-request streaming system for handling low-latency streaming

Publications (2)

Publication Number Publication Date
CN104221390A CN104221390A (zh) 2014-12-17
CN104221390B true CN104221390B (zh) 2018-10-02

Family

ID=48471085

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380020088.7A Active CN104221390B (zh) 2012-04-26 2013-04-25 用于处置低等待时间流送的增强型块请求流送系统

Country Status (13)

Country Link
EP (1) EP2842336A1 (zh)
JP (1) JP6105717B2 (zh)
KR (1) KR101741484B1 (zh)
CN (1) CN104221390B (zh)
BR (1) BR112014026741B1 (zh)
CA (1) CA2869311C (zh)
HK (1) HK1203015A1 (zh)
IL (1) IL234872A (zh)
MY (1) MY166917A (zh)
PH (1) PH12014502203A1 (zh)
RU (1) RU2629001C2 (zh)
TW (1) TWI492598B (zh)
WO (1) WO2013163448A1 (zh)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10866952B2 (en) 2013-03-04 2020-12-15 Fisher-Rosemount Systems, Inc. Source-independent queries in distributed industrial system
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US10678225B2 (en) 2013-03-04 2020-06-09 Fisher-Rosemount Systems, Inc. Data analytic services for distributed industrial performance monitoring
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US9558220B2 (en) 2013-03-04 2017-01-31 Fisher-Rosemount Systems, Inc. Big data in process control systems
US9665088B2 (en) 2014-01-31 2017-05-30 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
US10909137B2 (en) * 2014-10-06 2021-02-02 Fisher-Rosemount Systems, Inc. Streaming data for analytics in process control systems
US10152031B2 (en) 2013-03-15 2018-12-11 Fisher-Rosemount Systems, Inc. Generating checklists in a process control environment
WO2015081218A1 (en) 2013-11-27 2015-06-04 Interdigital Patent Holdings, Inc. Media presentation description
US9813474B2 (en) 2014-03-07 2017-11-07 Ericsson Ab ABR video white spot coverage system and method
US10135890B2 (en) * 2015-03-06 2018-11-20 Sony Interactive Entertainment LLC Latency-dependent cloud input channel management
US10528345B2 (en) * 2015-03-27 2020-01-07 Intel Corporation Instructions and logic to provide atomic range modification operations
KR102367134B1 (ko) 2015-06-25 2022-02-24 삼성전자주식회사 가속기를 제어하는 방법 및 이를 이용한 가속기
CN106559677B (zh) * 2015-09-30 2020-04-03 华为技术有限公司 终端、缓存服务器及获取视频分片的方法及装置
KR102393158B1 (ko) * 2015-10-13 2022-05-02 삼성전자주식회사 메타데이터를 포함하는 비트 스트림을 이용한 서비스 제공 방법 및 장치
CN105406913B (zh) * 2015-10-27 2019-07-19 航天恒星科技有限公司 信号处理方法、装置及中国移动多媒体广播系统
US9426543B1 (en) * 2015-12-18 2016-08-23 Vuclip (Singapore) Pte. Ltd. Server-based video stitching
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network
US10079884B2 (en) * 2016-03-14 2018-09-18 Adobe Systems Incorporated Streaming digital content synchronization
CN105915582B (zh) * 2016-03-28 2019-04-02 深圳市双赢伟业科技股份有限公司 路由器访问网页的方法及路由器
WO2017207861A1 (en) * 2016-05-30 2017-12-07 Teleste Oyj An arrangement for media stream organization
CN107634930B (zh) * 2016-07-18 2020-04-03 华为技术有限公司 一种媒体数据的获取方法和装置
US11617019B2 (en) * 2016-07-28 2023-03-28 Qualcomm Incorporated Retrieving and accessing segment chunks for media streaming
RU2745113C2 (ru) * 2016-09-30 2021-03-22 Лайвстриминг Свиден АБ Буферизация воспроизведения в системе распределения контента, транслируемого в прямом эфире
MX2019005456A (es) * 2016-11-10 2019-08-12 Ericsson Telefon Ab L M Segmentacion de recursos para mejorar el rendimiento de entrega.
WO2018174367A1 (ko) * 2017-03-22 2018-09-27 엘지전자 주식회사 방송 신호 송수신 방법 및 장치
CN108668179B (zh) * 2017-03-27 2021-05-14 华为技术有限公司 媒体索引文件的传输方法及相关设备
CN109936715B (zh) 2017-12-19 2021-09-03 华为技术有限公司 一种mp4文件的处理方法及其相关设备
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
US11197052B2 (en) * 2019-07-12 2021-12-07 Apple Inc. Low latency streaming media
CN110324727A (zh) 2019-07-16 2019-10-11 浙江大华技术股份有限公司 计算机可读存储介质、服务器及其响应播放请求的方法
US12072850B2 (en) * 2021-07-28 2024-08-27 Grass Valley Limited Virtual file system for dynamically providing media content

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217553A (zh) * 2008-01-15 2008-07-09 中兴通讯股份有限公司 一种媒体流的随机访问处理方法
CN101222616A (zh) * 2008-01-22 2008-07-16 中兴通讯股份有限公司 点播服务中的mpeg传送流的传输处理方法
CN101989977A (zh) * 2009-08-04 2011-03-23 华为技术有限公司 富媒体实时业务实现的方法、设备、服务器和系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7594250B2 (en) 1992-04-02 2009-09-22 Debey Henry C Method and system of program transmission optimization using a redundant transmission sequence
US7941554B2 (en) * 2003-08-01 2011-05-10 Microsoft Corporation Sparse caching for streaming media
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US7805456B2 (en) * 2007-02-05 2010-09-28 Microsoft Corporation Query pattern to enable type flow of element types
KR101087379B1 (ko) * 2007-02-23 2011-11-25 노키아 코포레이션 패킷화 방법 및 장치, 비트스트림 표현 처리 방법 및 장치와 컴퓨터 판독 가능 매체
CN101146110B (zh) * 2007-09-25 2011-06-29 深圳市迅雷网络技术有限公司 一种播放流媒体的方法
WO2009054907A2 (en) * 2007-10-19 2009-04-30 Swarmcast, Inc. Media playback point seeking using data range requests
TWI355168B (en) * 2007-12-07 2011-12-21 Univ Nat Chiao Tung Application classification method in network traff
US20090257508A1 (en) * 2008-04-10 2009-10-15 Gaurav Aggarwal Method and system for enabling video trick modes
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US9917874B2 (en) * 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
KR101737325B1 (ko) * 2010-08-19 2017-05-22 삼성전자주식회사 멀티미디어 시스템에서 멀티미디어 서비스의 경험 품질 감소를 줄이는 방법 및 장치

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217553A (zh) * 2008-01-15 2008-07-09 中兴通讯股份有限公司 一种媒体流的随机访问处理方法
CN101222616A (zh) * 2008-01-22 2008-07-16 中兴通讯股份有限公司 点播服务中的mpeg传送流的传输处理方法
CN101989977A (zh) * 2009-08-04 2011-03-23 华为技术有限公司 富媒体实时业务实现的方法、设备、服务器和系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Technologies under consideration;ANONYMOUS;《MPEG METTING》;20111203;全文 *
text of ISO/IEC IS 23009-1 media presentation description and segment formats;ANONYMOUS;《MPEG MEETING》;20120106;全文 *

Also Published As

Publication number Publication date
TW201408020A (zh) 2014-02-16
BR112014026741B1 (pt) 2021-10-26
CA2869311C (en) 2018-02-13
IL234872A (en) 2017-05-29
PH12014502203B1 (en) 2014-12-10
CA2869311A1 (en) 2013-10-31
RU2629001C2 (ru) 2017-08-24
CN104221390A (zh) 2014-12-17
MY166917A (en) 2018-07-24
EP2842336A1 (en) 2015-03-04
HK1203015A1 (zh) 2015-10-09
JP2015519813A (ja) 2015-07-09
BR112014026741A8 (pt) 2021-06-22
KR20150003296A (ko) 2015-01-08
RU2014147463A (ru) 2016-06-20
WO2013163448A1 (en) 2013-10-31
BR112014026741A2 (pt) 2017-06-27
PH12014502203A1 (en) 2014-12-10
JP6105717B2 (ja) 2017-03-29
KR101741484B1 (ko) 2017-05-30
TWI492598B (zh) 2015-07-11

Similar Documents

Publication Publication Date Title
CN104221390B (zh) 用于处置低等待时间流送的增强型块请求流送系统
CN106209892B (zh) 使用可伸缩编码的增强型块请求流送
CN102577307B (zh) 使用url模板和构造规则的增强型块请求流送
JP7352673B2 (ja) シグナリング又はブロック生成を用いた拡張ブロック－要求ストリーミングシステム
CN102550034B (zh) 使用块划分或请求控制以获得改善的客户端侧处置的增强型块请求流送
CN102549999B (zh) 使用协作式并行http和前向纠错的增强型块请求流送

Legal Events

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

Ref country code: HK

Ref legal event code: DE

Ref document number: 1203015

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant