Brightcove NextGen Live: ベストプラクティス
Brightcove Live は、ライブ配信イベントや 24時間 365日 のライブリニア配信を作成するための堅牢なサービスを提供します。本ガイドでは、ライブ配信を最適化するためのベストプラクティスを解説します。
コンテンツのコンテキスト
配信するコンテンツの種類は、入力品質を維持するために必要な設定に影響するため、考慮する必要があります。トレードオフがあり、可能な限り高い設定を使用すると、フレームがスキップされるなどの問題が発生する可能性があることに注意してください。
以下の情報に基づき、ライブイベントの前に品質とパフォーマンスを見極めるために異なる設定の組み合わせをテストすることを推奨します。
主な入力パラメータは以下の表にまとめています:
| パラメータ | 備考 |
|---|---|
| 入力ビットレート | エンコーダーから送信される映像ソースフィードのビットレート。一般的な目安として、ソース入力ビットレートはチャンネル設定内で最上位レンディションのビットレートの約2倍(2x)にする必要があります。注意: 高いビットレートのソースフィードはネットワーク損失(インターネット区間)の影響を受けやすくなります。 |
| 入力解像度 | これはソース コンテンツに一致させる必要があります。オリジナル ソースより大きくしてもメリットはなく、数値を高くするとそれをサポートするために必要なビットレートも高くなります。 |
| プロファイル | 異なるプロファイル(baseline、main、high)は、それぞれデータの圧縮率が異なります(baseline: 最小、high: 最大)。圧縮率を高めると伝送効率は向上しますが、デコードに必要な CPU リソースも増加します。エンコーダーが利用できるリソースに大きな制約がない限り、baseline プロファイルは避けるべきです。一方、高いビットレートで high プロファイルを使用すると、必要なデコード CPU リソースが増えるためフレームスキップが発生しやすくなります。
詳細は下記のGOP構造も参照してください。 |
| フレームレート | ソースに一致させる必要があります。
フレームレートが高いと、それに比例して入力ビットレートも高くなります。例えば、動きの多いスポーツのコンテンツでは、60fps の入力ストリームは 30fps のストリームに比べて多くのデータを必要とします。 60fps のような高いフレームレートは、高ビットレートで複雑なコンテンツを扱う場合にフレームスキップの問題が発生しやすくなります。 |
| キーフレームレート | 1秒あたりのキーフレーム数。例えば、0.5 という値は 2 秒ごとに 1 つのキーフレームが挿入されることを意味します。3 という値は 1 秒間に 3 つのキーフレームを意味します。トランスコード プロファイルではキーフレームレートを分数値で定義します。したがって 0.5 という値は 1/0.5 = 2 となり、2 秒ごとにキーフレームが挿入されることを示します。 |
| GOP 構造 | 下記のGOP 構造を参照してください。 |
入力制限
最高品質で一貫したストリーミング体験を確保するために、Brightcove Live では入力ストリーム設定を以下に制限しています:
- プロトコル:
rtmp、rtp、またはsrt(rtmp以外はすべて MPEG2-TS 入力用)[1-1] - 解像度: 最大 1920 x 1080
- 推奨: 30fps、最大: 60fps。注意: フレームレートが高いほど、ソースフィードの品質を維持するためにより高い入力ビットレートが必要になります。
- 取り込み可能な最大入力ビットレートは 50 Mbps、最大出力ビットレートは 25 Mbpsです。
- エンコーダーは固定ビットレート(CBR)に設定してください。可変ビットレート(VBR)のフィードはライブ配信パイプラインで問題を引き起こす可能性があります。
- ビデオコーデック: h.264、HEVC
- スライス: エンコーダーにこのオプションがある場合は
1に設定してください。 - オーディオ コーデックは
AACでなければなりません。 - オーディオ サンプリングレート: 44.1khz または 48khz が推奨されるサンプルレートになります。
- キーフレームレートまたは GOP(Group of Pictures)の整合性:
- キーフレームは入力と出力の両方(25fpsビデオを含む)で必ず 2 秒ごと に発生する必要があります。つまり、ストリーム中の 2 秒ごとにエンコーダーから Brightcove へキーフレームが送信されます。このプロセスは異なる方法で定義できますが、一般的には キーフレームレート と呼ばれます。
- エンコーダーごとに異なる方法で計算されます。例:
- Wirecast はフレーム数で計算するため、30fps のビデオでは設定値は 60 になります。
- Elemental エンコーダーは秒数で指定するため、正しい設定値は「2」となります。
- 60 fpsビデオの場合、この設定がフレーム数でカウントされる場合は 120 フレームごとに 2 秒となります。
- Keyframe Aligned(キーフレームを揃える)、Sync GOP(GOP同期)、Align Keyframes(キーフレームを揃える)などのオプションがある場合は、必ずキーフレームが整合するようにしてください。キーフレームが整合していないと、HLS セグメントの同期に問題が発生します。
- Brightcove Live は h.264 ヘッダー内のインバンド(in-band)608 字幕に対応しています。このトピックの詳細についてはライブストリームでのキャプションを参照してください。[1-2]
注意事項
- [1-1] TS 入力に複数のビデオ/オーディオ トラックがある場合、各トラックの最初のものが選択されます。また、UDP 経由のプレーン TS はインターネット上では非常に不安定なため、FEC の使用を強く推奨します。FEC では、行/列に使用する値が小さければ小さいほど、エラー訂正の信頼性が高くなります(ただし代償として、帯域幅は増加します)。
- [1-2] 608 字幕を実装する場合は、608 データ内で字幕位置を設定する必要があります。
ストリーミングにおける主な問題
エンコーダーから Brightcove へのストリーミング体験に関連して、一般的に発生する問題は次のとおりです:
- 入力に影響を与えるネットワークの不安定性:
- インターネットは一般的に信頼性がありますが、完全ではなく問題が発生することがあります。特に高いビットレートでは問題が発生しやすくなります。
- 動画のアップロードにリアルタイム以上の時間がかかると、入力ドリフト(映像の受信が送信時点より大幅に遅れる)が発生します。
- トランスコーダーの過負荷によるフレーム スキップ: トランスコーダーに十分な余裕を持たせるよう対応していますが、コンテンツの複雑さの急激な増加やネットワークの乱れ/回復、その他の中断によりフレーム スキップが発生する場合があります。入力が複雑であるほど、フレーム スキップが発生する可能性は高くなります。また、既知の問題として、5分 以上の静止画像から突然動きの強いコンテンツに切り替わると過負荷が発生する場合があります。
- エンコーダーが可変フレーム長を送信している場合: 一貫したキーフレームの分布とセグメントサイズを確保するために、整数のフレームレート(例: 30fps)の使用が推奨されます。
- エンコーダーが一定間隔でないキーフレームを送信している: キーフレームレートはフレームレート(秒単位)の最低 2 倍である必要があります。例えば、30 fpsの場合、キーフレーム間隔は 60 フレーム(2秒)で、最大でも 1 セグメントごとに 1 回である必要があります。つまり 6 秒のセグメントであれば、30 fpsで 180 フレームが最大間隔となります。
コンテンツタイプ
一般的に、より複雑なコンテンツでは高めの設定を使用する必要があり、その分フレーム スキップが発生しやすくなります。以下の表では、複雑さの順にいくつかの例を示しています。これらはあくまで例であり、エンコーダーの設定はそれぞれ異なるため、テストと検証を行うことを推奨します。
| コンテンツタイプ | 設定例 |
|---|---|
| Web カメラ |
|
| Web 会議 |
|
| アニメーション |
|
| トーキングヘッド / ニュース |
|
| ライブ コンサート |
|
| ライブスポーツ |
|
| ライブスポーツ 高FPS |
|
Transmux Live ジョブ
キーフレームの挿入をリクエストのセグメンテーション設定に合わせて設定してください。例えば、フレームレートが毎秒 25 フレームで、6 秒ごとのセグメントを希望する場合、キーフレーム間隔を少なくとも 300 フレームごとに設定する必要があります。
ターゲット デバイスに合わせてエンコーダーの設定/出力をテストしてください。これは、すべてのユーザー機器と互換性のないストリームになる可能性のある高度な設定を持っている放送用のエンコーダーを使用する場合に特に注意が必要です。また、特に高度な設定は避けた方がよいでしょう。どの設定が問題になるかは、利用可能なエンコーダーやオプションが非常に多いため一概には言えませんが、一般的に推奨されるプロファイルは以下のようになります:
- 6 Mbps のピーク ビットレート
- H.264 High プロファイル
- Bフレーム: 2
- 8 bit 4:2:0 カラー
検証とテスト
理想的には、最も複雑な(変化が多い)コンテンツで可能な限り低い設定から開始し、出力が許容できるまで各種設定を上げてテストしてください。これは、一般的に設定を高くすればするほどネットワークやトランスコードで問題が発生する可能性が高くなるためです。
帯域幅のテスト
入力ストリームに適した設定を決定するための第一歩は、設置場所で利用可能な帯域幅を確認することです。以下のようなツールが役立ちます:
- SpeedOf.Me (https://speedof.me) - HTTP 接続で利用可能な総帯域幅を確認することは有効な第一歩です。ただし、入力フィードは HTTP ではなく RTMP を通じて Live モジュールにストリーミングされるため、RTMP 接続で実際に利用可能な帯域幅は大幅に少なくなります。
- Speedtest (https://speed.cloudflare.com/) - 現在のアップロード速度とダウンロード速度を確認するオンラインツール。
入力帯域幅
視聴者に最高の体験を提供する唯一の方法は、高品質で安定した入力ストリームを提供することです。良好な入力ストリームは、ロケーションから利用可能な最大の帯域幅で最高の映像品質を提供します。
- 最小入力帯域幅: 2.5 Mbps
- 最大入力帯域幅: 20 Mbps
入力制限のスパイク
- 最大入力ビットレート: 30 Mbps
- 最大出力ビットレート: 20 Mbps
エンコーダーの性能確認
ライブストリームをエンコードして Live モジュールに送信するために使用するソフトウェアやハードウェアの性能を理解することも重要です。高品質の 1080p 入力ストリームを送信できるビットレートが十分にあっても、ハードウェア自体がリアルタイム以上の速度でエンコードできる必要があります。一部のエンコードツールでは、CPU 使用率や使用中の帯域幅に関する情報が表示されます。例えば、Telestream Wirecast では、Wirecast ウィンドウの下部に出力統計が表示されます。

この情報は、特定のハードウェアで可能な最も安定した高品質のストリームを判断するのに役立ちます。Wirecast で注意すべき点:
- CPU 使用率は 80% 未満であること
- データレートはターゲット ビットレートに近いこと
- FPS は入力ストリーム設定のレートであること
GOP構造
ビデオの Group of Pictures (GOP) 構造は、使用されるプロファイルによって決まります:
- Baseline プロファイルは、I フレームと P フレーム、および CAVLC エントロピーエンコードのみをサポートします。
- Main および High は、I・B・P フレームと CABAC エントロピー エンコードをサポートします。
Main および High プロファイルは、一般的に高品質かつ高い圧縮率を実現しますが、エンコードとデコードに追加の計算を必要とするため、フレームスキップが発生しやすくなります。また、これらのプロファイルは B(双方向)フレームを使用するため、エンコード処理に遅延が生じます。
Baseline プロファイルは、エンコードやデコードに必要な CPU が少なくて済みますが、圧縮率が低いため品質を維持するには高いビットレートが必要で、ネットワーク問題の影響を受けやすくなります。
フレームタイプとパフォーマンスへの影響に関する注意:
- 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 のトランスコーディング プラットフォーム間の経路における小さな混雑、ルーター間の予期しないフェイルオーバー、その他の問題が、映像出力の中断を引き起こす可能性があります。重要なライブ放送では、専用回線、予約済みの衛星帯域幅、またはマネージド ネットワーク上の確保された帯域幅など、複数の専用ネットワークを利用するのが一般的です。これには高額なコストが伴いますが、多くの場合インターネットでも十分な結果を得ることが可能です。ただし、完全に障害のない配信が必須の場合は、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 プレーヤーの最新バージョンを使用していることを確認することは、最適なパフォーマンス、セキュリティ、最新機能へのアクセスを維持する上で重要です。新しいリリースには、多くの場合バグ修正、パフォーマンス改善、新機能が含まれており、ライブ配信体験を向上させることができます。
プレーヤー更新のベストプラクティス
- 最新のプレーヤーバージョンについて把握するために、Brightcove Player リリースノートを定期的に確認してください。
- 現在のプレーヤー設定と構成のバックアップを必ず取得してください。
- 新しいプレーヤーバージョンをステージング環境に導入し、カスタマイズや統合を含めたすべての機能をテストしてください。
- 少数のリスクの低いライブイベントから導入を開始し、パフォーマンスを監視してから本格的に展開してください。
- 新しいプレーヤーバージョンについて、エンドユーザーや関係者からフィードバックを収集してください。
スレート ソースファイルの推奨事項
- 解像度: (エンコーディング ラダーの中で最良のもの)
- FPS: (ソースと同じ)
- ビットレート: (エンコーディング ラダーの中で最良のもの、またはそれ以上)
- オーディオ: (最高品質のレンディションと同じビットレート、チャンネル数、サンプリング周波数、サンプルあたりのビット数、または入力と同じ)
出力の推奨事項
以下は推奨される出力設定ですが、多くのエンコーダーでは RTMP 入力が 20 Mbps(ビデオ + オーディオ)およびフレームレート 30fps に制限されている点に注意してください。
| 項目 | 推奨内容 |
|---|---|
| ビデオ コーデック | h264 が現在利用可能な唯一のオプションです |
| オーディオ コーデック | aac が現在利用可能な唯一のオプションです |
| 幅 | width または height が指定されていない場合は、ソースのサイズが使用されます。width または height のいずれかが指定された場合、もう一方のサイズはソースのアスペクト比を維持するように計算されます。 |
| 高さ | width または height が指定されていない場合は、ソースのサイズが使用されます。width または height のいずれかが指定された場合、もう一方のサイズはソースのアスペクト比を維持するように計算されます。 |
| ビットレート | 現在サポートされている最大出力ビットレートは 20 Mbps です |
| キーフレーム間隔 | 2 秒 |
FAQ
- ジョブが waiting 状態(未開始)で、
max_waiting_time_msが経過した場合、ジョブは終了/無効化されます。 - ジョブが disconnected 状態(開始済みだが切断された状態)で、
reconnect_timeが経過した場合、ジョブは終了/無効化されます。 channel(24x7)ジョブの数はリージョンごとに0または少数に制限されています(アカウントタイプにより変わります)。- 同時に running 状態の
eventジョブ数はリージョンごとに制限され、一般的に 100 までです。 - 同時に waiting to connect 状態の
eventジョブ数は 5 に制限されています。 - リージョンごとの SEP ジョブ数は 3 または 10 に制限されています(対応する AWS リージョンを参照)。
- ストリームで発生している具体的な症状(例:まったく再生されない、またはカクつく/フリーズするなど)
- このストリームが過去に正常に動作したかどうか
- エンコーダーで使用しているエントリポイントURL
- 使用しているエンコード用ソフトウェアとハードウェア
- ライブイベントを公開したプレーヤーのURL
- ライブアセットの動画ID
- エンコーダーから配信ポイントホストまでのトレースルートの結果
ライブジョブを作成してからどのくらいの時間で配信を開始する必要がありますか?
Brightcove Liveでは、状態がwaiting から finishing に移行する条件は 2 つあります:
event_length が 30 分を超える場合、ジョブは 30 分で終了します。event_length が 30 分未満の場合、ジョブは event_length の時間で終了します。
例えば、event_length が 60 分の場合、ライブジョブは 30 分で終了します。event_length が 15 分の場合、ライブジョブは15分で終了します。
reconnect_time は waiting 状態には影響しません。
同時ライブジョブ設定の制限は何ですか?
同時に有効な waiting ジョブは最大 5 つまで許可されます。
その他の同時実行ジョブに関する制限:
これらの制限は、サポートに依頼することでアカウント単位で調整可能です。追加のキャパシティが必要な場合は、弊社営業にまでお問い合わせください。
入力帯域幅が十分であれば、Brightcove Live は 1080p 品質で配信できますか?
はい、すべてのアカウントで 1080p 入力が有効になっています。DRM は利用できますか?
はい!ライブアカウントに DRM サポートを追加したい場合は、弊社営業までお問い合わせください。さらにサポートが必要な場合
ライブイベントがうまく動作しない場合は、弊社サポートまでお問い合わせください。最速で対応を受けられるようにするために、以下の情報を Brightcove サポートにご提供ください。