Freigeben über

Azure Media Services での DASH によるライブ ストリーミング

  • Artikel

このポストは、9 月 13 日に投稿された DASH Live Streaming with Azure Media Service の翻訳です。

この記事では、Azure Media Services で使用可能な DASH のライブ ストリーミング機能、および Web ブラウザーやその他のあらゆる最新のデバイスにライブ ストリーミング配信やビデオ オンデマンド (VOD) のアダプティブ ストリーミング配信を行う方法について説明します。現在、各種ブラウザーやデバイスでは DASH が標準でサポートされるようになりつつあります。DASH によるライブ ストリーミングは現在パブリック プレビューで使用可能であり、プレビュー期間が終了すると通常のサービス レベル アグリーメントが適用される「一般提供」が開始される予定です。

DASH による出力は、あらゆるライブ ストリーミングおよび VOD ストリーミングを Azure Media Services から配信する際に使用されるランタイム オプションです。この機能では、それぞれの URL 要求に DASH の形式タグを含めるだけで、プレイヤーが DASH の Media Presentation Description (MPD) のマニフェスト、および互換性のある ISO Base Media ファイル形式の「メディア セグメント」を要求できます。これと同一のファイル、またはライブ ストリーミングは、URL の形式タグで配信形式のいずれかを指定すると、Microsoft Smooth Streaming、Apple HLS、および Adobe HDS で配信できます。このため、新しいブラウザーやデバイスに DASH を導入しながら、同時に従来のプレイヤーや形式との互換性も維持されます。また、メディア ファイルのセグメントをリアルタイムで動的にパッケージ化する機能により、ライブ ストリーミングのレイテンシを低く抑えると共に効率的に複数のプラットフォームをサポートできます。

ライブ チャネル、ライブ エンコーダー、およびストリーミング配信元のサーバーで Azure Media Services アカウントをセットアップする方法については、Jason Suess が執筆したブログ記事「Azure 管理ポータルを使用したライブ ストリーミングの開始」を参照してください。Azure Media Services のサーバーから配信する場合、Azure CDN などのコンテンツ配信ネットワーク (CDN) を使用して膨大な数の同時ストリーミング配信を行えます。

DASH によるストリーミング配信とは

DASH とは「Dynamic Streaming over HTTP」の略で、「ISO/IEC 29009-1:2014 「Dynamic Adaptive Streaming over HTTP (DASH) パート 1 メディア プレゼンテーションの説明とセグメント形式に関する仕様 (英語)」で定められている国際標準のアダプティブ ストリーミング プロトコルです。DASH は MPEG (Moving Picture Experts Group (ISO/IEC Study Group 29/Working Group 11)) で規格化されていて、Media Presentation Description のマニフェストの XML スキーマ、および MPEG-2 トランスポート ストリームや MPEG-4 ISO Base Media ファイルの特定のプロファイルなどのメディアを記述する一般的なオプションなどが含まれています。この ISO メディアのプロファイルは、Microsoft Smooth Streaming や Adobe HDS のものと類似していて、このため Smooth、Flash、PrimeTime などのプレイヤーでは大きな変更を行わなくても DASH の ISO メディアのプロファイルをサポートできます。

アダプティブ ストリーミングでは、非常に多様なビデオ デバイスがそれぞれに互換性のある音声および動画のエンコードを複数のオプションから選択し、ネットワークの状況に応じてビットレートを動的に増減させ、ネットワークとデバイスがサポートしている範囲で最高の品質で継続的にビデオを配信することができるため、今やインターネットでやり取りされるデータの大半を占める映像データの爆発的な増大を可能にしています。HTTP アダプティブ ストリーミングは Web サーバーやコンテンツ配信ネットワークで活用されていて、サーバーやバックボーンの負荷を抑えつつ、キャッシュ済みの特定のメディア セグメントを非常に多数のクライアントに同時にストリーミング配信することができます。

DASH の標準規格は、主要な動画仕様策定組織や関連業種が共同で単一のインターネット動画配信形式を開発したものです。インターネットでは、動画メディア タイプ以外でも HTTP、PNG、Unicode、MP3 などの Web 標準規格が策定されて Web ページが全世界で相互運用可能になっていますが、DASH もそれと同様のものです。Netflix や YouTube、その他の大手動画プロバイダーが ISO メディアを使用する DASH に移行しつつあり、また各種主要ブラウザーはすべて DASH 再生用の W3C API をサポートしています。さらに、最新のモバイル デバイス、インターネット接続型テレビ、およびセットトップ ボックスでも DASH の再生がサポートされています。ISO メディアを使用する DASH は、テレビ番組をインターネット配信することを目的として、放送会社や機器メーカーでも採用されています。Silverlight や Flash などのブラウザーのプラグインの利用は、セキュリティや煩雑性の面から下火になりつつあるため、HTML5 対応ブラウザーがスクリプト化により DASH 再生をネイティブにサポートすることが、専用のストリーミング形式に替わって必要とされています。

配信元や放送会社の目標は、単一の HTML5 形式の Web ページから DASH プロトコルでストリーミング配信を行い、HTML5 対応ブラウザーによりすべてのデバイスでインタラクティブな Web エクスペリエンスを構築することです。デバイスごとに個別にアプリケーションを開発しサポートを提供すると、コストが膨らみ、市場の範囲が制限され、また市場投入までの期間も長くなります。今後は複数のアプリケーションの代わりを単一の Web ページが受け持ち、新しい HTML5 対応ブラウザーが市場のシェアを大きく確保することが予想されます。

DASH によるストリーミング配信は「ただ動作するだけ」なのか

そうではありません。

DASH とは基本的に表示方法を指定する「ツール キット」であり、メディア形式、デコード処理、アダプティブ ストリーミングでの切り替え処理、プレイヤーの実装や相互運用性を指定するものではありません。

DASH Industry Forum、3GPP、DVB、EBU、DECE、HbbTV、DLNA などの組織は、DASH 標準規格に含まれる「ISO Media Live Profile」および「ISO Media On Demand Profile」という DASH の「プロファイル」を指定しました。DASH で指定されたそれぞれの ISO メディア プロファイルは、特定の適用シナリオや専門性を持つ他の組織から派生する規格を作成するときに一貫性を保つことを目的としています。デジタル テレビや DVD なども過去に同様の過程をたどり、汎用的な MPEG 標準規格から派生した仕様が広まりました。一般的に、DASH 標準のプロファイルでは、音声と動画のムービー フラグメントをダウンロードして一般的な表示用のタイムラインで同期できるように、ISO メディアのムービー フラグメントを含む ISO メディアのセグメントが MPD でどのように記述されるかを指定します。DASH では、どのセグメントがシームレスに切り替え可能であるか、アダプティブ ストリーミングのビットレートの基本要件、およびデコード可能であるかどうかは指定されません。これは、DASH 標準では指定されないパーサーおよびデコーダーの機能に依存するため、エンコードやデコードの相互運用性を確保するようにアプリケーションの仕様を決定する必要があります。

DASH-IF の実装ガイドライン (英語) などの仕様では、異なる Representation とのセグメントの連結、コーデック、エンコード パラメーター、暗号化パラメーター、Adaptation Set の制約などで重要となるムービー フラグメントのパッケージ化の制約が定義されます。これにより、シームレスな切り替えが可能になり、また特定の DASH ツールを使用可能にして、高度に定義された「相互運用性ポイント」を作成し DASH のコンテンツやプレイヤーで再生時の信頼性を高めることができるようになります。

Azure Media Services は、DASH-IF のガイドラインに沿って DASH の MPD およびメディアのセグメントを生成します。Azure Media Services の機能の一部により、配信シナリオとプレイヤーの対応範囲を最大化し、また広告の対象を絞ったり、高スケーラビリティかつ高可用性のシステムで DRM コンテンツを保護するなどの重要な使用例 (オリンピックやワールドカップのコンテンツを複数のデータ センターから複数の大陸に向けて 100% の冗長性と可用性を確保しつつ配信するというスケールでテストを実施) のサポートを実現します。

DASH Live MPD の作成

自動処理による作成

Azure Media Services のチャネル (取り込み用 URL) に配信される音声とビデオ ストリーミングに基づいて、下に示すような DASH MPD が自動的に作成されます。このとき、配信には RTMP や Smooth Streaming HTTP:(Post) などのアップリンク プロトコルが使用されます。このプロトコルでは、CSF ムービー フラグメントとしてパッケージ化された MP4 のストリーミングやマルチビットレート形式でエンコードされたムービー フラグメントがプッシュされます。これらのパッケージ化は、チャネルからのプログラムがストリーミング ロケーター (配信元サーバー) に割り当てられた後にメディアのセグメントが要求された際に実施されます。詳細については、「Azure 管理ポータルを使用したライブ ストリーミングの開始」を参照してください。

AVC でエンコードされたビデオ シーケンスの長さは約 2 秒です。その理由は、この長さがビデオのセグメントの長さを決定し、またセグメントの長さとして 2 秒間はビデオ コーデックの効率とのバランスを考慮すると高ビットレートの場合に最適であるためです。また、セグメントの長さが 2 秒であると、ライブ配信用エンコーダーにビデオ フレームが届いてからプレイヤーで表示されるまでのレイテンシが比較的短く抑えられます。実際のレイテンシは、各プレイヤーのバッファー処理とネットワーク接続の信頼性により変化します。通常、レイテンシは数秒から 30 秒程度に調整されます。Azure Media Services では「リアルタイム」のセグメントのアドレス指定と MPD セグメントのタイムラインを使用するため、プレイヤーは最も新しく使用可能になったメディア セグメントがどこであるかを把握し、まだ使用できないセグメントに対する要求を送信することを避けつつ、リアルタイムのストリーミングの「ライブ再生の先頭」を追加することができます。まだ使用できないセグメントに対する要求を送信すると、コンテンツ配信ネットワークと配信元サーバーとの間で大量の HTTP 404 (Not Found) エラーが発生するため、非常に多数のプレイヤーがこれを繰り返すとサービス拒否攻撃のような状態になり、ネットワークで輻輳が発生する可能性があります。DASH のアドレス指定スキームは、プレイヤーの時間と配信元サーバーの時間が同期していることを前提としていて、時間に関するエラーにより発生する最悪の事態を予防できるための安全マージンを取りつつ、しかしセグメントのタイムラインで大きなレイテンシが発生しない程度に「スピードを落とす」必要があります。

プレビュー期間開始時には、単純な AAC 形式の音声と AVC 形式のビデオの組み合わせのトラックのみがサポートされていますが、一般提供開始の発表までには、複数のトラックと追加のコーデックのテストが終了する予定です。プレイヤーにクローズド キャプション形式で配信するために、CEA-608/708 規格のキャプションが AVC ストリームの SEI メッセージに埋め込まれます。また、DASH、Smooth、HLS、HDS で同等の同時配信を可能にするために、期間が 1 種類の MPD がサポートされています。イベント メッセージの形式の整合性を保つことで、放送用ビデオ (SCTE-35 や VMAP など) で既に使用されているプログラム挿入メッセージをすべてのプラットフォームに配信することが可能になり、DASH 特有のソリューションである複数のセグメント長に依存しないでもプレイヤーが広告の挿入などを行えるようになります。

ストリーミング ロケーターが次に示す形で DASH の形式タグ (format=mpd-time-csf) を含むマニフェストを要求するたびに、取り込まれたメディアやメタデータを使用して MPD が構築されます。

https://<ストリーミング ロケーターの URL>/<プレゼンテーション名>.ism/manifest(format=mpd-time-csf)

ライブ プレゼンテーションではアセットが生成され、この MPD に小変更を加えることで VOD 形式での表示に使用できるようになります。MPD の変更には、MPD@type を “static” に変更したり、MPD@availabilityStartTime に替えて MPD@presentationDuration を追加したり、MPD@timeshiftBufferDepth の制限がある場合はそれを削除したりする場合などがあります。

DASH の Live Profile はライブ配信と VOD 配信の両方で便利ですが、DASH の「On Demand Profile」は VOD 配信のみに制限されていて、動的な広告挿入やその他の各 ISO メディア ファイルに格納されているバイト範囲インデックスを無効化するようなランタイムの変更を前提とした設計ではありません。単一の方法でライブ配信とオンデマンド配信の両方のシナリオに完全に対応可能で、また保存されているメディアの再利用と編集に適していて、さらにプレイヤーの実装が簡単なうえにプロファイルのテストも 1 種類で済むというメリットがあるため、Azure Media Services では DASH の「ISO Media Live Profile」を使用します。

また、Azure Media Services では音声やビデオのストリーミング配信における一般的な暗号化や、PlayReady DRM ライセンスもサポートしています。詳細については、Mingfei Yan が執筆したブログ記事「Azure Media Services の Content Protection (コンテンツ保護) サービスを公開」をお読みください。また、条件付きアクセス エンベロープの暗号化の詳細については、同じく Yan が執筆したブログ記事「サービスとしての PlayReady および AES による動的暗号化を Azure Media Services でサポート (英語)」をお読みください。

Azure Media のライブ ストリーミング用 MPD の例

主な機能

  1. DASH の「ISO Media Live Profile」に準拠し、独立した音声および動画のセグメントを使用して、プレイヤーのセグメント連結、個別のトラックの保存と結合を単純化します。
  2. リアルタイムでのエンコードと更新が可能です (MPD@type=”dynamic”)。
  3. MPD のダウンロードが必要となるのは開始時、およびメディア セグメントでプレイヤーがイベント メッセージ (‘emsg’) ボックスの通知を受けたときのみです。更新期間はゼロ (MPD@minimumUpdatePeriod=”PTS0S”) で、<InbandEventStream> 要素はサーバーが必要なとき (ライブ プレゼンテーションの終了時など) に MPD の更新イベントを送信することを示しています。簡易なプレイヤーでは、セグメントの長さとほぼ同じ頻度 (2 秒ごとなど) で MPD の更新をダウンロードする代わりにメディア ストリーム内のこの更新イベントを無視するオプションがありますが、この場合、結果的にネットワーク効率が低下し、レイテンシが大きくなります。
  4. 各 MPD のバージョンは MPD@publishTime で識別されます。これをイベント メッセージの MPD の有効期限と比較し、MPD の更新が必要かどうかが決定されます。
  5. この例では、サーバーが PVR のタイム シフト バッファーをライブ配信の先頭から 4 分間の範囲で維持します (既定では PVR のバッファーは無制限で、録画されたビデオではすべてランダム アクセスが可能です)。
  6. MPD@availabilityStartTime はライブ プレゼンテーションの開始時刻を UTC 時間で表したもので、MPD のプレゼンテーション時間がゼロの時点に相当し、すべてのメディア トラックおよび Adaptation Set の同期に使用されます。
  7. AdaptationSet@bitstreamSwitching=”true” の設定により、1 つの Adaptation Set につき Initialization Segment の処理は開始時の 1 回のみが必要となります。ビットレートを切り替えても再初期化は不要で、セグメントの連続的なシーケンスにより有効な ISO Media CSF (Common Streaming Format) ファイルが形成されます。詳細については、DECE DMEDIA の「一般的なファイル形式とメディア形式の仕様 (英語)」を参照してください。この仕様により、既存のデコーダーで最適なパフォーマンスが得られると共に、さまざまなプレイヤーでシームレスにビットレートの変更が可能です。なお、一部のプレイヤーではメディアのパイプラインおよびデコーダーを再初期化するときに異常が発生する場合があります。
  8. <SegmentTemplate> により、プレイヤーが新しいプレイリストをダウンロードしなくても、次のセグメントのアドレスを計算して次の URL を取得できます。URL は、メディア プレゼンテーションの各セグメントの開始時間を示す $Time$ という代入パラメーターで解決されます。メディア プレゼンテーションの時間は各 CSF メディア セグメントの Track Fragment Decode Time (‘tfdt’) ボックス (ISO メディアのトラックの時間範囲内のタイムスタンプを整数で示しています)、および ISO メディアのトラックの XML Representation の AdaptationSet@timescale に格納されています。Azure Media Services で配信される場合の形式は、「./Fragments(video=$Time$,format=mpd-time-csf)」のように、URL の形式タグで決定されます。この例では、時間によるアドレス指定で MPD とメディア セグメントが示されていて、同時に CSF メディア セグメントも示されています。URL はドキュメントと相関性があり、同一の MPD に対して、編集により異なるルート URL (ストリーミング ロケーターの URL) が指定される場合があります。
  9. <SegmentTimeline> では Adaptation Set のメディア タイムラインがリストに存在する特定の Adaptation Set の各セグメントの開始時刻および長さと共に保持され、連結やシーン検出、セグメントの欠落などのライブ エンコード処理に関する要因により発生したさまざまな長さのセグメントで、正確なタイムスタンプを提供します。セグメントのタイムラインが正確なことにより、独立したエンコーダーと同一のライブ フィードで操作されているサーバーとの間でセグメントのタイムスタンプと URL の同期が可能になります。また、広告の挿入など、時間に基づいて同期されるイベントも使用できます。@t 属性が期間の最初のセグメントのタイムスタンプを識別します。これは UTC 時間の @availabilityStartTime と同時刻で、この場合では単一の期間の中でプレゼンテーション時間がゼロの時点から開始されます。ライブ エンコードされるストリーミング メディアは、ライブ配信かビデオ オンデマンド配信かによって、長さ、タイムスタンプ、時間範囲を変更する必要はありません。セグメントのタイムラインはメディアのタイムベースおよび開始点を柔軟にサポートします。音声と動画の同期を正確に行うために、動画は必ず負のコンポジションのオフセットを使用して、最初のサンプル プレゼンテーション時間が各セグメントの最初のサンプル デコード時間と同一になるようにします (最初のサンプル デコード時間は各セグメントの ‘tfdt’ ボックスに保存されています)。この例では、動画の SegmentTimeline は非常に簡潔で、動画のフラグメントの長さが 120 であり、これは正確に 2 秒間であることを表しています (@r=119 は、同一の長さが 119 回繰り返されることを表しています)。この結果、タイムシフト バッファーは約 4 分となり、MPD は発行時に使用可能なセグメント以外のリストを作成する必要はありません。
  10. この例では 8 つの異なる Representation がビデオの Adaptation Set に存在しています。それぞれが特定のビットレート、および元のビットレートと画像サイズの断片である空間的サブサンプリングを使用してエンコードされています。AVC のエンコード処理およびトリミング パラメーターを正確にコード化することにより、正確なスケールの復元およびピクセルの登録が可能になり、比較的低い領域では目立たないようにビットレートを変更できます。また、ビットレートの抑制に応じてサブサンプリングを実行することにより、ビットレートが低下することによる画像の「軟化」以外は、コード化による副作用が品質に影響することを予防するために役立ちます。
  11. 音声の Adaptation Set には単一の Representation のみが存在し、また通常とは少し異なるパターンのセグメント要素として <S> が登場します。この @d の長さは 10MHz のタイムベースによるもので、44.1kHz の複数の音声トラックの平均的なタイムベースや同期フレームの長さ、セグメント長とは異なります。

MPD のサンプル (DASH の Media Presentation Description の 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. Javascript プレイヤー (英語) を使用して、マイクロソフトや Google などがリリースしている最新の HTML5 ブラウザーでライブ ストリーミングをテストできます。

このプレイヤーはオープン ソースの GitHub プロジェクトである DASH.js を基盤として作成されていて (英語)、発行者が DASH.js スクリプトを自分の Web ページに追加し、DASH によるストリーミング配信ができるようになっています。また、このプレイヤーでは最新の開発ブランチが使用されていて、その中にライブ ストリーミングのサポートが含まれています。

2. 「Azure 管理ポータルを使用したライブ ストリーミングの開始」の記事で説明したように、エンコーダー、Azure Media Services アカウント、およびライブ チャネルをセットアップして、自身のライブ ストリーミングのエンコード処理ができます。

 

マイクロソフトが制作した DASH プレイヤーのオプションに関する詳細は、Cenk Dingiloglu が執筆した「Microsoft Smooth Streaming クライアント 2.5 と MPEG DASH のサポートの発表 (英語)」およびその他のブログ記事を参照してください。他にも、OSMF プラグインを使用して Flash で DASH を再生したり、Windows Phone で DASH を再生するなどの内容の記事があります。また、Microsoft PlayReady チームが Android および iOS 向けに DASH と PlayReady の開発キット (英語) アプリケーションを提供しています。Azure Media Services では、DASH の VOD サービスの一般提供開始を NAB 2014 で発表しました。マイクロソフトやその他のメーカーからこれをサポートする DASH プレイヤーが多数リリースされていますが、Azure Media Services で今回導入された DASH によるライブ配信を行って各プレイヤーをテストし、ライブ ストリーミングでの信頼性を確認してください。