Freigeben über

Azure 媒体服务支持 DASH 实时传送流

  • Artikel

Kilroy Hughes Azure 媒体服务数字媒体架构师

本文重点介绍 Azure 媒体服务支持的 DASH 实时传送流功能，同时阐述如何利用这些功能将实时和点播自适应流传送至 Web 浏览器和各类新设备，这些浏览器和设备都支持DASH 标准了。DSAH 实时传送流现在处于公众预览版阶段，预览版结束后我们会“正式发布”这项服务并提供正常的服务级别协议。

DASH 输出是适用于 Azure 媒体服务发出的所有实时和 VOD 流的运行时的一种选项。播放器只需在每个 URL 请求中将format标记的值定为DASH，便可以请求 ‘DASH 媒体展现说明’元数据和兼容的 ISO 基本媒体文件格式’媒体分段’。通过在 URL format标记中指明这些格式，即能够将相同的文件或实时流以 Microsoft Smooth Streaming、Apple HLS 或 Adobe HDS 格式传输。这样便在将 DASH 传送至新的浏览器和设备的同时，保留了与旧播放器和旧格式的兼容性。动态实时地对媒体分段封装是保证低延迟实时传送流以及有效的多平台支持的关键所在。

有关设置Azure媒体账户并使用实时频道、实时编码器以及流式传输源服务器信息，请访问 Jason Suess 的精彩博客“通过 Azure 媒体管理门户开始使用直播流媒体”。Azure 媒体源服务器可使用内容传送网络 (CDN)（包括 Azure CDN）支持数百万个并行流。

什么是 DASH 流？

DASH 是“Dynamic Streaming over HTTP”的首字母缩写词，它是指如下国际标准指定的提供自适应流的协议：ISO/IEC 29009-1:2014“信息技术 — 通过 HTTP 提供动态自适应流 (DASH) — 第 1 部分：媒体展现说明和分段格式”。DASH 采用活动图像专家小组 (MPEG) 制定的标准，具体是指 ISO/IEC 第 29 研究组/第 11 工作组 (ISO/IEC Study Group 29/Working Group) 制定的标准。它包括一份有关媒体展现元数据 (MPD) 的 XML 架构和用于描述媒体的常规选项，包括一些特定于 MPEG-2 传送流的配置文件和 MPEG-4 ISO 基础媒体文件。ISO Media 配置文件与 Microsoft Smooth Streaming 和 Adobe HDS 相似。正是由于这种相似性，Smooth、Flash 以及 PrimeTime 播放器才能支持 DASH 的 ISO Media 配置文件，无需进行大幅修改。

自适应流引发了互联网视频数量的爆炸式增长，现在视频已成为互联网数据的中坚力量。这是因为，从自适应流出现之后，大量视频设备都能够从众多选项中选择兼容的音频和视频编码，并可以根据网络状况动态选择更高或更低的比特率，从而在网络和设备能够保证的前提下以最高质量水平连续不断地播放视频。HTTP 自适应流利用 Web 服务器和内容传送网络 (CDN) 支持数百万个来自相同媒体分段的缓存并行传递流，不会给服务器和主干网络带来额外负载。

DASH 标准是集体智慧的结晶，每个大型视频规范组织和行业部门都参与了互联网视频传送统一格式的制定，这一点与实现包含非视频媒体类型的网页的全球统一标准的其他 Web 标准（HTTP、PNG、Unicode、MP3 等）类似。Netflix、YouTube 以及其他大型视频提供商将转型支持 DASH with ISO Media；所有主要浏览器都支持可实现 DASH 播放的 W3C API；新型移动设备、联网电视以及机顶盒也支持 DASH 播放。DASH with ISO Media 已被广播公司和设备制造商采纳，用于通过互联网传送电视节目内容。出于安全和复杂性考虑，Silverlight 和 Flash 等浏览器插件已被弃用，因此，要取代专用流格式，必须在 HTML5 浏览器中内置支持包含脚本的DASH 播放。

出版商和广播公司的目标是创建一个 HTML5 网页，通过该网页将 DASH 及其交互式 Web 体验传递至所有安装 HTML5 浏览器的设备。为每一类设备都开发单独的应用程序并提供相关支持，需要投入资金、降低推广度，而且会延缓上市时间，因此，当新的 HTML5 浏览器的市场份额达到一定程度后，单个 Web 页面可能会取代多个应用程序。

只要DASH 流就够了吗？

否。

从根本上说，DASH 是一款描述展示方法的”工具包”，但没有指定媒体格式、解码、自适应交换行为、播放器实现或互操作性。

DASH Industry Forum、3GPP、DVB、EBU、DECE、HbbTV、DLNA 等组织根据 DASH 标准中包含的“ISO Media Live Profile”和“ISO Media On Demand Profile”衍生出了 DASH 配置文件。DASH 指定的 ISO Media Profile 可帮助具有特定应用情景和专业知识的其他组织衍生配置文件。过去，数字电视和 DVD 等媒体也有过类似经历，它们也根据通用 MPEG 标准衍生应用规范。DASH 标准中的配置文件规定了 MPD 描述包含 ISO Media 电影片段的 ISO Media Segment 的大体方式，以便在统一的展现时间轴上下载和同步音频和视频电影片段。DASH 没有规定哪些片段可以无缝交换（这是自动调节比特率的流的基本要求），甚至也没有规定这些片段是否可以解码。这些内容取决于 DASH 标准中未进行规定的解析器和解码器功能，因此，需要制定有关编码解码互操作性的应用规范。

DASH-IF 实现准则等规范规定了电影片段封装限制, 这对拼接来自不同表示器、编解码器、编码参数、加密参数、适配集限制的分段来说是非常重要的，只有这样才可以实现分段无缝交换；这一点对于特定 DASH 工具的使用来说也至关重要，因为只有创建了定义明确且 DASH 文件及播放器可以支持和识别的“互操作点”，才能实现稳定播放。

Azure 媒体服务按照 DASH-IF 准则规定提供 DASH MPD 和媒体分段。Azure 媒体专有功能实现了与范围最广的传送情景和播放器兼容，并且支持定向广告和高度可伸缩可用系统中的 DRM 内容保护等重要用例，也就是说，在保证 100% 冗余度和可用性的条件下，通过从多个数据中心向几个大洲提供奥林匹克和世界杯赛事转播，Azure 媒体的功能在大规模应用中得到检验。

创建 DASH Live MPD

这是自动操作！

为频道节目指定流定位器（源服务器）后，如接收到了媒体分段请求，系统将根据使用 RTMP 或 Smooth Streaming HTTP:(Post) 等上行链路协议传输至 Azure 媒体频道（摄取 URL）的音频和视频流自动创建与下文 MPD 类似的 DASH MPD，以推送封装为 CSF 电影片段的 MP4 流或多比特率编码的电影片段。有关详细信息，请访问“通过 Azure 媒体管理门户开始使用直播流媒体”。

AVC 编码的视频序列的持续时间应为 2 秒钟左右，因为该持续时间决定了视频段的持续时间，而且 2 秒时长片段最理想，既能实现快速的比特率自适应，又能保证视频编解码器效率。两秒时长片段还可以相对减少从视频帧到达实时编码器到在播放器上展现之间的延迟。实际延迟视每个播放器的缓冲逻辑和网络状况的稳定性而定。通常，延迟时间从几秒钟到三十秒钟不等。由于 Azure 媒体服务使用“实时”分段寻址和 MPD 分段时间轴，因此，播放器能够识别最后那个可用的媒体分段，从而加入实时流“领地”，不必冒险请求尚不可用的分段。请求尚不可用的分段会引发内容传送网络 (CDN) 和源服务器之间出现多个 HTTP 404（找不到）错误，因此，如果数千台播放器执行这一请求，可能会造成网络阻塞（如拒绝服务攻击）。依赖播放器时钟与源服务器时钟之间同步的 DASH 寻址架构必须能够处理超出最大时钟错误的安全限度的情况，但分段时间轴可避免额外延迟。

在预览阶段开始，我们支持简单的 AAC 音频和 AVC 视频轨道组合，但在宣布正式发布前，我们会验证多个轨道和更多的编码解码器。在 AVC 视频流的 SEI 消息中可嵌入 CEA-608/708 字幕，从而以封闭字幕的形式向播放器传送这些字幕。支持单周期 MPD，以便以 DASH、Smooth、HLS 以及 HDS 格式同时展现相同的内容。在采用统一活动消息格式的条件下，可向所有平台传送广播视频中已经存在的节目植入消息（如 SCTE-35、VMAP），因此播放器不需要依赖多个周期（特定于 DASH 的解决方案）便可以播放植入广告等内容。

每当使用如下传送流定位器请求带有 DASH format标记 (format=mpd-time-csf) 的元数据时，都会使用传入的媒体和元数据构建 MPD：

实时展现生成的资源经过细微改动变成 MPD 后可用于 VOD 展现，例如，将 MPD@type 改为 “static”、添加 MPD@presentationDuration 取代 MPD@availabilityStartTime 并删除 MPD@timeshiftBufferDepth 限制（如果有的话）。

DASH Live Profile 对实时传送和 VOD 传送均适用，而 DASH“On Demand Profile”仅适用于 VOD 传送，并不适用于动态广告植入或其他会使得每个 ISO Media 文件中存储的字节范围索引无效化的运行时更改。Azure 媒体服务使用 DASH“ISO Media Live Profile”，因为它为所有实时传送和点播传送情景提供了统一的解决方案、可优化已存储媒体重复使用与编辑，并简化播放器实现及单个 Profile 测试。

Azure 媒体服务还支持音频与视频流的 Common Encryption以及 PlayReady DRM 许可（详见 Mingfei Yan 的博客“宣布正式发布 Azure 媒体服务内容保护服务”）；支持条件存取封套加密（详见 Mingfei Yan 的博客“发布 PlayReady 即服务和 Azure 媒体服务支持的 AES 动态加密服务”）。

Azure 媒体实时传送流 MPD 示例

功能亮点：

  1. 符合 DASH“ISO Media Live Profile”标准，使用独立音频和视频分段简化播放器的分段拼接独立轨道存储及其组合。
  2. 实时编码和更新 (MPD@type="dynamic")。
  3. 只需在启动时以及播放器媒体分段中的事件消息框（Event Message Box，即 emsg）收到通知时才需要下载 MPD。将更新周期设为零 (MPD@minimumUpdatePeriod="PT0S") 并使用
    <InbandEventStream> 元素, 服务器将会在必要时（如在实时展现结束时）发送 MPD 更新事件。设计简单的播放器可选择忽略媒体流中的更新事件，取而代之的是以约等于分段持续时间的频率（如每 2 秒钟一次）下载 MPD 更新，但这会导致网络效率下降，而延迟增加。
  4. MPD@publishTime 将识别每个 MPD 版本，并将其与事件消息 MPD 到期时间对比，以确定是否需要 MPD 更新。
  5. 在本示例中，为服务器维持了当前在播放的那一刻之后4 分钟的 PVR缓冲深度（默认深度为无限制 PVR 缓冲，在这种情况下，整个录制的视频均可随机访问）。
  6. MPD@availabilityStartTime 是实时展示启动时的 UTC 时间，零 MPD 展示时间同样意味着可对所有媒体轨道/适配集进行同步。
  7. AdaptationSet@bitstreamSwitching="true"，因此，启动时只需对每个适配集处理一个初始化分段。比特率交换时无需执行重新初始化，而且任何连续的分段序列均可构成有效的 ISO Media CSF（Common Streaming Format，常规流格式）文件。请参见 DECE DMEDIA“常见文件格式和媒体格式规范”。这会充分发挥现有解码器的性能，并在大部分播放器之间实现最流畅的比特率交换（一些播放器可能会在媒体通道和解码器重新初始化时出现问题）。
  8. <SegmentTemplate> 可让播放器计算下一个分段地址，无需下载新的播放列表来获取下一个 URL。通过用每个分段开始部分的媒体展现时间来替换 $Time$参数以生成 URL。媒体展现时间存储在每个 CSF 媒体分段的轨道片段解码时间框 (‘tfdt’) 中，此时间戳在 ISO Media 轨道时间标度中以整数形式表示，在 ISO Media 轨道 XML 表示中以 AdaptationSet@timescale 表示。Azure 媒体服务采用的 URL 格式由 URL 格式标记决定，如 “./Fragments(video=$Time$,format=mpd-time-csf)”。在本示例中，格式标记表示使用时间寻址的媒体分段和MPD, 以及 CSF 媒体分段。URL 是与文档相对的，因此编辑时可将相同的 MPD 放置在不同的根 URL（流定位器 URL）上。
  9. <SegmentTimeline> 维护适配集的媒体时间轴，并列出了适配集中每个分段的开始时间和持续时间，以便为各种持续时间不同的片段提供准确的时间戳, 因拼接、场景检测、丢弃的片段以及其他实时编码活动可能引起各片段持续时间不同。准确的分段时间轴还可以让处理相同实时源的独立编码器和服务器之间实现分段时间戳和URL同步, 并支持基于时间的事件同步（如广告植入）。@t 属性表示周期内第一个分段的媒体时间戳，该属性与 UTC @availabilityStartTime 一致，在本示例中与从零展现时间开始的单个周期一致。针对不同的展现形式（如从实时展现改为 VOD 展现），不需要改变实时编码流的持续时间、时间戳以及时间标度，因为分段时间轴支持灵活的媒体时间基础和起点。要实现准确的音频/视频同步，视频必须使用负的组合偏移，使每个分段中的第一个样本展现时间等于第一个样本解码时间（第一个样本解码时间存储在每个分段的“tfdt”框中）。本示例中的视频分段时间轴非常简洁明了，因为电影片段持续时间完全匹配, 这意味着120, 也就是两秒钟长的片段（@r=119 表示 119 个完全相同持续时间的重复）。该持续时间可填充不断滚动的 4 分钟时移缓冲，而且 MPD 不需要在分段可用时列出超出可用数量的分段。
  10. 本示例在视频适配集中提供了 8 种不同的表示，每个表示使用作为源比特率和空间二次抽样进行编码, 抽样是从源比特率和图像尺寸中选取。对 AVC 编码进行精确编码并使用裁切参数可实现图像重新缩放和像素配准，因此人们不会注意到相对较小的比特率变化，同时按比特率减少比例进行二次抽样可保持可感知的视频质量, 因为它避免了除了在比特率降低时对图像进行”软化”处理以外的人工编码工作。
  11. 音频适配集具有单个表现和一个不寻常且略有差异的分段元素 <S> @d 持续时间模式，这是因为 10MHz 时基不是音频的 44.1kHz 轨道时基的偶数倍, 此外还有同步帧持续时间以及分段持续时间。

MPD 示例（DASH 媒体展示说明 XML 文档）

<?xml version="1.0" encoding="utf-8"?>

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi=<a href="https://www.w3.org/2001/XMLSchema-instance">https://www.w3.org/2001/XMLSchema-instance</a>

profiles="urn:mpeg:dash:profile:isoff-live:2011"

type="dynamic"

publishTime="2014-09-11T22:16:32Z"

minimumUpdatePeriod="PT0S"

timeShiftBufferDepth="PT4M0S"

availabilityStartTime="2014-09-09T21:36:00Z"

minBufferTime="PT3S">

      <Period start="PT0S">

            <AdaptationSet id="1" group="1" profiles="ccff" bitstreamSwitching="true" segmentAlignment="true"

                contentType="video" mimeType="video/mp4" codecs="avc1.64001F" maxWidth="1280" maxHeight="720" startWithSAP="1">

                  <InbandEventStream schemeIdUri="urn:mpeg:dash:event:2012" value="1"/>

                  <SegmentTemplate timescale="10000000"

                      
media="QualityLevels($Bandwidth$)/Fragments(video=$Time$,format=mpd-time-csf)"

                      
initialization="QualityLevels($Bandwidth$)/Fragments(video=i,format=mpd-time-csf)">

                  <SegmentTimeline>

                        <S
t="1749929391643" d="20000000" r="119"/>

                  </SegmentTimeline>

                  </SegmentTemplate>

                  <Representation
id="1_V_video_3036584097160919574" bandwidth="477000"
width="368" height="208"/>

                  <Representation
id="1_V_video_1525935660032550912" bandwidth="2962000"
width="1280" height="720"/>

                  <Representation
id="1_V_video_8768634852038808351" bandwidth="1427000"
width="768" height="432"/>

                  <Representation
id="1_V_video_7183729080090115923" bandwidth="331000"
width="284" height="160"/>

                  <Representation
id="1_V_video_5821161055196117281" bandwidth="688000"
width="448" height="252"/>

                  <Representation
id="1_V_video_11970265954542642125" bandwidth="991000"
width="592" height="332"/>

                  <Representation
id="1_V_video_12301116055337443231" bandwidth="2056000"
width="992" height="560"/>

                  <Representation
id="1_V_video_13845503576954141943" bandwidth="230000"
width="224" height="128"/>

            </AdaptationSet>

            <AdaptationSet id="2"
group="5" profiles="ccff"
bitstreamSwitching="true" segmentAlignment="true"

                contentType="audio"
mimeType="audio/mp4" codecs="mp4a.40.2">

                  <InbandEventStream
schemeIdUri="urn:mpeg:dash:event:2012" value="1"/>

                  <SegmentTemplate
timescale="10000000"

                      
media="QualityLevels($Bandwidth$)/Fragments(audio=$Time$,format=mpd-time-csf)"

                      
initialization="QualityLevels($Bandwidth$)/Fragments(audio=i,format=mpd-time-csf)">

                        <SegmentTimeline>

                               <S t="1749929389828" d="20201361"/>

                               <S d="19969161" r="5"/>

                               <S d="20201360"/>

                               <S d="19969162"/>

                               <S d="19969161"/>

                               <S d="19969160"/>

                               <S d="19969162"/>

                               <S d="19969161"/>

                               <S d="19969160"/>

                               <S d="19969162"/>

                               <S d="20201360"/>

                               <S d="19969161" r="5"/>

                               <S d="20201361"/>

                               <S d="19969161"/>

                               <S d="19969160"/>

                               <S d="19969162"/>

                               <S d="19969161" r="1"/>

                               <S d="19969160"/>

                               <S d="19969162"/>

                               <S d="20201360"/>

                               <S d="19969161" r="5"/>

                               <S d="20201361"/>

                               <S d="19969161"/>

                               <S d="19969160"/>

                               <S d="19969162"/>

                               <S d="19969161" r="3"/>

                               <S d="20201360"/>

                               <S d="19969161" r="5"/>

                               <S d="20201361"/>

                               <S d="19969161" r="6"/>

                               <S d="20201360"/>

                               <S d="19969161" r="5"/>

                               <S d="20201361"/>

                               <S d="19969161" r="6"/>

                               <S d="20201360"/>

                               <S d="19969161" r="5"/>

                               <S d="20201361"/>

                               <S d="19969161" r="6"/>

                               <S d="20201360"/>

                               <S d="19969161" r="6"/>

                               <S d="20201361"/>

                               <S d="19969161" r="5"/>

                               <S d="20201360"/>

                               <S d="19969161"/>

                               <S d="19969162"/>

                               <S d="19969160"/>

                               <S d="19969161"/>

                               <S d="19969162"/>

                               <S d="19969160"/>

                               <S d="19969161"/>

                               <S d="20201361"/>

                               <S d="19969161" r="5"/>

                        </SegmentTimeline>

                  </SegmentTemplate>

            <Representation id="5_A_audio_10091442596786975675" bandwidth="160000" audioSamplingRate="44100"/>

            </AdaptationSet>

      </Period>

</MPD>

体验一下吧

您可以：

1. 在 Microsoft、Google 等公司推出的最新 HTML5 浏览器上使用此款 Javascript 播放器体验实时传送视频流。

此款播放器基于 DASH.js 开源 GitHub 项目开发，让发布者可在网页上添加 DASH.js 脚本，以流式传输 DASH。此款播放器使用支持实时传送流的最新开发分支。

2.  按照下文说明设置编码器、Azure 媒体帐户以及实时传送频道，对自己的实时传送流进行编码。

通过 Azure 媒体管理门户开始使用直播流媒体

 3. 另外，使用 Richard Li 博客中介绍的全天候实时传送流测试服务器对播放器进行测试。

全天候提供引用媒体流直播

频道 1

  • 属性
    • 地区：美国东部
    • timeShiftBufferDepth：1 小时
    • 片段大小：2 秒
  • 清单文件
  • MPEG-DASH

频道 2

  • 属性
    • 地区：美国东部
    • timeShiftBufferDepth：15 分钟
    • 片段大小：2 秒
  • 清单文件
  • MPEG-DASH

Cenk Dingiloglu 的博客中介绍了更多 Microsoft DASH 播放器选项，第一篇博客是“公告：含 MPEG DASH 支持的 Microsoft Smooth Streaming Client 2.5”。Cenk Dingiloglu 的其他博客介绍了使用 OSMF 插件的 Flash 上的 DASH 播放、Windows Phone 上的 DASH 播放等。Microsoft PlayReady 团队在 Android 和 iOS 系统上还提供适用于 DASH plus PlayReady 的开发套件应用程序。Azure 媒体服务在 2014 年 NAB 上宣布正式发布 DASH VOD 服务，来自 Microsoft 和其他源的多个 DASH 播放器均支持这一服务，但播放器需使用现已可用的 Azure 媒体实时 DASH 流进行测试，确定其传送实时流的稳定性。

如果你有任何疑问, 欢迎访问MSDN社区，由专家来为您解答Windows Azure各种技术问题，或者拨打世纪互联客户服务热线400-089-0365/010-84563652咨询各类服务信息。

本文翻译自：https://azure.microsoft.com/blog/2014/09/13/dash-live-streaming-with-azure-media-service