Callaba SRT Server

SRTサーバーとは？

ここでいう SRTサーバー とは、SRT接続を受け付け、管理するエンドポイントです。エンコーダーからライブSRTストリームを受信して別のシステムへ中継したり、遠隔ソースと制作プラットフォームの間の管理された受け渡し地点として機能したりします。

一般的なライブワークフローでは、SRTサーバーは実務上、次の4つの役割を担います。

• ライブフィードを受信する： カメラエンコーダー、OBS、vMix、FFmpeg、Larixなどのソースがサーバーへ映像を送信します。
• コントリビューション経路を保護する： SRTは失われたパケットを復旧し、伝送セッションを暗号化できます。
• ライブ統計を表示する： オペレーターはビットレート、RTT、パケットロス、再送、接続状態を監視できます。
• ストリームを下流へ渡す： サーバーはフィードを録画、トランスコード、再配信、スイッチング、再生の各ワークフローへルーティングできます。

このように、SRTサーバーはソース側とプラットフォーム側の境界になります。遠隔スタッフが“送信中です”と言ったとき、信号が実際に到着しているか、安定しているか、下流で利用できるかを確認する場所がSRTサーバーです。

SRTサーバーとSRTプロトコルの違い

ここでいう SRTプロトコル は伝送方式であり、一方、 SRTサーバー は、そのプロトコルを使ってライブストリームを受信または送信するシステムやソフトウェアのエンドポイントです。

SRTライブサーバーとは？

ここでいう SRTライブサーバー とは、リアルタイムまたは準リアルタイムのライブ映像コントリビューションに使うSRTサーバーです。イベントの進行中にライブストリームを受信し、ライブ制作、録画、配信のワークフローへ転送します。

SRTライブサーバーは、遠隔イベントからのコントリビューション、カメラやエンコーダーからのクラウドインジェスト、スタジオからクラウドへの伝送、パートナーフィードの受け渡し、バックアップのコントリビューション経路、リモート制作、複数宛先への再配信に使われます。

“ライブ”という点が重要なのは、SRTの調整がファイル転送とは異なるためです。サーバーは遅延と復旧のバランスを取る必要があります。実際のネットワーク経路に対して遅延設定が低すぎると、接続はできてもパケットロスやジッター時に映像が途切れる場合があります。

SRTサーバーの仕組み

SRTサーバーは、SRT接続を介してエンコード済みの音声と映像を受信します。SRTが伝送する前に、メディアはすでにエンコードされています。ライブ映像ワークフローでは、多重化されたMPEG-TSストリームをSRTで運ぶことが一般的ですが、実際のコンテナは送信側とワークフローによって異なります。実務では通常、H.264やH.265/HEVCなどの映像、AACなどの音声、ときにはメタデータを含む、完成したメディアストリームを受信します。

1. エンコーダーがライブ音声と映像のストリームを作成します。
2. エンコーダーがストリームをSRTサーバーへ送信します。
3. SRTサーバーがストリームを受信し、接続状態を追跡します。
4. パケットが失われた場合、まだ利用価値がある間にSRTが再送を要求できます。
5. サーバーが次の工程へストリームを渡します。録画装置、トランスコーダー、再配信、スイッチャー、APIワークフロー、再生システムなどです。

Caller、Listener、Rendezvousモード

SRTには3つの接続モードがあります。どちら側が接続を開始するか、ファイアウォールやNATを介してセッションをどのように確立するかをモードが決めます。

• Listener： 既知のUDPポートで受信SRT接続を待ちます。クラウドインジェストサーバーやデータセンターのエンドポイントで一般的なモードです。
• Caller： Listenerへの接続を開始します。現場のエンコーダー、OBS、vMix、FFmpeg、モバイルアプリ、遠隔ソースで一般的です。
• Rendezvous： 両側が接続を開始します。一部のNAT環境で役立ちますが、本番前に慎重なテストが必要です。

SRTサーバーのポートとファイアウォール規則

SRTはUDPを使用します。そのため、クラウドのセキュリティグループ、ホストのファイアウォール、ルーター、ネットワークポリシーで、正しいUDPポートを開ける必要があります。

• サーバーにパブリックIPまたは到達可能なネットワークアドレスがあること。
• 正しいUDPポートが開いていること。
• エンコーダーが正しいCaller/Listenerモードを使用していること。
• Stream IDを使用する場合、サーバーのルーティング規則と一致していること。
• 暗号化する場合、両側のパスフレーズが一致していること。
• 受信ワークフローが正しい下流出力にマッピングされていること。

エンコーダーに“接続済み”と表示されることだけを確認するのは、よくある誤りです。接続だけでは不十分です。メディアが到着していること、ビットレートが安定していること、下流システムがストリームを利用できることも確認してください。

SRTサーバーの設定例

これは実用的な初回テスト構成です。ホスト、ポート、Stream ID、パスフレーズは実際の値に置き換えてください。

Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

ライブストリーミングワークフローにおけるSRTサーバーの位置

SRTは通常、ワークフローのコントリビューション側、つまりライブフィードがソースからプラットフォームへ移動する部分で最も力を発揮します。

カメラまたはエンコーダー → SRTサーバー → トランスコーダー / 録画装置 / 再配信 / プレーヤーワークフロー

SRTサーバーがストリームを受信した後、プラットフォームは再配信、録画、トランスコード、再生、ルーティング、フェイルオーバー、APIワークフロー、本番監視のためにストリームを処理できます。

SRTサーバーとRTMP、HLS、WebRTC、NDIの違い

SRTは、すべての映像技術に取って代わるものではありません。ワークフローの特定部分を解決します。

プロトコル単位の比較については、 SRTとRTMPの比較をご覧ください。

SRTサーバーを導入する方法

具体的な設定はソフトウェア、クラウドプロバイダー、ワークフローによって異なりますが、導入の考え方は通常同じです。

1. サーバーまたはクラウドインスタンスを作成 し、ワークフローに十分なCPU、ネットワーク容量、ストレージを用意します。
2. 必要なUDPポートを開放 し、クラウドのセキュリティグループとホストのファイアウォールに適用します。
3. SRT Listenerを作成 し、受信ストリームを受け付けます。
4. Stream IDとパスフレーズの規則を設定 し、必要に応じてルーティングと暗号化を行います。
5. エンコーダーを接続 し、SRT CallerとしてListenerエンドポイントへストリームを送信します。
6. ライブ統計を確認 します。ビットレート、RTT、パケットロス、再送、接続状態などです。
7. ストリームを下流へルーティング し、録画、再配信、トランスコード、再生に使用します。

CallabaでSRTサーバーを使用する方法

Callabaでは通常、SRTサーバーを管理されたインジェストポイントとして使用します。遠隔ソースがCallabaへストリームを送信し、Callabaが次のワークフロー工程で利用できるようにします。

一般的なCallabaワークフロー：

• SRTエンコーダーからCallabaへ送信し、TwitchやYouTubeへ再配信。
• OBSからSRT経由でCallabaへ送信し、ストリームを録画。
• vMixからSRT経由でCallabaへ送信し、別の宛先へフィードをルーティング。
• モバイルアプリからSRT経由でCallabaへ送信し、ソーシャルプラットフォームへ再配信。
• 遠隔会場からCallabaへ送信し、ブラウザー再生向けにパッケージング。
• SRT入力をブラウザーのマルチビュー、録画装置、APIルーティング、管理されたプレーヤー配信へ接続。

SRTサーバーで監視すべき項目

SRTセッションが接続されても、ストリームが正常とは限りません。伝送状態とメディア状態の両方を監視してください。

伝送シグナル

• 接続状態： 接続、切断、再接続中、失敗。
• 受信ビットレート： メディアが想定レートで流れ続けているか。
• RTT： 送信側と受信側の往復時間。
• パケットロス： 経路上で失われているデータ量。
• 再送： 欠落パケットをSRTが復旧する頻度。
• ジッター： パケット到着時刻のばらつき。
• 受信バッファーの圧力： 接続が復旧限界に近づきすぎていないか。

メディアシグナル

• 黒画面、映像のフリーズ、音声の欠落または無音。
• 誤ったコーデック、フレームレート、解像度、音声形式。
• 不正なタイムスタンプ、キーフレームの欠落、互換性のないストリームマッピング。

SRTサーバーでよくある問題

SRT接続が開始しない

接続モード、UDPポート、パブリックIP、ファイアウォール規則、Stream ID、暗号化パスフレーズを確認してください。SRTハンドシェイク失敗の多くは、モードの誤り、UDPトラフィックの遮断、ポートの誤り、セキュリティ設定の不一致が原因です。

ストリームは接続するが映像が不安定

RTT、ジッター、パケットロス、再送、遅延設定を確認してください。ネットワーク経路に対して遅延値が低すぎると、失われたパケットが役に立たなくなる前にSRTが復旧できない場合があります。

ストリームは接続するが音声がない

まずエンコーダーを確認してください。音声ソースが有効で、正しい音声デバイスが選択され、音声コーデックが次のワークフロー工程と互換性があり、受信アプリケーションが音声トラックを読み取れることを確認します。

SRTサーバーを調べる前に、ソース側に音声があることを確認してください。ネットワークやサーバーを疑う前に、OBS、vMix、ハードウェアエンコーダーのローカル監視、ヘッドホン、端末のプレビューを使います。

SRT統計は良好だが視聴者側に問題がある

SRTリンクが正常でも、視聴者側で停止やアーティファクトが見える場合、問題は下流にある可能性があります。トランスコード、パッケージング、オリジン、CDN、プレーヤーの動作、出力形式を確認してください。チェーン全体を確認する前にSRTサーバーを原因と決めつけないでください。

セルフホスト型とマネージド型SRTサーバー

SRTサーバーは自分で運用することも、マネージドプラットフォームを使用することもできます。適切な選択は、チームがどこまで運用管理を担いたいかによって決まります。

Callabaは、クラウド型またはセルフホスト型のSRTワークフロープラットフォームとして利用できます。AWSで起動するか自社サーバーにインストールし、SRTインジェストポイントを作成して、再配信、録画、ルーティング、ブラウザープレビュー、マルチビュー、プレーヤー配信、APIワークフローへ接続できます。

SRTサーバーのイベント当日チェックリスト

• サーバーのIPまたはホスト名を確認する。
• UDPポートが開いていることを確認する。
• 両側のCaller/Listener/Rendezvousモードを確認する。
• 使用する場合はStream IDを確認する。
• 使用する場合は暗号化パスフレーズを確認する。
• 想定ビットレート、コーデック、フレームレート、解像度、音声形式を確認する。
• ストリームを開始して受信ビットレートを確認する。
• RTT、パケットロス、再送、ジッターを確認する。
• 接続状態だけでなく、実際の映像と音声を確認する。
• 下流ルート（録画、再配信、トランスコード、再生）を確認する。
• 時刻同期を確認する。トラブルシューティング中にログと録画を関連付けられるよう、サーバーとエンコーダーでNTPなど一貫した時刻源を使用します。
• イベント開始前にバックアップ経路をテストする。

公式資料と関連情報

プロトコルレベルのSRT詳細、Callabaの設定資料、関連ワークフローガイドが必要な場合に参照してください。

• SRTプロトコル草案
• Haivision SRT Live Transmitドキュメント
• SRTプロトコルとは？
• OBS StudioでSRTストリーミングを開始する方法
• OBS StudioでSRTストリームを受信する方法
• vMixでSRTストリームを送受信する
• SRT設定に最適な遅延を見つける
• SRTサーバーAPIドキュメント

よくある質問

SRTサーバーとは？

SRTサーバーは、SRTストリームを受信、送信、ルーティングするライブ映像のインジェストまたは中継エンドポイントです。通常、エンコーダー、カメラ、遠隔会場、スタジオ、モバイル端末、パートナーシステムからのライブフィードを、管理されたメディアワークフローへ渡すために使います。

SRTライブサーバーとは？

SRTライブサーバーは、リアルタイムのライブ映像コントリビューションに使うSRTサーバーです。イベント中にライブ映像を受信し、録画、再配信、トランスコード、スイッチング、ルーティング、再生の各ワークフローへ渡します。

SRTサーバーとストリーミングサーバーは同じですか？

必ずしも同じではありません。SRTサーバーは通常、管理されたエンドポイント間のライブインジェストや伝送を扱います。完全なストリーミングプラットフォームは、トランスコード、録画、視聴者向け再生、分析、アクセス制御、APIワークフロー、CDN配信も扱う場合があります。

SRTサーバーはUDPを使用しますか？

はい。SRTはUDP上で動作します。そのため、サーバーのファイアウォール、クラウドのセキュリティグループ、ルーター、ネットワークポリシーで正しいUDPポートを開ける必要があります。

SRTサーバーはどのポートを使用しますか？

SRTには全環境共通の固定ポートはありません。ポートはサーバー設定で決まります。本番環境では通常、SRTインジェスト用に明確なUDPポートまたはポート範囲を予約し、各ポートを利用するフィード、テナント、イベントを記録します。

SRTサーバーはListenerとCallerのどちらにすべきですか？

多くのクラウドインジェストワークフローでは、SRTサーバーをListener、エンコーダーをCallerにします。サーバーにパブリックIPまたはDNS名、既知のUDPポート、明確なファイアウォール規則があれば、安定して動作します。

OBSからSRTサーバーへ送信できますか？

はい。SRT出力URLを設定すれば、OBSからSRTサーバーへ映像を送信できます。サーバーがストリームを受信し、録画、再配信、トランスコード、再生の各ワークフローへルーティングできます。

vMixからSRTサーバーへ送信できますか？

はい。vMixはSRTワークフローに対応し、SRTストリームを送受信できます。一般的な構成では、vMixからCallabaへSRTを送信し、Callabaが監視、ルーティング、録画、再配信を処理します。

SRTはRTMPより優れていますか？

不安定、損失がある、長距離といったネットワークでのコントリビューションでは、通常SRTがRTMPより適しています。RTMPは簡単な配信やプラットフォームへのインジェストで今も一般的です。多くのワークフローでは、コントリビューションにSRTを使い、ソーシャルプラットフォームへの最終配信にRTMPまたはRTMPSを使います。

ブラウザーでSRTを直接再生できますか？

通常のWebワークフローでは、ブラウザーはSRTを直接再生しません。SRTサーバーが先にストリームを受信し、その後プラットフォームがHLSやWebRTCなど視聴者向けの形式に変換またはパッケージングします。

SRTストリームが接続するのに映像が表示されないのはなぜですか？

SRTの伝送接続が機能していても、メディアペイロードが正しくない場合があります。コーデック、コンテナ、タイムスタンプ、キーフレーム、音声トラック、ストリームマッピング、下流の互換性、実際にサーバーへビットレートが到着しているかを確認してください。

SRTサーバーの信頼性を高めるには？

安定したサーバーを使い、正しいUDPポートを開け、現実的な遅延を選び、RTTと再送を監視し、十分な帯域の余力を確保し、メディアペイロードを検証し、イベント前にバックアップエンドポイントをテストしてください。

SRTは通常MPEG-TSを伝送しますか？

ライブ映像ワークフローでは、音声と映像を多重化したMPEG-TSをSRTで運ぶことが一般的ですが、実際のメディアコンテナは送信側とワークフローによって異なります。サーバーはSRT接続だけでなく、ペイロードも検証する必要があります。

最初に監視すべきSRTサーバー指標は何ですか？

まず受信ビットレート、RTT、パケットロス、再送、接続状態を確認します。良好な条件ではRTTが20–60 ms程度になる場合があります。RTTが継続的に150 msを超える、またはパケットロスが1–2%を超える場合は、遅延を増やす、ビットレートを下げる、ネットワーク経路を改善する対応が必要です。

次に進む場所

• SRTプロトコルとは？
• SRTとRTMPの比較
• OBS StudioでSRTストリーミングを開始する方法
• OBS StudioでSRTストリームを受信する方法
• vMixでSRTストリームを送受信する
• SRT設定に最適な遅延を見つける
• SRTサーバーAPIドキュメント

最終更新日：2026年7月22日