コンテンツへ移動
Callaba
料金ログインCallabaをAWSにデプロイ推奨リージョン: Tokyo.

Callaba · クラウド＆セルフホスト

ライブ制作向けSRTサーバーソフトウェア

リモートカメラのフィードや完成プログラムを受信します。ブラウザーで映像、音声、接続状態を監視してから、ソースをルーティングまたは録画します。対応するデプロイ環境では、Video Mixerでライブ制作を追加できます。

ライブSRT接続を試す構成を選ぶ

お客様が運用するAWSアカウントまたはLinuxインフラストラクチャーで実行します。

ライブSRTデモ

ライブSRT接続を試す

1時間有効な一時接続を作成します。Callerモードでパブリッシャーアドレスへフィードを送信し、 Stream IDは空のままにします。 下のMultiviewで視聴するか、Callerモードで受信側アドレスに受信側を接続します。

作成可能

サーバー制御

SRT接続とサーバーログを監視

ダッシュボードを離れずに、接続中のパブリッシャー、そのビットレートとRTT、接続イベントを確認できます。

接続する相手を制御

Stream IDまたはピアIPルールでパブリッシャーと受信側のアクセスを制御します。暗号化を有効にする場合は、対応するSRTパスフレーズを設定します。

ネットワーク経路を確認

受信側またはエンコーダーを変更する前に、ビットレート、RTT、パケット損失、接続中のピアを確認します。

接続エラーを見つける

サーバー設定からShow logsを開きます。更新を停止し、時刻またはメッセージで検索して、必要なイベントをエクスポートします。

自前のSRTサーバー

最初の接続を作成する

エンコーダーと受信側の接続方法を選びます。プレースホルダーをCallabaダッシュボードに表示される値に置き換えてください。

接続パターン

ホストとポートのパターン異なる2つのUDPポート：1つはパブリッシャー用、もう1つは受信側用。Stream IDは意図して空にします。

パブリッシャーアドレス

srt://example.invalid:YOUR_PUBLISHER_PORT?mode=caller

パブリッシャーUDPポートを使用します。この個別ポートパターンではStream IDを空にします。

受信側アドレス

srt://example.invalid:YOUR_RECEIVER_PORT?mode=caller

異なる受信側UDPポートを使用します。ここでもStream IDは空のままにします。

サーバーを準備

「Streaming servers → SRT servers」でListenerを作成し、UDPポートを予約します。「Streams」で、意図したパブリッシャーと受信側のロールに空のStream IDを許可します。

両エンドポイントを設定

エンコーダーと受信側をCallerに設定し、それぞれのアドレスを貼り付けます。CallerとListenerはセッションを開始する側を表し、メディアの方向を表すものではありません。

映像と音声を確認

送信元を開始します。Statisticsでパブリッシャーと受信ビットレートを確認してから、受信側で映像と音声を確認します。

エンコーダーと受信側の設定

エンコーダーと受信機を接続する

OBS、vMix、またはSRTエンコーダーからパブリッシャーアドレスへ送信します。受信アプリケーションで受信機アドレスを開きます。各端の接続設定を一致させ、受信機がメディア形式をサポートしていることを確認してください。

プロダクション、監視、配信

番組を作る、または完成済みの番組を取り込む

SRTフィードはCallabaの他の機能で利用できます。既存のプロダクション環境を維持してその出力をここで扱うことも、カメラをVideo Mixerに取り込んでブラウザーで番組を制作することもできます。

監視

各Multiviewタイルのストリーム情報とともに、着信映像と音声を並べて確認します。

Multiviewを見る

ミキシング

ライブソースとメディアをシーンで組み合わせます。次のショットをPreviewで準備し、Programへ送出して音声をミックスします。

SRT送信元をミキシング

実行場所を選ぶ

AWSまたは自社Linuxサーバー。

フィードを実行する場所の制御を維持できます。Callabaはブラウザーのワークスペースを提供し、ホスト、ネットワークアクセス、ストレージはチームが運用します。

AWSアカウントにデプロイ

AWS Marketplaceで現在のソフトウェア料金とサブスクリプション条件を確認してください。EC2、ストレージ、データ転送は別途インフラコストです。

AWSにデプロイ ↗

Linuxサーバーにインストール

対応Linuxホスト、VM、またはプライベートクラウドを使います。最新のインストールガイドに従い、ワークフローに必要なモジュールユニットをライセンスします。

セルフホスト版をインストール →

ワークフローから始める

何を実行しますか？

ワークフローを選ぶと、下のモジュール数が置き換わります。環境に合わせて調整し、ソフトウェア料金の更新を確認してください。

1つのソースを受信して転送

1本の入力SRTソースと、独立した1つの転送またはリストリームタスク。

4本の入力ソースを監視

4本の入力ストリームを同時にMultiviewで表示します。

3つのカメラソースで制作

3台の入力カメラ、3つのMixer入力とMultiviewソース、1つの録画と1つのリストリームタスク。

現在の選択: カスタム構成。

構成ビルダー

SRTワークフローの料金を確認。

同時に実行するモジュールを選びます。ソフトウェアとインフラストラクチャーは別料金です。

月額・モジュールごと：ユニット1～20は $6、21～40は $5、41以降は $4。各階層はその範囲のユニットだけに適用されます。

入力ストリーム
再配信とトランスコードのタスク
録画
Multiview
AV Mixer 入力
SRT リカバリーパス
さらにモジュールを表示
VOD 視聴者
ペイパービュー視聴者
ビデオ通話の参加者
NDI アダプター
API アクセス
料金とワークロード計画の全体を見る

容量計画

ストリーム、処理、ストレージを考慮する

同時送信元と宛先を数えます。再送のためのネットワーク容量と録画のためのディスク容量を確保してください。Multiview、ミキシング、トランスコードは、同じエンコード済みフィードの転送を超える処理負荷を追加します。

接続確認

SRT接続をトラブルシューティング

エンコーダーが接続しない

サーバーが有効であること、パブリックアドレスとパブリッシャーUDPポートが正しいこと、ファイアウォール、NAT、AWSセキュリティグループがトラフィックを許可していることを確認します。次に、両端で許可されたStream IDとパスフレーズを確認します。

コーデック設定を変える前に、イベント履歴とShow logsで接続試行を確認してください。

接続済みだが映像または音声がない

まず受信ビットレートがあることを確認します。受信側ポートまたは対になる受信側Stream IDが意図したフィードを選択していることを確認します。次に、受信アプリケーションに対してコンテナー、映像コーデック、音声トラックを確認します。

ブラウザーでの視聴には互換性のある再生経路が必要です。ブラウザーは生のSRT URLを直接再生しません。

映像が乱れる、またはストリームが切断される

同じ区間のビットレート、RTT、パケット損失を比較します。アップリンク容量と再送の余裕を確認してから、レイテンシー設定を見直します。大きなバッファでも、継続的に不足するアップリンクは直りません。

対応するサーバーログをエクスポートし、切断と送信元またはネットワークのイベントを関連付けます。

SRT Serverに関する質問

Stream IDは必要ですか？

デモで使う個別のパブリッシャー／受信側ポートでは空のままにします。共有Listenerポートでは、対になるパブリッシャーと受信側IDを使います。2つの接続方法を参照してください。

SRTフィードをYouTubeまたはTwitchへ送れますか？

Callabaで送信元を受信してから、宛先のストリームURLとキーを指定したリストリーミングタスクを作成します。そのプラットフォームが必要とする映像・音声設定に合わせてください。

複数のSRT送信元をミキシングできますか？

はい。SRT送信元をAV Mixerに追加し、Previewでシーンを組み立て、CUTまたはFADEで次のシーンをProgramへ送ります。カメラまたはその他の各ミキサー入力は1ユニットを使用します。現在のMixer入力料金を参照してください。

SRTサーバーの選択肢の中でCallabaはどう位置付けられますか？

誰がサーバーを運用するか、インジェスト後に何を行う必要があるかから始めてください。CastrやIN/OUT-SRTのようなホステッドサービス、MediaMTXやSRSのようなオープンソースサーバー、SRT Mini ServerのようなWindowsソフトウェアは、それぞれ異なる運用モデルに適しています。CallabaはAWSまたはお客様のLinuxインフラストラクチャー上で、ブラウザー制御と接続済み映像モジュールを提供します。

主なタスクがエンドポイント間のルーティングなら、SRT Gatewayワークフローも確認してください。

APIアクセス

curlでSRTサーバーを一覧表示

この読み取り専用リクエストは設定済みSRTサーバーを返します。ホストとAPIトークンをサーバーの値に置き換えてください。このリクエストは設定を変更しません。

curlでSRTサーバーを一覧表示
curl --request POST 'https://YOUR_CALLABA_SERVER/api/srt-servers/getAll' \
  --header 'x-access-token: YOUR_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"limit":10,"skip":0,"sort":{"server_created":1}}'

Ask AI

接続ガイドと技術リファレンスモード、ポート、遅延、アクセス、トラブルシューティング
プロトコルの説明をお探しですか？

SRT接続リファレンス：ポート、Stream ID、レイテンシー

個別ポートまたは対になるStream IDの設定、トランスポート状態の確認、レイテンシーの設定、ライブコントリビューション経路の診断に使える実践的なSRTサーバーリファレンスです。

コントリビューション区間にはSRTを使う

SRTサーバー（SRTライブサーバー）は、SRTコントリビューションセッション用に設定するエンドポイントです。SRTはUDPで動作し、接続モード、リカバリー、任意の暗号化を提供します。SRTプロトコル草案でトランスポートが説明されています。

Callerはセッションを開始し、Listenerは接続を待ちます。この名称はメディアの方向を示しません。関連するエンドポイントまたは下流ジョブでパブリッシャーか受信側かを設定してください。

アクセス方式を統一する

サーバーはStreaming servers → SRT serversで作成します。Streamsでパブリッシャーと受信側のアクセスを許可し、そのサーバーのホストと割り当てられたUDPポートを使用します。

個別ポートでは、パブリッシャー用と受信側用に各1ポートを予約します。StreamsエントリーとエンドポイントURLでは空のStream IDが有効です。共有Listenerポートでは、同じサーバーコードとStream IDを持つパブリッシャー／受信側アクセスエントリーを対にし、publisher/…とreceiver/…のプレフィックスを使います。テストでは識別子を混在させず、どちらか一方の方式を選んでください。

選択したUDPポートまたは範囲をホストのファイアウォールとネットワーク境界で開放します。NAT配下のCallerは到達可能なListenerへアウトバウンド接続できます。実際の送信元ネットワークからテストしてください。暗号化を有効にする場合は、両エンドポイントに同じパスフレーズを設定します。

FFmpegでテストする

個別のパブリッシャー／受信側ポートと空のStream IDを設定したサーバーの例です。ホスト、割り当てポート、入力ファイルを置き換えてください。FFmpegのSRTプロトコル文書でURLオプションが定義されています。

ローカルMPEG-TSファイルを送出する

Command 
ffmpeg -re -stream_loop -1 -i input.ts -c copy -f mpegts "srt://YOUR_CALLABA_HOST:YOUR_ASSIGNED_PUBLISHER_PORT?mode=caller&latency=200000"

受信側ポートから受信する

Command 
ffplay "srt://YOUR_CALLABA_HOST:YOUR_ASSIGNED_RECEIVER_PORT?mode=caller&latency=200000"

FFmpegのlatency=200000は、オプションがマイクロ秒単位のため200 msの例です。本番のレイテンシーは、測定したRTT、損失、許容されるエンドツーエンド遅延から決めてください。SRTレイテンシーガイドも参照してください。

使う経路を事前確認する

  • イベントで予定しているホスト名、UDPポート、アクセス方式、パスフレーズで送信元ネットワークからテストする。
  • 受信セッションだけでなく、選択したストリームの宛先映像とプログラム音声を確認する。
  • 有効な設定を保存し、送信元、サーバー、宛先で対応するログ時刻を記録する。
  • イベントで使う場合のみフェイルオーバー手順をテストし、宛先の挙動とオペレーターの引き継ぎも含める。

現実的な運用上限を設定する

SRTレイテンシーはトランスポートのリカバリーバッファであり、グラス・ツー・グラス遅延の全てではありません。キャプチャー、エンコード、受信側バッファ、デコード、パッケージング、プレーヤーバッファも時間を加えます。バッファを減らす前に経路全体を測定してください。

同時ストリーム、測定ビットレート、再送、監視、有効な下流ジョブに合わせてネットワークとホストのリソースを計画します。長時間イベントの前には、キューイング、リソース競合、送信元接続の不安定さが現れるまで、計画した全負荷を十分に観測してください。メイン／バックアップのトランスポート経路は切り替え時も接続済みの受信側とPullerセッションを維持できます。イベントで頼る前に、フィード、バッファ、宛先の挙動をテストしてください。

その他のセットアップガイド

実際のフィードで開始

導入モデルに合わせてCallaba SRT Serverを評価

クラウドで起動する、Linuxにインストールする、または自動化の前にライブMultiviewを確認できます。

SRTの構成とワークフローをさらに詳しく見る