SRT RTMP 違いを解説：SRTLAも含め、IRL配信に最適なのは？

2026年10月09日 · 読了目安 1 分

IRL配信では、RTMPよりSRTのほうが向いていることが多く、複数の回線で同時に送れるならSRTLAが最適です。配信プラットフォームはRTMPでの受信を前提にしているため、RTMPは今も必要です。ただし使う場所は、モバイル回線ではなく、サーバーからプラットフォームまでの安定した最後の区間です。

このガイドでは、SRT・RTMPの違いを中心に、3つのプロトコルの仕組み、モバイル回線での挙動、SRTのレイテンシーの正しい設定方法を解説します。

当社のソリューション：IRL エンドポイントサーバー

RTMPとは？

RTMP（Real-Time Messaging Protocol）はAdobeが策定し、2009年にオープンな仕様として公開されました。TCPのような信頼性の高いトランスポート上で動く設計で、すべてのメッセージが順番どおりに届くことを保証します（RTMP仕様書）。SRTのIETFドラフトは、RTMPを公衆インターネット経由で映像を送る用途の事実上の標準と位置づけています。ほぼすべてのエンコーダー、アプリ、プラットフォームが対応しているのはそのためです。

弱点も同じ設計から生まれます。RTMPはTCPに頼るため、ラウンドトリップタイムが短い回線でないと十分な信頼性が出ません。TCPの輻輳制御のせいで、回線の帯域をフルに使い切ることもできません。基地局を渡り歩くスマートフォンには、相性のよくない仕組みです。

従来のRTMPにはコーデックの制約もあります。音声は2チャンネルまで、対応コーデックも限られ、HEVC、VP9、AV1は使えません。Enhanced RTMP仕様でこれらのコーデックが追加され、YouTubeもRTMP(S)向けにH.264、H.265、AV1を挙げています。ただし、使うソフトウェアとプラットフォームの両方が対応している必要があります。RTMPSはRTMPを暗号化されたSSL接続の中で動かす方式で、YouTubeはまさにその理由で推奨しています。

SRTとは？

SRT（Secure Reliable Transport）はオープンソースのプロトコルです。Haivisionの公開GitHubリポジトリで開発され、IETFのInternet-Draftに仕様がまとめられています。UDP上で動き、UDPだけでは足りない信頼性を補います。主な手段はARQ（Automatic Repeat reQuest）です。受信側がパケットの欠落に気づくと、送信側にそのパケットの再送を依頼します。Forward Error Correctionや独自のコネクションボンディングにも対応しています。

IRL配信で重要な特徴は3つあります。

レイテンシーバッファ：受信側は、すべてのパケットを設定した時間だけ保持してから次へ渡します。この時間があるので、失われたパケットを再送でき、ストリーム本来のタイミングも再現できます。遅れすぎたパケットは破棄されることがあり、遅延は増え続けず一定に保たれます。
暗号化：SRTは128、192、256ビット鍵のAES暗号化に対応しています。
コーデック非依存：SRTはペイロードの中身を問いません。HEVCを含め、あらゆるコーデック、解像度、フレームレートを送れます。

トレードオフは仕様に組み込まれています。バッファは意図的に遅延を加えるので、ネットワークに合ったレイテンシー値を選ぶ必要があります（詳しくは後述します）。

SRTLAとは？

SRTLAは、リンクアグリゲーション機能を持つSRTトランスポートプロキシです。BELABOXプロジェクトから生まれ、SRTのトラフィックを複数のネットワーク回線で送ることで、帯域と冗長性を高めます。トラフィックはネットワークの状況に応じて動的に振り分けられ、モバイルモデムをボンディングしてライブ配信する用途を想定しています。

SRTLAはSRTの代わりではありません。SRTの送信側と受信側の間に入ります。たとえばSIMカード2枚、またはSIM1枚とWi-Fiで端末がSRTストリームを送り出し、SRTLAに対応した受信側がパケットを組み立て直して、通常のSRTストリームとして渡します。実際には、次の3点に注意が必要です。

SRTLA対応の送信側が必要です。たとえば無料のiOSアプリMoblinは、モバイル回線1つ、Wi-Fi1つ、複数のEthernet接続を同時に使えます。IRL ProとBELABOXの機器もSRTLAボンディングに対応しています。
SRTLA対応の受信側が必要です。配信プラットフォームや通常のSRTリスナーでは処理できないため、間にSRTLA入力に対応したサーバーを置く必要があります。
チューニングが必要です。パケットは回線ごとに順序が入れ替わって届きます。そのためREADMEでは、lossmaxttlなどの受信側オプションと適切なレイテンシーを必須としています。

RTMP・SRT・SRTLAを比較

項目	RTMP	SRT	SRTLA
転送方式	TCP	再送（ARQ）付きUDP	複数の回線に振り分けたSRTトラフィック
弱いモバイル電波	信頼性を保つには、ラウンドトリップタイムが短い必要がある	レイテンシーウィンドウ内で、失われたパケットを回復	SRTと同様。さらに、2本目の回線が弱い回線を補える
レイテンシー	調整できるバッファなし	レイテンシーウィンドウを設定可能	並べ替えと再送に十分なレイテンシーが必要
ボンディング	なし	単体では不可	可能（複数の接続）
HEVC	両端がEnhanced RTMPに対応している場合のみ	可能（コーデック非依存）	可能（SRTを運ぶため）
暗号化	RTMPS（TLS）	AES標準搭載	受信側の構成による
アプリとプラットフォーム	ほぼすべてのアプリと、大手プラットフォームが公式に案内している受信方式	多くのアプリとOBSが対応。ただしプラットフォーム側はRTMP(S)を案内していることが多い	SRTLA対応アプリとSRTLA受信側

プラットフォームがRTMPを求める理由と、間にサーバーを置く理由

大手プラットフォームのエンコーダー向けドキュメントは、今もRTMPが中心です。YouTubeはエンコーダーのプロトコルとしてRTMP/RTMPSを挙げ（代替はHLS）、Twitchの開発者向けドキュメントもRTMPでTwitchにストリームを送る方法を説明しています。そのため多くの場合、SRTやSRTLAをプラットフォームに直接向けることはできません。

サーバーを挟めばこの問題が解決し、もう1つメリットも生まれます。流れは次のとおりです。

スマートフォンやエンコーダーが、サーバーにSRTまたはSRTLA（あるいはRTMP）で送ります。
OBS Studioなどの配信ソフトが、そのサーバーからストリームを取得します。
OBSが完成したストリームを、安定した回線からRTMP(S)でプラットフォームに送ります。

不安定なモバイル区間には耐性の高いプロトコルを使い、プラットフォームには動かない回線から期待どおりのプロトコルで届けます。モバイルの電波が一瞬途切れても、OBSはプラットフォームへの配信を続けるため、視聴者側で配信が終わることはありません。エンコーダーもOBSもサーバーへ外向きに接続するので、ルーターのポートを開ける必要もありません。

自分のPCのOBSと組み合わせて、この役割を果たすのが当社のIRL エンドポイントサーバーです。RTMP、SRT、SRTLAを入力として受け付けます。配信用のPCがない場合は、IRL 配信サーバーがクラウドでOBS Studioを動かし、同じ3つの入力を受け付けます。IRLセットアップ全体の考え方は、IRL配信ガイドをご覧ください。

SRTのレイテンシーの設定方法

SRTのレイテンシーは、カメラから視聴者までの総遅延ではありません。Haivisionのドキュメントでは、ネットワークを通して送る際に生じる遅延だけを指します。エンコード、デコード、OBS、プラットフォームの分は別途加わります。この設定が実際に決めるのは、遅れて届くパケットや再送を待つために、受信側が余分に待つ時間です。

OBSナレッジベースは、最も重要なオプションについて目安を示しています。

デフォルトは120 msです。
値は、エンコーダーとサーバー間のラウンドトリップタイム（ミリ秒）の2.5倍以上にします。
OBSが使うFFmpeg形式のURLでは、単位がマイクロ秒です。レイテンシー1秒はlatency=1000000と書きます。

例：サーバーへのpingでラウンドトリップタイムが80 msなら、この目安で最小値は200 msになるため、srt://SERVER:PORT?latency=200000と入力します。アドレスとポートは、カスタマーポータルに表示されたものをそのまま使ってください。OBSでは、こうしたオプションをメディアソースやカスタム配信先のSRT URLの末尾に追加できます。

当社サーバーへの配信では、レイテンシーは2秒を推奨します。アプリによって、2000（ミリ秒）または2000000（マイクロ秒）で入力します。多くのアプリには専用の入力欄があります。ない場合は、SRT URLの末尾に追加してください。例：srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000。もっと小さい値にもできますが、安定性を優先して、あえて2秒を推奨しています。

次の点にも注意してください。

単位が違います。SRTライブラリとSRTLAのREADMEはミリ秒、FFmpeg形式のURLはマイクロ秒です。値を入力する前に、使っているアプリがどちらの単位を求めるか確認しましょう。
両側で交渉されます。SRTドラフトによると、接続のレイテンシーは、送信側と受信側がそれぞれ提示した値のうち大きいほうになります。片側だけ下げても、もう片側がより大きな値を求めれば効果はありません。
モバイルやボンディングには余裕が必要です。上の目安は推奨値ではなく最小値です。ウィンドウを広げると再送や並べ替えに使える時間が増えますが、遅延も大きくなります。たとえばSRTLAのREADMEでは、サンプルの受信側設定でlatency=2000（ms）をlossmaxttlとあわせて使っています。
一度に変更するのは1つだけにして、デスクの前だけでなく、移動しながらテストしましょう。

サーバーの場所とレイテンシー

SRTの最小レイテンシーはラウンドトリップタイムに比例するため、距離が効いてきます。サーバーが近いほどラウンドトリップタイムが短くなり、レイテンシーのウィンドウを小さくできます。同じ安定性を、より少ない遅延で得られるということです。最後の区間にも同じ理屈が当てはまります。たとえばTwitchは、端末までのネットワーク経路に基づいてインジェストエンドポイントを推奨しています。

サーバーのリージョンは、米国、ヨーロッパ、アジア、南米から選べます。IRL エンドポイントサーバーでは、スタンダードプランでリージョンを選べ、カスタマーポータルからいつでも切り替えられます。旅行中に便利です。Dedicatedプランでは当社がエンドポイントを用意し、標準では請求先住所にいちばん近い場所に設定します。

どのプロトコルを使うべき？

接続が1つで、新しいアプリ：SRTを使い、ラウンドトリップタイムに基づいてレイテンシーを設定します。
接続が2つ以上：アプリが対応し、サーバーも受け付けるならSRTLAを使います。
RTMPにしか対応しないアプリやカメラ：RTMPを使います。動作はしますが、弱いネットワークには強くありません。
HEVC：SRTはコーデックに依存しません。エンコーダーからOBS、プラットフォームまで、全体の経路が対応しているか確認してください。エンコーダーのキーフレーム間隔は2秒に設定し、AppleデバイスでHEVCを使う場合は、アプリが対応していればBフレームを無効にしてください。

当社のソリューション：IRL 配信サーバー

FAQ

IRL配信ではSRTのほうがRTMPより優れていますか？

モバイル区間については、たいていそうです。SRTはUDPで動き、設定可能なレイテンシーウィンドウの中で、失われたパケットを再送します。一方RTMPはTCPに頼っていて、ラウンドトリップタイムが短い回線でしか信頼性を保てません。サーバーやOBSからプラットフォームへの接続には、今もRTMPが一般的な選択肢です。

SRTとSRTLAの違いは何ですか？

SRTは1つの接続用のトランスポートプロトコルです。SRTLAは、たとえばSIMカード2枚のように、複数のネットワーク回線でSRTトラフィックを同時に送り、帯域と冗長性を高めます。SRTLAには、SRTLA対応のアプリと、それを理解する受信側が必要です。

SRTでTwitchやYouTubeに直接配信できますか？

両プラットフォームのエンコーダー向けドキュメントはRTMP(S)が中心で、YouTubeではHLSも代替として挙げられています。モバイル区間でSRTやSRTLAを使いたい場合は、端末とプラットフォームの間にサーバーとOBSを置いてください。

SRTのレイテンシーはいくつに設定すればいいですか？

当社サーバーへの配信では2秒を推奨します。アプリによって2000（ミリ秒）または2000000（マイクロ秒）で入力します。もっと小さい値にもできますが、2秒は安定性を優先した推奨値です。一般的な目安として、OBSナレッジベースではサーバーまでのラウンドトリップタイムの2.5倍以上、デフォルトは120 msとされています。モバイル回線やボンディング接続では、遅延が増える代わりに、たいていもっと余裕が必要です。

IRL エンドポイントサーバーは3つのプロトコルすべてに対応していますか？

はい。IRL エンドポイントサーバーとIRL 配信サーバーは、RTMP、SRT、SRTLAを入力として受け付けます。