Media Services ライブ ストリーミングのベスト プラクティス ガイド
お客様は、ライブ ストリームの待機時間を短縮する方法を尋ねることがよくあります。 この記事では、ライブ イベント エンコードに加えて、待機時間の短いライブ ストリームを実現するためのベスト プラクティスについて説明します。
手記
この記事を読み続ける前に、「低待機時間 HLS (LL-HLS) 」 記事を読み、ライブ イベント エンコードによる待機時間の短縮について理解してください。 次に、このガイドに戻って、ストリーミング待機時間に影響する可能性がある他の内容を理解してください。
メディアのエンコード方法以外に、ストリームのエンドツーエンドの待機時間を決定する要因は多数あります。 考慮すべき点を次に示します。
コントリビューション エンコーダー側の遅延。 お客様が OBS Studio、Wirecast などのエンコード ソフトウェアを使用して RTMP ライブ ストリームを Media Services に送信する場合。 このソフトウェアの設定は、ライブ ストリームのエンドツーエンドの待機時間に影響します。
Azure Media Services 内のライブ ストリーミング パイプラインの遅延
CDN のパフォーマンス
ビデオ プレーヤーのバッファリング アルゴリズムとクライアント側のネットワーク条件
プロビジョニングのタイミング
コントリビューション エンコーダー
RTMP ストリームが Media Services に到達する前に、ソース エンコーダー設定の設定を制御できます。 可能な限り短い待機時間を提供する設定の推奨事項を次に示します。
Media Services アカウントの投稿エンコーダーに最も近い物理リージョンを選択します。 これにより、Media Services アカウントに優れたネットワーク接続が確保されます。
一貫性のあるフラグメント サイズを使用します。 GOP サイズは 2 秒にすることをお勧めします。 OBS などの一部のエンコーダーの既定値は 8 秒です。 この設定は必ず変更してください。
エンコード ソフトウェアで可能な場合は、GPU エンコーダーを使用します。 これにより、CPU 作業を GPU にオフロードできます。
待機時間が短い場合に最適化されたエンコード プロファイルを使用します。 たとえば、OBS Studio では、Nvidia H.264 エンコーダーを使用すると、"待機時間ゼロ" プリセットが表示されることがあります。
ストリーミングする予定よりも解像度の高いコンテンツを送信します。 たとえば、720p 標準エンコード ライブ イベントを使用している場合は、既に 720p のストリームを送信します。
パススルー ライブ イベントを使用しない限り、フレームレートは 30fps 以下にしてください。 ライブ イベントでは 60 fps の入力をサポートしていますが、エンコード ライブ イベントの出力は 30 fps を超えていません。 低待機時間 HLSの場合は、固定フレーム レートをお勧めします。最適なエクスペリエンスを実現するには、最大フレーム期間が 0.5 秒を超えないようにしてください。
Azure Media Services ライブ イベントの構成
パイプラインの待機時間を短縮するのに役立ついくつかの構成を次に示します。
ライブ イベントには、待機時間の短いストリーム オプションを使用します。 Standard エンコード (最大 720p) および Premium エンコード (最大 1080p) ストリーム オプションの場合、DVR ウィンドウが 6 時間を超える場合やスムーズ ストリーミング出力が必要な場合を除き、低待機時間のストリーム待機時間設定を使用します。
HLS と DASH の両方の再生に CMAF 出力を選択することをお勧めします。 これにより、両方の形式で同じフラグメントを共有できます。 CDN を使用すると、キャッシュ ヒット率が増加します。 例えば：
種類 形式 URL の例 HLS CMAF format=m3u8-cmaf https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=m3u8-cmaf)CMAF の MPEG-DASH format=mpd-time-cmaf https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=mpd-time-cmaf)TS 出力を選択する必要がある場合は、HLS パッキング比率 1 を使用します。 これにより、1 つの HLS セグメントに 1 つのフラグメントのみをパックできます。 ネイティブの Apple プレーヤーで LL-HLS の利点を最大限に活用することはできません。
プレイヤーの最適化
ビデオ プレーヤーを選択して構成するときは、待機時間を短縮するために最適化された設定を使用してください。
Media Services では、DASH、TS 出力の HLS、CMAF フラグメントを使用した HLS など、さまざまなストリーミング プロトコル出力がサポートされています。
LowLatencyV2 ストリーム オプションを使用する場合は、低待機時間 HLS (LL-HLS) をサポートするプレイヤーを見つけてください。 プレイヤーの実装に応じて、バッファリングの決定はビューアーが観察する待機時間に影響します。 再生の品質と安定性を優先する不適切なネットワーク条件または既定のアルゴリズムにより、プレイヤーは再生中の中断を防ぐために、より多くのコンテンツを事前にバッファーすることを決定する可能性があります。 これらのバッファーは、再生セッションの前と実行中に、エンドツーエンドの待機時間に追加されます。
Azure Media Player を使用すると、低待機時間ヒューリスティック プロファイルにより、プレイヤー側で待ち時間が最小限になるようにプレイヤーが最適化されます。 このプレイヤーは、Apple デバイス上の Safari で使用されていない限り、DASH のみをサポートします。
CDN の選択と最適化
ストリーミング エンドポイントは、ライブ および VOD ストリーミング コンテンツを CDN または顧客に直接配信する配信元サーバーです。 メディア コンテンツのトラフィックが効率的に配信されるように、配信元がシールドされたコンテンツ配信ネットワーク (CDN) を使用することをお勧めします。
Verizon (Standard または Premium) によって提供される Azure CDN を使用することをお勧めします。 お客様が Azure portal で 1 つの選択でこの CDN を構成できるように、統合エクスペリエンスが最適化されました。 ストリーミング エンドポイント 開始するたびに、CDN エンドポイントの配信元シールドの とストリーミングの最適化を有効にしてください。
また、お客様には、独自の CDN を導入する優れたエクスペリエンスもあります。 配信元を過剰なトラフィックから保護するための対策が CDN で行われるようにします。
CDN プロファイルの規則を構成することで、パフォーマンスを向上させることもできます。 「CDN 最適化を有効にする方法」を参照してください。
ストリーミング エンドポイントのスケーリング
手記
標準ストリーミング エンドポイント/配信元 は、トラフィック量が少ないお客様が低コストでコンテンツをストリーミングできる、共有 リソースです。 大量のトラフィックが予想される場合、または CDN を使用する予定の場合は、標準ストリーミング エンドポイントを使用してストリーミング ユニットをスケーリング
同じストリーミング エンドポイントを使用して多数のライブ イベントを同時にストリーミングできますが、1 つのストリーミング エンドポイントに必要な既定のストリーミング ユニットの最大数は 10 です。 サポート チケットを開いて、既定の 10 を超える要求を行うことができます。
必要な Premium ストリーミング ユニットを決定する
必要なストリーミング エンドポイントとストリーミング ユニットの数を決定するには、次の 2 つの手順があります。
必要なエグレスの合計を決定します。
合計エグレスを 200 で除算します。これは、各ストリーミング ユニットがストリーミングできる最大 Mbps です。
必要なエグレスの合計を決定する
次の式を使用して、必要なエグレスの合計を決定します。
必要なエグレスの合計 = 平均帯域幅 x 同時ビューアー数 x ストリーミング エンドポイントによって処理割合。
次に、各乗数を見てみましょう。
平均帯域幅。 ストリーミングを計画している 平均 ビットレートは何ですか? 言い換えると、複数のビットレートを使用する場合、計画しているすべてのビットレートの平均は何ビット レートですか? これは、次のいずれかの方法を使用して見積もることができます。
エンコードを含むライブ イベント
の平均 帯域幅がわからない場合は、上位ビットレートを見積もりとして使用できます。 トップ ビットレートは 1080p でエンコードされたライブ イベントでは 5.5 Mbps であるため、平均ビットレートは 3.5 Mbps 前後になります。
ライブ イベントのエンコードに使用されるエンコード プリセット (AdaptiveStreaming(H.264) プリセットなど) を確認します。 この 出力例を参照してください。
エンコードではなくパススルーを使用するライブ イベントの場合:
- ローカル エンコーダーで使用されているエンコード ビットレート ラダーを確認します。
同時閲覧者の数。 同時閲覧者の数はどのくらいですか? これは見積もりが難しいかもしれませんが、顧客データに基づいて最善を尽くします。 世界中のユーザーに会議をストリーミングしていますか? 一連の製品を顧客に販売するためにライブ ストリームを計画していますか?
必要な Premium ストリーミング ユニットの数を決定する
Premium ストリーミング ユニットが必要 = 平均帯域幅 x 視聴者数 x CDN で処理されないトラフィックの割合 / 200 Mbps
例
最近新しい製品をリリースし、確立された顧客に提示したいと考えています。 既にビジー状態の対象ユーザーにストレスを感じさせたくないため、待機時間を短くする必要があるため、Premium ストリーミング エンドポイントと CDN を使用します。
顧客数は約 100,000 人ですが、ライブ イベントをすべて視聴するわけではありません。 最良のケースでは、そのうちの 1 つの% のみが出席し、予想される同時視聴者数が 1,000 人になると推測されます。
同時ユーザー数 =1,000
Media Services を使用してライブ ストリームをエンコードし、パススルーを使用しないことを決定しました。 平均帯域幅が何になるのかはわかりませんが、1080p (5.5 Mbps の上位 ビットレート) で配信されることがわかっているため、の平均 帯域幅は計算に 3.5 Mbps と推定されます。
平均帯域幅 =3.5
対象ユーザーは世界中に分散しているため、CDN がライブ トラフィックの大部分 (90%) を処理することが予想されます。 そのため、Premium ストリーミング エンドポイントはトラフィックの 10% のみを処理します。
ストリーミング エンドポイントによって処理される割合 =10% = 0.1
上記の数式を使用します。
必要なエグレスの合計数 = ストリーミング エンドポイントによって処理される平均帯域幅 x 同時ビューアー数 x パーセント。
必要なエグレスの合計 = 3.5 x 1,000 x 0.1
必要なエグレスの合計 = 350 Mbps
エグレスの合計を 200 で割ると、1.75 個の Premium ストリーミング ユニットが必要であると判断されます。
Premium ストリーミング ユニットが必要 = 必要なエグレスの合計/200Mpbs
Premium ストリーミング ユニットに必要な = 1.75
この数値を 2 に切り上げ、必要な 2 ユニットを提供します。
ポータルを使用してニーズを見積もる
Azure portal は、計算を簡略化するのに役立ちます。 ストリーミング ページでは、提供されている電卓を使用して、平均帯域幅、CDN ヒット率、ストリーミング ユニット数を変更したときの推定対象ユーザーのリーチを確認できます。
[Media Services アカウント] ページで、メニューから [Steaming エンドポイント
選択します。 [ストリーミング エンドポイントの追加] を選択して、新しいストリーミング エンドポイント
追加します。 ストリーミング エンドポイントに名前を付けます。
ストリーミング エンドポイント 種類 Premium ストリーミング エンドポイントを選択します。
この時点で見積もりを取得しているだけなので、作成後にストリーミング エンドポイントを開始しないでください。 [なし] を選択します。
CDN 価格レベル
Standard Verizon または Premium Verizon選択します。 プロファイル名はそれに応じて変更されます。 この演習の名前はそのままにします。 CDN プロファイルで、[新規作成]
選択します。 [
作成] を選択します。 エンドポイントがデプロイされると、ストリーミング エンドポイント画面が表示されます。 先ほど作成したストリーミング エンドポイントを選択します。 ストリーミング エンドポイント画面が表示され、対象ユーザーのリーチの見積もりが表示されます。
1 つのストリーミング ユニットがあるストリーミング エンドポイントの既定の設定では、CDN の 90% とストリーミング エンドポイントの 10% を使用して、3.5 Mbps で 571 人の同時ビューアーにストリーミングすると推定されます。
エグレス ソース の割合を CDN キャッシュから 90% から 0%に変更します。 この計算ツールでは、CDN を しなくても、200 Mbps
で 3.5 Mbps で 57 人の同時ビューアーにストリーミングできると推定されます。 次に、エグレス ソース を 90%に戻します。
次に、ストリーミング ユニットの を 2 に変更します。 この計算ツールは、3.5 Mbps で 1143 人の同時ビューアーにストリーミングでき、4,000Mpbs で CDN がトラフィックの 90% を処理できることを推定します。
[保存]を選択します。
ストリーミング エンドポイントを開始し、トラフィックの送信を試みることができます。 画面の下部にあるメトリックは、実際のトラフィックを追跡します。
タイミング
ストリーミング ユニットの準備が整うように、予想されるピーク時の使用量の 1 時間前にストリーミング ユニットをプロビジョニングできます。
ヘルプとサポートを受ける
Media Services に質問がある場合は、次のいずれかの方法で更新プログラムに従ってください。
- Q & A
-
Stack Overflow。
azure-media-servicesで質問にタグを付け. - @MSFTAzureMedia または @AzureSupport を使用してサポートを要求します。
- Azure portal からサポート チケットを開きます。