Media Services ライブ ストリーミングのベスト プラクティス ガイド

  • [アーティクル]

ライブ ストリームの待機時間を短くする方法について問い合わせを受けることがよくあります。 この記事では、ライブ イベント エンコードに加えて、 を使用して、待機時間の短いライブ ストリームを実現するためのベスト プラクティスについて説明します。

注意

この記事を読み続ける前に、「 低待機時間 HLS (LL-HLS)」 の記事を参照して、ライブ イベント エンコードによる待機時間の短縮を理解してください。 次に、このガイドに戻って、ストリーミングの待機時間に影響を与える可能性がある他の内容を理解します。

メディアのエンコード方法以外にも、ストリームのエンドツーエンドの待機時間を決定する要因は多数あります。 考慮すべきこととして以下のことがあります:

  1. コントリビューション エンコーダー側での遅延。 お客様が OBSStudio、Wirecast などのエンコード ソフトウェアを使用して、Media Services に RTMP ライブ ストリームを送信する場合に発生します。 このソフトウェアの設定は、ライブ ストリームのエンドツーエンドの待機時間に影響を与えます。

  2. Azure Media Services 内のライブ ストリーミング パイプラインの遅延

  3. CDN パフォーマンス

  4. ビデオ プレーヤーのバッファリング アルゴリズムとクライアント側のネットワーク条件

  5. プロビジョニングのタイミング

コントリビューション エンコーダー

RTMP ストリームが Media Services に到達する前にソース エンコーダーの設定を管理できます。 以下、できるだけ待機時間が短くなるように設定するための推奨事項を示します:

  1. Media Services アカウントのコントリビューション エンコーダーに最も近い物理リージョンを選択します。 これにより、Media Services アカウントへの優れたネットワーク接続を確保できます。

  2. 正しいフラグメント サイズを使用します。 2 秒の長さとなる GOP が推奨値です。 OBS などの一部のエンコーダーのデフォルト値は 8 秒です。 この設定は必ず変更してください。

  3. エンコード ソフトウェアが許可する場合は、GPU エンコーダーを使います。 これにより、CPU の作業を GPU にオフロードできます。

  4. 低遅延用に最適化されたエンコード プロファイルを使います。 たとえば、OBS Studio で、Nvidia H.264 エンコーダーを使用すると、「ゼロ待機時間」プリセットが表示される場合があります。

  5. ストリーミングしたいものと同じまたはそれ以下の解像度を持つコンテンツを送信します。 たとえば、720 p 標準エンコード ライブ イベントを使っている場合は、720 p のストリームを送信します。

  6. パススルー ライブ イベントを使う場合を除き、フレームレートは 30 fps 以下にしてください。 ライブ イベントへの入力は 60 fps をサポートしていますが、エンコード ライブ イベントの出力はまだ 30 fps より高くはなっていません。 低待機時間 HLS の場合は、固定フレーム レートをお勧めします。最適なエクスペリエンスを得るには、最大フレーム期間が 0.5 秒を超えないようにしてください。

Azure Media Services ライブ イベントの設定

以下、パイプラインの待機時間の短縮の手助けとなる設定を示します:

  1. ライブ イベントには、待機時間の短いストリーム オプションを使用します。 Standard エンコード (最大 720p) および Premium エンコード (最大 1080p) ストリーム オプションの場合は、DVR ウィンドウが 6 時間を超える場合やスムーズなストリーミング出力が必要な場合を除き、[待機時間の短いストリーム待機時間] 設定を使用します。

  2. 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)
    MPEG-DASH CMAF format=mpd-time-cmaf https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=mpd-time-cmaf)

  3. 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 (標準またはプレミアム) によって提供される Azure CDN を使うことをお勧めします。 Azure portal で 1 つの選択で CDN を設定できるように、統合エクスペリエンスを最適化しました。 ストリーミング エンドポイントを開始するたびに、CDN エンドポイントの 配信元シールド とストリーミングの最適化を有効にしてください。

ユーザーもまた独自の CDN を持ち、良いエクスペリエンスを持っています。 過剰なトラフィックから配信元をシールドするための対策が確実に CDN で施されるようにしてください。

CDN プロファイルの規則を構成することで、パフォーマンスを向上させることもできます。 CDN の最適化を有効にする方法に関するページを参照してください。

ストリーミング エンドポイントのスケーリング

注意

標準ストリーミング エンドポイント/配信元は、トラフィック量が少ないお客様が低コストでコンテンツをストリーミングできるようにする共有リソースです。 大量のトラフィックが予想される場合、または CDN を使う予定がある場合は、ストリーミング ユニットのスケーリングのために標準ストリーミング エンドポイントは使わないでしょう。

プレミアム ストリーミング エンドポイント/配信元は、専用のストリーミング ユニットを追加または削除することにより、お客様がスケーリングするためのより高い柔軟性と分離性を提供します。 ストリーミング ユニットは、ストリーミング エンドポイントに割り当てられるコンピューティング リソースです。 各ストリーミング ユニットは、約 200 Mbps のトラフィックをストリーミングできます。

同じストリーミング エンドポイントを使用して一度に多数のライブ イベントを同時にストリーミングすることができますが、1 つのストリーミング エンドポイントに必要となるデフォルトでのストリーミング ユニットの最大数は 10 です。 サポート チケットを開いて、デフォルト値である 10 よりも多くのストリーミング ユニットを要求できます。

必要なプレミアム ストリーミング ユニットを決定する

必要なストリーミング エンドポイントとストリーミング ユニットの数を決定するには、次の 2 つの手順があります:

  1. 必要となるエグレスの総数を決定します。

  2. エグレスの総数を 200 で割ります。これは、各ストリーミング ユニットがストリーミングできる最大のデータ伝送速度 (Mbps) です。

必要となるエグレスの総数を決定する

次の数式を用いて、必要となるエグレスの総数を決定します。

必要となるエグレスの総数 = 平均帯域幅 x 同時に視聴する人の数 x ストリーミング エンドポイントによって処理される割合 (パーセント)。

それぞれの乗数を順番に見てみましょう:

平均帯域幅。 ストリーミングを予定している平均のビットレートはいくつになりますか? 別の言い方をすると、複数のビットレートを使える場合、予定しているすべてのビットレートの平均値はいくつになりますか? これは、次のいずれかの方法により計算できます:

エンコードを含むライブイベントの場合:

  • 平均帯域幅がどのような値になるか分からない場合は、最も高いビットレートを見積もり値として使うことができます。 1080 p でエンコードされたライブ イベントの場合の最大のビットレートは 5.5 Mbps です。したがって、ビットレートの平均値は約 3.5 Mbps となります。

  • ライブ イベントのエンコードに使用されるエンコード プリセット (AdaptiveStreaming (H.264) プリセットなど) を確認します。 この出力例をご覧ください。

エンコードではなくパススルーを使うだけのライブイベントの場合:

  • ローカル エンコーダーで使われるエンコード ビットレート ラダーを確認します。

同時視聴者の数。 同時視聴者の数は何人になると予想されますか? この見積もりは難しいかもしれませんが、顧客データに基づいて最善を尽くしてください。 世界中の視聴者に会議をストリーミングしますか? 一連の製品を顧客に販売するためにライブ ストリームをおこなう計画がありますか?

ストリーミング エンドポイントによって処理されるトラフィックの割合。これは、実際に数式に入る数であるため、「CDN によって処理されないトラフィックの割合」として表される場合があります。 では、このことを念頭に置いて、CDN オフロードはどれぐらいだと予想されますか? CDN がライブ トラフィックの 90% を処理すると予想される場合、そのトラフィックのわずか 10% がストリーミング エンドポイントにあると予想されます。 数式で使用される数は .10 です。これは、ストリーミング エンドポイントにあると予想されるトラフィックの割合です。

必要となるプレミアム ストリーミング ユニットの数を決定する

必要となるプレミアム ストリーミング ユニット = 平均帯域幅 x 視聴者の数 x CDN によって処理されないトラフィックの割合 / 200 Mbps

例

最近新しい製品を発売し、既存の顧客に提示したいとします。 既に忙しい顧客を苛立たせたくないので待機時間を短くしたいです。そこで、プレミアム ストリーミング エンドポイントと CDN を使います。

約 10 万人の顧客がいますが、おそらくすべての顧客がライブ イベントを見るわけではありません。 最高の状態でも参加するのは 1% だけだと予想します。すると、同時視聴者は 1000 人となります。

同時視聴者数 =1,000

ライブストリームをエンコードするために Media Services を使い、パススルーは使わないことにしました。 平均帯域幅がどのようになるかはわかりませんが、1080 p (最大で 5.5 Mbps の ビットレート) で提供されることがわかっているので、平均帯域幅は計算により 3.5 Mbps と予想されます。

平均帯域幅 = 3.5

視聴者は世界中に分散しているため、CDN がライブトラフィックのほとんど (90%) を処理すると予想されます。 そのため、premium ストリーミング エンドポイントはトラフィックの 10% のみを処理します。

ストリーミング エンドポイントによって処理される割合 = 10% = 0.1

上に示した数式を使います:

必要となるエグレスの総数 = 平均帯域幅 x 同時に視聴する人の数 x ストリーミング エンドポイントによって処理される割合 (パーセント)。

必要とされるエグレスの総数 = 3.5 x 1000 x 0.1

必要とされるエグレスの総数 = 350 Mbps

エグレスの総数を 200 で割ると、1.75 プレミアム ストリーミング ユニットが必要になると決定します。

必要とされるプレミアム ストリーミング ユニット = 必要とされるエグレスの総数/200 Mbps

必要とされるプレミアム ストリーミング ユニット = 1.75

この数を切り上げると 2 になり、2 つのユニットが必要となります。

ポータルを使ってニーズを見積もる

Azure portal は、計算を簡略化するのに役立ちます。 ストリーミングのページでは、平均的な帯域幅、CDN ヒット率、およびストリーミング ユニットの数を変更した場合に、与えられた計算ツールによって、視聴者にどれぐらい伝わるかを見積もることができます。

  1. Media services のアカウント ページで、メニューから [ストリーミング エンドポイント] を選びます。

  2. [ストリーミング エンドポイントの追加] を選び、新しいストリーミング エンドポイントを追加します。

  3. ストリーミング エンドポイントに名前をつけます。

  4. ストリーミング エンドポイントの種類として [プレミアムストリーミング エンドポイント] を選びます。

  5. この時点では推定値を取得しただけにすぎないため、ストリーミング エンドポイントを作った後も開始しないでください。 このため、 [いいえ] を選択します。

  6. CDN 価格レベルとして標準 Verizon またはプレミアム Verizon を選びます。 プロファイル名はそれに応じて変更されます。 この演習では名前はそのままにしておきます。

  7. CDN プロファイルの場合は、[新規作成] を選びます。

  8. ［作成］ を選択します エンドポイントが配置されると、ストリーミング エンドポイント画面が表示されます。

  9. 作成したストリーミング エンドポイントを選びます。 ストリーミング エンドポイント画面が、視聴者への伝わり具合の予測値とともに表示されます。

  10. 1 つのストリーミング ユニットを持つストリーミング エンドポイントのデフォルトの設定は、CDN の 90% とストリーミングエンドポイントの 10% を使って、571 人の同時視聴者に 3.5 Mbps でストリーミングすると予想されることを示しています。

  11. [エグレス ソース]の割合を「CDN キャッシュから 90%」から「0%」に変更します。 計算ツールは、CDN を使用しない場合には 200 Mbps で伝送できる条件下で、3.5 Mbps で 57 人の同時視聴者にストリーミングできることを見積もります。

  12. ここでエグレス ソースを 90% に戻します。

  13. 次に、ストリーミング ユニットを 2 に変更します。 計算ツールは、トラフィックの 90% を CDN がハンドリングする場合に 4000 Mbps で伝送できる条件下で、3.5 Mbps で 1143 人の同時視聴者にストリーミングできることを見積もります。

  14. [保存] を選択します。

  15. ストリーミング エンドポイントを開始して、そのエンドポイントへのトラフィックの送信を試みることができます。 画面の下部にあるメトリックは、実際のトラフィックをトラックします。

タイミング

ストリーミング ユニットの準備ができていることを確認するために、予想されるピーク時の使用量の 1 時間前にストリーミング ユニットをプロビジョニングできます。

ヘルプとサポート

質問がある場合は Media Services に問い合わせるか、次のいずれかの方法で更新内容に従ってください。