Azure Media Services 用の包括的なツール


このポストは、4 月 20 日に投稿された A Comprehensive Tool for Azure Media Services の翻訳です。

プロフェッショナル レベルのオンライン ビデオ ストリーミング ソリューションを Azure Media Services (AMS) で構築する場合、データ フローは多岐にわたります。ライブ ストリーミングの場合を例に考えてみましょう。

  1. 当然のことながら最も重要なものはビデオ フローで、キャプチャから始まり、長距離のフィード、エンコード、AMS への取り込み、アーカイブ、動的なパッケージ化や保護、CDN への送信、最後にクライアント プレイヤーへの配信という手順になります。ビデオを画面に表示することは最初の段階に過ぎず、最も難しい部分ではありません。むしろ、ビデオを画面に表示することは「簡単」で、どのようにして「ビデオが表示されないようにするか」(DRM 保護) や、ビデオ以外のもの (動的に挿入された広告、コンテンツ制御 (CC)、試合の得点や選手の情報といったメタデータ、緊急発表、天候による遅延を伝えるメッセージなど) をどのようにしてユーザーに視聴してもらうかというところが「難しい」部分です。
  2. 次に、広告フローがあります。これは広告マーカーの挿入から始まり、ストリーミング形式に応じた広告マーカーの各種 SCTE 形式への動的なパッケージ化、プレイヤーによる広告マーカーの解析、広告の決定と配信へと続き、最後は広告の再生という手順になります。
  3. コンテンツ制御フローでは、テキスト形式のコンテンツが生成されてコントリビューション フィードに追加され、ビデオ コンテンツと共にパス全体に送られます。
  4. メタデータ フローでは、まず各種サブシステムでメタデータが生成され、コンテンツ管理ストレージ (CMS) に追加され、その後 Web ポータルやクライアント プレイヤーに配信されて表示やフェールオーバーなどの目的に使用されます。たとえば、AMS でアセットが発行されストリーミング URL が生成された場合、この URL は完全に自動化および統合された形で下記の方向に送られます。
    • エンド ユーザーが閲覧、検索、再生できるようにユーザーのビデオ ポータルにフィードを行う CMS データベースに送られます。
    • メタデータの 1 つとしてユーザーの広告プロバイダーに送られます。
    • プライマリ URL、および配信元で問題が発生した場合のフェールオーバーに使用するセカンダリ URL などのメタデータをビデオ プレイヤー クライアントに提供するエンド ポイント (WebAPI サービスなど) に送られます。
  5. コンテンツ保護フローでは、コンテンツ キーの生成から始まり、動的コンテンツ保護のセットアップ、認証トークンの発行、DRM ライセンスまたは暗号化解除キーの配信と続き、最後にクライアント プレイヤーでのコンテンツの暗号化解除が行われます。
  6. 分析フローでは、クライアント プレイヤーからクラウドにデータが集約され、他のフローの管理やフロント エンドでの表示に関する意思決定に使用されます。
  7. アカウントのプロビジョニング、課金、エンドユーザー向けポータル、ユーザー認証、承認、EPG (電子番組表)、EMS など、インターネットによるビデオ配信では重要性の高い項目は上記に含まれていません。

これらのデータ「フロー」は正しい方向 (特定のサブシステムから他のサブシステムへ) に適切な速度 (視聴者の規模やニーズ、ネットワーク帯域幅、クライアントの CPU などに基づく) で流れ、適切なタイミング (秒単位またはフレーム単位の正確性) で配信先に届けられる必要があります。このため、これらの「フロー」が連携して動作するように「フロー」を制御する「コントローラー」が必要です。この「コントローラー」は多くの場合、広い意味でコンテンツ管理システム (CMS) と呼ばれます。

このような CMS を迅速かつより良い形で構築するにはどうすればよいでしょうか。また、何か利用できるものはないでしょうか。

Azure Media Services でビデオ ソリューションを構築する場合は、下記のシナリオが考えられます。

  1. CMS ツールを構築して既存の自社システムと統合し、ワークフローを自動化する場合。
  2. 顧客が Azure Media Services を基盤とするビデオ ソリューションを構築する場合にそれを支援するシステム インテグレーター (SI) が、そのようなプロジェクトをゼロから始める必要がないように、パッケージ化された SDK やソフトウェア フレームワークを構築することを選択する場合。この手法により、市場投入までの期間の短縮、プロジェクトの配信の反復性の向上、および SI の市場競争力の強化が可能です。

このような場合、顧客および SI が必要としているものは、人間用のスタンドアロン型ツールではなく、自動化されたワークフローで完全に統合化されたソリューションを短期間で構築する方法です。作成者は、そのようなソリューションで使用されているツールセットを共有したいと考えます。コードは各シナリオに適用するように作成されており、このツールセットの価値は、ソース コードを公開できるという点にあります。このソース コードは、サンプル コードとして使用したり、ソリューションで直接使用したり、ソリューションの設計や計画作成に利用することができます。

ソース コードは、マイクロソフトの LCA が承認したものが MIT ライセンスの下で OSS としてリリースされており、GitHub (英語) で公開されています。

この包括的なツールセットでは、下記の Azure Media Services の主要なすべての機能に対応しています。

  1. ライブ放送
  2. VOD
  3. ライブから VOD への移行の管理とライブ アーカイブの診断
  4. PlayReady 保護機能 (ライブ放送と VOD の両方に適用)
  5. AES-128 暗号化機能 (ライブ放送と VOD の両方に適用)
  6. 広告の挿入 (Aventus ライブ エンコーダー用)

このツールの機能は、実際にソリューションやユース ケースで使用されているものです。このツールは「実践的なテスト」を経ています。

  1. Azure Media Services リリース前の最終テストの一環として、NBC Sports のソリューションのシナリオのテストに使用されました。
  2. iStreamPlanet の CMS ツールの準備が整う前に、NBC Sports が行うイベントのライブ ストリーミング (英語) に使用されました。
  3. ソチ オリンピックのストリーミング放送をサポートするために、NBC Sports と Deltatre (診断機能用) で広く使用されました。
  4. 北米、ヨーロッパ、アジアの 15 のベンダーが使用するライブ ストリーミング エンジニアリング環境を 24 時間体制で休みなく運用するために、NBC Sports/ソチ オリンピック プロジェクト (英語) のエンジニアリング プロセス全体を通して使用されました。
  5. NBC Sports/ソチ オリンピック プロジェクト (英語) の VOD サブシステムで、Azure Media Processor および Kayak Media Processor (英語) の両方ですべての VOD コード変換ワークフローのパフォーマンス テストを実施する際に使用されました。
  6. このツールのソース コードは大部分が iStreamPlanet (英語) と共有され、NBC Sports/ソチ オリンピック プロジェクト用ソリューション (英語) を運用する CMS ツールの開発に利用されました。
  7. このツールのソース コードの一部は Deltatre (英語) と共有され、ソチ オリンピック プロジェクト期間中に重要な機能の一部に使用されました。
  8. PlayReady 保護のエンドツーエンド プロトタイプおよび AES 暗号化のエンドツーエンド プロトタイプの作成にも使用されました。

主な特長

ここからは、ツールの主な対象と機能を説明します。ここでご紹介するツールの機能のサブセットはすべて、NBC Sports が毎日のスポーツのストリーミング放送で使用している基幹業務 (LOB) ソリューションである NBC Sports/ソチ オリンピック プロジェクト用ソリューション (英語) など、実際のソリューションに使用されたものです。

ACS の冗長性

REST API であるか .NET API であるかによらず、AMS の API 呼び出しでは必ず Active Control Service (ACS) の有効なベアラー トークンが必要であり、この ACS トークンは AMS の ACS から取得されます。当然のことながら、重要なライブ イベントのときは、1 つの ACS インスタンスのみを使用することは推奨されません。ライブ イベント中に ACS トークンを取得できないと、メディア サービスへのアクセスが完全に遮断されるため、致命的な事態に陥る可能性があります。このツールでは AMS の複数の ACS インスタンス間での自動フェールオーバーが実装されており、また「優先 ACS」が「維持」されます。特に、このツールが持つ ACS の冗長性機能は下記の運用環境の要件を満たしており、2014 年のソチ オリンピックのライブ ストリーミング放送 (英語) にも十分に対応できました。

要件

要件の詳細

ACS の自動フェールオーバー

使用中の ACS が使用できなくなった場合に他の ACS に自動的に切り替える必要があります。

ACS トークンの再利用

Media Services SDK 3.0 の新機能を使用する必要があります。ACS トークンの期限がまだ切れていない場合は、CloudMediaContext を作成するときにトークンを再利用します。

ACS トークンの自動更新

ACS トークンの期限が切れている場合は、CloudMediaContext を作成する前に ACS トークンを更新します。

複数のコンテキスト インスタンスのサポート

アプリケーションが複数のメディア サービスを利用する必要がある場合、そのアプリケーションでは複数の CloudMediaContext インスタンスを利用する必要があります。

SDK の今後の変更への対応

今後リリースされる AMS SDK では、ACS トークンが CloudMediaContext コンストラクターで更新されなくなる可能性があります。ACS トークンの期限の確認および ACS トークンの更新は、コード内で行う必要があります (手動による ACS トークンの更新)。

ACS の「維持」

特定の「優先」ACS インスタンスが使用可能な限り、フェールオーバーを待たず、その ACS を使用し続ける必要があります。

ACS インスタンスのサポート

AMS のすべての ACS インスタンスをサポートする必要があります。

単一の ACS のサポート

SwitchACSEnabled と PreferredACSEnabled を false に設定すると、単一の ACS インスタンスのみが使用されます。環境によっては、AMS の ACS インスタンスが 1 つしか使用できない場合があります。

 

Azure BLOB から AMS のアセットに変換する

物理的なビデオ ファイルを BLOB として Azure Storage に格納しており、これを AMS のアセットに変換する必要がある場合があります。このツールでは、下記のような場合に変換機能を使用できます。

  1. BLOB が作業対象のメディア サービスと関連付けられているストレージに格納されている場合
  2. BLOB が作業対象のメディア サービスと関連付けられていないストレージに格納されている場合

CDN のデータセンター間で一貫した URL を作成する

AMS のライブ プログラムの URL の形式は、次のようになります。

http://[配信元名]-[メディア サービス名].streaming.mediaservices.windows.net/[ロケーター ID]/[マニフェスト ファイル名].ism

具体的な例を次に示します。
http://chaventus-willzhanmediaservice.streaming.mediaservices.windows.net/faecd1a8-71de-4f1e-8607-739c989301d5/LyncSkypeSizzleVideo750k.ism/Manifest

通常、ロケーター ID は生成された GUID となります。冗長性を確保するために 2 か所のデータセンターを使用している場合、同一ライブ チャンネルの同一プログラムには、ホスト名の部分のみが異なり、仮想パスは同一の 2 つの URL を使用する必要があります。このとき、対応する 2 つのプログラムを 2 つの異なるデータセンターで作成するには、ロケーター ID (ロケーター パス) とマニフェスト ファイル名がまったく同一である必要があります。このツールでは、ライブ ストリーミング プログラムを作成するときにこの機能を使用できます。

特定のストレージでプログラムを作成する

Azure Media Services では、単一のメディア サービスに複数の Azure Storage を使用できます。信頼性を高めるためには、ライブ アーカイブやオンデマンド用アセットの格納先として、基盤となる Azure Blob Storage を 1 つのメディア サービスで複数使用します。このツールでは、プログラム作成時にどのストレージを使用するかを指定できます。このため、複数のチャンネルを同時に配信する場合、アーカイブの負荷を複数の BLOB ストレージに分散することができます。

ライブ アーカイブの診断

このツールでは、通常の処理の他にライブ ストリーミングとライブ アーカイブを診断することも可能で、ライブ ストリーミングの実行中および実行後にライブ アーカイブの問題を迅速に発見できます。このツールで診断しレポートを生成することができる問題の例を下記に示します。

  1. 最初のフラグメントで品質レベルが不十分なライブ アーカイブの「開始時のジャギー」。ライブ アーカイブでは「開始時のジャギー」が発生することが珍しくありません。WAMS チームによると、これはバグではなく、フラグメントが異なるタイミングで到着するために発生します。

  2. Aventus からのフィードと Azure での取り込みの間でのネットワーク レイテンシ。Aventus のバッファーでのレイテンシやバースト。通常、6 秒間の GOP を使用している場合には、連続する FragBlob の書き込みの時間差は 6 秒前後である必要があります。次のスクリーンショットの 2 列目は、2 つの連続する FragBlob の実際の時間差から 6 秒を引いた数値を示しています。

  3. ライブ アーカイブで欠落している FragBlob。2 つの連続する FragBlob の時間差は 6 秒前後である必要があります。6 秒を大幅に超える場合、FragBlob の欠落が発生します。

コンテンツ保護

  1. オンデマンド ストリーミングの動的 PlayReady 保護
  2. ライブ ストリーミングの動的 PlayReady 保護
  3. ストレージの暗号化が適用されていないアセットのオンデマンド ストリーミングの動的 AES 暗号化
  4. ストレージの暗号化が適用されているアセットのオンデマンド ストリーミングの動的 AES 暗号化

コンテンツ保護には、動的保護と暗号化、ライセンスとキーの配信、プレイヤー クライアントの認証と認証トークン、配信元、プレイヤーの発行に使用する STS など、ソリューションの複数のサブシステムが含まれます。エンドツーエンドのコンテンツ保護の設計と実装については、Azure ブログの Media Services のカテゴリで公開されている次の 2 つの記事をご確認ください。

  1. ACS 認証および ACS トークン認証による AES 暗号化のエンドツーエンド プロトタイプ
  2. ACS 認証および ACS トークン認証による PlayReady 保護のエンドツーエンド プロトタイプ

この 2 つのエンドツーエンドのプロトタイプと設計では、SWT に加えて、そのアップグレードである JWT トークン認証もサポートされています。

制限事項

このツールにはいくつかの制限事項がありますが、そのうちの大きなものとして、ユーザーにわかりやすい UI が用意されていないことが挙げられます。このツールでは Windows コンソールのような Visual Studio プロジェクト (ライブ用、オンデマンド用、広告マーカー挿入用) を使用し、色分けが可能な UI では Console クラスで色をカスタマイズできます。個人的には、このツールは「Visual Studio をユーザー インターフェイスとして使用する (入力パラメーターの変更時、コンパイル時、実行時)」と最も使いやすいように感じられます。ただし、これには基本的な C# の構文を理解している必要があります。下記のような機能を持つ Web UI が使用できると理想的です。

  • Azure Active Directory による認証
  • マルチテナント化により異なるユーザーが自身のメディア サービスで使用可能
  • Azure で SaaS としてホストされ、ユーザーによるインストールとセットアップが不要

これらの機能も、近い将来に実装されることと思われます。

 

謝辞: Azure Media Services チームの多数のメンバーによる長年にわたる協力に感謝の意を表します。

Comments (0)

Skip to main content