サポートに連絡する| システムステータス
ページコンテンツ

    ブライトコーブライブ:ベストプラクティス

    Video Cloud Live を使用すると、ライブイベントを簡単にセットアップし、ウェブ、iOS、Android デバイスにマルチビットレートストリームを配信できます。このトピックでは、高品質で安定したライブストリーミング体験を実現するための一連のベストプラクティスと推奨事項について概説します。

    概要

    ブライトコーブライブは、ライブストリーミングイベントや 24 時間 365 日のライブストリームを作成するための堅牢なサービスを提供します。このガイドでは、ライブ配信を最適化するためのベストプラクティスを概説します

    コンテンツコンテキスト

    ストリーミングされるコンテンツのタイプは、入力の品質を維持するために必要な設定に影響を与えるため、考慮する必要があります。トレードオフがあり、可能な限り高い設定を使用すると、フレームがスキップされるなどの問題が発生する可能性があることに注意してください。

    以下の情報に基づいて、ライブイベントの前に、品質とパフォーマンスについてさまざまな設定の組み合わせをテストすることをお勧めします。

    次の表に、主要な入力パラメーターの概要を示します。

    ライブストリーミングの主要な入力パラメータ
    パラメーター
    入力ビットレート エンコーダが送信するビットレート。レートが高いほどネットワーク損失の影響を受けやすいため、できるだけ低く抑える必要があります。
    入力解像度 これはソースコンテンツと一致する必要があります。これを元のソースより大きくすることに利点はなく、この値が高いほど、それをサポートするために必要なビットレートが高くなります。
    トッププロファイルに対するビットレートの比率を入力します 入力ビットレートはトッププロファイルのレートよりも高くする必要がありますが、高すぎるとフレームのドロップやその他の問題が発生する可能性があります。たとえば、トップレートが1080p 30fpsの場合、入力は理想的には約4MBPSである必要があります。これはプロファイルの影響を受けることに注意してください。一般的に、入力ビットレートは、ライブレンディションの最高ビットレートの 2 倍(2 倍)にすることをお勧めします。

    高いビットレートのトップ出力が必要な場合は、 copy_video設定をテストする価値があります。これにより、入力エンコードを出力にコピーするだけです。

    プロファイル さまざまなプロファイル(ベースライン、メイン、高)は、データを昇順で圧縮します(ベースライン:最低、最高:最高)。圧縮率を上げると、伝送速度が向上しますが、データをデコードするためにより多くのCPUリソースが必要になります。エンコーダーが利用可能なリソースに高度に制約されていない限り、ベースラインプロファイルは避ける必要があります。一方、高ビットレートでハイプロファイルを使用すると、必要なデコードCPUリソースが増えるため、フレームがスキップされる可能性が高くなります。

    こちらもご覧くださいGOP構造未満。

    フレームレート これはソースと一致する必要があります。

    レートが高くなると、それに比例して高い入力ビットレートが必要になります。たとえば、アクションスポーツコンテンツの場合、60fpsの入力ストリームは30fpsのストリームよりも大幅に多くのデータを伝送します。

    60 fpsなどの高レートでは、高ビットレートの複雑なコンテンツでフレームスキップの問題が発生する可能性が高くなります。

    キーフレームレート このための最も効率的な設定は、セグメント期間xフレームレートです。たとえば、6秒のセグメントと30 fpsがある場合、キーフレームレートを180(6x30)にすると、デコーダーの負荷が最小になります。

    ただし、変動を考慮して、これはフレームレートの2倍に設定されます。たとえば、30fpsのフレームレートの場合は60に設定されます。

    GOP構造 見るGOP構造未満。

    入力制限

    最高品質で一貫したストリーミング体験を実現するために、Brightcoveライブでは入力ストリーム設定を以下の項目に制限しています。

    • プロトコル: rtmprtprtp-fec、またはsrt(ただしrtmp、すべてMPEG2-TS入力用です)[1-1]
    • 解像度:最大1920x1080
    • 最大30fps、これは典型的です。ブライトコーブは最大 60 fps をサポートしますが、制限を増やすにはブライトコーブのサポートに連絡する必要があります。60fps を使用する場合、ブライトコーブでは、コンテンツの画質と一定のフレームレートを実現するために、ビットレートを上げることをお勧めします。
    • 10Mbps未満
    • 一定ビットレート(CBR)は、問題の発生可能性を大幅に低減
    • ビデオコーデックはH.264である必要があります
    • スライス:エンコーダにこのオプションがある場合は、 1 に設定します。
    • オーディオコーデックはAAC
    • オーディオサンプリングレート:44.1khz と 48khz は、推奨されるサンプルオーディオレートです。
    • キーフレームレートまたは GOP (ピクチャのグループ) の位置合わせ:
      1. キーフレームは、入力と出力(25fps ビデオを含む)の両方で常に 2 秒ごとに発生する必要があります。つまり、ストリーム自体の 2 秒ごとにキーフレームがエンコーダから Brightcove に送信されます。このプロセスはさまざまな方法で定義できますが、最も一般的なのはキーフレームレート
      2. これは、異なるエンコーダによって異なる方法で計算することができます。例:
        • Wirecast は通過するフレームの量を使用するため、30 fps のビデオの場合、設定は 60 になります。
        • エレメントエンコーダは、正しい設定が '2' になるように、秒を使用します。
        • 60 FPS ビデオは、この設定がフレームでカウントされる場合にのみ変更されます。この場合、120 フレームごとに 2 秒になります。
    • オプションがある場合キーフレームの位置合わせ同期GOPキーフレームを揃える、またはそれらの線に沿った何かで、キーフレームが整列していることを確認してください。キーフレームが揃っていないと、HLS セグメンテーションで同期の問題が発生します。

    • [1-1] TS入力に複数のビデオ/オーディオトラックがある場合は、それぞれについて最初のトラックを選択します。また、インターネット経由の UDP 上のプレーンなTSは非常に信頼できないため、FEC を使用することを強くお勧めします。FECの場合、 小さい 行/列に使用する値ほど、エラー訂正の信頼性が高くなります(帯域幅が増加しますが)。

    ストリーミングに関する重要な問題

    エンコーダーからBrightcoveへのストリーミングエクスペリエンスの問題に関連して、一般的に発生するいくつかの問題があります。

    1. 入力に影響を与えるネットワークの不安定性:
      1. インターネットは一般的に非常に信頼性がありますが、間違いはなく、問題は発生します。ビットレートが高いほど、問題が発生する可能性が高くなります。
      2. ビデオのアップロードにリアルタイムよりも時間がかかる場合、入力ドリフトが発生する可能性があります(ビデオの受信時間は送信時よりも大幅に遅くなります)
    2. トランスコーダーの過負荷によりフレームがスキップされる:トランスコーダーに十分なオーバーヘッドがあることを確認するためにあらゆることを行っていますが、コンテンツの複雑さが突然急上昇したり、ネットワークの一時的な中断やトランスコーダーへのその他の中断によってフレームがスキップされたりすることがあります。入力が複雑になるほど、スキップされたフレームが発生する可能性が高くなります。また、静止画像から5分以上の長時間の変更や、アクションコンテンツの突然の変更により、過負荷が発生する可能性があるという既知の問題もあります。
    3. 可変フレーム期間を送信するエンコーダー:フレームレートは一定である必要があり、一定のキーフレーム間隔を許容するようなものである必要があります。たとえば、29.97別名30000/1001または23.976別名24000/1001などのフレームレートの場合、一定の間隔でキーフレームを設定することはできないため、避ける必要があります。
    4. 一定の期間間隔ではないキーフレームを送信するエンコーダーの場合、キーフレームレートは、秒単位のフレームレートの2倍以上である必要があります。たとえば、30fps のフレームレートの場合、キーフレーム間隔は 60 フレーム(2 秒)で、セグメントごとに最大間隔を 1 回にする必要があります。たとえば、6 秒のセグメントがある場合、最大間隔は 30 fps で 180 フレームになります。

    コンテンツタイプ

    一般に、より複雑なコンテンツでは、これらの設定のうち高い方を使用する必要があるため、フレームがスキップされる可能性が高くなります。以下の表は、複雑な順にいくつかの例を示しています。これらは単なる例であり、ほぼすべてのエンコーダ設定が異なることに注意してください。テストと検証を実行する必要があります。

    コンテンツタイプの例
    コンテンツタイプ 設定例
    ウェブカメラ
    • 解像度:360p
    • ビットレート:1 MBPS
    • プロフィール:ベースライン
    Web会議
    • 解像度:480p
    • ビットレート:2.5 MBPS
    • プロフィール:主要
    アニメーション
    • 解像度:720p
    • ビットレート:2.5 MBPS
    • プロフィール:主要
    トーキングヘッド/ニュース
    • 解像度:720p
    • ビットレート:4 MBPS
    • プロフィール:主要
    ライブコンサート
    • 解像度:1080p(またはソース)
    • ビットレート:5 MBPS
    • プロフィール:高い
    ライブスポーツ
    • 解像度:1080p(またはソース)
    • ビットレート:6 MBPS
    • プロフィール:高い
    ライブスポーツ高FPS
    • 解像度:1080p(またはソース)
    • ビットレート:10 MBPS
    • プロフィール:高い

    検証とテスト

    理想的には、最も複雑な(最も変化するコンテンツ)で可能な限り低い設定から始めて、出力が受け入れられるまでさまざまな設定を増やして、コンテンツでテストする必要があります。これは、一般に設定が高いほど、ネットワークまたはトランスコーディングのいずれかで問題が発生する可能性が高くなるためです。

    帯域幅のテスト

    入力ストリームの適切な設定に到達するための最初のステップは、サイト上で利用可能な帯域幅を決定することです。役立つツールはいくつかあります。

    • Speedof.me ( http://speedof.me )-HTTP 接続で使用可能な総帯域幅の決定は、最初のステップとして適しています。ただし、入力フィードは HTTP ではなく RTMP 経由で Live モジュールにストリーミングされるため、RTMP 接続で使用できる実際の帯域幅は大幅に小さくなります。
    • Speedtest ( http://www.speedtest.net )-現在のアップロードおよびダウンロード速度を決定するためのオンラインツール。

    入力帯域幅

    高品質で安定した入力ストリームを提供することは、視聴者に最高のユーザーエクスペリエンスを提供するための唯一の方法です。良好な入力ストリームは、ある場所から一貫して利用可能な帯域幅で最高のビデオ品質を提供します。

    • 最小入力帯域幅:2.5メガビット/秒
    • 最大入力帯域幅:10 mbps

    エンコーダー機能の決定

    ライブストリームをエンコードしてライブモジュールに送信するために使用されるソフトウェアとハードウェアの機能を理解することも重要です。高品質の1080pの入力ストリームを送信するには多くのビットレートがありますが、ハードウェアはリアルタイムよりも速い速度でエンコードできる必要があります。エンコードツールの中には、使用中の CPU 使用率と帯域幅の合計に関する情報を表示するものがあります。たとえば、Telestream Wirecast では、出力統計がページの上部に表示されます。この情報は、特定のハードウェア上で可能な最も安定した、最高品質のストリームを判断するときに役立ちます。

    Wirecastで確認する項目は次のとおりです。

    • CPUは80%未満でなければなりません
    • データレートはターゲットビットレートの近くになければなりません
    • FPSが入力ストリーム設定のレートであること

    GOP構造

    ビデオのGroupof Pictures(GOP)構造は、最初に次のように使用されるプロファイルに依存します。

    1. ベースラインプロファイルは、I フレームと P フレームと CAVLC エントロピーエンコーディングのみをサポートします。
    2. メインおよびハイサポート I、B、P フレームおよび CABAC エントロピーエンコード

    メインプロファイルとハイプロファイルは、一般に、より良い品質でより良い圧縮をもたらしますが、スキップされたフレームの影響を受けやすくなるため、エンコードとデコードに追加の計算も必要になります。さらに、これらのプロファイルはB(双方向)フレームを使用するため、エンコードプロセスにいくらかの遅延が発生します。

    ベースラインプロファイルは、エンコードとデコードに必要なCPUが少なくて済みますが、圧縮が少ないため、品質を維持するために必要なビットレートが高くなり、ネットワークの問題の影響を受けやすくなります。

    フレームタイプとパフォーマンスへの影響の可能性に関する注意:

    1. Iフレーム:最も多くの帯域幅を使用します。完全なシーンの変更またはセグメントの境界で追加するのが最適です。つまり、コンテンツが変更されるほど、必要なものが多くなります(GOPの長さが短くなります)。
    2. Pフレーム:Iフレーム間の基本単位です
    3. Bフレーム:前のフレームと将来のフレームの両方を使用すると、追加するほど圧縮率は高くなりますが、CPUとレイテンシーは高くなります

    Iフレームの使用は、セグメントの開始点 (パススルーを使用する場合は重要) またはシーンの変更に限定することが理想的です。すべてまたは多数のIフレームは、フレームのスキップにつながる過剰な負荷を引き起こす可能性があるため、避ける必要があります。

    その他の注意事項:

    • キーフレームの密な配置を防ぐためのオプションを使用します (例: min_keyin = 3+)。
    • キーフレームの挿入の定期的なリズムを保証するオプションを使用します。たとえば、GOPの長さを秒単位で指定する代わりに、正確な分数またはフレームで指定します。

    ビットレート

    • 最小入力帯域幅:2.5メガビット/秒
    • 最大入力帯域幅:10 mbps
    • max_bitrate = 1.1 * ターゲットビットレートで、ストリームを「ほぼ CBR」にします。
    • 可能な場合は、厳密なHRD準拠のレート制御モードを使用します。

    プロトコル

    インターネットは保証された配信ネットワークではないことに注意することが重要です。インターネット接続は「良好」と見なされる場合もありますが、高品質で信頼性の高いライブビデオストリーミングには不十分な場合があります。ISPでの少量の輻輳、ルーター間の計画外のフェイルオーバー、または同様の問題など、カスタマーエンコーダーとBrightcoveトランスコーディングプラットフォーム間のパスの小さな中断は、ビデオ出力の中断を引き起こす可能性があります。ハイステークスのライブブロードキャストでは、専用ファイバー、予約済み衛星帯域幅、または管理対象ネットワーク上のコミット済み帯域幅のいずれかで構成される複数の専用ネットワークを使用するのが通常の方法です。これにはかなりのコストがかかり、ほとんどの場合、インターネットを介して十分な成果を上げることができます。ただし、障害のないトランスポートを維持することが重要な場合は、AWS DirectConnectまたはある程度の専用帯域幅を提供できるISPを検討してください。

    私たちが推奨するオプションは(順番に):

    1. SRT -トランスポート速度(UDP)と、ある程度の制御およびエラー回復力の適切な組み合わせを提供します。すべてのエンコーダで使用できるわけではありません。ただし、srt-transmit などのローカル RTP から変換できるツールもあります。
    2. RTMP --TCPベースであるため、優れたレベルのエラー回復力が提供されます。欠点は、これにはかなりのオーバーヘッドが伴うことです。複数のオーディオトラックなどのすべての機能がRTMPで使用できるわけではないことに注意してください。
    3. RTP-FEC -エラー回復力を備えた高速UDPベースのトランスポートを提供します
    4. RTP -エラー回復力のない高速転送と高度な機能を提供します

    サポートされているエンコーダ

    見るライブイベントでサポートされているエンコーダー Liveで動作することがわかっているエンコーダーのリストについては。他のエンコーダも動作しますが、テストされていないことに注意してください。

    サポートされている CDN

    • アカマイ
    • Amazon CloudFront

    再試行

    エンコーダからの RTMP 接続の再試行をイネーブルにすることを推奨します。5 秒の再試行間隔での再試行回数が多くなると、エンコーダとエントリポイント間の断続的な接続の問題が軽減されます。

    ジョブ設定(Live APIのみ)

    推奨ジョブ設定

    ジョブ設定
    フィールド 推奨値
    ad_audio_loudness_level -23 (EBU R.128規格)

    スレートソースファイルの推奨事項

    • 解決策:(エンコーディングラダーで最高)
    • FPS : (お前のソースと同じ)
    • ビットレート:(あなたのエンコーディングラダーで最高)
    • オーディオ:(最適なレンディションと同じビットレート、チャンネル、サンプリング周波数、およびサンプルあたりのビット数、または入力と同じ)

    推奨を出力する

    以下は推奨出力設定ですが、多くのエンコーダでは、RTMP入力は10MBPS(ビデオ+オーディオ)、フレームレートは30fpsに制限されています。

    出力に関する推奨事項
    アイテム 推奨事項
    ビデオコーデック h264現在、唯一の選択肢です
    オーディオコーデック aac現在、唯一の選択肢です
    widthheightまたはが指定されていない場合は、ソースディメンションが使用されます。widthheightまたはが指定されている場合、ソースのアスペクト比を維持するためにもう一方の寸法が計算されます。
    高さ widthheightまたはが指定されていない場合は、ソースディメンションが使用されます。widthheightまたはが指定されている場合、ソースのアスペクト比を維持するためにもう一方の寸法が計算されます。
    ビットレート 入力ビットレート以下(最良の結果を得るには、最高出力ビットレートは入力ビットレートの半分である必要があります)
    キーフレームレート 2秒

    よくある質問

    ライブジョブを作成した後、ストリーミングを開始する必要があるのはどれくらいですか?
    ブライトコーブライブでは、waiting ステートがからに移行する条件は次の 2 つありますfinishing
    1. ジョブが待機状態(まだ開始されていない)で、max_waiting_time_msが経過した場合、ジョブは終了/非アクティブになります。
    2. ジョブが切断状態(開始済みだが切断)で、reconnect_timeが経過した場合、ジョブは終了/非アクティブになります。

    event_length が 30 分を超えると、ジョブは 30 分で終了します。がevent_length 30 分未満の場合、ジョブはで終了しますevent_length

    たとえば、がevent_length 60 分の場合、ライブジョブは 30 分で終了します。event_length が 15 分の場合、ライブジョブは 15 分で終了します。

    reconnect_time は、待機状態には影響しません。

    同時ライブ job_settings の制限は何ですか?

    アクティブな待機中、開始されていないジョブはいつでも最大 5 つまで許可されます。

    同時ジョブの追加制限:

    • channel (24 時間 365 日) ジョブの数は、リージョンごとに 0 または少ない数に制限されます (アカウントの種類によって異なります)。
    • event同時に実行されるジョブの数は、リージョンによって制限され、通常は 100 になります。
    • eventジョブの同時接続待ちの数は 5 に制限されています。
    • リージョンごとの SEP ジョブ数は 3 または 10 に制限されています(「サポートされている AWS リージョン」を参照)。

    これらの制限は、サポートがアカウントレベルで調整できます。追加の容量が必要な場合は、アカウントマネージャーにお問い合わせください。

    入力帯域幅が十分であれば、ブライトコーブライブは 1080p 品質をプッシュできますか?
    はい、1080p 入力はすべてのアカウントで有効です。
    DRMは利用可能ですか?
    はい!ライブアカウントに DRM サポートを追加する場合は、アカウントマネージャーにお問い合わせください。

    さらにサポートが必要な場合

    ライブイベントを機能させるのにさらにサポートが必要な場合は、お問い合わせください。可能な限り迅速に回答を得るために、問題を解決するためにブライトコーブサポートが必要なものを以下に示します。

    • ストリームに発生している特定の症状。例えば、それはまったく再生されないのですか、それとも吃音またはフリーズしますか?
    • このストリームが過去に正常に機能したかどうか
    • エンコーダで使用しているエントリポイント URL
    • 使用しているエンコーディングソフトウェアとハードウェア
    • ライブイベントを公開したプレイヤーの URL
    • Video Cloud Studio のライブアセットのビデオ ID
    • エンコーダからパブリッシュポイントホストへのトレースルートの結果

    ページの最終更新日30 Sep 2021