SRTコントリビューションをCallabaに取り込み、確認してから次の受信機を選びます。SRT受信機がソースメディアをすでに受け入れる場合にのみリレーを使います。処理が必要なRTMP公開出力にはRestreamingを、プロダクションネットワークへの引き渡しにはNDIワークフローを使用します。
1つのソースとその次の受信機から始めます。以下の経路では、制御されたインジェスト、透過的リレー、RTMP処理、名前付き接続を分けています。経路が稼働した後、選択した宛先を検証してください。
ライブSRTゲートウェイデモ
1時間有効な一時SRT接続を作成します。Callerモードでパブリッシャーアドレスへ送信元を送信し、 Stream IDは空のままにします。 Callerモードで受信側アドレスに受信側を接続します。パブリッシャーの接続後、Multiviewプレビューで映像と音声を確認してください。このテストではストリーム変換もフェイルオーバーの実証も行いません。
選ぶ場面Callabaが特定のパブリッシャーまたは受信側を受け入れる必要がある場合はSRT Serverを使用します。
選ぶ場面ソースとSRT受信機がコンテナー、コーデック、トラックについてすでに一致している場合にSRT Routeを使用します。メディアを変更せずにトランスポートをリレーします。
選ぶ場面変換、トランスコード、リサイズ、音声変更、オーバーレイが必要なRTMP公開出力にはRestreamingを使用します。プロダクションネットワークへの引き渡しにはNDIワークフローを使用します。
選ぶ場面既存のSRT Serverで名前付きのパブリッシャーまたは受信側接続が必要な場合はSRT Streamを使用します。
経路を選択した後、これらの簡潔なリンクで文書化されたメーカーの引き渡し方法を確認します。セットアップの開始点であり、デバイス認定や同一のファームウェア動作を約束するものではありません。
ソース、受信機、そして受信機が実際に必要とするメディア変更から始めます。 SRT Route は透過的なSRT-to-SRTリレー用です。コントリビューションを転送するため、受信機はコンテナー、コーデック、トラック、タイムスタンプをすでに受け入れられる必要があります。ソースメディアをリレーするものであり、ブラウザー出力を作成するものではありません。
次のジョブがRTMP公開なら、Restream出力を構成し、その宛先で必要な場合にのみ処理を有効にします。次のジョブがNDIプロダクションへの引き渡しなら、NDI出力経路を構成し、設計されたプロダクションネットワークで検証します。制御されたインジェストにはSRT Serverを、既存サーバー上の名前付き接続にはSRT Streamを使用します。ソースが接続されていることは、下流の受信機がフィードを受け入れた証拠ではありません。
| 着信SRTジョブ | 選択 | 遠端で検証 |
|---|---|---|
| SRT → SRT受信機 | 両方のエンドポイントがすでにソースメディアを受け入れる場合は、SRT Route。 | 受信機の接続、デコードされた映像、番組音声。 |
| SRT → RTMPパブリッシャー | 必要なRTMP宛先と、その出力に必要なメディア処理だけを使ったリストリーミング。 | RTMP受信機または配信プラットフォームが、意図した番組を受け入れること。 |
| SRT → NDIプロダクションへの引き渡し | 選択したデプロイメントとプロダクションネットワークに対応するNDI出力ワークフロー。 | 意図したNDI受信機で映像と番組音声が確認できること。 |
トランスコード、リサイズ、音声変更、オーバーレイには、リレーを超える処理作業が加わります。計画したソース、出力プロファイル、ホスト容量、宛先をまとめてテストしてください。インジェスト接続が緑色だからといって、最終出力を推測しないでください。
| 表示される状況 | 次に確認すること |
|---|---|
| パブリッシャーは接続済み、受信側にビットレートがない | ルートが意図した入力と出力を選択していることを確認し、受信側のホスト、ポート、Caller/Listenerロール、Stream ID、パスフレーズを比較します。 |
| 受信側にビットレートはあるが映像またはプログラム音声がない | 受信側でコンテナー、コーデック、トラック、タイムスタンプを確認します。SRTトランスポートは未対応ペイロードをデコード可能にはしません。 |
| イベントネットワークで映像が乱れる | 実際の経路でRTT、損失、再送、有効レイテンシーを比較します。送信元、ルート、受信側を一緒にテストしてください。 |
送信元と宛先のホスト、ポート、ロール、アクセス状態を記録します。セッションが拒否された場合や誤ったストリームに到達した場合は、エンドポイントログを使用してください。
送信元の稼働中に、ビットレート、RTT、パケット損失、接続イベント、ピア詳細を監視します。保存済みルートや実行中プロセスでは、宛先が受け入れたかは分かりません。
選択した受信機、プレーヤー、または Multiview タイルで映像と番組音声を確認します。Multiviewは監視の引き渡し先であり、リレーを本番用スイッチャーに変えるものではありません。
一時的なゲートウェイデモでは、1つのパブリッシャーと1つの受信機の接続をテストし、パブリッシャー接続後にMultiviewでプレビューします。ストリームの変換、プロトコル変換、フェイルオーバーの実証は行いません。
メイン／バックアップのコントリビューションでは、SRT RoutingでSRT main/backup failoverを選択し、Pullに移動し、両方のコントリビューションにソースホストとルーティングポートを入力します。トリガーと宛先に期待する動作をイベント計画に記載し、イベント前に実際のフィード、バッファー、宛先の動作をテストしてください。トランスポートの切り替えでは接続済みの受信機およびプラーのセッションを維持できますが、映像の切り替わりは、準備したフィード、バッファー、ネットワーク条件、宛先によって決まります。
ゲートウェイはAWS上、またはチームが管理するLinuxインフラストラクチャー上で実行します。メディア経路、ファイアウォールポリシー、運用チームに適した場所を選んでください。SRT経路を受け入れた後は、 Multiview を使用して選択したフィードを監視するか、 AV Mixer ワークフローを評価してください。これは、完成したフィードをリレーするのではなく、番組を作成して送出するジョブの場合に使用します。
ポートとアクセス設定にはSRT Serverガイドを、デコーダー設定または黒画面にはSRT Playerガイド。エンドツーエンドでテスト済みの経路だけを自動化してください。
まずインジェスト、透過的リレー、RTMP公開、NDIプロダクションへの引き渡しを選びます。次に、選択したエンコーダーまたはカメラの構成開始点としてデバイスディレクトリーを使用します。デバイスをイベント経路で使用する前に、インストール済みのファームウェア、SRTモード、ポート、Stream ID、暗号化、ペイロード設定をメーカー文書と照合してください。
小規模な開始構成については、 SRTリレープリセットを確認してください。これは1つのストリームと1つのRestreamジョブから始まります。実際のソース、宛先、受信機テストは、引き続きご自身で構成する必要があります。
