媒体片段 URI 1.0 (基础)

1 简介

当前，万维网（Web）上的音视频资源被视为“外部”对象，只能通过能够解码并与媒体资源交互的插件嵌入。通常需要专门的媒体服务器提供服务器端功能，例如直接访问视频的时间偏移而无需检索整个资源。不同媒体格式对这种媒体片段访问的支持程度不同，且阻碍了在 Web 上统一处理此类内容的标准化手段。

本规范提供了一种与媒体格式无关的、在 Web 上通过统一资源标识符 (URI) 寻址媒体片段的标准方法。在本文档中，媒体片段从多个不同维度（如时间、空间和轨道）进行考量。时间片段还可以标记名称，并通过使用 id 维度的 URI 引用该名称来进行寻址。指定的寻址方案主要适用于音频和视频资源——空间片段寻址也可用于图像。

本规范旨在增强 Web 基础设施，以支持对基于时间的 Web 资源的子部分进行寻址和检索，以及为了重用而对这些子部分进行自动化处理。示例用途包括通过电子邮件与朋友共享此类片段 URI、在搜索引擎界面中自动创建此类片段 URI，或使用 RDF 标注媒体片段。此类用例示例以及本规范的其他辅助条件和现有媒体片段寻址方法的综述，均在随本文档附带的《媒体片段用例与要求》文档中提供。

2 标准化问题

2.1 术语

关键词 MUST（必须）、MUST NOT（不得）、SHOULD（应该）和 SHOULD NOT（不应该）按 RFC 2119 中的定义解释。

根据 RFC 3986，“URI”一词不包括相对引用。在本文档中，我们同时考虑 URI 和相对引用。因此，我们使用 RFC 3986（第 4.1 节）中定义的术语“URI 引用”。不过，为了简单起见，本文档仅使用“媒体片段 URI”来代替“媒体片段 URI 引用”。

以下术语在本文档中经常使用，需要明确理解：

URI 片段：片段组件由井号 ("#") 字符标识，并由 URI 的末尾终止。
URI 查询：查询组件由第一个问号 ("?") 字符标识，并由井号 ("#") 字符或 URI 的末尾终止。
媒体片段 URI：一种寻址媒体资源子部分的 URI——可以通过 URI 查询或 URI 片段来实现

2.2 媒体片段标准化

媒体片段 URI 标准化的基础是 URI 规范 RFC 3986。在 URI 中提供媒体片段标识信息，在此是指规定 URI 片段或 URI 查询的结构。本文档将解释 URI 片段和 URI 查询如何构建以识别媒体片段。它规范化了 URI 片段和 URI 查询中用于寻址媒体片段的键值参数。这些参数建立在现有的 CGI 参数约定之上。在本节中，我们将探讨标准化媒体片段 URI 结构的影响。

2.2.1 URI 片段

URI 规范 RFC 3986 在第 3.5 节中关于 URI 片段格式的表述如下：

“片段的格式和解析 [...] 取决于潜在检索到的表示形式的媒体类型 [RFC2046]。[...] 片段标识符语义独立于 URI 方案，因此无法由方案规范重新定义。”

这本质上意味着只有媒体类型定义（通过 RFC 4288 中定义的流程注册）才能为该 MIME 类型引入 URI 片段的标准结构。媒体类型注册过程的一部分可以包含有关如何构建与该媒体类型结合使用的 URI 中的片段标识符的信息。

如 RFC 4288 第 4.11 节所述，注册 URI 片段构建规则是一项“应该”（SHOULD）要求。媒体片段工作组无权更新所有目标媒体类型的注册表。对所有媒体类型注册的分析表明，目前只有 audio/*、image/*、video/* 分支中的极少数媒体类型定义了片段或片段语义（例如，参见 SVG 1.1 第 17 章中关于 SVG 的片段定义）。据我们所知，只有极少数媒体类型实际上具有指定的片段格式，即使它并未在媒体类型中注册：这些包括 Ogg、MPEG-4 和 MPEG-21。此外，只有少数软件库实际上支持这些片段格式。对于所有其他格式，片段的语义被认为是未知的。

因此，本文档旨在向 audio/*、image/* 和 video/* 分支中的所有媒体类型所有者提出建议，以实现一种结构化的 URI 片段方法，并规范化通过 URI 片段寻址媒体片段（即媒体资源的子部分）的通用维度。我们建议媒体类型所有者将其现有方案与本文档中提出的方案进行协调，并更新或在其媒体类型注册中添加片段语义规范。

2.2.2 URI 查询

URI 规范 RFC 3986 在第 3.4 节中关于 URI 查询格式的表述如下：

“查询组件 [...] 用于在 URI 的方案和命名权限（如果有）范围内标识资源。[...] 查询组件通常用于以“键=值”对的形式携带识别信息 [...]。”

URI 查询规范与 URI 方案的联系更为紧密，其中一些甚至不使用查询组件。我们主要关注 HTTP RFC 2616 和 RTP/RTSP RFC 2326 协议，这两者都支持查询组件。HTTP 对如何解释 URI 查询只字未提。RTSP 明确表示，此时片段和查询标识符没有明确定义的含义，其解释留给 RTSP 服务器。

URI 规范 RFC 3986 在第 7.3 节中特别指出 HTTP 的一般性描述：

“例如在 HTTP 中，典型的用户代理会将 URI 解析为其五个主要组件，访问权限服务器，并向其发送权限、路径和查询组件中的数据。典型的服务器将获取该信息，将路径解析为段，将查询解析为键/值对，然后调用实现特定的处理程序来响应请求。”

由于查询组件的解释取决于服务器的功能，本文档关于查询组件的意图是建议使用标准的键值对格式，以便通过 URI 查询寻址媒体片段。我们建议服务器和服务器类型软件提供商协调其现有的媒体资源使用方案，以支持本规范中提出的命名法。

3 URI 片段与 URI 查询

要寻址媒体片段，需要找到传达片段信息的方法。本规范建立在 URI 规范 RFC 3986 之上。每个 URI 定义为由以下四个部分组成：

<方案名称> : <层级部分> [ ? <查询> ] [ # <片段> ]

因此，在 URI 中表示媒体片段寻址有两种可能性：URI 查询部分或URI 片段部分。

3.1 何时选择 URI 片段？何时选择 URI 查询？

对于媒体片段寻址，两种方法——URI 查询和 URI 片段——都很有用。URI 查询和 URI 片段的主要区别在于，URI 查询产生一个新资源，而 URI 片段提供与主资源具有关系的次要资源。URI 片段是从主资源中解析出来的，无需再次进行检索操作。这意味着用户代理应该能够在不从服务器获取更多数据的情况下，解析已接收资源上的 URI 片段。

本规范施加了进一步的约束，即检索到的片段的媒体类型应与主资源的媒体类型相同。除其他事项外，这意味着指向较长视频中的单个视频帧的 URI 片段会产生单帧视频，而不是静态图像。要提取静态图像，需要创建一个 URI 查询方案——这在本文档中虽未设想，但很容易设计。

本规范中有不同类型的媒体片段寻址。正如《媒体片段用例与要求》文档（“媒体容器/资源的适应性条件”部分）中所述：并非所有容器格式和编解码器都“适合”支持不同类型的片段 URI。“适应性”是指可以从主资源中提取媒体片段，而无需修改语法元素或对比特流进行转码。

因此，符合“适应性”的资源可以用 URI 片段寻址。“条件适应”的资源可以用 URI 片段寻址，但需要额外的检索操作来检索修改后的语法元素，同时保持编解码器数据不变。“不适应”的资源需要转码。此类转码后的媒体片段无法通过 URI 片段寻址，只能通过 URI 查询寻址。

因此，当使用 URI 机制寻址媒体片段时，作者必须知道该媒体片段是否可以在不进行任何转码活动的情况下从（主）资源本身产生，或者它是否需要转码。在后一种情况下，唯一的选择是使用 URI 查询，并使用支持转码和交付（主）派生资源的服务器来满足查询需求。

3.2 在用户代理内解析 URI 片段

用户代理可能自行解析并控制媒体片段 URI 的呈现。最简单的情况是用户代理已经下载了整个资源，并可以从其本地缓存的副本中执行提取。对于某些媒体类型，也可能在网络上执行提取而无需任何特殊的协议协助。对于时间片段，这要求用户代理能够使用现有的协议机制在媒体资源上进行搜索。

用于寻址媒体片段的 URI 片段示例如 http://www.example.org/video.ogv#t=60,100。在这种情况下，用户代理知道主资源是 http://www.example.org/video.ogv，并且它仅被要求显示与片段 #t=60,100（即 60-100 秒）相关的主资源部分。因此，保持了主资源与媒体片段之间的关系。

在传统的 URI 片段检索中，用户代理从服务器请求完整的主资源，然后在本地应用分段。在媒体片段的情况下，这将导致对完整媒体资源的检索操作，用户代理随后会在其上本地执行片段提取——这对于如此庞大的资源来说通常是不可行的。因此，媒体资源并不总是通过单次 HTTP 请求检索。它们可能作为对原始资源 URI 的一系列字节范围请求检索，或者作为对代表媒体小部分的不同 URI 的一系列请求来检索。采取此类机制的原因包括带宽节约（客户端选择在播放期间分散请求以最大化其他活动的可用带宽）和带宽适应（客户端根据当前的带宽可用性在具有不同比特率的各种表示之间进行选择）。

知道如何将媒体片段映射到字节范围的用户代理将能够自行满足 URI 片段请求（如上面的示例）。这通常适用于知道如何通过网络搜索媒体片段的用户代理。例如，处理包含其可搜索结构索引的媒体文件的用户代理，可以从索引中将媒体片段地址解析为字节范围。例如，可搜索的 QuickTime 文件就是这种情况。另一个例子是用户代理知道如何通过一系列字节范围请求在媒体文件上搜索，并最终接收到正确的媒体片段。例如，Firefox 3.5 以上版本中的 Ogg 文件就是这种情况。

同样，知道如何将媒体片段映射到一系列 URI 的用户代理也可以自行满足 URI 片段请求。这通常适用于执行自适应流传输的用户代理。例如，处理包含一系列 URI（每个 URI 是持续几秒钟的媒体文件）的媒体资源的用户代理，可以将媒体片段地址解析为这些 URI 的子序列。QuickTime 自适应比特率流或 IIS 平滑流就是这种情况。

如果此类用户代理原生支持本文档中指定的媒体片段语法，则认为它符合本规范的片段部分及特定维度要求。

对于原生支持媒体片段语法但必须使用其自身搜索方法的用户代理，补充规范提供了一种优化，可以使字节偏移搜索更有效。它需要一个符合规范的服务器，用户代理将与其遵循单独的《媒体片段 1.0 URI（高级）》文档中定义的协议，在该协议中，用户代理要求服务器自行执行媒体片段地址的字节范围映射，并回传适当的字节范围。此方法不能通过 URI 完成，必须通过添加协议头来完成。与符合规范的服务器交互并遵循此协议的用户代理将直接接收适当的字节范围，而无需在网络上进行昂贵的搜索。

3.3 解析 URI 查询

所描述的 URI 片段寻址方法仅适用于字节完全相同的媒体资源片段，因为我们假设媒体片段与每个基础设施元素都能处理的字节之间存在简单的映射。在无法保持字节相同且必须对资源进行某种转码的情况下，用户代理无法自行解析分段，因此需要服务器交互。在这种情况下，必须使用 URI 查询，因为它们会导致服务器交互并可以交付转码后的资源。

URI 查询的另一个用途是当用户代理实际上想要接收一个全新的资源，而不是仅仅从现有的（主）资源中获取一个字节范围时。例如，这适用于媒体片段资源的播放列表。即使可以通过 URI 片段解析媒体片段，URI 查询也可能更可取，因为它不携带原始主资源的负担——其文件头可能更小，其持续时间可能更短，并且它不会自动允许访问原始主资源的其余部分。

当使用 URI 查询时，检索操作还必须确保创建一个完全有效的新资源。例如，对于 Ogg 格式，这意味着重建 Ogg 头以准确描述新资源（例如非零开始时间或不同的编码参数）。此类资源将被 Web 代理缓存为与原始主资源不同的资源。

包含媒体片段规范的 URI 查询示例如 http://www.example.org/video.ogv?t=60,100。这将产生一个持续时间为 40 秒的视频（假设原始视频长度超过 100 秒）。请注意，此资源与原始主资源本身没有必然关系。当用户代理将此类 URI 与例如 HTML5 视频元素一起使用时，浏览器对原始资源一无所知，只能将此视频显示为从 0 秒开始的 40 秒长视频。原始资源的上下文丢失了。

用户代理可能希望显示资源的原始开始时间作为视频的开始时间，以便与 URI 中的信息保持一致。可以通过以下两种方式之一实现此目的：要么视频文件本身知道它是来自不同文件的提取，并从某个偏移量开始；要么用户代理通过检索操作得知检索到的资源与哪个原始主资源相关，并可以通过另一个检索操作找到关于它的信息。

具有此类所需自我知识的媒体资源的一个例子是 Ogg 文件。具有骨架（skeleton）轨道并从主资源正确创建的 Ogg 文件将知道其开始时间不是 0 秒，而是上面的示例中的 60 秒。浏览器可以直接从接收到的比特流中解析出此信息，并且如果愿意，可以在视频控件中显示从 60 秒开始到 100 秒结束的时间轴。另一个选择是浏览器解析 URI，并了解媒体资源如何遵循标准片段规范。然后浏览器可以解释查询参数并提取正确的开始和结束时间以及原始主资源。它然后也可以在视频控件中显示从 60 秒开始到 100 秒结束的时间轴。此外，它还可以允许右键菜单在需要时点击跳转回原始资源。

视频控件可能既不从 0 秒开始也不从 60 秒开始的一个用例是 mash-up（混搭）视频，它是通过媒体片段 URI 列表创建的。在这样的播放列表中，用户代理可能更喜欢显示贯穿所有媒体片段的单一连续时间轴，而不是为每个片段显示各自的时间轴集合。因此，60 秒到 100 秒的片段可能被映射到 3 分 20 秒到 4 分钟的时间间隔。

执行媒体片段检索的 URI 查询不需要新的协议头。一些提高信息交换的可选协议头将在本文档后面推荐。

3.4 结合 URI 片段与 URI 查询

将媒体片段的 URI 查询与 URI 片段结合使用，可以在新创建的资源之上生成 URI 片段解析。由于具有查询部分的 URI 创建了一个新资源，我们必须在新资源上执行片段偏移。这完全符合 URI 标准 RFC 3986 的规定。

例如，http://www.example.org/video.ogv?t=60,100#t=20 将导致 20 秒的片段偏移量应用于从 60 开始到 100 结束的新资源。因此，对此的回复是一个 40 秒长的资源，其播放将从 20 秒的偏移量开始。

4 媒体片段语法

本节描述媒体片段 (MF) 标识符的语法表示及其解释方式。定义媒体片段语法的指导原则如下：

a. 查询和片段的 MF 语法应该是相同的
b. MF 语法应该是明确的
c. MF 语法应允许对需要该功能的维度使用任何 UTF-8 字符
d. MF 语法应遵守适用的正式标准
e. MF 语法应遵守查询和片段的实际用法
f. MF 语法应尽可能简洁

4.1 基本结构

键值对列表编码在 URI 的查询或片段组件中。名称和值组件由等号 (=) 分隔，而多个键值对由与号 (&) 分隔。

name = fragment - "&" - "="
value = fragment - "&"
namevalue = name [ "=" value ]
namevalues = namevalue *( "&" namevalue )

名称和值可以是任意 Unicode 字符串，以 UTF-8 编码，并按照 RFC 3986 进行百分号编码。以下是一些在片段组件中带有键值对的 URI 示例，以演示基本结构：

http://www.example.com/example.ogv#t=10,20
http://www.example.com/example.ogv#track=audio&t=10,20
http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202

虽然任意键值对可以以这种方式编码，但本规范定义了一组固定的维度。维度关键字名称编码在名称组件中，而维度特定的语法编码在值组件中。

第 5.1.1 处理键值组件 节更详细地定义了如何处理键值对语法，从而得到键值 Unicode 字符串对列表。4.2 片段维度 中的语法定义适用于这些 Unicode 字符串。

4.2 片段维度

媒体片段支持沿两个维度（基础版本中）对媒体进行寻址：

时间 (temporal): 此维度表示原始媒体中的特定时间范围，例如“从第 10 秒开始，持续到第 20 秒”；
spatial: 此维度表示原始媒体中的特定像素范围，例如“大小为 (100,100) 的矩形，其左上角坐标为 (10,10)”；

媒体片段还支持沿另外两个维度（在《媒体片段 1.0 URI（高级）》中定义的版本中）对媒体进行寻址：

track: 此维度表示原始媒体中的一个或多个轨道，例如“英语音轨和视频轨道”；
id: 此维度表示原始媒体中命名的特定时间片段，例如“第 2 章”，可以视为指定时间片段的一种便捷方式。

所有维度在逻辑上是独立的，并且可以组合使用。结果与维度的顺序无关。然而，id 维度是时间维度的快捷方式，组合使用这两个维度时必须按照 6.2.1 通用 URI 级别的错误 节中所述进行处理。track 维度是指一组并行媒体流中的一个（例如“视频的英语音轨”），而不是指源媒体的（可能是自包含的）部分（例如“CD 的音频轨道 2”）。

4.2.1 时间维度

时间裁剪由名称 t 表示，并指定为具有开始时间和结束时间的间隔（在视频编辑术语中称为入点和出点）。一个或两个参数都可以省略，开始时间默认为 0 秒，结束时间默认为源媒体的持续时间。该间隔是半开区间：开始时间被视为间隔的一部分，而结束时间被视为不属于该间隔的第一个时间点。如果仅给出一个数字，则该数字对应开始时间，除非它前面有一个逗号，在这种情况下将表示结束时间。

示例

t=10,20   # => results in the time interval [10,20)
t=,20     # => results in the time interval [0,20)
t=10      # => results in the time interval [10,end)

时间裁剪被指定为正常播放时间 (npt) RFC 2326。在《媒体片段 1.0 URI（高级）》文档中描述的高级版本中，它也可以指定为 SMPTE 时间码 SMPTE 或现实世界时钟时间 (clock) RFC 2326。开始和结束时间始终以相同的格式指定。该格式由名称指定，后跟冒号 (:)，npt: 为默认值。在本版本的媒体片段规范中，没有添加时间格式说明符的可扩展机制。

timeprefix    = %x74                                        ; "t"
timeparam     = npttimedef

正常播放时间可以指定为秒（带有可选的小数部分以表示毫秒），或以冒号分隔的时、分、秒（同样带有可选的小数部分）。分和秒必须指定为正好两位数字，小时和分数秒可以是任意位数的数字。NPT 的时、分、秒规范仅为方便起见，它并不代表帧精度。“npt:”标识符的指定是可选的，因为 NPT 是默认的时间方案。本规范建立在 RTSP 的 NPT 规范 RFC 2326 之上。

npt-sec       =  1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326,
npt-mmss      =  npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

deftimeformat = %x6E.70.74                                  ; "npt"
npttime       = npt-sec / npt-mmss / npt-hhmmss

示例

t=npt:10,20         # => results in the time interval [10,20)
t=npt:,121.5        # => results in the time interval [0,121.5)
t=0:02:00,121.5     # => results in the time interval [120,121.5)
t=npt:120,0:02:01.5 # => also results in the time interval [120,121.5)

4.2.2 空间维度

空间裁剪从视觉媒体流中选择一个像素区域。对于本版本的媒体片段规范，仅支持矩形选择。矩形可以指定为像素坐标或百分比。

像素坐标在考虑了资源的尺寸、纵横比、显示区域 (clean aperture)、分辨率等因素后进行解释，正如资源所使用的格式所定义的那样。如果变形格式没有定义如何将纵横比应用于视频数据的尺寸以获得“正确”尺寸，则用户代理必须通过增加一个维度并保持另一个维度不变来应用该比例。

矩形选择由名称 xywh 表示。其值是一个可选格式 pixel: 或 percent:（默认为 pixel）以及 4 个逗号分隔的整数。这些整数分别表示 x、y、宽度和高度，其中 x=0, y=0 为图像的左上角。如果使用百分比，x 和宽度将被解释为原始媒体宽度的百分比，y 和高度将被解释为原始媒体高度的百分比。

xywhprefix    = %x78.79.77.68                               ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                            ; "pixel"
              / %x70.65.72.63.65.6E.74                      ; "percent"

示例

xywh=160,120,320,240        # => results in a 320x240 box at x=160 and y=120
xywh=pixel:160,120,320,240  # => results in a 320x240 box at x=160 and y=120
xywh=percent:25,25,50,50    # => results in a 50%x50% box at x=25% and y=25%

如果裁剪区域基于像素，并且图像是多分辨率的（例如 ICO 文件），则该片段必须被忽略，以便 url 表示整个图像。更一般地，不建议对没有单一明确定义像素分辨率（宽度和高度）的图像进行像素裁剪。

5 媒体片段处理

本节通过 3 URI 片段与 URI 查询 节中解释的情况，定义了 HTTP 协议上的不同交换场景。

4 媒体片段语法 节中定义的正式文法描述了媒体片段生产者应该输出的内容。它没有考虑根据 RFC 3986 有效的可能的百分号编码，且该文法并不是媒体片段应该如何解析的规范。因此，5.1 处理媒体片段 URI 节定义了如何解析媒体片段 URI。

5.1 处理媒体片段 URI

本节定义了如何解析 4 媒体片段语法 节中定义的媒体片段 URI，并附带了一些需要注意的注意事项。实施者可以自由使用任何等效技术。

5.1.1 处理键值组件

本节定义了如何将八位字节字符串（来自 URI 的查询或片段组件）转换为键值 Unicode 字符串对列表。

根据 namevalues 语法解析八位字节字符串，产生一个键值对列表，其中名称和值都是八位字节字符串。根据 RFC 3986，在解码百分号编码的八位字节之前，必须解析并分离名称和值组件。
对于每个键值对：
1. 按照 RFC 3986 的定义解码名称和值中的百分号编码八位字节。如果名称或值不是有效的百分号编码字符串，则从列表中删除该键值对。
2. 通过将其解释为 UTF-8 将名称和值转换为 Unicode 字符串。如果名称或值不是有效的 UTF-8 字符串，则从列表中删除该键值对。

请注意，对于任何输入，输出都是明确定义的。

示例

输入：	输出：	注
"t=1"	[("t", "1")]	简单情况
"t=1&t=2"	[("t", "1"), ("t", "2")]	重复名称
"a=b=c"	[("a", "b=c")]	值中的 "="
"a&b=c"	[("a", ""), ("b", "c")]	缺失值
"%74=%6ept%3A%310"	[("t", "npt:10")]	不必要的百分号编码
"id=%xy&t=1"	[("t", "1")]	无效的百分号编码
"id=%E4r&t=1"	[("t", "1")]	无效的 UTF-8

虽然本节定义的处理过程被设计为与许多 HTTP 服务器环境中的 URI 查询组件解析基本兼容，但实施者应注意以下不兼容的差异：

"&" 是键值对的唯一主要分隔符，但某些服务器端语言也将 ";" 视为分隔符。
应忽略具有无效百分号编码的键值对，但某些服务器端语言会静默屏蔽此类错误。
"+" 字符不应被特殊处理，但某些服务器端语言将其替换为空格 (" ") 字符。
必须保留相同名称的多次出现，但某些服务器端语言仅保留最后一次出现。

5.1.2 处理键值列表

本节定义了如何将键值 Unicode 字符串对列表转换为媒体片段维度。

给定 4.2 片段维度 节中定义的维度，每个维度都有一对分别对应名称和值组件的生成规则：

Keyword（关键字）	维度
t	4.2.1 时间维度
xywh	4.2.2 空间维度
track	媒体片段 1.0 URI（高级）
id	媒体片段 1.0 URI（高级）

最初，所有维度都是未定义的。
对于每个键值对：
1. 如果名称与上表中的关键字匹配，则按相应部分解释值。
2. 否则，该键值对不代表媒体片段维度。验证器应发出警告。用户代理必须忽略该键值对。

注意：因为键值对是按顺序处理的，所以使用的任何维度的最后一次有效出现才是被采用的。

5.2 HTTP 中 URI 片段与查询的解析协议

解析和交付指定为 URI 片段或 URI 查询的媒体片段的协议步骤，通过单独的《媒体片段 1.0 URI（高级）》文档中的各种方案进行描述。

6 媒体片段语义

在本节中，我们将讨论用户代理应如何解释媒体片段 URI。给出了有效情况和错误情况。在错误情况下，我们区分了可以仅基于媒体片段 URI 检测到的错误，以及只有当用户代理拥有媒体资源信息（例如媒体资源的持续时间）时才能检测到的错误。

6.1 有效的媒体片段 URI

对于每个维度，都给出了许多有效的媒体片段及其语义。

6.1.1 有效的时间维度

为了描述时间媒体片段的不同情况，我们做如下定义：

s：媒体的起点，始终为零（以 NPT 为单位）；
e：媒体的终点（即持续时间），且 e > 0；
a：一个正整数，a >= 0；
b：一个正整数，b >= 0。

此外，正如 4.2.1 时间维度 节中所述，时间间隔是半开区间（即开始时间被视为间隔的一部分，而结束时间被视为不属于该间隔的第一个时间点）。因此，如果我们下文陈述“媒体从 x 播放到 y”，这意味着对应于 y 的帧将不会被播放。

对于 a <= b 时的 t=a,b，以下时间片段是有效的：

t=a (a < e)：媒体从 a 播放到 e。
t=,b (b <= e)：媒体从 s 播放到 b。
t=,b (e < b)：媒体从 s 播放到 e。
t=a,b (a = 0, b = e)：播放整个媒体资源。
t=a,b (a < b, a < e, b <= e)：媒体从 a 播放到 b（正常情况）。
t=a,b (a < b, a < e, e < b)：媒体从 a 播放到 e。
%74=10,20 将百分号编码解析为 t=10,20。
t=%31%30 将百分号编码解析为 t=10。
t=10%2C20 将百分号编码解析为 t=10,20。
t=%6ept:10 将百分号编码解析为 t=npt:10。
t=npt%3a10 将百分号编码解析为 t=npt:10。

6.3.2 时间维度的错误

为了描述时间媒体片段的不同情况，我们使用 6.1.1 有效的时间维度 中的定义。只有当用户代理知道持续时间（对于不存在的时间片段）和源媒体的帧速率时，才能检测到以下时间片段的无效性。

t=a,b (a > 0, a < b, a >= e, b > e)：一个不存在的时间片段，用户代理搜索到媒体的末尾 e。
t=a (a >= e)：一个不存在的时间片段，用户代理搜索到媒体的末尾 e。

6.3.3 空间维度的错误

为了描述空间媒体片段的不同情况，我们使用 6.1.2 有效的空间维度 中的定义。只有当用户代理知道源媒体的分辨率时，才能检测到以下空间片段的无效性。

xywh=a,b,c,d (a >= w 和/或 b >= h)：矩形的左上角坐标 (a,b) 位于源媒体之外，因此无效。用户代理应该忽略此空间片段。

7 实施者注意事项（非规范性）

本节包含给实施者的注意事项。这里的一些信息已经在文档的其他地方正式说明，此处的参考主要是作为提醒。其他项目确实超出了本规范的范围，但此处的注释反映了作者认为的最佳实践。

各小节并非互斥。因此，作为媒体片段客户端的 Web 浏览器实施者应该阅读 7.1 浏览器渲染媒体片段、7.2 客户端显示媒体片段 和 7.3 所有媒体片段客户端 节。

7.1 浏览器渲染媒体片段

4.2.2 空间维度 节中定义的像素坐标旨在与 HTML5 中定义的内在宽度和高度一致。对于空间 URI 片段，下一节描述了两个不同的用例：高亮显示和裁剪。然而，HTML 渲染客户端预计将裁剪作为默认的渲染机制实现。

7.2 客户端显示媒体片段

在处理媒体片段时，存在一个问题：是在上下文中还是在没有上下文的情况下显示媒体片段。通常，建议在上下文中显示 URI 片段，因为它属于较大的资源。另一方面，URI 查询产生一个新资源，因此建议将其作为没有上下文的完整资源显示。接下来的段落讨论了每个轴上媒体片段的上下文，并提供了有关其上下文中 URI 片段可视化的建议。

对于时间 URI 片段，建议从等于片段开始的时间偏移量开始播放，并在片段结束时暂停。当再次点击“播放”按钮时，资源将继续加载并播放到片段结束之后。当搜索到特定的偏移量时，资源将从这些搜索点开始加载和播放。还建议引入一个“重新加载”按钮来仅重播 URI 片段。通过这种方式，URI 片段基本上代表了“聚焦注意力”。此外，时间 URI 片段可以在传输栏上高亮显示。

对于空间 URI 片段，我们预见到了两个不同的用例：在上下文中高亮显示空间区域，以及裁剪到该区域。在第一种情况下，空间区域可以通过边界框来指示，或者背景（即不包含在该区域内的所有像素）可以被模糊或变暗。在第二种情况下，仅显示该区域作为裁剪区域。文档作者如何指定预期的用例超出了本规范的范围，我们建议规范的实施者通过属性或样式表元素等方式为此提供手段。

最后，对于轨道 URI 片段，建议仅播放由轨道 URI 片段标识的轨道。如果没有指定轨道，则应播放默认轨道。可以使用下拉框或按钮选择不同的轨道，选定的轨道在播放期间会高亮显示。用户代理如何检索有关特定资源可用轨道的信息超出了本规范的范围。

7.3 所有媒体片段客户端

解析顺序： 当在同一个 URI 片段请求中组合多个维度时，实施方案预计首先在容器级别执行时间、id 和轨道选择，然后在编解码器级别执行空间裁剪。

媒体片段文法： 请注意，媒体片段 URI 的文法仅指定了本规范所标准化功能的文法。如果字符串解析不正确，并不一定意味着 URI 是错误的，仅意味着它不是本规范定义的媒体片段 URI。它可能对某些扩展形式或完全不同的片段规范方法是正确的。因此，对媒体片段说明符中的语法错误进行自动恢复是不明智的。

外部裁剪： 对于在另一种裁剪方法上下文中使用的媒体片段 URI，没有强制性的解析方法。从形式上讲，由嵌入媒体片段 URI 的上下文来决定外部裁剪方法是覆盖媒体片段 URI 还是级联（即在结果资源上定义）。在没有充分理由采取其他做法的情况下，我们建议采用级联。一个例子是如下的 SMIL 元素：<smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/>。这应该从第 105 秒开始播放原始媒体资源，并于 115 秒停止。

7.4 媒体片段服务器

媒体类型： 通过 URI 片段请求检索到的资源的媒体类型与主资源的媒体类型相同。因此，从视频中检索单个帧将导致一个长达一帧的视频。从视频资源中检索所有音轨将导致视频，而不是音频资源。使用 URI 查询方法时，媒体类型可能会发生变化。例如，可以作为 JPEG 检索视频在特定时间偏移处的空间片段，并在请求中使用特定的 HTTP “Accept” 标头。

同步： 当检索该资源的媒体片段时，需要保持媒体资源不同轨道之间的同步。这对于 URI 片段和 URI 查询检索都是如此。使用 URI 查询时，如果需要转码，则同步中不可察觉的变化是可以接受的。

嵌入式时间码： 当媒体资源包含嵌入式时间码时，在进行媒体片段检索时需要保持这些时间码，特别是在使用 URI 片段方法时。当使用 URI 查询并进行转码时，如果嵌入式时间码有用且需要，则应予以保留。

合理的裁剪： 时间裁剪需要尽可能接近媒体片段指定的内容，并且不得省略任何请求的数据。“合理接近”是指完全包含请求片段的、最接近该请求片段的压缩实体。对于时间片段，这意味着如果请求了 http://www.example.org/video.ogv#t=60,100，但因为这是音频和视频包边界所在的位置，最接近的可解码范围是 t=58,102，那么将返回此范围。用户代理随后有能力仅显示请求的子部分，也应该只这样做。对于某些容器格式来说，这不是问题，因为容器格式允许指定逻辑开始和结束。

合理的字节范围： 如果单个时间范围请求会导致不成比例的大量字节范围，则服务器最好返回一个重定向，指向媒体片段的查询形式。如果底层媒体文件以奇怪的方式组织，则可能会发生这种情况。

7.5 媒体片段 Web 应用

媒体片段 URI 仅定义在媒体资源上。然而，许多创建带有视频或音频的 Web 页面的 Web 开发人员希望向其用户提供直接跳转到媒体片段的能力——特别是通过为 Web 页面提供 URI 方案跳转到视频中的时间偏移量。实现这一目标且无需额外服务器交互的方法是，在 Web 页面上使用由 JavaScript 解析的 URI 片段方案，并将媒体片段传达给音频或视频资源加载器。在 HTML5 中，需要用适当的 URI 片段更改相应 <audio> 或 <video> 元素的 @src 属性，然后调用 load() 函数，使元素以该 URI（重新）加载资源。

此类 Web 页面的 URI 方案可能包含本规范定义的与号分隔的键值对，例如 http://example.com/videopage.html#t=60,100&xywh=12,12,42,42。但是，Web 开发人员必须创建一个能够与 Web 页面其余片段寻址功能协同工作的方案。例如，如果 Web 页面利用页面上元素的 ID 属性进行页面滚动，那么向 Web 页面寻址添加媒体片段 URI 寻址将导致失败。例如，如果 http://example.com/videopage.html#first 有效并滚动到该 Web 页面上的一个偏移量，那么 http://example.com/videopage.html#first&t=60,100 将不会执行相同的滚动。Web 开发人员随后将需要解析片段参数，并使用 scrollTo() 或 scrollTop() 函数手动用 JavaScript 实现滚动功能。

A 参考文献

[RFC 2119]: S. Bradner. 用于 RFC 以指示要求级别的关键词。IETF RFC 2119，1997 年 3 月。网址：http://www.ietf.org/rfc/rfc2119.txt。
[RFC 2326]: 实时流协议 (RTSP)。IETF RFC 2326，1998 年 4 月。网址：http://www.ietf.org/rfc/rfc2326.txt。
[RFC 2327]: 会话描述协议 (SDP)。IETF RFC 2327，1998 年 4 月。网址：http://www.ietf.org/rfc/rfc2327.txt。
[RFC 2616]: 超文本传输协议 -- HTTP/1.1。IETF RFC 2616，1999 年 6 月。网址：http://www.ietf.org/rfc/rfc2616.txt。
[RFC 3339]: G. Klyne 和 C. Newman. 互联网上的日期和时间：时间戳。IETF RFC 3339，2002 年 7 月。网址：http://www.ietf.org/rfc/rfc3339.txt。
[RFC 3533]: Ogg 封装格式版本 0。IETF RFC 3533，2003 年 5 月。网址：http://www.ietf.org/rfc/rfc3533.txt。
[RFC 3986]: T. Berners-Lee, R. Fielding 和 L. Masinter. 统一资源标识符 (URI)：通用语法。IETF RFC 3986，2005 年 1 月。网址：http://www.ietf.org/rfc/rfc3986.txt。
[RFC 5234]: D. Crocker. 语法规范的增广 BNF：ABNF。IETF RFC 5234，2008 年 1 月。网址：http://tools.ietf.org/html/rfc5234。
[RFC 4288]: N. Freed 和 J. Klensin. 媒体类型规范和注册程序。IETF RFC 4288，2005 年 12 月。网址：http://www.ietf.org/rfc/rfc4288.txt。
[RFC 5147]: E. Wilde 和 M. Duerst. text/plain 媒体类型的 URI 片段标识符。IETF RFC 5147，2008 年 4 月。网址：http://tools.ietf.org/html/rfc5147。
[HTML 4.0]: D. Ragett, A. Le Hors 和 I. Jacobs. HTML 片段标识符。W3C 推荐标准，1999 年 12 月。网址：https://w3org.cn/TR/REC-html40/intro/intro.html#fragment-uri。
[HTML 5]: Ian Hickson. HTML5。W3C 工作草案，2011 年 5 月。网址：https://w3org.cn/TR/2011/WD-html5-20110525/。
[SVG 1.1]: J. Ferraiolo.链接到 SVG 内容：IRI 片段和 SVG 视图。W3C 推荐标准，2011 年 8 月。网址：https://w3org.cn/TR/2011/REC-SVG11-20110816/linking.html#LinksIntoSVG。
[SMIL]: Sjoerd Mullender. 同步多媒体集成语言 (SMIL 3.0)。W3C 推荐标准，2008 年 12 月。网址：https://w3org.cn/TR/2008/REC-SMIL3-20081201/。
[xpointer]: P. Grosso, E. Maler, J. Marsh 和 N. Walsh. XPointer 框架。W3C 推荐标准，2003 年 3 月。网址：https://w3org.cn/TR/xptr-framework/。
[MPEG-7]: Information Technology - Multimedia Content Description Interface (MPEG-7). 标准号 ISO/IEC 15938:2001，国际标准化组织（ISO），2001年。
[temporal URI]: S. Pfeiffer, C. Parker 和 A. Pang. 在基于时间的 Web 资源的 URI 查询和片段中指定时间间隔。Internet 草案，2005 年 3 月。网址：http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html。
[CMML]: 连续媒体标记语言 (CMML)，版本 2.1。Internet 草案，2006 年 3 月 http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt。
[ROE]: 富开放多轨道媒体展示 (ROE)。Xiph Wiki。网址：http://wiki.xiph.org/index.php/ROE。
[Skeleton]: Ogg 骨架。Xiph Wiki。网址：http://wiki.xiph.org/OggSkeleton。
[MPEG-21]: 信息技术 - 多媒体框架 (MPEG-21)。标准号 ISO/IEC 21000:2002，国际标准化组织 (ISO)，2002 年。网址：http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip。
[SMPTE]: SMPTE RP 136 用于 24、25 或 30 帧/秒电影系统的帧和控制码
[ISO 基础媒体文件格式]: 信息技术 - 音视频对象编码 - 第 12 部分：ISO 基础媒体文件格式。网址：http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip
[媒体片段用例与要求]: 媒体片段用例与要求。W3C 工作草案，2009 年 12 月。网址：https://w3org.cn/TR/2009/WD-media-frags-reqs-20091217
[媒体片段 1.0 URI（高级）]: 媒体片段 1.0 URI（高级）。W3C 工作草案，2011 年 12 月。网址：https://w3org.cn/TR/2011/WD-media-frags-recipes-20111201/
[UTF-8]: UTF-8，一种 ISO 10646 的转换格式。网址：http://tools.ietf.org/html/rfc3629
[ECMA-262 第 5 版]: ECMA-262 第 5 版。网址：http://www.ecma-international.org/publications/standards/Ecma-262.htm
[媒体标注]: 媒体资源 API 1.0。W3C 候选推荐标准，2011 年 11 月。网址：https://w3org.cn/TR/2011/CR-mediaont-api-1.0-20111122/
[Web 链接]: Web 链接。Internet 草案，2010 年 5 月。网址：http://tools.ietf.org/html/draft-nottingham-http-link-header-10

B 收集的 URI ABNF 语法（非规范性）

unichar       = <any Unicode code point>
unistring     = *unichar

; defined in RFC 5234
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in RFC 3986
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )

; defined in RFC 2326
npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326
npt-mmss      = npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

; defined in RFC 3339
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

; Mediafragment definitions
segment       = mediasegment / *( pchar / "/" / "?" )     ; augmented fragment
                                                          ; definition taken from
                                                          ; RFC 3986

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Common Prefixes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;

deftimeformat    = %x6E.70.74                                      ; "npt"
pfxdeftimeformat = %x74.3A.6E.70.74                                ; "t:npt"
smpteformat      = %x73.6D.70.74.65                                ; "smpte"
                  / %x73.6D.70.74.65.2D.32.35                      ; "smpte-25"
                  / %x73.6D.70.74.65.2D.33.30                      ; "smpte-30"
                  / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70       ; "smpte-30-drop"
pfxsmpteformat   = %x74.3A.73.6D.70.74.65                          ; "t:smpte"
                  / %x74.3A.73.6D.70.74.65.2D.32.35                ; "t:smpte-25"
                  / %x74.3A.73.6D.70.74.65.2D.33.30                ; "t:smpte-30"
                  / %x74.3A.73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "t:smpte-30-drop"
clockformat      = %x63.6C.6F.63.6B                                ; "clock"
pfxclockformat   = %x74.3A.63.6C.6F.63.6B                          ; "clock"

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment      = ( timesegment / spacesegment / tracksegment / idsegment )
               *( "&" ( timesegment / spacesegment / tracksegment  / idsegment )

timesegment      = timeprefix "=" timeparam
timeprefix       = %x74                                      ; "t"
timeparam        = npttimedef / smptetimedef / clocktimedef
npttimedef       = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

npttime       = npt-sec / npt-mmss / npt-hhmmss

smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]

clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clocktime     = (datetime / walltime / date)
datetime      = date-time                                 ; inclusion of RFC 3339

spacesegment  = xywhprefix   "=" xywhparam
xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"

tracksegment  = trackprefix "=" trackparam
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring

idsegment   = idprefix "=" idparam
idprefix    = %x69.64					                  ; "id"
idparam     = unistring

C 致谢（非规范性）

本文档是 W3C 媒体片段工作组的工作成果。工作组成员（撰写本文时，按字母顺序排列）为：Eric Carlson (Apple, Inc.), Chris Double (Mozilla Foundation), Michael Hausenblas (DERI Galway at the National University of Ireland, Galway, Ireland), Jack Jansen (CWI), Philip Jägenstedt (Opera Software), Yves Lafon (W3C), Erik Mannens (IBBT), Thierry Michel (W3C/ERCIM), Guillaume (Jean-Louis) Olivrin (Meraka Institute), Soohong Daniel Park (Samsung Electronics Co., Ltd.), Conrad Parker (W3C 特邀专家), Silvia Pfeiffer (W3C 特邀专家), Nobuhisa Shiraishi (NEC Corporation), David Singer (Apple, Inc.), Thomas Steiner (Google, Inc.), Raphaël Troncy (EURECOM), Davy Van Deursen (IBBT),

也非常感谢为 public-media-fragment@w3.org 上的讨论做出贡献的人们。特别是：Olivier Aubert, Werner Bailer, Tobias Bürger, Pierre-Antoine Champin, Cyril Concolato, Fantasai, Franck Denoual, Martin J. Dürst, Jean Pierre Evain, Ken Harrenstien, Kilroy Hughes, Ryo Kawaguchi, Wim Van Lancker, Véronique Malaisé, Henrik Nordstrom, Christoph Päper, Yannick Prié, Yves Raimond, Julian Reschke, Sam Sneddon, Felix Sasaki, Jakub Sendor, Philip Taylor, Christian Timmerer, Jorrit Vermeiren, Jeroen Wijering, Munjo Yu 和 Boris Zbarsky。