/* */  製品の更新 | | サポート問い合わせ先 | | システムステータス
Page Contents

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

    VideoCloudLiveを使用すると、ライブイベントを簡単に設定でき、Web、iOS、およびAndroidデバイスにマルチビットレートストリームを配信できます。このトピックでは、高品質で安定したライブストリーミングエクスペリエンスを実現するために役立つ一連のベストプラクティスと推奨事項の概要を説明します。

    概要

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

    コンテンツコンテキスト

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

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

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

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

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

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

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

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

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

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

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

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

    GOP構造 見るGOP構造下。

    入力制限

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

    • プロトコル: rtmp rtp rtp-fec 、 またsrt (除くすべてrtmpは MPEG2-TS 入力用です) [1-1]
    • 解像度:最大1920x1080
    • 最大30fps、これは典型的です。Brightcove は最大 60 fps をサポートしますが、ブライトコーブ サポートへのお問い合わせ上限を引き上げます。60 fpsを使用する場合、Brightcoveは、コンテンツに必要な視覚品質と一定のフレームレートを実現するために、ビットレートを上げることをお勧めします。
    • 10 Mbps未満
    • 一定ビットレート(CBR)は、問題の発生可能性を大幅に低減
    • ビデオコーデックはH.264である必要があります。
    • スライス:エンコーダーにこのオプションがある場合は、次のように設定します。 1
    • オーディオコーデックはAAC
    • オーディオサンプリングレート:44.1khz と 48khz は、推奨されるサンプルオーディオレートです。
    • キーフレームレートまたは GOP (ピクチャのグループ) の位置合わせ:
      1. キーフレーム常に 2 秒ごとに発生する必要があります入力と出力の両方に対応 (25fps ビデオを含む) .つまり、ストリーム自体の 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分以上の長時間(例えば、5分以上)の変更や、アクションコンテンツへの突然の変更によって過負荷が発生することがあるという既知の問題もあります。
    3. 可変フレーム期間を送信するエンコーダ:フレームレートは一定である必要があり、一定のキーフレーム間隔を許容する必要があります。たとえば、29.97aka30000/1001や23.976aka24000/1001のようなフレームレートでは、キーフレームを一定の間隔で設定することはできません。そのような場合は避ける必要があります。
    4. 一貫した持続時間間隔でないキーフレームを送信するエンコーダ。キーフレームレートは、フレームレートの2倍(秒単位)以上にする必要があります。たとえば、フレームレートが30fpsの場合、キーフレーム間隔は2秒で、セグメントごとに1回の最大間隔である60フレームにする必要があります。たとえば、6秒のセグメントがある場合、最大間隔は30fpsで180フレームになります。

    コンテンツタイプ

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

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

    検証とテスト

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

    帯域幅のテスト

    入力ストリームの適切な設定を見つける第一歩は、現場で利用可能な帯域幅を特定することです。次のようなツールが役立ちます。

    • SpeedOf.Me ( http://speedof.me ) - HTTP 接続に使用できる合計帯域幅を決定することは、最初の適切なステップです。しかし、入力フィードはHTTPではなく、RTMPでLiveモジュールにストリーミングされるため、RTMP接続で利用可能な実際の帯域幅は相当少なくなります。
    • スピードテスト ( http://www.speedtest.net ) - 現在のアップロード速度とダウンロード速度を判断するためのオンライン ツール。

    入力帯域幅

    視聴者に最高のユーザー視聴エクスペリエンスを提供する唯一確実な方法は、高品質で安定した入力ストリームを提供することです。品質の高い入力ストリームを提供することで、特定の場所から一貫して利用可能な最大帯域幅で最高の動画品質を実現できます。

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

    エンコーダー機能の決定

    ライブストリームをエンコードし、Liveモジュールに送信するソフトウェアおよびハードウェアの機能について理解することも重要です。高品質な1080p入力ストリームの送信に十分なビットレートが確保できでも、ハードウェアがエンコードを行うにはリアルタイムよりも速い速度が必要です。一部のエンコーディングツールでは、合計CPU使用率および使用帯域幅に関する情報が表示されます。たとえば、TelestreamWirecastでは、[Wirecast]ウィンドウの下部に出力統計情報が表示されます。

    この情報は、特定のハードウェア上で可能な最も安定した、最高品質のストリームを判断するときに役立ちます。Wirecastで確認する項目は次のとおりです。

    • CPU使用率が80%未満であること
    • データレートが目標ビットレートに近いこと
    • FPSが入力ストリーム設定のレートであること

    GOP構造

    ビデオのGroupofPictures(GOP;グループオブピクチャ)構造は、最初に次のように使用されるプロファイルに依存します。

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

    通常、メインプロファイルとハイプロファイルは、より高品質の圧縮を実現しますが、エンコードとデコードには追加の計算が必要です。そのため、スキップされたフレームの影響を受けやすくなります。さらに、これらのプロファイルではB(双方向)フレームが使用されるため、符号化プロセスに多少の遅延が生じます。

    ベースラインプロファイルでは、符号化およびデコードに必要なCPUの数が少なくなりますが、圧縮機能が少ないため、品質を維持するために高いビットレートが必要になるため、ネットワークの問題により影響されやすくなります。

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

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

    の用法I フレーム理想的には、セグメントの開始 (パススルーを使用する場合は重要) またはシーンの変更に制限する必要があります。Iフレームの数が多い場合は、過剰な負荷が発生してフレームがスキップされる可能性があるため、すべてのIフレームを避ける必要があります。

    その他の注意事項:

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

    ビットレート

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

    プロトコル

    注意すべき点は、インターネットは保証された配信ネットワークではなく、インターネット接続は良好と見なされるかもしれないが、高品質の信頼性の高いライブビデオストリーミングには十分ではない可能性があることです。カスタマーエンコーダとBrightcoveトランスコーディングプラットフォーム間のパスにわずかな障害(ISPでの輻輳の発生が少ない、ルータ間の予期しないフェールオーバーなど)が発生すると、ビデオ出力が中断される可能性があります。ハイリスクライブブロードキャストでは、管理対象ネットワーク上に専用ファイバ、予約済み衛星帯域幅、またはコミット済み帯域幅のいずれかで構成される複数の専用ネットワークを持つのが一般的です。これにはかなりのコストがかかりますが、ほとんどの場合、インターネット上で十分な結果を得ることが可能です。ただし、障害のない転送を維持することが重要な場合は、AWSDirectConnectまたはある程度の専用帯域幅を提供できるISPを検討してください。

    一般に、帯域幅に関連するネットワークの問題を完全に回避するために、エンコーダの予想ストリームサイズの2倍の帯域幅を割り当てることを推奨します。

    推奨されるオプションは次のとおりです(順番に)。

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

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

    サポートされるCDN

    • Akamai
    • Amazon CloudFront

    再試行

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

    ジョブ設定(LiveAPIのみ)

    推奨ジョブ設定

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

    ライブストリームの推奨事項を開始します。

    エンコーダ接続の前にジョブをアクティブにする必要があります。また、エンコーダからストリームを開始した後にジョブをアクティブにすることはサポートされていない手順であり、予期しない動作を引き起こす可能性があります。

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

    • 解像度: (エンコーディングラダーで最高)
    • FPS : (ソースと同じ)
    • ビットレート: (エンコーディングラダーで最高かそれ以上)
    • オーディオ: (ビットレート、チャネル、サンプリング周波数、およびサンプルあたりのビット数を最適な表現と同じにするか、入力と同じにする)

    推奨を出力する

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

    出力に関する推奨事項
    項目 推奨
    動画コーデック h264が現在唯一のオプションです
    オーディオコーデック aacが現在唯一のオプションです
    いいえまた身長ソース次元が使用されます。いずれかの場合また身長が指定されている場合、ソースの縦横比を維持するために他の寸法が計算されます。
    高さ いいえまた身長ソース次元が使用されます。いずれかの場合また身長が指定されている場合、ソースの縦横比を維持するために他の寸法が計算されます。
    ビットレート 入力ビットレート以下(最良の結果を得るために、最高出力ビットレートは入力ビットレートの半分にする必要があります)
    キーフレームレート 2秒

    よくある質問

    ライブジョブを作成した後、ストリーミングを開始する必要があるのはどれくらいですか?
    Brightcove Live では、状態が次から遷移するときに 2 つの条件があります。待っている仕上げ:
    1. 仕事が待っている状態 (まだ開始されていない) とmax_waiting_time_msが経過すると、ジョブは終了/非アクティブ化されます。
    2. ジョブが切断された状態 (開始されているが切断されている) と再接続時間が経過すると、ジョブは終了/非アクティブ化されます。

    もしイベントの長さが 30 分を超える場合、ジョブは 30 分で終了します。もしイベントの長さが 30 分未満の場合、ジョブは 30 分以内に終了しますイベントの長さ.

    たとえば、イベントの長さが 60 分である場合、ライブ ジョブは 30 分で終了します。もしイベントの長さが 15 分の場合、ライブ ジョブは 15 分で終了します

    再接続時間待機状態には影響しません。

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

    最大 5 アクティブ待っている、開始されていない仕事はいつでも許可されます。

    同時ジョブの追加制限:

    • の数チャネル(24x7) ジョブは、地域ごとに 0 または少数に制限されます (アカウントの種類によって異なります)。
    • 同時実行数ランニング イベントジョブは地域によって制限され、通常は 100 に制限されます。
    • 同時実行数接続待ち イベントジョブは 5 つに制限されています。
    • リージョンごとの SEP ジョブの数は 3 または 10 に制限されています (サポートされている AWS リージョン)。

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

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

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

    ライブ イベントを機能させるためにさらにサポートが必要な場合は、お問い合わせ.なるべく早くご返信ができるよう、問題解決のためにBrightcoveサポートチームが必要とする情報を以下にリストアップしています。

    • ストリームに見受けられる特定の兆候。たとえば、一部が再生できない、スムーズに再生できないなど
    • 問題のストリームが過去に正しく機能していたか
    • エンコーダーで使用しているエントリーポイントURL
    • 使用しているエンコーディングソフトウェアおよびハードウェア
    • ライブイベントを公開したプレーヤーのURL
    • ライブアセットのビデオID
    • エンコーダーから公開ポイントホストへのルートトラッキングの結果

    Page last updated on 05 Dec 2022