コンテンツへ移動
Callaba
製品ユーザーガイド

SRT サーバー

パブリッシャーとレシーバーへの明示的なアクセスを使用して、低遅延の SRT コントリビューションを受信、保護、監視、ルーティングします。

Callaba での場所ストリーミング サーバー → SRT サーバー
このモジュールの役割

SRT サーバーは、管理されたコントリビューション エンドポイントです。実際のネットワークのレイテンシーと帯域幅を構成し、ネットワークを保護してから、プレーヤーの症状から推測するのではなく、テレメトリと制御されたルートを使用します。

Callaba でこのワークフローを続ける

Callaba SRT サーバー

すべてのライフサイクル変更はメディアが正常に流れていることの確認で終了し、リタイアによって下流の隠れた依存関係が残ることはありません。

製品の仕組みを見る

開始前の準備

  • 到達可能な UDP ポートと、可能な場合は必要なソースに制限されたファイアウォール ルール。

  • 実際の SRT エンコーダまたはテスト ソースと、VLC やダウンストリーム Callaba モジュールなどのレシーバ。

  • ネットワーク RTT と予想されるピーク ビットレートを測定しました。

設定の説明

運用者に必要なコントロールだけを説明し、内部フィールド名や実装イベントは表示しません。

リスナー

SRT エンドポイントの ID とネットワーク容量。

名前と有効状態

この SRT サーバーのオペレーター向けラベルとライフサイクル状態です。

リスナー ポート

UDP 着信 SRT 接続で使用されるポート。

受信ポート

構成されたワークフローの受信側で使用されるオプションの個別のポート。

レイテンシ

SRT 測定されたネットワーク パスのサイズの回復バッファ。

測定された RTT から開始し、代表的なパケット損失の下でテストします。
最大帯域幅

ヘッドルーム SRT は、メディア ビットレートに関連した再送信に使用できます。

受信バッファ

SRT 受信機で使用できるホスト バッファ。

接続タイムアウト

セッションが失敗として扱われるまでに、利用できないピアが解決されないままになるまでの時間。

セキュリティとアクセス

メディアを保護し、公開または受信できるユーザーを制限します。

パスフレーズ

許可されたピアによって共有されるオプションの SRT 暗号化シークレット。

強力なシークレットを使用し、URL とは別に配布します。
アクセスモード

明示的なストリーム アクセス オブジェクトを要求するか、ホストによって制限するか、より広範囲のアクセスを意図的に許可します。

発行者と受信者の役割

メディアを送信するクライアントと、メディアを消費するクライアントを分離します。

Rルーティングとリカバリ

このエンドポイントを 1 つ以上の SRT ピアに接続します。

Rルーティング モード

ルーティングを無効にするか、Callaba/パブリック アドレス ピア定義を使用します。

プッシュまたはプル

PUSH はリスナーに向けて送信します。 PULL は利用可能なソースに接続します。

Rホストのルーティング

構成されたルート ワークフローで使用される順序付けされたピア アドレス。

可観測性

トランスポートパラメータを変更する前にライブ証拠を使用してください。

統計間隔

Frequency サポートされている統計収集またはコールバックに使用されます。

ライブビットレート

メディアが現在到着しているかどうかを示します。

ネットワークRTT

SRT セッションによって報告された往復時間。

接続とイベント履歴

Session およびトランスポート イベントは、切断の診断に使用されます。

安全な初回ワークフロー

  1. 01

    未使用の UDP ポートと明確なオペレーター名を使用してサーバーを作成します。

  2. 02

    実際のパスを測定し、そのネットワークの遅延、最大帯域幅、タイムアウトを設定します。

  3. 03

    パスフレーズと明示的な発行者/受信者のストリーム アクセスを追加します。

  4. 04

    サーバーを起動し、1 つの実際のパブリッシャーに接続します。

  5. 05

    1 つの受信機またはダウンストリーム モジュールを接続し、ライブ ビットレートとネットワーク RTT を確認します。

  6. 06

    単一パスが安定した後でのみ、ルーティングまたはバックアップ PULL ソースを追加します。

ワークフロー例

使用する状況

SRT サーバーの作成、検証、編集、廃止

オペレーターは、保存されたフォームを作業用メディア パスと間違えることなく、SRT エンドポイントを変更する必要があります。

作成Rロール、ポート、アクセス
スタートEエンドポイントの準備が完了しました
検証実際のメディアと出力
編集保存、再起動、再テスト
引退依存関係を削除する
アニメーション付きワークフロー図: SRT サーバーの作成、検証、編集、廃止

構築手順

  1. 1

    役割、ポート、アクセス ポリシー、および予想されるメディア設定を使用してサーバーを作成します。

  2. 2

    それを開始し、パブリッシャーまたはレシーバーが期待するエンドポイントの状態になるまで待ちます。

  3. 3

    実際のメディアを接続し、ビットレート、画像、オーディオ、および意図されたダウンストリーム出力を確認します。

  4. 4

    編集する前に、フィールドの停止または再起動が必要かどうかを確認してください。変更を保存し、サーバーを復元して、同じメディア テストを繰り返します。

  5. 5

    サーバーを削除する前に、それに依存するすべてのルート、録画、マルチビュー タイル、および出力を削除または再割り当てしてください。

使用する状況

本番への安全なリモート貢献

フィールド エンコーダは、パブリック インターネット経由でフィードを送信します。

フィールドエンコーダー暗号化された SRT PUSH
アクセス ポリシー発行者 ID
Callaba SRT回復 + 監視
生産マルチビュー / 録画 / リストリーム
アニメーション付きワークフロー図: 本番への安全なリモート貢献

構築手順

  1. 1

    SRT リスナーを作成し、測定されたパスから遅延を測定します。

  2. 2

    パスフレーズを設定し、エンコーダーのパブリッシャー ストリームを作成します。

  3. 3

    エンコーダーを接続し、ビットレート、RTT、安定したセッション状態を確認します。

  4. 4

    マルチビュー、録画、またはリストリーミングで検証済みの SRT ソースを選択します。

使用する状況

プライマリおよびバックアップ SRT の貢献

Production には独立して到達可能な 2 つのフィードがあり、制御された回復パスが必要です。

プライマリーSRT プル
バックアップSRT プル
Callaba SRT再接続 / 切り替え
マルチビューオペレータープルーフ
出力生産フィード
アニメーション付きワークフロー図: プライマリおよびバックアップ SRT の貢献

構築手順

  1. 1

    独立してテストされたプライマリ ホストとバックアップ ホストを PULL ルーティング プランに追加します。

  2. 2

    順序付きルート ワークフローを有効にする前に、各ソースを単独で検証してください。

  3. 3

    マルチビューまたはオペレーター インターフェイスで両方のソースのヘルス状態を監視します。

  4. 4

    計画的な切り替えの場合は、優先ルート制御を使用します。再接続回復の場合は、アクティブなセッションと出力を観察します。

  5. 5

    メンテナンス期間中のソース損失をシミュレートし、回復動作を記録します。

使用する状況

1 つのマルチトラック SRT プログラムからの多言語ブラウザ イベント

Production は、完成した複数の言語または解説トラックを含む 1 つの SRT/MPEG-TS プログラムを提供します。

マルチトラック SRT1 つのプログラム
SRT サーバー聴く + トラックに名前を付ける
ウェブ プレーヤーそれぞれ 1 曲ずつ選択
言語グループ視聴者が言語を選択
アニメーション付きワークフロー図: 1 つのマルチトラック SRT プログラムからの多言語ブラウザ イベント

構築手順

  1. 1

    マルチトラック SRT ソースを受信し、生成されたすべてのオーディオ トラックが存在することを確認します。

  2. 2

    SRT サーバー統計で検出されたトラックを聞き、オペレーターが判読できる言語名を割り当てます。

  3. 3

    視聴者の言語ごとに 1 つの Web プレーヤーを作成します。 「オーディオ トラックの変更」を「オーディオ トラックの選択」に設定し、目的のソース インデックスをマッピングします。

  4. 4

    これらのプレーヤーを言語リスト グループに追加し、デフォルトの言語を選択します。

  5. 5

    クリーンなブラウザ セッションで切り替え、アクセス ルール、再生をテストします。

使用する状況

個別の SRT フィードからの多言語ブラウザ イベント

Production は、完成した各言語を 1 つのマルチトラック プログラムではなく、独立した SRT フィードとして提供します。

言語フィード各 1 つの SRT フィード
SRT サーバー受信+モニター
ウェブ プレーヤー各プレイヤー 1 人
言語グループViewer が言語を選択します
アニメーション付きワークフロー図: 個別の SRT フィードからの多言語ブラウザ イベント

構築手順

  1. 1

    生成された言語ごとに 1 つの独立した SRT ソースを受信して検証します。

  2. 2

    検証済みフィードごとに Web プレーヤーを 1 つ作成し、視聴者に合わせた名前を付けます。

  3. 3

    これらのプレーヤーを言語リスト グループに追加し、デフォルトの言語を選択します。

  4. 4

    クリーンなブラウザ セッションで切り替え、アクセス ルール、再生をテストします。

結果を確認

  • 実際のパブリッシャーとレシーバーは、計画されたテスト期間中接続されたままになります。
  • Live ビットレートによりメディアの到着が確認され、ネットワーク RTT がテスト済みのレイテンシー バジェット内に留まっていることが確認されます。
  • 承認されていないストリーム ID またはホストは、選択したアクセス ポリシーによって拒否されます。
  • バックアップ ソース テストにより、文書化されたリカバリ動作が生成されます。

トラブルシューティング

Session は接続しますが、メディアが切断されます

確認項目
  • 利用可能なアップロードとビットレートを比較します。
  • RTT とパケット損失の動作を確認します。
  • 遅延と最大帯域幅を確認します。
次に行うこと

測定された証拠に基づいてのみ回復ヘッドルームを増加します。ソースのビットレートやネットワークのボトルネックも修正します。

パブリッシャーが接続できません

確認項目
  • UDP ファイアウォールとパブリック アドレスを確認します。
  • ポート、モード、パスフレーズ、およびストリーム ID を照合します。
次に行うこと

ダウンストリーム モジュールを使用せずに 1 つのパブリッシャーをテストし、検証されたレシーバー パスを復元します。

バックアップが期待どおりに引き継がれません

確認項目
  • 両方のソースを個別に検証します。
  • ルートの順序、モード、タイムアウトを確認します。
  • O障害時のアクティブなセッションを観察します。
次に行うこと

失敗したソースまたはルーティング定義を修正し、制御された失敗テストを繰り返します。