通过 DASH 传送直播 YouTube 内容

本文档提供了使用 DASH 投放格式从编码器中流式传输 YouTube 上的实时数据的准则。它旨在帮助编码器供应商为其产品添加 DASH 传送支持。

了解 DASH

下表列出了一些关键的 DASH 功能和属性：

  • 基于开放标准。
  • 基于 HTTP。因此，DASH 兼容互联网基础架构，可以穿越防火墙。
  • 支持高传输比特率。DASH 支持多个同时进行的 HTTP 会话和无顺序分段传送，与依赖单个 TCP 连接的协议相比，具有更高的弹性。
  • 通过 HTTPS 安全递送。
  • 通过 HTTP 和 HTTPS 进行无损传送。
  • 与编解码器无关。
  • 支持包含 H264 和 AAC 的 MP4 以及包含 VP8/VP9 和 Vorbis/Opus 的 WebM。

规范

要求

以下小节介绍了使用 DASH 向 YouTube 传送直播的要求。

Timing

YouTube DASH 端点充当被动 HTTP 服务器，它会记录编码器发送的 PUT 方法调用。

  • DASH 端点支持并发 TCP 连接。您可以根据 HTTP/1.1 重复使用连接。
  • MPD 和初始化片段应在第一个媒体片段后的 3 秒内放置。（建议您在 MPD 中包含初始化细分。）
  • 每个片段或 MPD 都必须使用单独的 PUT 请求；不支持多次上传多个片段。
  • 媒体时段的 PUT 操作可能会重叠，以便提高上传带宽。
  • 可在大约 3 秒内不连续地提供细分受众群。
  • MPD 和初始化细分受众群应至少每 60 秒更新一次，并包含更新后的 availabilityStartTime 和 startNumber。（如上所述，初始化 MP 可包含在 MPD 中。在这种情况下，一个 PUT 请求可以更新这两个细分受众群。）

网址结构

编码器必须将字符串附加到 YouTube 端点基准网址，以形成 PUT 网址。您需要使用 YouTube Live Streaming API 创建 DASH 提取端点。

编码器随后可以通过 YouTube Live Streaming API 以编程方式获取端点的基准网址。如果您想手动向编码器提供相应网址，基准网址也会在 YouTube 直播活动界面中显示。

附加到基准网址的字符串可包含以下一组 ASCII 字符：

  • 小写字母：a-z
  • 大写字母：A-Z
  • 数字：0-9
  • 特殊字符：_（下划线）、-（连字符）、.（句号）

MPD 网址

除了上述要求之外，MPD 网址必须以 .mpd 结尾，以便 YouTube 服务器能够轻松识别 MPD。其他细分受众群网址不得以 .mpd 结尾。

初始化和媒体段网址

如果数据位于 ISO BMFF 容器中，则初始化细分网址和所有媒体段网址必须以 .mp4 结尾；如果数据位于 WebM 容器中，则必须以 .webm 结尾。

MPD 内容

MPD 必须完整且符合 DASH 标准。且必须仅包含以下某个元素。此列表标识了 YouTube 特别要求的元素，DASH 标准可能会标识其他必需元素。元素使用 XPath 语法表示，并与 DASH 标准一致。

  • /mpd:MPD/attribute::type
  • /mpd:MPD/mpd:Period
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

请注意元素值的以下要求：

  • <MPD> 元素的 minimumUpdatePeriod 属性必须设置为等于或小于 60 秒 (PT60S) 的值。
  • <SegmentTemplate> 元素的 media 属性必须指定使用 $Number$ 生成媒体段网址。（startNumber 属性用于标识将分配给第一个媒体段的编号。）

初始化片段的长度

初始化段不得超过 100kb。（通常，初始化细分要比这个小得多。）如果 MPD 中包含初始化片段，那么包含该片段的 data: 网址的长度不得超过 100kb。

编码器输出

初始化段和媒体段必须构成具有封闭 GOP（图片组）的多路复用 ISO BMFF 或 WebM 文件流。

  • GOP 的大小应约为 2 秒，并且必须小于 8 秒。
  • 多路复用流必须包含音频和视频轨道。

其他最佳实践

加密

YouTube 支持通过 HTTPS 进行流加密。我们强烈建议您使用此功能。

MPD 中的初始化片段

根据 RFC 2397，您可以使用 data: 网址直接在 MPD 中表示初始化细分。这样可以简化数据流设置，并降低初始化细分与数据流的其余部分不符的可能性。

此元素的 XPath 为：

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

目标细分受众群时长

为了确保良好的提取性能并在吞吐量和延迟时间之间做出较好的权衡，您的媒体时长应介于 1 到 5 秒之间。我们强烈建议您在 MPD 中使用以下两个元素传达这些细分受众群的目标时长：

  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

根据这些属性计算得出的时长应在所有实际片段时长的 2 倍的范围内，否则流式传输性能可能会受到影响。

请注意，提取的目标时长不等于 YouTube 生成的直播的分块时长。YouTube 会对输入进行转码和重新分块，输出目标时长取决于流是针对流式传输质量还是针对延迟进行了优化。

重试和指数退避

所有 HTTP PUT 请求都应该执行超时，我们建议将该值设置为大于片段时长 500 毫秒的值。

因超时或其他错误而失败的媒体段 PUT 请求对应于视频流中的间隔。因此，您应该使用随机二元指数退避算法重试任何此类请求：

  1. 如果失败，请等待 [0 ... 100] 毫秒之间的随机时间段，然后重试该请求。
  2. 如果请求再次失败，请等待 [0 ... 200] 毫秒之间的随机时间段，然后重试该请求。
  3. 如果请求再次失败，请等待 [0 ... 400] 毫秒之间的随机时间段，然后重试该请求。
  4. 等等

请注意，如果重复故障对应于失败的广播，则应向编码器运营商发送信号。

HTTP 响应代码

以下部分介绍了 YouTube 为响应通过 DASH 提供的片段而返回的响应代码。

200 (OK)

HTTP 200 (OK) 响应表示 YouTube 服务器已收到预期操作，并且已成功处理了该请求。

202（已接受）

对任何 PUT 或 POST 操作的 HTTP 202（已接受）响应表示操作是意外的，并允许进行延迟处理。不过，延迟的操作可能会成功或失败，因此响应无法保证 YouTube 实际上能够成功处理该操作。

此响应最常在按顺序分发细分受众群时发生。通常情况下，YouTube 可在收到上述片段后正确处理接受的片段，因此您无需重新发送该片段。

例如，在以下任一情况下，YouTube 都可以返回 202 响应：

  • 在 MPD 之前收到的初始化片段。
  • 系统会先接收媒体片段，再接收 MPD 和初始化片段。
  • 系统会先接收媒体片段，再接收更早的细分受众群，例如先接收细分受众群 3，再接收细分受众群 2。

但是，如果 YouTube 在收到 POST 或 PUT 请求时无法完全验证商品标识码，则 202 响应还可能表明该商品标识码不正确。例如，发生这种情况的原因之一是：YouTube 收到并接受一个初始化片段，然后又收到了 MPD，但初始化片段却被认定为无效。在这种情况下，YouTube 会接受初始化片段并返回 202，然后确定此片段在收到 MPD 后是否有效。您可以在 MPD 中包含初始化细分，以避免这种特定情况。

400 (Bad Request)

HTTP 400（错误请求）响应表示发生了以下某个问题：

  • 网址格式错误
  • 帖子过大 (>10MB)
  • 无法解析 MPD
  • MPD 中的初始化片段已损坏

401 (Unauthorized)

HTTP 401（未授权）响应表示 YouTube DASH 端点的基准网址已损坏或过期。

405（不允许的方法）

HTTP 405（不允许的方法）响应表示发送的请求不是 POST 或 PUT。

409 (Conflict)

如果对任何 PUT 或 POST 操作发出 HTTP 409（冲突）响应，则表示 YouTube 无法处理该请求。例如，如果要求提出者发送了很多媒体片段，但 YouTube 还没有 MPD 和/或初始化片段，就可能会收到此响应。在此示例中，编码器需要重新发送 MPD 和初始化片段，然后再重试失败的请求。

500（内部服务器错误）

HTTP 500（内部服务器错误）响应表示服务器无法处理该请求。对于此错误，我们建议您使用指数退避算法重试该请求。

示例

网址序列

以下网址序列显示了通过 DASH 传送内容的一系列 PUT 请求。该序列假定 YouTube DASH 端点的基准网址为：

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

此序列显示了分别发送的 MPD 片段和初始化片段。不过，可以直接在 MPD 中表示初始化细分，我们建议您采用这种做法。此外，MPD 和初始化细分受众群应至少每 60 秒更新一次。因此，这些片段的网址最终会再次出现于此序列中，随后便是更多媒体片段的网址。

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

WebM 细分

包含嵌入式初始化细分的 MPD

以下示例 MPD 的 RFC 2397 数据网址中具有初始化初始化段。我们建议您以这种方式嵌入初始化细分，而不是单独发送。

此示例符合将 WebM（VP8 或 VP9、Opus）提取到 YouTube 的情形。为了便于阅读，我们省略了大部分数据网址：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

以下示例 MPD（不含嵌入式初始化细分）也符合使用 WebM（VP8 或 VP9、Opus）提取到 YouTube 的规范：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

初始化

下面显示了一个示例 WebM 初始化段的布局。它包含 WebM 流直到该部分（但不包括第一个集群）的部分。

媒体

下面显示了一个示例 WebM 媒体段的布局。它由一个 WebM 集群组成。与 ISO BMFF 流一样，前置到一系列聚类的初始化细分应生成有效的 WebM 流。

ISO BMFF 细分受众群

包含嵌入式初始化细分的 MPD

以下示例 MPD 的 RFC 2397 数据网址中具有初始化初始化段。我们建议您以这种方式嵌入初始化细分，而不是单独发送。

此示例符合将 YouTube 内容提取到 ISO BMFF（H.264、AAC）的要求。为了便于阅读，我们省略了大部分数据网址：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

以下示例 MPD（不含嵌入式初始化片段）也符合 ISO BMFF（H.264、AAC）提取到 YouTube 的要求：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

初始化

下图显示了多路复用 ISO BMFF 初始化段的示例布局。YouTube 不一定要使用 Atom，但这是一个符合要求的示例。具体而言，音频和视频轨道都有代表性内容。

媒体

下图显示了多路复用 ISO BMFF 媒体段的布局示例。YouTube 未必会使用所有 Atom，但这是一个符合要求的示例。具体而言，音频和视频轨道都有代表性内容。您可以将一系列线段附加到初始化细分，以生成有效且完整的多路复用 ISO BMFF 流。

已知的限制

RTMP 和 DASH 提取

您不能将 RTMP 和 DASH 提取内容混合到 YouTube 中。这适用于在广播期间在两者之间切换，以及将其中一种用作主要提取方法而另一种用于备用提取。