CN110140335A

CN110140335A - 用于改进递送性能的资源分段

Info

Publication number: CN110140335A
Application number: CN201780082944.XA
Authority: CN
Inventors: M.韦斯特伦德; B.格拉富拉-冈萨雷斯; G.埃里克森
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2016-11-10
Filing date: 2017-11-10
Publication date: 2019-08-16
Anticipated expiration: 2037-11-10
Also published as: JP2019537897A; WO2018087311A1; EP3539270A1; AU2021200397A1; JP2019536354A; US20190281367A1; KR20190075137A; KR102220188B1; WO2018087309A1; AU2017358996A1; CN110140335B; US20210307861A1; JP7178998B2; EP3539270B1; US20200186896A1; JP7061121B2; MX2019005456A; AU2021200397B2; EP3539271A1; US11558677B2

Abstract

一种用于将资源（例如，媒体资源（诸如媒体段）或其它资源（诸如通常使用像如HTTP的通用文件传输协议所获取或推送的资源））分段成多个片段的灵活方法。通过采用此类方法，减少了直到可以在客户端侧利用资源的延迟。提供了某些实施例，其将灵活分段方法应用于ISOBMFF媒体段以用于视频流播，例如会与直播DASH流播一起使用。

Description

用于改进递送性能的资源分段

技术领域

公开的是用于分段资源（诸如在直播流播中使用的媒体段）的实施例。

背景技术

当前的流播方法

用于直播和视频点播自适应位率流播的当前方法主要依赖于超文本传输协议（HTTP）（参见例如[HTTP]）。在这些方法中，客户端（也称为用户代理或UA）可以使用HTTP来检索大量的媒体段，每个媒体段包含媒体样本（即，音频样本和/或视频样本）。这些媒体段根据某些格式（例如，ISOBMFF）而使能客户端解析媒体段、解码媒体样本，并最终向客户端的用户播放媒体。也就是说，在已检索到媒体段之后，客户端能够解析媒体段的内容并将其呈现给用户。

在这些当前方法下，存在较高层，其提供关于独立媒体段的位置的信息，包括此类媒体段的潜在不同表示（例如，具有不同编码质量的不同表示）。使用两种主导解决方案：（1）HTTP直播流播（HLS）（参见例如[HLS]），以及（2）HTTP上的动态自适应流播（DASH）（参见例如[DASH]）。这两种解决方案都使用描述不同媒体段及其位率的清单文件，使得流播客户端可以确定要检索哪个媒体段。虽然存在若干不同的媒体段格式，但HLS和DASH都支持ISO基础媒体文件格式（ISOBMFF）（参见例如[ISOBMFF]）。

媒体段格式

ISOBMFF是灵活的媒体容器文件格式。它由称为框的结构组成。框可以包括标识符和长度字段，并且可以包括定义框包含什么的元数据。框可以包含其它类型的一个或多个框。特定格式（例如对于某些类型的媒体或用例）可能对通用ISOBMFF结构给予附加约束（例如，定义对媒体文件的要求，指定文件必须包含哪些类型的框）。DASH使用ISOBMFF文件格式来定义若干类型的段，例如初始化段和媒体段。初始化段可以包含对解码媒体段所必需的信息。但只有媒体段包含媒体样本。每个媒体段包含moof框和mdat框。

MOOF框包含跟踪片段（traf）框，其包含跟踪运行框（trun）。trun框记载了被存储在mdat框内部的连续媒体样本集合。因此，对于每个媒体样本，至少提供其数据大小以及媒体样本的持续时间。这使能媒体样本在彼此之后被连续存储在mdat框内部。moof框被存储在mdat框之前。

工作负载的分发

存在关于HTTP的带外（OOB）内容编码机制的正在进行的工作（参见例如[OOB]）。此OOB机制使能服务器将HTTP响应主体的服务重定向到另一信任域。例如，这可以用于安全地重定向到内容分发网络（CDN）节点、边缘服务器或第三方高速缓存/代理，而不违反相同起源（origin）策略、具有良好的隐私性质、并且当所有独立HTTP请求在传输层安全性（TLS）连接的上下文中被完成时使能在内容分发方面的更大灵活性。

HTTP备选服务（参见例如[alt-services]）是用于将对请求的响应重定向到其它网络位置和可能的其它递送协议的另一方法。使用HTTP备选服务，资源身份与资源的位置分离。然而，此重定向应用于整个起源，并且不能在独立资源级别上执行。

资源验证

在HTTP上下文中，存在正被开发以用于保护和验证所请求资源（例如，所请求媒体段）的主体的完整性的若干不同机制。一个提议是针对响应主体的签名（参见，例如，[CONTENTSIG]）。另一方法是应用高级加密标准（AES）Galois计数器模式（GCM）或AES GCM，其允许作为内容编码的消息主体的机密性和完整性验证（参见例如[aesgcm]）。另一提议是Merkle完整性内容编码或MICE，其使用固定大小记录来提供完整性验证（参见，例如[MICE]）。通过MICE，假定验证了先前记录或执行验证的实体已知该记录的正确散列，则每个记录可以在它到达时被验证，允许在接收器侧上的逐步验证。

参考文献

[CONTENTSIG] Thomson，M.，“Content-Signature Header Field for HTTP”，draft-thomson-http-content-signature-00（正在进行的工作），2015年7月。

[MICE] Thomson，M.，“Merkle Integrity Content Encoding”，draft-thomson-http-mice-01（正在进行的工作），2016年6月。

[OOB] J.Reschke和S.Loreto，“'Out-Of-Band'Content Coding for HTTP”，draft-reschke-http-oob-encoding-08（正在进行的工作），2016年9月。

[RFC6454]，A.Barth，“The Web Origin Concept”，RFC 6454，2011年12月。

[HLS] R.Pantos和W.May，“HTTP Live Streaming”，draft-pantos-http-live-streaming-20（正在进行的工作），2016年9月。

[DASH] “Information technology -- Dynamic adaptive streaming overHTTP (DASH) -- Part 1: Media presentation description and segment formats”，ISO / IEC 23009-1：2014，2014年5月。

[HTTP] R.Fielding，J.Reschke，“Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing”，IETF RFC 7230，2014年6月。

[ISOBMFF] “Information technology — Coding of audio-visual objects -Part 12: ISO base media file format”，ISO / IEC 14496-12，2012年7月。

[aesgcm] M. Thomson，“Encrypted Content-Encoding for HTTP”，IETF draft-ietf-httpbis-encryption-encoding-03（正在进行的工作），2016年10月。

[alt-services] M.Nottingham等人，“HTTP Alternative Services”，IETF RFC7838，2016年4月。

[S4-141201] 3GPP TSG-SA4＃81，“MI-EMO: Guidelines for out of ordersending of movie fragments”，http：//www.3gpp.org/ftp/tsg_sa/wg4_codec/TSGS4_81/Docs /S4-141201.zip，2014年8月。

发明内容

现有解决方案的问题

用于递送直播流播的一种常见方式是使用具有ISO基础媒体文件格式（ISO BMFF）的DASH。ISO BMFF媒体段格式指定moof框（即包含被包括在moof的对应mdat框中的媒体样本的元数据（例如，长度和位置）的框）在mdat框之前。此要求防止编码器在编码器已完成对应媒体样本的编码之前生成整个moof。因此，这引入了延迟。所述延迟可以被测量为T_{源_到_回放}（从编码器开始生成媒体段的媒体样本的时间到客户端可以开始回放的时间的延迟）。此延迟对用户是重要的，因为它影响媒体段多快可用于被观看。T_{源_到_回放}还可以被测量为T_{源_到_接收}（从编码器开始编码媒体段的时间到编码器可以向接收实体提供媒体段的时间的延迟）和T_{接收_到_回放}（从接收实体首次开始接收媒体段的时间到回放可以开始的时间的延迟）的总和。要求在文件格式中在数据部分之前写入媒体样本的长度和位置（例如，在生成所有媒体样本之前不能完成moof）因此增加了T_{源_到_回放}，因为它增加了T_{源_到_接收}。此延迟随着媒体段的长度而增加（通常大约2-10秒）。

用于处理此延迟（即最小化上面提到的延迟）的一种已知方法是针对具体媒体段来创建多个ISOBMFF“电影片段（movie fragment）”。也就是说，创建包括一系列moof/mdat框对的媒体段。例如，媒体段可以包含第一电影片段（即，第一moof框由第一mdat框跟随）和第二电影片段（即第二moof框由第二mdat框跟随）。一旦已创建了电影片段，这一方法就使能电影片段的传输。这可以降低延迟，因为延迟取决于片段的长度，并且此方法创建更多片段，其各自具有更小的长度。然而，除了降低延迟之外，此方法还增加了开销。此外，所述方法创建附加的随机访问点（根据标准被定义为可以开始解码和连续回放而不依赖于段中的任何先前数据的点）。所述方法还可以影响视频编码，因为随机访问点的频率负面地影响编码的效率（例如，对于视频编码，它可能引起次优数量的I-帧）。

上面描述的方法还遭受附加问题。例如，当要求验证资源（例如，媒体段）完整性时，所述方法进一步遭受不允许随机访问。由于完整性机制的性质，不受约束的随机访问是不可能的。尽管如此，除了资源的起始之外，上面描述的方法不允许资源内的任何随机访问点。提供附加的随机访问点将提供益处，例如使得后加入者能够直播流播，或在更大的视频序列内寻找，或访问媒体段内的具体随机访问点。

当采用具有带外（OOB）编码（特别是具有HTTP资源检索）的上面描述的方法时，出现了另外的问题。例如，如果使用AES GCM用于验证，则上面描述的方法要求检索整个资源以便验证资源的完整性。这影响内容摄取直到接收客户端可以播放内容之间的最短时间，即编码和客户端回放之间的时间（即，T_{源_到_回放}）。在摄取（编码）侧，在可以计算完整性验证散列之前，需要完全摄取内容。这是因为关于整个资源而计算了此类散列。然后，在接收器（解码）侧，正用曾意图发送的内容来验证客户端已接收的内容的客户端必须首先接收关于其而计算了完整性散列的所有内容，即整个资源。

除了AES GCM之外，另一种已知方法是Merkle完整性内容编码（MICE）。然而，即使使用这一方法，仍然存在缺点。MICE部分地解决了AES GCM的一些问题，因为它允许接收器中每个块已完成递送时在每块的基础上执行资源的逐步验证（其中块是比资源更小的单元）。因此，上面提到的客户端侧延迟取决于所使用的块大小及其与底层内容结构的对齐，而不是整个资源的大小。然而，MICE没有解决上面提到的服务器侧延迟，因为所述方法仍然要求编码器在计算完整性保护并将散列链添加到内容时具有资源的最后部分。

已知的完整性验证机制不能对动态生成的内容有效地起作用。这是因为此类机制倾向于要求编码器知道要验证的整个资源。尽管TLS或SSL可以与分组块的传输编码一起使用，并且当正由单个服务器或信任域发送数据时在传输级别验证数据可以是可能的，但是当多个域正发送出信息时（例如取决于来自带外服务器的资源的完整性验证的、像如OOB的递送模型），该解决方案不可行。

示例性提议实施例的简要概述

本申请描述了一种用于将资源（例如，媒体资源（诸如媒体段）或其它资源（诸如通常使用像如HTTP的通用文件传输协议所获取或推送的资源））分段成多个片段的灵活方法。通过采用此类方法，减少了直到可以在客户端侧利用资源的延迟。提供了某些实施例，其将灵活分段方法具体应用于ISOBMFF媒体段以用于视频流播，例如会与直播DASH流播一起使用。通过使用所描述的灵活分段，这些实施例可以显著减少媒体样本在服务器侧变得可用直到客户端侧回放可以开始之间的延迟（即，T_{源_到_回放}）。在一个实施例中，这通过使用这里提出的文件分段机制来完成，所述机制能够改变检索资源的部分所采用的顺序（例如，检索顺序可以与逻辑顺序不同），以及能够使能当通过摄取的媒体样本来创建资源的部分时逐步获取或推送资源的部分。所提出的资源分段机制还提供元数据以使能接收器（客户端侧）在比已知解决方案准许的阶段更早的阶段利用资源片段。

本申请的另一方面涉及确保完整资源以及资源片段的完整性，同时维持通过灵活分段所提供的特性和益处。例如，所描述的方法使能资源片段的独立组块的逐步完整性验证。对于将被逐步生成的资源，关于独立组块或组块群组（完整性框）的散列使能逐步验证。在每个完整性框的独立散列上使用签名确保散列可以被信任，即它们已由可信实体生成。包括适当的完整性保护的分段解决方案还能够处理来自不同信任域的资源段的检索，例如，当使用HTTP中的带外编码或备选服务时创建的资源段。所述解决方案还支持独立或不同的密钥或甚至独立或不同的保护机制，以用于独立资源段的机密性保护，以便完全支持多个信任和安全性上下文的使用。

在一个方面中，提供了一种由服务器所执行的方法。所述方法包括所述服务器生成媒体段的分段图，所述媒体段包括排序的片段集合，所述排序的片段集合包括第一片段和第二片段。所述方法还包括所述服务器向客户端提供所述分段图。所述分段图包括：与所述第一片段关联的第一片段元数据；与所述第二片段关联的第二片段元数据；以及标识所述集合内的片段的排序的排序信息，所述排序信息包括指示所述第一片段被排序在所述第二片段之前的信息。所述第一片段元数据包括：1）供访问所述第一片段使用的第一片段标识符，以及2）以下项中的一项或多项：2a）所述第一片段的第一相关性信息，所述第一相关性信息指示要从所述服务器递送的所述第一片段的可用性取决于所述集合中的一个或多个其它片段；2b）第一位置信息，所述第一位置信息包括以下项中的一项或多项：所述第一片段的长度、所述媒体段中的所述第一片段的开始位置、以及所述媒体段中的所述第一片段的结束位置；以及2c）供验证所述第一片段的完整性使用的第一片段级别安全性信息。所述第二片段元数据包括供访问所述第二片段使用的第二片段标识符。

在一些实施例中，所述第一片段元数据包括所述第一相关性信息、所述第一位置信息和所述第一片段级别安全性信息。

在一些实施例中，所述第一片段元数据包括所述第一片段级别安全性信息，以及所述片段级别安全性信息包括散列信息，所述散列信息由所述服务器用来生成以下项中的至少一项的散列：所述第一片段和所述第一片段的一部分。

在一些实施例中，所述第二片段元数据还包括以下项中的一项或多项：所述第二片段的第二相关性信息，所述第二相关性信息指示要从所述服务器递送的所述第二片段的可用性取决于所述集合中的一个或多个其它片段；第二位置信息，所述第二位置信息包括以下项中的一项或多项：所述第二片段的长度、所述媒体段中的所述第二片段的开始位置、以及所述媒体段中的所述第二片段的结束位置；以及供验证所述第二片段的所述完整性使用的第二片段级别安全性信息。

在一些实施例中，所述第一片段元数据还包括与所述第一片段对应的优先级值。

在一些实施例中，所述第一片段元数据还包括编码标识符。

在一些实施例中，所述第一片段标识符包括标识所述第一片段的统一资源标识符URI。

在一些实施例中，所述第一片段元数据还包括与所述媒体段的类型关联的应用级别提示，以及所述应用级别提示使能客户端在接收另一些多个片段中的每个之前利用所述第一片段。

在一些实施例中，所述第一相关性信息包括大小相关性信息，以及所述大小相关性信息指示在可以确定所述第一片段的大小之前必须被生成的零个或多个其它片段。

在一些实施例中，所述第一相关性信息包括内容相关性信息，以及所述内容相关性信息指示在可以生成所述第一片段的内容之前必须被生成的零个或多个其它片段。

在一些实施例中，所述排序信息包括与每个片段元数据关联的序列标识符。

在一些实施例中，所述排序信息在存储多个片段元数据的数据结构中是隐式的。

在一些实施例中，所述分段图还包括媒体段元数据，所述媒体段元数据包括以下项中的一项或多项：所述媒体段的媒体类型；资源级别完整性信息；所述媒体段的统一资源定位符（URL）；以及指示建议所述客户端何时更新所述分段图的更新提示，所述更新提示包括以下项中的一项或多项：到期时间和内容相关性属性。

在一些实施例中，所述方法还包括从所述客户端接收对所述媒体段的请求；以及响应于对所述媒体段的所述请求，向所述客户端发送所述分段图。

在一些实施例中，所述方法还包括从所述客户端接收对所述第一片段的请求；以及响应于接收到对所述第一片段的所述请求，向所述客户端发送所述第一片段。

在一些实施例中，所述方法还包括基于新信息来更新所述分段图，其中所述新信息包括以下项中的一项或多项：多个片段中的一个片段的长度、多个片段中的一个片段的开始位置、以及多个片段中的一个片段的结束位置；以及向所述客户端发送所更新的分段图。

在另一方面中，提供了一种由客户端所执行的方法。所述方法包括客户端接收由服务器传送的分段图，其中所述分段图用于包括多个媒体段的媒体流的第一媒体段，所述多个媒体段包括所述第一媒体段和第二媒体段，所述第一媒体段包括排序的片段集合，所述排序的片段集合包括第一片段和第二片段。所述方法还包括所述客户端处理所述分段图。所述分段图包括：与所述第一片段关联的第一片段元数据；与所述第二片段关联的第二片段元数据；以及标识所述集合内的片段的排序的排序信息，所述排序信息包括指示所述第一片段被排序在所述第二片段之前的信息。所述第一片段元数据包括：1）供访问所述第一片段使用的第一片段标识符，以及2）以下项中的一项或多项：2a）所述第一片段的第一相关性信息，所述第一相关性信息指示要从所述服务器递送的所述第一片段的可用性取决于所述集合中的一个或多个其它片段；2b）第一位置信息，所述第一位置信息包括以下项中的一项或多项：所述第一片段的长度、所述第一媒体段中的所述第一片段的开始位置、以及所述第一媒体段中的所述第一片段的结束位置；以及2c）供验证所述第一片段的完整性使用的第一片段级别安全性信息。所述第二片段元数据包括供访问所述第二片段使用的第二片段标识符。

下面描述其它实施例和方面。

优点

灵活的分段机制可用于采用多种方式来改进递送。例如，可以减少直到可以由接收客户端消耗资源的相关片段的延迟。另一示例是所述方法完全支持在接收客户端附近使用边缘服务器或高速缓存，从而允许资源片段在此类边缘服务器或高速缓存中是可用的，并允许用户从更近或以其它方式最优的提供方取得任何片段，同时可以从其它片段在其中可用的其它实例中检索所述其它片段。这引起改进的递送性能。另外的示例是向用户提供和指示资源片段存储中的冗余的能力。另外的优点是同时从潜在不同的源检索或接收多个片段的能力，这可以引起改进的递送性能，从而使编码过程更快。

此外，本申请中描述的分段机制可用于通过媒体段的智能分段来显著改进针对像如DASH和HLS的直播流播机制的从内容摄取直到播放的延迟（T_{源_到_回放}）。当通过分组化器将编码的媒体样本添加到段时，此智能分段使能到独立片段的客户端的逐步递送。这也移除或至少减少了在能够开始传输之前在ISOBMFF文件中完成电影片段方面的延迟。

此外，本申请中描述的分段机制可用于改进安全性模型，例如资源验证和/或机密性。例如，当将资源分段成多个片段时，所描述的安全性模型是特别有利的，其中可以从多个提供方检索那些片段。本申请中描述的安全性模型使能当将资源分段成多个片段时灵活地使用适合于应用的需要的不同完整性机制。例如，对于直播视频流播情况，处理灵活记录大小的基于签名或加密钥的完整性机制是有利的。此类机制允许独立组块是完整性受保护的，并且允许递送的数据被立即验证为是正确的并被消耗而没有附加延迟。

附图说明

图1示出了根据示例性实施例的***。

图2示出了根据实施例的方法。

图3示出了根据实施例的方法。

图4示出了根据实施例的方法。

图5示出了根据实施例的方法。

图6示出了根据实施例的方法。

图7示出了根据实施例的方法。

图8示出了根据实施例的方法。

图9示出了根据本发明的示例性实施例的客户端-服务器交互。

图10示出了根据本发明的示例性实施例的客户端-服务器交互。

图11示出了根据本发明的示例性实施例的示例性序列。

图12示出了根据本发明的示例性实施例的ISOBMFF媒体段的示例性分片段。

图13示出了根据一些实施例的设备的框图。

具体实施方式

除非以其它方式指示，否则如本文所使用的“一”应该被解译为意味着“一个或多个”。

本申请描述了用于分段资源（例如，意图使用像如HTTP、FLUTE或FCAST的文件递送协议来从服务器递送到客户端的资源）的示例性实施例。实施例涉及分段的资源的格式、用于执行资源分段的方法和装置、和/或用于接收/传送分段的资源的方法和装置。

用于分段的示例性解决方案基于为客户端提供给定资源的分段图。在一些实施例中，客户端可以具体地从服务器请求分段图或给定资源。如图1中示出的，客户端102与服务器104通信。在一些实施例中，服务器104可以是传统服务器；在其它实施例中，它可以是对等网络中的同位体客户端。

给定资源被分段成适合于应用或递送的需要的任何数量的片段。随着关于独立片段的更多信息被确定，可以针对给定资源更新分段图。也就是说，可以在具有关于资源的独立片段的完整信息之前（即，在资源被完全指定之前）创建分段图。

根据示例性实施例，分段图具有以下描述的特征的某一组合。

分段图指示显式地（例如，通过索引或序列标识符）或隐式地（例如，通过由实现全部或部分分段图的数据结构所施加的顺序）来组装独立片段的顺序。

每个片段在分段图创建（包括对分段图进行的任何更新）的时间具有已知或未知长度。因此，对于每个片段，如果长度在图被创建的时间是已知的，则分段图可以指示片段的长度（例如，以位为单位）。如果长度是未知的，则文件递送协议必须能够指示片段的最终长度，例如通过使用HTTP分组块或通过当已由服务器将片段完全递送到客户端时关闭连接。

在分段图创建的时间，每个片段具有相对于完整资源的已知或未知位置（例如，偏移）。因此，对于每个片段，分段图可以指示片段的偏移。如果位置未知，则客户端或解码器可以在接收到分段图之后（例如，当已经确定先前片段的结束的位置时，或者通过接收包括给定片段的位置的经更新的分段图）确定位置。不知道片段位置的一个缺点是它可能导致附加的移动或拷贝操作（尽管如稍后所描述的，基于在分段图中提供的相关性信息，存储器受限的客户端可以对片段的检索进行排序以最小化此类移动或拷贝）。

每个片段具有要由文件检索协议（例如HTTP URL或URL与到该URL中的偏移的组合）使用的、其自己的标识符（例如，定位符、名称等）。因此，对于每个片段，分段图可以指示片段的标识符。这使能使用像如OOB的机制来检索作为其自己的资源的单独片段或者出于各种原因而使用多个不同的服务器的灵活性。在检索域中或出于内容处理原因的负载平衡可能由于负载扩展而引起性能改进。针对每个片段使用定位符还使能在URL级别或使用像如备选服务（参见例如[alt-services]）的机制而重定向到另一递送或检索协议。

每个片段可以具有用于机密性和完整性验证的独立安全性机制。因此，对于每个片段，分段图可以包括执行与片段关联的安全性操作所需要的信息。这可以是关于片段的数据的散列，或指示哪个证书或密钥已被用于生成散列或签名。

对于每个片段，分段图可以包括检索提示或相关性信息，其向客户端指示为了最优性能客户端应该采用哪种顺序来检索片段。一种此类优化是最小化直到递送完成的延迟。另一提示可以指示在已经成功递送一个或若干其它片段之后应该递送具体片段。

对于每个片段，分段图可以包括与资源媒体类型关联的应用级别提示，其使能接收客户端利用在完全递送之前或关于其自己的片段，而不是整个资源。

分段图还可以具有资源级别性质。例如，为了确保在适当的点处完成分段图的更新，分段图可以包括以下提示：当已经达到递送和重新组装过程中的具体步骤时可以请求经更新的分段图。

现在参考图1，客户端102可以与服务器104进行通信。如本文所使用的，“服务器”可以是提供服务的单个计算机、提供服务的计算机集合，其中计算机集合可以被共同定位（例如，计算机集群）或在地理上分散。客户端102可以包括接收器202和解码器204。接收器202包括使能客户端102从服务器104接收数据的电路（例如，有线或无线链路，诸如RF接收器或以太网接口）。解码器204可操作以解码各种媒体文件格式。服务器104可以包括源馈送302、编码器304、分组化器306和分段器308。源馈送302可以向服务器104提供媒体数据，例如在直播数据被生成时（例如，来自线缆馈送、卫星馈送或其它源）的直播数据，或已经生成并存储在服务器104或其它地方的数据。编码器304可操作以使用例如H.264或MPEG-4高级视频编码（AVC）将从源馈送302接收的媒体数据编码成各种媒体样本。分组化器306可操作以获得媒体样本并将它们置于适合于通过基于分组的协议（例如HTTP）来发送的分组化格式（例如，分组化器306可以通过例如创建具有包含媒体样本的mdat框的媒体段将媒体样本置于ISO基础媒体文件格式。分段器308可操作以获得分组化媒体并将它置于分段的格式中或采用分段的格式来递送它（例如，根据分段图来递送它）。

图2示出了根据示例性实施例的用于生成和接收分段图的方法。在一些实施例中，方法包括生成媒体段的分段图，所述媒体段包括排序的片段集合，其包括第一片段和第二片段（步骤202a）。在实施例中，服务器104执行生成分段图步骤。在一些实施例中，方法包括接收媒体段的分段图，所述媒体段包括排序的片段集合，其包括第一片段和第二片段（步骤202b）。在实施例中，客户端102执行接收分段图步骤。

图3示出了用于递送（或接收）动态生成的媒体流的示例性实施例。例如，在一些实施例中，动态生成的媒体流表示数据的直播源，例如直播电视馈送。在一些实施例中，所述方法可以使用HTTP在因特网上发生，并且客户端102和服务器104两者都可以是因特网使能装置。根据一个实施例，提供了一种用于向客户端递送动态生成的媒体流的方法，所述媒体流包括多个媒体段，所述多个媒体段包括第一媒体段和第二媒体段。所述方法包括从客户端接收对清单文件的请求（步骤302）。在一些实施例中，清单文件包括用于使能客户端生成对媒体段的请求的信息。所述方法还包括响应于接收到对清单文件的请求而向客户端发送清单文件（步骤304）。所述方法还包括在向客户端发送清单文件之后，从客户端接收标识第一媒体段的请求（步骤306）。在一些实施例中，由客户端传送标识第一媒体段的请求作为客户端处理清单文件的结果。在一些实施例中，在服务器能够向客户端提供完整媒体段之前（例如，服务器尚未完成生成moof和mdat框）由客户端传送请求。

所述方法还包括：响应于标识第一媒体段的请求，向客户端发送第一媒体段的分段图（步骤308）。在一些实施例中，第一媒体段包括排序的片段集合，其包括第一片段（例如，moof框）和第二片段（例如，mdat框），并且分段图包括：包括供从服务器检索第一片段使用的第一片段标识符的第一片段元数据，包括供从服务器检索第二片段使用的第二片段标识符的第二片段元数据，以及标识所述片段集合内的片段的排序的排序信息，所述排序信息包括指示第一片段被排序在第二片段之前的信息。

图4提供示出了用于接收动态生成的媒体流的示例性实施例，所述媒体流包括多个媒体段，所述多个媒体段包括第一媒体段和第二媒体段。所述方法包括向服务器发送对清单文件的请求（步骤402）。在一些实施例中，清单文件包括用于使能客户端生成对媒体段的请求的信息。所述方法还包括接收清单文件（步骤404）。所述方法还包括处理所接收的清单文件（步骤406）。所述方法还包括在处理清单文件之后，向服务器发送标识第一媒体段的请求（步骤408）。所述方法还包括响应于发送标识第一媒体段的请求而接收第一媒体段的分段图（步骤410）。在一些实施例中，第一媒体段包括排序的片段集合，其包括第一片段和第二片段，并且分段图包括：包括供从第一服务器检索第一片段使用的第一片段标识符的第一片段元数据，包括供从服务器检索第二片段使用的第二片段标识符的第二片段元数据，以及标识所述片段集合内片段的排序的排序信息，所述排序信息包括指示第一片段被排序在第二片段之前的信息。所述方法还包括向服务器发送对第一片段的请求（步骤412）。所述方法还包括接收第一片段（步骤414）。

图5示出了用于递送动态生成的媒体流的附加示例性实施例。例如，在一些实施例中，客户端102可以在对第一媒体段的请求（或任何其它请求）中包括客户端支持分段的模式的指示符。在一些实施例中，用于向客户端递送动态生成的媒体流的方法还包括至少部分地基于所述指示符来确定使用分段的模式来递送媒体段（步骤502）。例如，如果客户端不支持分段的模式，则服务器104可以不使用分段的模式，并且因此将不向客户端发送分段图。在一些实施例中，确定使用分段的模式来递送媒体段还取决于第一媒体段是否已被完全生成。例如，如果第一媒体段已被完全生成，则服务器104可以使用常规的文件流播技术来递送第一媒体段。另一方面，如果尚未完全生成第一媒体段，则服务器104可以确定使用分段的模式来递送第一媒体段。

本发明的实施例支持用于处理或准备从源接收的媒体使得其准备好递送的多种方式。例如，在一些实施例中，所述方法还可以包括从动态生成媒体流的源接收第一媒体段的一部分（步骤504）。在实施例中，经由源馈送302接收第一媒体段的该部分。在一些实施例中，第一媒体段的该部分对应于媒体样本和媒体应用数据单元（ADU）中的至少一个（例如，第一媒体段的该部分可以包含媒体帧（即，音频帧和/或视频帧））。在一些实施例中，接收的第一媒体段的该部分被编码，例如采用音频或视频格式（诸如H.264或MPEG-4高级视频编码（AVC））。在其它实施例中，所述方法还可以包括编码第一媒体段（步骤506）。例如，编码可以将第一媒体段的该部分变换成音频或视频格式，例如H.264或MPEG-4高级视频编码（AVC）。在实施例中，编码器304执行此步骤。所述方法还可以包括根据格式来分组化第一媒体段的该部分（步骤508）。例如，格式可以是ISO基础媒体文件格式（ISOBMFF）。在实施例中，分组化器306执行此步骤。所述方法还可以包括分段第一媒体段并生成第一媒体段的分段图（步骤510）。例如，分段图可以具有本申请中公开的示例性分段图的一个或多个性质。在实施例中，分段器308执行此步骤。在一些实施例中，生成第一媒体段的分段图基于采用所述格式的第一媒体段的经分组化部分。

在一些实施例中，所述方法还包括基于新信息来更新分段图并向客户端发送经更新的图（步骤512）。例如，在初始创建分段图的时间，某些信息可能不是已知的（诸如媒体段内的独立片段的长度或位置信息）。在完成媒体段或媒体段内具体片段的编码和分组化时，服务器104可以在该时间通过新信息（例如，长度或位置信息）来更新分段图。所述方法还可以包括从客户端接收标识第一片段的请求（步骤514）；以及响应于接收到标识第一片段的请求而向客户端发送第一片段（例如，可以使用HTTP分组块向客户端发送第一片段）（步骤516）。

图6示出了用于接收动态生成的媒体流的附加示例性实施例。在一些实施例中，用于接收动态生成的媒体流的方法还可以包括向服务器发送对第二片段的请求（步骤602）。所述方法还可以包括由客户端与接收第一片段同时接收第二片段（步骤604）。在一些实施例中，客户端可以继续发送对片段的请求，并接收对应的片段，直到客户端已经接收到媒体段的所有片段为止。所述方法还可以包括解码和播放第一片段（步骤606）。在一些实施例中，解码和播放第一片段在客户端接收第一媒体段的第三片段之前发生。所述方法还可以包括验证第一片段（步骤608）。所述方法还可以包括验证第一媒体段（步骤610）。在一些实施例中，在验证第一片段之后并且在验证第一媒体段之前，解码和播放第一片段发生。

本发明的实施例可适用于多个不同递送机制。例如，在一些实施例中，客户端可以主动地从服务器请求或拉取数据（包括例如媒体段的片段）。在其它实施例中，客户端可以是被动的，并且某一其它实体可以向客户端推送数据（包括例如媒体段的片段）。

图7示出了用于递送媒体流的示例性实施例。根据一个实施例，提供了一种用于向客户端递送媒体段的方法。所述方法包括生成被分段成片段序列的媒体段的分段图（步骤708）。所述方法还包括向客户端发送分段图（步骤710）。在一些实施例中，所述方法还可以包括由服务器接收媒体段（步骤702）。例如，服务器可以经由源馈送302接收媒体段，并且通过编码器304、分组化器306和分段器308中的一个或多个来传递分段。所述方法还可以包括将媒体段分段成包括第一片段和第二片段的片段序列（步骤704）。例如，此类分段可以由分段308完成。所述方法还可以包括从客户端接收对媒体段的第一请求（步骤706）。所述方法还可以包括从客户端接收对第一片段的第二请求（步骤712）。所述方法还可以包括向客户端发送第一片段（步骤714）。所述方法还可以包括基于新信息来更新分段图并向客户端发送经更新的图（步骤716）。例如，在一些实施例中，新信息包括以下项中的一项或多项：多个片段中的一个片段的长度、媒体段中该片段的开始位置以及媒体段中该片段的结束位置。在一些实施例中，响应于客户端请求经更新的分段图，可以执行更新分段图和向客户端发送经更新的图中的一个或两者。在一些实施例中，服务器可以引导客户端从辅服务器（例如，不同信任域中的带外服务器）请求片段。在一些实施例中，分段图将包括将客户端引导到针对具体片段的辅服务器的信息。

图8示出了根据示例性实施例的用于解码媒体段的方法。所述方法包括由客户端发送对媒体段的请求（步骤802）。所述方法还包括由客户端接收被分段成片段序列的媒体段的分段图（步骤804）。在一些实施例中，所述方法还可以包括由客户端请求第一片段（步骤806）。所述方法还可以包括由客户端接收第一片段（步骤808）。所述方法还可以包括由客户端播放第一片段（步骤810）。所述方法还可以包括验证第一片段的完整性（步骤812）。所述方法还可以包括验证媒体段的完整性（步骤814）。所述方法还可以包括接收经更新的分段图（步骤816）。在一些实施例中，对于多个片段中的其它片段中的每个片段，所述方法还可以包括请求、接收和播放此类片段。在一些实施例中，在播放媒体段的任何片段之前，客户端首先验证此类片段的完整性，并且只有在客户端肯定地验证了此类片段的完整性时才播放此类片段。在一些实施例中，客户端可以采用与对应于片段序列的逻辑排序不同的顺序来排序对片段的请求。在一些实施例中，以之做出对片段的请求的顺序至少部分地取决于相关性信息，例如关于每个片段的大小相关性和内容相关性信息。在一些实施例中，客户端可以并行地做出对不同片段的请求。在一些实施例中，可以从不同服务器接收片段，并且在一些实施例中，可以向不同服务器发送对片段的请求。

现在参考图9，客户端102还可以与请求调解器902进行通信。请求调解器902可以是客户端102的一部分（例如，客户端102可以执行与客户端102的请求调解器组件进行通信的应用，例如视频播放器），或者请求调解器902可以位于客户端102附近，或者它可以是服务器104的一部分，或者位于服务器104附近，或者它可以与客户端102或服务器104分离且独立于客户端102或服务器104。在从服务器104接收到分段图之后，客户端102（例如，应用）可以发送对各种媒体段的一系列请求。分段图可以指示一些片段具有对其它片段的相关性。这可能意味着，例如，在可以检索一个片段之前，必须首先检索另一片段。请求调解器902的角色是处理此相关性信息。因此，客户端102（例如，应用）可以向调解器902发送片段请求，并且调解器902然后可以基于分段图中包括的相关性信息在适当的时间向服务器104转发所述请求。这可能意味着，例如，调解器902立即向服务器104转发请求（例如，如果不存在相关性的话），或者它可能意味着调解器902引起在满足条件之前挂起或阻塞的请求（例如，分辨出（resolve）任何相关性）。请求调解器902还可以包含用于允许其基于片段优先级或其它片段元数据来调解请求的逻辑。

现在参考图10，客户端102还可以与多个辅服务器1002进行通信。因此，客户端102可以从不同辅服务器1002中的一个或多个接收一个或多个片段，而不是从服务器104接收所有媒体段。根据一些实施例，客户端102将初始从服务器104请求片段，但是请求然后将被重新引导到辅服务器1002中的一个。根据一些实施例，例如，基于被包含在分段图中的信息（例如，片段定位符可以指向辅服务器），客户端102将初始直接从辅服务器1002中的一个来请求片段。根据一些实施例，请求调解器902将把请求引导到辅服务器中的一个。例如，请求调解器902可以充当负载平衡器，并且可以基于诸如发送到其它服务器的请求的量和可用带宽的多个因素或者基于地理考虑来做出将请求引导到辅服务器的决定。

辅服务器1002中的一个或多个和服务器104驻留在不同信任域（例如，图10中示出的三个信任域1004、1006、1008中的一个）中是可能的。这可能暗示同一起源策略，并且具有对于希望在访问资源之前验证该资源的完整性的客户端的暗示。本发明的实施例完全支持这一点，并使能客户端跨多个不同信任域来验证完整性，如下面更完整解释的。

尽管未在附图中完全示出（出于简单性的缘故），在一些实施例中，客户端102、服务器104、请求调解器902和辅服务器1002中的每个各自能够互相进行通信（例如，服务器104可以与辅服务器1002中的每个进行通信，并且反之亦然）。还注意到，服务器104的责任可以在一个或多个辅服务器1002之间分发。这意味着，例如，编码媒体资源的服务器、生成分段图的服务器、调解客户端请求的服务器、以及向客户端供应媒体资源片段的一个或多个服务器可以各自是不同的服务器。

机密性和完整性解决方案

无论是否采用机密性和完整性机制，分段图提供了优点。然而，在采用此类机制的情况下，分段图提供了超过现有技术水平的附加优点。

通常，可以采用多种方式来确定完整资源的完整性。最基本的一个方式是当在客户端中已完全接收到资源时验证资源。此类解决方案中的最基本解决方案是简单地计算关于完整资源的散列值，并将其包括在分段图中，假设从资源的权威域（authoritativedomain）的安全性递送。对于此，存在若干解决方案，例如HTTP的内容签名报头字段（参见例如[CONTENTSIG]）或Merkle完整性内容编码（参见例如[MICE]）。然而，使用这些方法以用于客户端可能想要逐步消耗的资源的分段存在明显的缺点。对于此类方法，客户端或应用如果想要避免使用未验证的数据，则必须等待直到完整资源已被递送为止。当然，如果使用未验证的数据是可接受的，则备选方案会是消耗数据并且然后如果资源稍后验证失败则警告用户或以其它方式处理。这种方法可能是有风险且不得当的，因为它取决于使用未验证且因此不受信任的数据。

用于验证的此类方法的另一问题是，如果完整资源验证指示资源未正确验证，则客户端不能确定哪个片段引起验证失败。为了解决此问题，独立资源片段需要其自己的完整性验证信息。这可以通过以下操作来完成：在递送协议级别上将每个片段视为其自己的资源，并且使分段图指示用于每个片段的完整性验证机制，连同与完整性验证机制关联的任何参数。

为了在逐步消耗资源片段时使能验证，需要在递送资源片段的适合组块时在资源片段的适合组块上提供完整性解决方案。此类解决方案应该优选地关于记录大小是灵活的，以当在每个组块中提供的数据量与固定记录大小不对齐时避免阻塞问题。对于像如视频的媒体流，单个媒体样本（例如，经编码的视频帧）是要保护的适合组块。MICE可以可用于所准备的数据，以及可用于在开始递送资源段之前完整DASH段可用的情况（即，不动态生成媒体流的情况）。可以在该设置中通过在每个递送组块中递送完整记录来围绕（由MICE所施加的）固定记录大小而工作。

然而，上面的方法未良好地作用于直播或动态生成的内容，在所述内容中下一媒体样本在准备传送具体组块的时间是不可用的。替代地，另一方法是对独立组块（而不是完整媒体段）进行散列，并将得到的散列与每个记录一起包括。可以使用散列上的签名或使用加密钥的散列来使散列在起源于受分段图的提供方所信任的源时在客户端中是可验证的。由于完整性机制及其用于保护数据的结构，此解决方案避免了添加任何显著延迟。

数据完整性（是该数据可信赖的）是安全性的一个重要方面。另一方面是机密性（保持数据对未授权方是隐藏的）。

本发明的实施例允许在多个实体（例如，靠近于用户的边缘服务器或高速缓存）上扩展的资源的递送。但是，具有可能潜在地产生和递送给定媒体资源的不同片段的多个实体存在关于机密性的一些复杂性。出于安全性原因，不同的实体可能不共享安全性上下文。因此，分段图可能需要指示资源片段特定的安全性上下文信息，例如密钥。

逐步消耗的资源片段的机密性的另一方面是确保片段可以从其开始点被解密，并且可以解密在组块级别上的数据。在一些情况下，这可能要求加密层填充以确保加密算法可以在组块边界执行解密。

利用不同的信任域

通过利用独立资源片段的通用定位符，可以潜在地从任何位置检索具体资源片段。也就是说，一个片段的检索点可能不取决于另一片段的检索点。因此，可以从不同信任域（例如，可能具有不同域名***（DNS）名称的不同主机）检索不同片段。还可以使用OOB内容编码来提供资源段，使能资源片段的主域在轮到它时指向可以检索片段的内容的一个或多个辅资源。

这两个解决方案可以潜在地被集成到具有多个OOB辅资源的组合式分段图中，或者所述两个解决方案可以采用合适的组合在彼此之后被应用。

由分段图以及OOB编码解决方案所创建以指向任何资源位置的可能性具有各种影响。例如，在HTTP中，这可能影响同一起源策略（参见例如[RFC6454]），从而使能在完整资源的域（主域）的控制之外加载资源。为避免这种结果，可以应用适当的安全性模型。一种可能性是主域（即，提供分段图的域）提供用于验证来自辅域的所检索的段的完整性的方法，即，从辅域检索的内容与根据主域所意图的内容匹配。通过在分段图中包括片段的散列，可以最容易地实现这一点。另一可能性（基于信任辅域的主域）是具有使主域指示主域对辅域具有的信任的某一方式。例如，主域可以通过在分段图中指示辅域将使用哪个密钥或证书来证明资源片段的完整性而指示主域对辅域具有的信任。

分段图的示例实施例

对于分段图，存在满足大部分或所有上述特性的许多不同形式和格式。下面提供了可以与HTTP 1.1一起使用的分段图的一个可能实施例。

在此示例中，客户端使用HTTP 1.1请求在定位符（例如，URL）“https://example.org/xyz/seg-2-14.mp4”处的资源（其在此示例中是分片段的MPEG-4（mp4）媒体段）。客户端指示它支持称为“分段”的内容编码，以指示其对分段机制的支持。服务器也在响应中支持并利用分段机制。所述响应包括分段的内容编码的使用的指示，并且主体包括描述片段的JSON编码的分段图。在这种情况下，第一请求在已构建完整资源之前到达。

HTTP请求如下：

包括示例性分段图的对HTTP请求的响应如下：

分段图通过资源级别性质开始。这包括通过分段图所描述的资源的实际媒体类型（“Content-Type”）。这也是分段图可以包括像如关于完整资源的散列的资源级别完整性机制的地方。然而，在此示例中，这是不可能的，因为资源尚未被完全构建。然而，用于加密不同资源片段的秘密密钥（crypto key）被包括在“Crypto-Key”参数中。完整资源URL被包括仅为了使能处理在HTTP请求的上下文之外的分段图。

分段图还包括“Update-Hint”属性。这指示建议为了更完整信息何时更新分段图。在这种情况下，存在Cntent-Dependency属性，其具有更新取决于被标识为“4”的片段的内容可用性的含义。如稍后将描述的，这指示当在服务器侧已知资源内容时，然后可以在没有开放范围的情况下构建此分段图（即，具有开始和结束位置的已知值）。然而，Content-Dependency属性要求客户端请求数据来确定何时可以更新分段图。由于此方法要求在请求经更新的图之前处理片段，因此另一补充方法是使用更基于时间的提示。此示例包括HTTP到期报头，其用于指示在服务器生成分段图后3秒，应更新分段图。在这种情况下，3秒是基于在这一时间将已经构建了完整资源的知识而被指示的。到期报头也作为参数被包含在“Update-Hint”属性中。

在资源级别属性之后，接着是描述排序的片段序列的阵列。在此示例中，资源（媒体段）在逻辑上被分段成四个片段：对应于媒体段的styp框的第一片段；对应于媒体段的moof框的第二片段；对应于mdat框的报头部分的第三片段；以及对应于mdat框的有效载荷部分（即媒体样本）的第四片段。

关于术语的注释：在包括实际资源数据的意义上，分段图不包括“片段”；替代地，分段图包括与每个资源片段关联的元数据，包括关于如何获得实际资源数据的信息。因此，当描述分段图中的“第一片段”时，意味的是第一片段的元数据，或被存储在分段图中的、与第一片段关联的信息。

现在描述阵列中的第一片段（也就是说，第一片段的元数据）。第一片段中的第一元数据信息是片段的标识符，在“Fragment”参数中给出并且具有值“1”。这后面是“FL”参数，所述“FL”参数提供此片段的片段位置集合，即一个或多个URL，在其中片段可以被请求作为其自己的资源。“Offset”参数提供到完整资源中的片段的偏移（或完整资源中的片段的位置），以及片段的长度（如果已知的话）。格式是“开始-结束/长度”。偏移参数的三个值部分中的任何一个，即开始位置、结束位置或长度，可能是未知的（并且因此不被提供）。此第一片段在完整资源的开始处（开始=0）并且具有已知长度（长度=494）。在所述示例中，值“0-493/494”提供开始字节、结束字节和以字节为单位的长度。

第一片段的下一参数是“Size-Dependency”和“Content-Dependency”。通过列出片段的标识符，这些参数可以表达对其它片段存在什么相关性。大小相关性参数是片段标识符集合，其标识客户端需要什么其它片段的大小信息（开始和结束位置、长度）以便确定给定片段的开始位置。内容相关性参数是片段标识符集合，其标识客户端需要什么其它片段以便接收给定片段。在这种情况下，这两个相关性参数包括空集。因此，可以在HTTP响应中排除所述参数，但出于解释的缘故，在这里包括所述参数。优先级参数指示在请求此片段方面关于其它片段的相对优先级；在这个示例中，更低的数字是更重要的，或者具有更大优先级。下面更多地描述此信息的潜在使用。

仍然考虑第一片段的元数据，在优先级参数之后，接着有与作为其自己的资源的片段相关的属性集合。也就是说，在取得片段时可以使用参数。在这种情况下，指示“aesgcm”的内容编码。AES GCM（参见，例如，[aesgcm]）是跨整个片段的加密和完整性保护机制。采用此内容编码的片段可以从片段开始到结束在秘密块基础上被连续解密，但完整性验证只能在已经递送完整片段时被执行。这种机制是加密钥和伪装过的（salted）；密钥是用于解锁机密性保护的方法，并且也是用于确保为片段保留了完整性的方法。在本示例中，实际key-id跨所有资源片段而是公共的（并且与Crypto-Key参数中包括的资源级别key-id值相同）。然而，此示例中的每个片段有单独的伪装过的值，以便防止对两个片段使用相同的密码。这由“Encryption”参数提供。这结束了第一片段的元数据。

第二片段是类似的，但是将描述其参数和附加参数方面的一些差异。首先，片段id为“2”，并且此片段的URL也指向第二片段（也就是说，URL与第一片段的那些URL不同）。片段的偏移提供了开始位置，但是具有未知长度，并且因此具有未知的结束位置。优先级被设置成1，此完整资源中最优先化的片段。属性包括“Transfer-Encoding”：“chunked”。这指示可以使用HTTP分组块机制来递送此片段。例如，这可以用于当在服务器侧生成数据时（例如，当生成媒体样本及其元数据时）针对片段逐步递送所述数据。“Type-Specific”：“moof”参数和数据要在完整资源媒体类型“video/mp4”的上下文中被解译。例如，“moof”可以指示此片段包含moof框。

在此示例中，第三片段（id=“3”）具有已知长度（长度=12字节），但是因为它在具有未知长度（直到客户端完全构建第二片段或接收经更新的分段图为止）的第二片段之后到来，因此开始或结束偏移是未知的。此片段对其它片段的相关性使用“Size-Dependency”：{[“1”，“2”]}和“Content-Dependency”：{[“4”]}来表达。大小相关性在这里意味着当片段1和2的大小已知时，给出此片段的大小和位置（也就是说，将被客户端已知）。Content-Dependency在这里指示此片段的内容具有对片段4中的内容的相关性。在这种情况下，这是因为片段3表示包含片段4中的数据的长度字段的报头。所以在已完全生成片段4之前不能检索片段3，因为在该时间之前片段3本身不能被生成。如所指示的，此片段具有顶级优先级，也就是优先级1。

第四片段（id=“4”）具有与第二片段类似的性质。然而，由于更早的片段具有未知大小，因此在生成分段图的时间此片段的实际偏移是未知的。此片段的优先级是“1”，并且它不具有对其它片段的内容相关性。然而，其大小和偏移取决于片段3。内容类型特定提示“Type-Specific”：“mdat-samples”指示此片段在mdat框的样本的开始处开始。此提示使能媒体类型感知客户端在数据正由分组块的HTTP传输所递送时开始消耗数据。

如上面所指示的，在此示例中，每个片段的元数据包括指示其在序列中的顺序的片段标识符（即，标识符1、2、3和4）。此外，片段（即，多个片段元数据）被存储在阵列中，在此示例中，阵列是排序的数据结构，阵列可以对片段施加顺序。在此示例中，两个顺序（由数据结构所暗示的顺序和由片段标识符所指示的顺序）是一致的。

给定上述分段图，客户端可以确定用于请求片段的适合顺序。例如，对于不具有存储约束且不具有附加拷贝问题的客户端（例如，客户端愿意执行片段的中间检索并然后执行片段的组装），则一种可能的检索策略会是请求片段2（其不具有内容相关性并具有优先级1），并且并行地请求片段4（也不具有相关性并具有优先级1），并且并行地请求片段1（也不具有相关性，但具有较低的优先级3）。这留下了片段3。片段3具有内容相关性（对片段4），但是为了使延迟保持最小，客户端可以早地对此片段进行另一并行请求，期望此请求将挂起，直到片段4已被完全生成为止。

现在参考图11，描绘了完成上面请求的可能情形。在时间T0，分段图已由客户端处理，并且客户端如上所述那样进行请求。一已由适当的服务器处理了独立请求，就开始片段1、2和4（各自不具有内容相关性）的递送。尽管片段1具有更低的优先级，但在此示例中，由于其有限的大小，片段1将首先完成（在时间T1）。片段2和4（按其传输编码值）正使用分组块的递送。在这种情况下，如由条形图所描绘的，将周期性地传输媒体样本和元数据的组块。在时间T2，服务器（或多个服务器）已经完成了片段2和4的数据的生成，并且略在T2之后它们的递送将完成，并且分组块的传输机制将指示它们的递送的完成。根据此示例，对片段3的请求已由于其内容相关性而从T0一直到T2正挂起。在时间T2，已经生成了片段3的数据（在此示例中是标识mdat框的长度的长度信息）并且可以开始其递送。片段3的递送在时间T3被完成。在时间T3，客户端可以将片段组装成ISO BMFF媒体段。

如上面所指示的，请求的顺序对应于不具有存储约束且不具有附加拷贝的问题的客户端。然而，对于受限的接收器，例如想要避免拷贝并最小化存储要求的接收器，接收器可以使用大小相关性元数据来确定它可以采用哪种顺序来请求片段使得它们的位置是已知的。在这种情况下，客户端初始会只请求片段1和2。这是因为片段1和2不具有大小相关性；也就是说，片段1具有已知大小并在资源文件的起始处开始。片段2在片段1之后直接开始，但其长度不是初始已知的。因此，接收器将能够在接收到数据时将数据写入公共连续文件中。当片段2已经被递送时，然后片段3和4会具有已知大小。因此，客户端然后可以并行地请求片段3和4两者。通过已知大小和到连续文件中的偏移，可以在接收时直接将数据写入正确的位置中。

用于DASH直播媒体段的另一示例实施例

本申请中描述的分段解决方案的实施例可用于减少从在媒体递送服务器处内容摄取开始直到在客户端处已开始播出的延迟（T_{源_到_回放}）。初始，编码器采用适合于流播递送的格式（例如，H.264）在单个帧级别上或在某一略微更粗略的级别上（例如对于每一个图片群组（GOP））生成编码的媒体内容。从这里，所编码的媒体被分组化，或者通过分组化器或文件格式构建器，以将所编码的媒体置于用于通过基于分组的协议（例如HTTP）的递送的格式中（例如，所编码的媒体被置于mp4或ISOBMFF格式中）。

现在将使用具有ISOBMFF文件的DASH直播媒体流播来描述示例。

对于此示例中的每个媒体段，假设所述段具有3秒的长度并且采用ISOBMFF格式来提供。文件构建器创建初始结构，在这种情况下通过段类型框（styp）开始。这可以基于在媒体初始化段中使用的文件类型和媒体段的类别来构建。对于根据DASH所分段的ISOBMFF文件，单个段将使用电影片段（moof）框来提供关于样本位置的信息。这里的问题是moof框中的一些信息取决于独立样本。此类相关性的一个示例是跟踪片段运行框（trun），其是跟踪片段框（traf）的一部分，所述跟踪片段框是moof框的一部分。对于存储在mdat内部的每个样本，trun包含到此样本所位于的地方的偏移。因此，在已将对应样本添加到mdat中之后（即，当首先知道偏移时），只能将偏移写入trun中的样本条目中。作为相关性的另一示例，框的长度字段可能是问题，因为在所有框或样本被写入给定框中之前不知道该框的完整长度。如果框运行直到文件的结束，则为长度指定值0是可能的，这意味着框的长度持续直到文件的结束。然而，由于mdat框通常必须在moof后，所以moof的长度通常不能被指定为0。

本申请中公开的资源分段的实施例可以被应用于根据DASH规范的ISOBMFF的使用而格式化的媒体段。这样做可以减少延迟并在媒体样本数据变得可用时使能HTTP分组块递送或其它推送递送。

现在参考图12，DASH媒体段资源的分段可以如下进行。第一资源片段1210可以包含文件的开始，具有可以初始生成的信息。此片段1210包含在已生成所有样本之前已知的所有初始框1204。下一资源片段1212可以包含moof框1206。如[S4-141201]中所描述的，在生成所有样本之前估计moof框1206（连同被包含在moof框内的框）将占多少地盘空间。此类估计可能包括一些保留空间。因此，可以估计完整长度，并且如果在已添加必要样本之后存在任何剩余空间，则可以使用空闲框将此空间标记为空闲（在这种情况下需要空闲框以符合ISOBMFF规范）。注意到，低估大小在这里将导致差地或不完整地格式化的段；高估大小将导致浪费的空间。因此高估是优选的。估计可以基于例如已知或估计的帧速率和持续时间，引起已知或估计数量的样本。第三资源片段1214可以包含mdat框1208。在生成所有样本之前，此框1208的大小是未知的，然而所述框将运行直到文件的结束。因此，可能使用长度字段值0。第三资源片段1214主要包括mdat框1208的数据部分，即媒体样本的数据。这里，资源段的初始偏移是已知的（片段3偏移=1562），但是对应于框的结束的偏移是未知的。因此，结束偏移被指示为开放式的。

客户端现在可以通过首先检索第一资源片段开始。在那之后，客户端可以检索第二片段（具有trun框的内容）和第三片段（具有mdat框的内容）；这两个片段可以开始使用两个独立的HTTP资源请求通过独立资源片段的HTTP分组块来递送。HTTP分组块用于在适当的数据组块（例如，独立媒体样本）完成编码时递送它们，并且对应的样本在它们被完成时在trun框中运行。当属于媒体段的所有样本已被写入mdat框中时，则通过使用HTTP分组块来关闭片段以指示分组块的递送的结束。moof片段还通过写trun框的最后部分来完成，并且剩余空间（如果有的话）被空闲框消耗（从而使片段的字节计数达到预确定的长度）。这完成了媒体段的递送。

如果必要的话，分段图还可以包含提示以向接收客户端指示资源片段的开始是什么。例如，分段图可能指示一个片段是mdat框的开始（这里是片段3），这会使能客户端在媒体样本通过http分组块而得以递送时消耗所述媒体样本。

上面的示例使用估计的和预先指配的空间以用于moof框（并且尤其是trun框）的内容要被写入的资源段。备选实施例不估计此框需要多少空间，并且替代地指示该资源段在开始处具有未知长度，并且然后使用HTTP分组块来指示何时已递送完整资源段，即，何时已包括意图被包括在ISOBMFF段文件中的所有样本，并且已知所有数据的最终位置。当发生该情况时，则写最终的trun，并且当确定moof框的结束时，HTTP分组块递送空组块以指示这是结束。然而，为了在这种情况下正确指示moof框的长度，moof框的开始（包括长度字段）需要被置于单独的片段中，使得此单独的片段可以在已确定moof框的长度之后被递送。

此方法（即，不估计moof框需要多少空间）具有避免错误估计所需空间的风险的优点，并且还避免浪费任何未使用的空间。然而，如果要存储最终资源以用于将来用途，则将通常要求附加的拷贝操作来将资源片段组装为最终组装资源的一个连续字节流。但是，在一些用例中，这不是主要用途，并且替代地，对数据的最早可能访问同时仍然被格式化为遵循ISOBMFF的直播配置文件是主要用途。

比较性示例

现在提供比较性示例。服务器（例如服务器104）正服务两个客户端，第一个是能够接收和处理根据当前公开的实施例的分段图的客户端（例如客户端102）（称为“智能客户端”），第二个是根据当前公开的实施例不能够接收和处理分段图的常规客户端（称为“哑客户端”或“常规客户端”）。

服务器正提供对直播流播媒体事件（例如，晚间电视新闻节目）的访问。当事件正在进行时，服务器正继续接收源馈送。服务器可能很少了解源馈送，例如总持续时间、源馈送质量、预期收视率等等；备选地，可以预先完全确定此类信息，或者服务器可以具有一些信息，要关于所述一些信息形成此类事情（例如，节目的典型开始和停止时间，以及传入馈送的典型质量）的估计。在任何事件，服务器都为直播流播媒体事件准备清单文件。此文件将把事件分解成多个段或媒体资源，典型独立地在2秒到10秒持续时间之间。清单文件可能包含关于客户端何时应该访问具体段或媒体资源的提示。例如，服务器可以知道或估计它将在时间t0开始接收第一资源以及它将花费A秒来处理资源（例如，来编码和分组化资源使得其准备好到客户端的递送）。

常规客户端将遵循清单文件，因为它不能在服务器已经处理单独的媒体资源并且准备所述单独的媒体资源以用于递送之前开始接收所述单独的媒体资源。因此，常规客户端将在时间t1（t1=t0+A）或在其之后请求第一媒体资源。因此，常规客户端的延迟T_{源_到_接收}是A。A的典型值可以在2秒到10秒之间。

此外，常规客户端将必须在开始回放之前接收和处理整个资源，这将花费B秒。因此，常规客户端在时间t2（t2=t1+B=t0+A+B）之前不能开始回放，并且因此常规客户端的延迟T_{源_到_接收}是B。这引起延迟T_{源_到_回放}=A+B.

另一方面，智能客户端，也就是能够接收和处理分段图的客户端，将能够在服务器完全处理第一媒体资源之前请求第一媒体资源。生成分段图并开始向客户端提供部分媒体资源可能只花费服务器C秒。因此，智能客户端将在时间t1'（t1'=t0+C）或在其之后请求第一媒体资源。因此，智能客户端的延迟T_{源_到_接收}是C。C的典型值可以是大约200ms。此时间由用于形成分段图的时间、用于递送分段图的额外往返组成，并且然后使客户端要求片段，并且然后能够开始递送片段。

此外，智能客户端能够在接收整个段之前开始回放。例如，如上面所描述的，应用级别提示可以使能客户端这样做，例如在接收的D秒内。因此，智能客户端可以在t2'（t2'=t1'+C=t0+C+D）开始回放，并且因此智能客户端的延迟T_{源_到_接收}是D。这引起延迟T_{源_到_回放}=C+D。在本示例中，因为MOOF相对小（几kb），所以在此示例中，差B-D在几毫秒的数量级上。

根据此示例，延迟T_{源_到_接收}可以从大约2-10秒减少到大约200毫秒，或减少大约90％-98％。延迟T_{接收_到_回放}可以减少几毫秒。总的来说，这引起从源摄取到回放的延迟方面的显著减少。

如从此示例中显而易见的，资源段可用于由客户端消耗时的时间将取决于客户端是否支持分段的模式而显著不同。在一些实施例中，支持分段的模式的智能客户端可以确定忽略或适当地修改清单文件中提供的可用性提示。在一些实施例中，服务器可以向常规客户端提供一个清单文件，并向智能客户端提供不同的清单文件（具有修订的可用性提示）。

图13是根据一些实施例的可用于实现客户端102或服务器104的设备1300的框图。如图13中示出的，所述设备可以包括：数据处理***（DPS）1302，其可以包括一个或多个处理器1355（例如，通用微处理器和/或一个或多个其它处理器，诸如专用集成电路（ASIC）、现场可编程门阵列（FPGA）等等）；传送器1305和接收器1306，其可被耦合到天线或通信端口以供与其它设备进行通信使用；以及本地存储单元（也称为“数据存储***”）1312，其可以包括一个或多个非易失性存储装置（例如，闪速存储器、硬盘、光盘等）和/或一个或多个易失性存储装置（例如，易失性随机存取存储器（RAM））。在DPS 1302包括可编程微处理器的实施例中，可以提供计算机程序产品（CPP）1341。CPP 1341包括存储包括计算机可读指令（CRI）1344的计算机程序（CP）1343的计算机可读介质（CRM）1342。CRM 1342可以是非暂时性计算机可读介质，例如但不限于磁介质（例如，硬盘）、光介质（例如，DVD）、存储器装置（例如，闪速存储器、易失性RAM）等等。在一些实施例中，计算机程序1343的CRI 1344被配置使得当由数据处理***1302执行时，CRI使设备执行本文描述的步骤（例如，上面参考流程图所描述的步骤）。在其它实施例中，所述设备可以配置成在不需要代码的情况下执行本文描述的步骤。也就是说，例如，数据处理***1302可以仅由一个或多个ASIC组成。因此，本文描述的实施例的特征可以采用硬件和/或软件来实现。

虽然本文（包括附录）描述了本公开的各种实施例，但应该理解，它们仅作为示例而非限制已被呈现。因此，本公开的广度和范畴不应该受任何上述示例性实施例所限制。此外，除非本文以其它方式指示或通过上下文以其它方式明确否定，否则采用其所有可能变型的上述元件的任何组合都被本公开所涵盖。

此外，虽然上面描述的和附图中示出的过程被示出为一系列步骤，但这仅仅是出于说明的缘故而进行的。相应地，设想可以添加一些步骤、可以省略一些步骤、可以重新布置步骤的顺序、并且可以并行地执行一些步骤。

Claims

1. 一种方法，包括：

服务器（104），所述服务器（104）生成媒体段的分段图，所述媒体段包括排序的片段集合（1210，1212，1214），所述排序的片段集合（1210，1212，1214）包括第一片段（1210）和第二片段（1212）；以及

所述服务器（104）向客户端（102）提供所述分段图，其中

所述分段图包括：

与所述第一片段（1210）关联的第一片段元数据；

与所述第二片段（1212）关联的第二片段元数据；以及

标识所述集合（1210，1212，1214）内的片段的排序的排序信息，所述排序信息包括指示所述第一片段（1210）被排序在所述第二片段（1212）之前的信息，以及

所述第一片段元数据包括：1）供访问所述第一片段（1210）使用的第一片段标识符，以及2）以下项中的一项或多项：

2a）所述第一片段（1210）的第一相关性信息，所述第一相关性信息指示要从所述服务器（104）递送的所述第一片段（1210）的可用性取决于所述集合（1210，1212，1214）中的一个或多个其它片段；

2b）第一位置信息，所述第一位置信息包括以下项中的一项或多项：所述第一片段（1210）的长度、所述媒体段中的所述第一片段（1210）的开始位置、以及所述媒体段中的所述第一片段（1210）的结束位置；以及

2c）供验证所述第一片段（1210）的完整性使用的第一片段级别安全性信息，以及

所述第二片段元数据包括供访问所述第二片段（1212）使用的第二片段标识符。

2. 如权利要求1所述的方法，其中所述第一片段元数据包括所述第一相关性信息、所述第一位置信息和所述第一片段级别安全性信息。

3. 如权利要求1或2所述的方法，其中

所述第一片段元数据包括所述第一片段级别安全性信息，以及

所述片段级别安全性信息包括散列信息，所述散列信息由所述服务器（104）用来生成以下项中的至少一项的散列：所述第一片段（1210）和所述第一片段（1210）的一部分。

4.如权利要求1-3中任一项所述的方法，其中所述第二片段元数据还包括以下项中的一项或多项：

所述第二片段（1212）的第二相关性信息，所述第二相关性信息指示要从所述服务器（104）递送的所述第二片段（1212）的可用性取决于所述集合（1210，1212，1214）中的一个或多个其它片段；

第二位置信息，所述第二位置信息包括以下项中的一项或多项：所述第二片段（1212）的长度、所述媒体段中的所述第二片段（1212）的开始位置、以及所述媒体段中的所述第二片段（1212）的结束位置；以及

供验证所述第二片段（1212）的所述完整性使用的第二片段级别安全性信息。

5.如权利要求1-4中任一项所述的方法，其中所述第一片段元数据还包括与所述第一片段（1210）对应的优先级值。

6.如权利要求1-5中任一项所述的方法，其中所述第一片段元数据还包括编码标识符。

7. 如权利要求1-6中任一项所述的方法，其中所述第一片段标识符包括标识所述第一片段（1210）的统一资源标识符URI。

8. 如权利要求1-7中任一项所述的方法，其中

所述第一片段元数据还包括与所述媒体段的类型关联的应用级别提示，以及

所述应用级别提示使能客户端（102）在接收另一些多个片段（1210，1212，1214）中的每个之前利用所述第一片段（1210）。

9. 如权利要求1-8中任一项所述的方法，其中

所述第一相关性信息包括大小相关性信息，以及

所述大小相关性信息指示在可以确定所述第一片段（1210）的大小之前必须被生成的零个或多个其它片段（1210，1212，1214）。

10. 如权利要求1-8中任一项所述的方法，其中

所述第一相关性信息包括内容相关性信息，以及

所述内容相关性信息指示在可以生成所述第一片段（1210）的内容之前必须被生成的零个或多个其它片段（1210，1212，1214）。

11.如权利要求1-10中任一项所述的方法，其中所述排序信息包括与每个片段元数据关联的序列标识符。

12.如权利要求1-10中任一项所述的方法，其中所述排序信息在存储多个片段元数据的数据结构中是隐式的。

13.如权利要求1-12中任一项所述的方法，其中所述分段图还包括媒体段元数据，所述媒体段元数据包括以下项中的一项或多项：

所述媒体段的媒体类型；

资源级别完整性信息；

所述媒体段的统一资源定位符URL；以及

指示建议所述客户端（102）何时更新所述分段图的更新提示，所述更新提示包括以下项中的一项或多项：到期时间和内容相关性属性。

14. 如权利要求1-13中任一项所述的方法，还包括：

从所述客户端（102）接收对所述媒体段的请求；以及

响应于对所述媒体段的所述请求，向所述客户端（102）发送所述分段图。

15. 如权利要求14所述的方法，还包括：

从所述客户端（102）接收对所述第一片段（1210）的请求；以及

响应于接收到对所述第一片段（1210）的所述请求，向所述客户端（102）发送所述第一片段（1210）。

16. 如权利要求1-15中任一项所述的方法，还包括：

基于新信息来更新所述分段图，其中所述新信息包括以下项中的一项或多项：多个片段（1210，1212，1214）中的一个片段的长度、多个片段（1210，1212，1214）中的一个片段的开始位置、以及多个片段（1210，1212，1214）中的一个片段的结束位置；以及

向所述客户端（102）发送所更新的分段图。

17.一种服务器（104），所述服务器（104）配置成执行如权利要求1-16中任一项所述的方法。

18. 一种服务器（104），所述服务器（104）包括：

数据存储***（1312），所述数据存储***（1312）包括存储器；以及

数据处理***（1302），所述数据处理***（1302）包括处理器（1355），其中所述服务器（104）配置成执行如权利要求1-16中任一项所述的方法。

19. 一种方法，包括：

客户端（102）接收由服务器（104）传送的分段图，其中所述分段图用于包括多个媒体段的媒体流的第一媒体段，所述多个媒体段包括所述第一媒体段和第二媒体段，所述第一媒体段包括排序的片段集合（1210，1212，1214），所述排序的片段集合（1210，1212，1214）包括第一片段（1210）和第二片段（1212）；以及

所述客户端（102）处理所述分段图，其中

所述分段图包括：

与所述第一片段（1210）关联的第一片段元数据；

与所述第二片段（1212）关联的第二片段元数据；以及

2b）第一位置信息，所述第一位置信息包括以下项中的一项或多项：所述第一片段（1210）的长度、所述第一媒体段中的所述第一片段（1210）的开始位置、以及所述第一媒体段中的所述第一片段（1210）的结束位置；以及

20.如权利要求19所述的方法，还包括：

在接收由所述服务器（104）传送的所述分段图之前，所述客户端（102）向所述服务器（104）传送对所述第一媒体段的请求。

21. 如权利要求20所述的方法，还包括：

在接收由所述服务器（104）传送的所述分段图之前，接收清单文件，其中所述清单文件包括用于使能所述客户端（102）发送对所述第一媒体段的所述请求的信息；以及

处理所接收的清单文件，其中

所述客户端（102）在处理所述清单文件之后向所述服务器（104）传送对所述第一媒体段的所述请求。

22.如权利要求20或21所述的方法，其中对所述第一媒体段的所述请求包括指示所述客户端（102）支持分段的模式的指示符。

23. 如权利要求19-22中任一项所述的方法，还包括：

接收所述第一片段（1210）；以及

播放所述第一片段（1210）。

24.如权利要求23所述的方法，其中所述播放所述第一片段（1210）的步骤在所述客户端（102）接收被包括在所述排序的片段集合（1210，1212，1214）中的所有所述片段之前发生。

25.如权利要求23或24所述的方法，还包括：

验证所述第一片段（1210）的所述完整性。

26.如权利要求19-25中任一项所述的方法，其中

基于指示所述第一片段（1210）取决于所述第二片段（1212）的片段相关性信息，所述客户端（102）在传送对所述第一片段（1210）的请求之前传送对所述第二片段（1212）的请求。

27.一种客户端（102），所述客户端（102）配置成执行如权利要求19-26中任一项所述的方法。

28. 一种客户端（102），所述客户端（102）包括：

数据处理***（1302），所述数据处理***（1302）包括处理器（1355），其中所述客户端（102）配置成执行如权利要求19-26中任一项所述的方法。

29.一种计算机程序（1343），包括指令（1344），所述指令（1344）当由数据处理***（1302）执行时，使所述数据处理***（1302）执行如权利要求1-16和19-26中任一项所述的方法。

30.一种计算机程序产品（1341），包括非暂态计算机可读介质（1342），所述非暂态计算机可读介质（1342）包括如权利要求29所述的计算机程序（1343）。