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

时间：2023-03-08 16:28:53

Azure 媒体服务支持 DASH 实时传送流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：

　http://<流定位器
url>/<展现名称>.ism/manifest(format=mpd-time-csf)

实时展现生成的资源经过细微改动变成
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="http://www.w3.org/2001/XMLSchema-instance">http://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咨询各类服务信息。

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