Brightcove Live:ベストプラクティス
概要
Brightcove Live は、ライブストリーミングイベントや 24 時間 365 日のライブストリームを作成するための堅牢なサービスを提供します。このガイドでは、ライブストリームを最適化するためのベストプラクティスの概要を説明します。
コンテンツのコンテキスト
ストリーミングするコンテンツの種類は、入力品質を維持するために必要な設定に影響するため、考慮する必要があります。最高の設定を使用するとフレームのスキップなどの問題が発生する場合があるため、トレードオフがあることに注意してください。
以下の情報に基づき、ライブイベントの前にさまざまな設定の組み合わせで品質とパフォーマンスをテストすることをお勧めします。
主な入力パラメーターは、以下の表にまとめられています:
| パラメーター | 注記 |
|---|---|
| 入力ビットレート | エンコーダーが送信するビットレートです。高いレートはネットワーク損失の影響を受けやすいため、実用的な範囲でできるだけ低く設定する必要があります。 |
| 入力解像度 | ソースコンテンツと一致させる必要があります。元のソースより高くしても利点はなく、この値が高いほどサポートに必要なビットレートも高くなります。 |
| 入力ビットレートとトッププロファイルの比率 |
ライブイベント中に最適なパフォーマンスを確保するため、入力ビットレートを最高ビットレートのライブレンディションのビットレートに合わせることをお勧めします。ただし、最大レンディションビットレートを大幅に超えると、バッファリング、高い入出力ドリフト、その他の関連問題が発生する可能性があります。したがって、Brightcove は入力ビットレートを決定する際に以下の要素を慎重に検討することを推奨します:
|
| プロファイル | 異なるプロファイル(ベースライン、メイン、ハイ)はデータを昇順で圧縮します(ベースライン:最低、ハイ:最高)。圧縮が高いほど伝送速度が向上しますが、データのデコードに必要な CPU リソースも増加します。エンコーダーのリソースが大幅に制限されていない限り、ベースラインプロファイルは避けるべきです。一方、高ビットレートでハイプロファイルを使用すると、デコードに必要な CPU リソースが増加するため、フレームのスキップが発生しやすくなります。
GOP 構造も参照してください。 |
| フレームレート | ソースと一致させる必要があります。
高いレートは比例して高い入力ビットレートを必要とします。例えば、アクションスポーツコンテンツでは 60fps の入力ストリームは 30fps のストリームよりも大幅に多くのデータを含みます。 60fps などの高いレートは、高ビットレートの複雑なコンテンツでフレームのスキップ問題が発生しやすくなります。 |
| キーフレームレート | この設定で最も効率的なのは、セグメント長 × フレームレートです。例えば、6 秒セグメントと 30fps の場合、キーフレームレートを 180(6×30)に設定するとデコーダーの負荷が最小になります。
ただし、変動を考慮して 2 × フレームレートに設定されています。例えば、30fps の場合は 60 です。 |
| GOP 構造 | 以下の GOP 構造を参照してください。 |
入力制限
最高品質で最も一貫したストリーミングエクスペリエンスを確保するため、Brightcove Live では入力ストリームの設定を以下に制限しています:
- プロトコル:
rtmp、rtp、rtp-fec、またはsrt(rtmp以外はすべて MPEG2-TS 入力用)[1-1] - 解像度:最大 1920x1080
- 最大 30fps(一般的)。Brightcove は最大 60fps をサポートしていますが、制限を引き上げるには Brightcove サポートにお問い合わせください。60fps を使用する場合、コンテンツに対して望ましい視覚的品質を達成するためにビットレートを上げ、一定のフレームレートを維持することを Brightcove は推奨します。
- 取り込み可能な最大入力ビットレートは 30Mbps に設定されています。最大出力ビットレートは 20Mbps です。
- 固定ビットレート(CBR)は問題発生の可能性を大幅に減少させます。
- 動画コーデックは H.264 である必要があります。
- スライス:エンコーダーにこのオプションがある場合は
1に設定してください。 - 音声コーデックは
AACである必要があります。 - 音声サンプリングレート:推奨サンプル音声レートは 44.1kHz および 48kHz です。
- キーフレームレートまたは GOP(Group of Pictures)のアライメント:
- キーフレームは常に 2 秒ごとに発生する必要があります(入出力の両方(25fps の動画を含む))。つまり、キーフレームはストリーム自体の 2 秒ごとにエンコーダーから Brightcove に送信されます。このプロセスはさまざまな方法で定義できますが、キーフレームレートが最も一般的です。
- 異なるエンコーダーではさまざまな方法で計算できます。例えば:
- Wirecast はフレーム数を使用するため、30fps の動画の場合、設定は 60 になります。
- Elemental エンコーダーは秒を使用するため、正しい設定は「2」になります。
- 60FPS の動画は、この設定がフレーム数でカウントされる場合のみ変更が必要で、その場合は 120 フレームごとが 2 秒になります。
- Keyframe Aligned、Sync GOP、Align Keyframes、またはそれに類するオプションがある場合は、キーフレームが揃っていることを確認してください。キーフレームが揃っていない場合、HLS セグメンテーションで同期の問題が発生します。
- Brightcove Live は h.264 ヘッダー内の 608 字幕(インバンド)をサポートしています。このトピックの詳細については、ライブストリームの字幕を参照してください。[1-2]
注記
- [1-1] TS 入力に複数の動画/音声トラックがある場合、それぞれの最初のトラックを選択します。また、FEC の使用を強くお勧めします。インターネット経由のプレーン TS over UDP は非常に信頼性が低いためです。FEC については、行/列に使用する値が小さいほどエラー訂正の信頼性が高くなります(帯域幅の増加というコストと引き換えに)。
- [1-2] 608 字幕を実装する際は、608 データでの字幕の位置設定が必要です。
長時間実行ジョブ
長時間実行ジョブ(リニアチャンネルなど)がある場合は、バグ修正と新機能の利点を活用するために、毎月再アクティブ化してください。
ストリーミングの主な問題
エンコーダーから Brightcove へのストリーミングエクスペリエンスの問題に関連して、一般的にいくつかの問題が発生します:
- 入力に影響するネットワークの不安定性:
- インターネットは一般的に非常に信頼性が高いですが、完全ではなく問題が発生することがあります。問題は高いビットレートでより顕著になる傾向があります。
- 動画のアップロードにリアルタイムより長くかかる場合、入力ドリフトが発生することがあります(動画が受信される時刻が送信された時刻より大幅に遅れる)。
- フレームのスキップを引き起こすトランスコーダーの過負荷:トランスコーダーに十分な余裕を確保するために最善を尽くしていますが、コンテンツの複雑さの急激なスパイク、ネットワークの途切れ/回復、またはトランスコーダーへの他の割り込みにより、フレームのスキップが発生することがあります。入力が複雑なほど、フレームのスキップが発生しやすくなります。また、静止画像が 5 分以上続いた後にアクションコンテンツに突然変化すると過負荷が発生する既知の問題があります。
- エンコーダーが可変フレーム期間を送信する:整数フレームレート(30fps など)を使用することをお勧めします。これにより、一貫したキーフレーム配布とセグメントサイズが確保されます。
- エンコーダーが一定の間隔でないキーフレームを送信する場合、キーフレームレートはフレームレート(秒換算)の最低 2 倍である必要があります。例えば、フレームレートが 30fps の場合、キーフレームインターバルは 60 フレーム(2 秒)であり、セグメントごとに 1 回を最大インターバルとする必要があります。例えば、6 秒のセグメントがある場合、30fps での最大インターバルは 180 フレームです。
コンテンツタイプ
一般的に、より複雑なコンテンツほど高い設定が必要であり、フレームのスキップが発生しやすくなります。以下の表は、複雑さの順にいくつかの例を示しています。これらはあくまでも例であり、エンコーダーの設定は異なるため、テストと検証を実施する必要があります。
| コンテンツタイプ | 設定例 |
|---|---|
| ウェブカム |
|
| ウェブ会議 |
|
| アニメーション |
|
| トーキングヘッド / ニュース |
|
| ライブコンサート |
|
| ライブスポーツ |
|
| ライブスポーツ(高フレームレート) |
|
トランスマックスライブジョブ
キーフレームの挿入を要求されたセグメンテーション設定と一致するように設定してください。例えば、フレームレートが 25fps でセグメントを 6 秒にしたい場合は、キーフレームインターバルを少なくとも 300 フレームごとに 1 回に設定してください。
エンコーダーの設定/出力を目的のターゲットデバイスでテストしてください。特に、すべてのコンシューマデバイスと互換性がない可能性のある高度な設定を持つブロードキャスト寄与エンコーダーを使用している場合は重要です。また、特に高度な設定を避けることをお勧めします。一般的なトップレートプロファイルは以下のようになります:
- 6Mbps ピークビットレート
- H264 High プロファイル
- B フレーム:2
- 8bit 4:2:0 カラー
検証とテスト
理想的には、最も複雑な(最も変化の多い)コンテンツで可能な限り低い設定から始め、出力が許容できるレベルになるまでさまざまな設定を上げてテストしてください。これは、一般的に設定が高いほどネットワークまたはトランスコーディングの問題が発生しやすくなるためです。
帯域幅のテスト
入力ストリームの適切な設定を決定するための最初のステップは、現地で利用可能な帯域幅を確認することです。役立つツールがいくつかあります:
- SpeedOf.Me (https://speedof.me) - HTTP 接続で利用可能な総帯域幅を確認することは良い第一歩です。ただし、入力フィードは HTTP ではなく RTMP で Live モジュールにストリーミングされるため、RTMP 接続で実際に利用可能な帯域幅は大幅に少なくなります。
- Speedtest (https://www.speedtest.net) - 現在のアップロードおよびダウンロード速度を確認するオンラインツールです。
入力帯域幅
高品質で安定した入力ストリームを提供することが、視聴者に最高のユーザーエクスペリエンスを保証する唯一の方法です。良い入力ストリームは、特定の場所から最も高く一貫して利用可能な帯域幅で最高の動画品質を提供します。
- 最小入力帯域幅:2.5 mbps
- 最大入力帯域幅:20 mbps
入力制限のスパイク
- 最大入力ビットレート:30Mbps
- 最大出力ビットレート:20Mbps
エンコーダー能力の確認
ライブストリームをエンコードして Live モジュールに送信するために使用するソフトウェアおよびハードウェアの能力を理解することも重要です。高品質の 1080p 入力ストリームを送信するための十分なビットレートがあっても、ハードウェアがリアルタイムより高速でエンコードできる必要があります。一部のエンコーディングツールは総 CPU 使用率と使用中の帯域幅に関する情報を表示します。例えば、Telestream Wirecast では Wirecast ウィンドウの下部に出力統計が表示されます。

この情報は、指定のハードウェアで可能な最も安定した高品質ストリームを決定する際に役立ちます。Wirecast で確認すべき点:
- CPU は 80% 未満である必要があります
- データレートは目標ビットレートに近い必要があります
- FPS は入力ストリーム設定のレートである必要があります
GOP 構造
動画の GOP(Group of Pictures)構造は、まず使用するプロファイルに依存します:
- Baseline プロファイルは I フレームと P フレーム、および CAVLC エントロピーエンコーディングのみをサポートします
- Main と High は I、B、P フレームと CABAC エントロピーエンコーディングをサポートします
Main と High プロファイルは一般的により良い品質でより良い圧縮を実現しますが、エンコードとデコードに追加の計算が必要であるため、フレームのスキップが発生しやすくなる場合があります。さらに、これらのプロファイルは B(双方向)フレームを使用するため、エンコーディングプロセスに遅延が生じます。
Baseline プロファイルはエンコードとデコードに必要な CPU が少ないですが、圧縮率が低いため品質を維持するには高いビットレートが必要で、ネットワークの問題が発生しやすくなります。
フレームタイプとパフォーマンスへの影響についての注記:
- I フレーム:最も多くの帯域幅を使用します。完全なシーンの変化またはセグメントの境界に追加するのが最適です。つまり、コンテンツが変化するほど多くの I フレームが必要になります(GOP 長が短い)。
- P フレーム:I フレーム間の基本単位です
- B フレーム:前後のフレームを使用します。追加するほど圧縮が向上しますが、CPU 使用率とレイテンシが増加します
I フレームの使用はセグメントの開始(パススルーを使用する場合は重要)またはシーン変化に限定するのが理想的です。すべてまたは多数の I フレームはスキップフレームを引き起こす過剰な負荷につながるため、避けるべきです。
追加の注記:
- キーフレームの密な配置を防ぐオプションを使用してください(例:
min_keyin= 3+)。 - キーフレームの定期的な挿入を確保するオプションを使用してください。例えば、GOP 長を秒数で指定する代わりに、正確な分数またはフレーム数で指定してください。
- スポーツ/高動作コンテンツの場合、「参照フレーム数」を
4に調整することを検討してください。 - スポーツ/高動作コンテンツの場合、「B フレーム数」を
3に調整することを検討してください。
ビットレート
- 最小入力帯域幅:2.5 mbps
- 最大入力帯域幅:20 mbps
- ストリームを「ほぼ CBR」にします。
max_bitrate= 1.1 * target_bitrate で設定します。 - 利用可能な場合は、厳格な HRD 準拠レート制御モードを使用してください。
プロトコル
インターネットは保証された配信ネットワークではなく、インターネット接続が「良好」と考えられていても、高品質の信頼性の高いライブ動画ストリーミングには十分でない場合があることに注意することが重要です。顧客のエンコーダーと Brightcove トランスコーディングプラットフォームの間のパスでのわずかな中断(ISP での少量の輻輳、ルーター間の計画外のフェイルオーバー、または同様の問題など)により、動画出力に中断が発生する可能性があります。高度なライブ放送では、専用の光ファイバー、予約済みの衛星帯域幅、またはマネージドネットワーク上のコミット帯域幅からなる複数の専用ネットワークを持つことが一般的な慣行です。これには相当なコストがかかりますが、ほとんどの場合、インターネット経由で十分な結果を達成することが可能です。ただし、障害のないトランスポートを維持することが重要な場合は、AWS Direct Connect または専用帯域幅を提供できる ISP を検討してください。
一般的に、帯域幅関連のネットワーク問題を完全に回避するために、エンコーダーの予想ストリームサイズの 2 倍の帯域幅を確保することをお勧めします。
推奨するオプション(順位付き):
- SRT - トランスポートの速度(UDP)と制御とエラー耐性を良い組み合わせで提供します。すべてのエンコーダーで利用できるわけではありませんが、srt-transmit などのローカル RTP から変換するツールがあります。
- RTMP - TCP ベースのため、高いエラー耐性を提供しますが、大きなオーバーヘッドが伴います。複数の音声トラックなどの一部の機能は RTMP では利用できないことに注意してください。
- RTP-FEC - 高速な UDP ベースのトランスポートとエラー耐性を提供します
- RTP - エラー耐性なしの高速トランスポートと高度な機能を提供します
サポートされているエンコーダー
Live で動作することが確認されているエンコーダーのリストについては、ライブイベント向けサポートエンコーダーを参照してください。他のエンコーダーも動作する場合がありますが、テストされていないことに注意してください。
再試行
エンコーダーからの RTMP 接続の再試行を有効にすることをお勧めします。5 秒の再試行インターバルで多数の再試行を行うことで、エンコーダーとエントリーポイント間の断続的な接続の問題を軽減できます。
ジョブ設定(Live API のみ)
推奨ジョブ設定
| フィールド | 推奨値 |
|---|---|
ad_audio_loudness_level |
-23 (EBU R.128 標準) |
ライブストリーム開始の推奨事項
エンコーダーの接続前にジョブをアクティブ化する必要があります。また、エンコーダーからストリームを開始した後にジョブをアクティブ化することはサポートされていない手順であり、予期しない動作が発生する可能性があります。
プレーヤーバージョンの更新
Brightcove Player の最新バージョンを使用していることを確認することは、最適なパフォーマンス、セキュリティ、および最新機能へのアクセスを維持するために重要です。新しいリリースには、バグ修正、パフォーマンスの改善、ライブストリーミングエクスペリエンスを向上させる新機能が含まれることが多いです。
プレーヤー更新のベストプラクティス
- 最新のプレーヤーバージョンを把握するために、Brightcove Player リリースノートを定期的に確認してください。
- 現在のプレーヤーの設定と構成のバックアップを確保してください。
- ステージング環境で新しいプレーヤーバージョンを実装し、カスタマイズや統合を含む全ての機能をテストしてください。
- 完全な規模での展開の前に、パフォーマンスを監視するために一部のリスクの低いライブイベントから始めてください。
- 新しいプレーヤーバージョンに関してエンドユーザーおよびステークホルダーからフィードバックを収集してください。
スレートソースファイルの推奨事項
- 解像度:(エンコーディングラダーの中で最良のもの)
- FPS:(ソースと同じ)
- ビットレート:(エンコーディングラダーの中で最良のものまたはそれ以上)
- 音声:(最良のレンディションと同じビットレート、チャンネル、サンプリング周波数、サンプルあたりのビット数、または入力と同じ)
出力の推奨事項
以下は推奨出力設定ですが、多くのエンコーダーでは RTMP 入力は 20 MBPS(動画+音声)および 30fps のフレームレートに制限されています。
| 項目 | 推奨事項 |
|---|---|
| 動画コーデック | h264 が現在唯一のオプションです |
| 音声コーデック | aac が現在唯一のオプションです |
| 幅 | width または height が指定されていない場合、ソースのサイズが使用されます。width または height のいずれかが指定された場合、もう一方の寸法はソースのアスペクト比を維持するように計算されます。 |
| 高さ | width または height が指定されていない場合、ソースのサイズが使用されます。width または height のいずれかが指定された場合、もう一方の寸法はソースのアスペクト比を維持するように計算されます。 |
| ビットレート | 現在サポートされている最大出力ビットレートは 20Mbps です |
| キーフレームレート | 2 秒 |
よくある質問
ライブジョブを作成してからストリーミングを開始するまでの時間はどのくらいですか?
Brightcove Live では、状態がwaiting から finishing に移行する条件が 2 つあります:
- ジョブが waiting(未開始)状態にあり、
max_waiting_time_msが経過した場合、ジョブは完了/非アクティブ化されます。 - ジョブが disconnected(開始されたが切断された)状態にあり、
reconnect_timeが経過した場合、ジョブは完了/非アクティブ化されます。
event_length が 30 分より大きい場合、ジョブは 30 分で終了します。event_length が 30 分未満の場合、ジョブは event_length で終了します。
例えば、event_length が 60 分の場合、ライブジョブは 30 分で終了します。event_length が 15 分の場合、ライブジョブは 15 分で終了します。
reconnect_time は waiting 状態には影響しません。
同時ライブジョブ設定の制限は何ですか?
任意の時点で、最大 5 つのアクティブな waiting(未開始)ジョブが許可されます。
同時ジョブに関する追加の制限:
channel(24×7)ジョブの数は、リージョンごとに 0 または少数に制限されています(アカウントタイプによって異なります)。- 同時に実行中の
eventジョブの数はリージョンごとに制限されており、一般的に 100 です。 - 同時に接続待機中の
eventジョブの数は 5 に制限されています。 - リージョンごとの SEP ジョブの数は 3 または 10 に制限されています(サポートされている AWS リージョンを参照)。
これらの制限はサポートによってアカウントレベルで調整できます。追加の容量が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
入力帯域幅が十分な場合、Brightcove Live は 1080p 品質を配信できますか?
はい、1080p 入力はすべてのアカウントで有効になっています。DRM は利用可能ですか?
はい!ライブアカウントに DRM サポートを追加することに興味がある場合は、カスタマーサクセスマネージャーにお問い合わせください。さらにサポートが必要な場合
ライブイベントの動作についてさらにサポートが必要な場合は、お問い合わせください。できるだけ迅速な対応を行うために、以下は Brightcove サポートが問題を解決するために必要な情報のリストです。
- ストリームで発生している具体的な症状。例えば、全く再生できないのか、それとも断続的に止まったりフリーズしたりするのかなど。
- このストリームが過去に正常に動作していたかどうか
- エンコーダーで使用しているエントリーポイント URL
- 使用しているエンコーディングソフトウェアとハードウェア
- ライブイベントを公開したプレーヤーへの URL
- ライブアセットの動画 ID
- エンコーダーからパブリッシングポイントホストへのトレースルートの結果