OBSマルチストリーミング：1つのfeedを複数の配信先へ

Fan-outの境界を意図して決める

Serverを使っても共有依存関係がすべて消えるわけではありません。すべての配信先は、OBS program、会場からの1本のupstream session、それを受信するCallaba deploymentに引き続き依存します。利点は障害境界が明確になることであり、魔法のような冗長化ではありません。

Stream keyを入力する前に制作環境を整える

• 配信先のeventを作成または予約し、各accountにlive配信の権限があることを確認します。
• Callabaが安定して受信できるcontribution resolution、frame rate、codec、bitrate、keyframe interval、audio programを1組決めます。
• 制作networkで持続可能なuploadを測定します。短時間のspeed testはリハーサルの代わりになりません。
• 動き、音声、同期基準を含む、短く識別しやすいtest programを使います。
• プラットフォームのkeyをscreenshot、公開runbook、analytics payloadに残さないでください。
• 共有inputと各プラットフォームのcontrol roomを同時に確認できるoperatorを割り当てます。

配信先の要件は変わります。古い記事のbitrate表を流用せず、本番前に各serviceの最新help pageを確認してください。

制御された1本のupstream用にOBSを設定する

1. Callaba inputを作成します。 制作に合ったRTMP ServerまたはSRT Serverを使います。起動後、dashboardから現在のpublisher valueをコピーします。
2. OBSで［設定］→［配信］を開きます。 OBSの公式interfaceでは、組み込みserviceまたはCustom Streaming Serverを選び、提供されたserverとstream keyを入力できます。Callabaの値をそのまま使用し、配信先プラットフォームのkeyをここで再利用しないでください。
3. ［設定］→［出力］を確認します。 共有pathが運べ、downstream workflowがdecodeできるprofileを選びます。最初のtestでは、codec、resolution、audio routingを同時に変更しないでください。
4. 非公開testを開始します。 OBSでencoder overloadとdropped frameを監視します。Callabaでは、incoming bitrateが持続し、想定した音声付きの映像をdecodeできていることを合格条件にします。
5. 停止して再接続します。 Sessionが閉じ、同じmanaged publisherが再接続できることを確認します。これにより、古いidentityやコピー間違いを検出できます。

RTMPに特化した手順は OBSでRTMPを送受信するガイドを参照してください。制作でSRT contributionを使う場合は OBSのSRT設定ガイド を開き、現在のOBS output methodを確認します。

配信先を1つ追加して検証し、その後で次を追加する

1. Callabaで Restreaming を開き、検証済みのOBS feedをsourceにして新しいrestreamを作成します。
2. 対応する配信先typeを選ぶか、プラットフォームから発行されたcustom output URLとkeyを正確に入力します。
3. OBS contributionが配信先の条件をすでに満たす場合は、transcodingを無効のままにします。別のprofileが必要なら、その条件で要求されるsettingだけを変更します。
4. Restreamを開始してプラットフォームのpreviewを開きます。映像、音声、account状態、プラットフォームのwarningを確認します。
5. 合格したrouteにevent名と配信先名を付け、次のプラットフォームでも同じ手順を繰り返します。

現在の項目については Callaba Restreamingユーザーガイドを参照してください。 Live Multiview demo ではoperator向けのmonitoring画面を確認できますが、自分のsourceと配信先には別途production testが必要です。

すべてを再起動せず、障害ツリーで切り分ける

Pluginは便利だが、リスクの責任範囲を変える

すべての配信でserver-side fan-outが必要なわけではありません。Workstationに十分なencodingとuploadの余裕があり、operatorが操作をローカルに集約したく、pluginがインストール済みのOBS releaseで検証されているなら、保守されているmulti-output pluginは実用的です。Pluginは保守中のproject sourceから取得し、本番前にupdate状況を確認してください。

追加outputがすべて「無料」だと考えないでください。Main encoderを共有する構成もあれば、追加のencodingやscalingを実行する構成もあります。Network sessionごとに再接続動作も異なります。全outputを本番相当の時間動かし、その後1つの配信先とnetworkを遮断して、operatorに必要な操作を確認します。

配信先matrixの承認後にautomationを追加する

Scheduling systemやcustomer dashboardから配信先を作る場合は マルチプラットフォームlive streaming API workflowを使います。合格済みsource、output type、media profile、命名policyを維持します。Keyをbrowser logやclient-side analyticsに残さず、再試行で重複live routeを作らないようoperationをidempotentにします。

API responseはcontrol operationの完了を示すだけです。外部プラットフォームの準備、programの音声、視聴者が正しいeventを見ていることまでは証明しません。プラットフォームpreviewとdecoded mediaを合格判定に残してください。

公式リファレンス

• OBS Studioの概要 — 現行のStreamおよびOutput controlの考え方。
• OBS stream接続のトラブルシューティング — network、service、bitrateの問題を切り分ける手順。
• OBS Profilesガイド — profileが保持するoutput setting。

よくある質問

OBSは標準機能で1本のstreamを複数のプラットフォームへ送れますか？

標準のStream設定で指定できるのは、選択したserviceまたはcustom serverです。複数のローカルoutputには通常、保守されているpluginなどの外部方式が必要です。Server-side fan-outでは、OBSから1本のstreamをCallabaへ送り、そこで配信先を作成します。

Server-side multistreamingにはどの程度のupload bandwidthが必要ですか？

会場は、1本のcontribution feed、通常のoverhead、安全な余裕を持続して送れる必要があります。配信先へのegressはCallaba deploymentが担います。両方の境界を本番bitrateで測定してください。

配信先ごとに別のbitrateやresolutionを使えますか？

選択したCallaba route、codec profile、deployment capacityが必要な変換をサポートしていれば可能です。配信先の要件が文書化されている場合だけ別profileを追加し、decoded outputを検証してください。