RTMPとSRTの違いとは？ライブ配信・OTTで使い分けるポイント

ライブ配信やOTT配信の現場では、長年にわたり RTMP が標準的なライブインジェスト方式として使われてきました。OBS、Wirecast、vMix、各種ハードウェアエンコーダーなど、多くの配信機材がRTMPに対応しており、現在でもRTMPは非常に実用的なプロトコルです。

一方で、スポーツ中継、屋外イベント、レース、リモートプロダクション、4G/5G回線を使った現場配信などが増えるにつれ、近年では SRT の採用を検討するケースが増えています。

ただし、ここで重要なのは、単純に「SRTはRTMPより優れているのか？」という話ではありません。

本当に考えるべきなのは、次の問いです。

SRTをOTTプラットフォームに導入すると、ライブ配信ワークフロー全体で何が変わるのか？

SRTは、単にインジェストサーバー側で受けられるようにすれば終わり、というものではありません。実際には、エンコーダー、インジェスト、トランスコーディング、HLSパッケージング、CDN配信、プレイヤー挙動、Web・モバイル・TVアプリでの検証まで、OTTワークフロー全体に影響します。

この記事では、RTMPとSRTの違いを整理しながら、OTTライブ配信においてどのように使い分けるべきかを実務目線で解説します。

RTMPだけでは不十分になるケースとは？

RTMPは、ライブ配信のインジェスト用途として非常に長い実績があります。設定が簡単で、対応エンコーダーも多く、安定したネットワーク環境では今でも十分に信頼できる選択肢です。

たとえば、以下のような環境ではRTMPは今でも有効です。

• スタジオ内の安定したLAN/WAN環境
• 専用線や高品質な光回線を使った配信
• シンプルなライブ配信ワークフロー
• 短期間で低コストに配信を始めたいケース
• 既存のエンコーダーがRTMPのみに対応しているケース

しかし、ライブ配信の現場がスタジオの外に広がると、状況は変わります。

スポーツ中継、屋外イベント、レース、地域イベント、ケーブルテレビ局の現場中継、自治体・学校・企業イベントのライブ配信などでは、必ずしも安定したネットワークを使えるとは限りません。

特に以下のような環境では、RTMPの弱点が出やすくなります。

• 4G/5G回線
• 公衆インターネット
• 衛星回線
• Wi-Fiが混雑するイベント会場
• 屋外や移動体からの配信
• 海外拠点・遠隔地からの映像伝送

RTMPはTCPベースのプロトコルです。TCPは、すべてのパケットを正しい順序で確実に届けることを重視します。これは安定したネットワークでは大きなメリットですが、パケットロスやジッターが多い環境では、head-of-line blocking と呼ばれる問題が発生しやすくなります。

簡単に言うと、途中で1つのパケットが失われると、その後ろに続くパケットも待たされてしまうという現象です。その結果、映像が遅延したり、止まったり、フレーム落ちが発生したりします。

これはRTMPの「欠陥」というより、TCPの性質によるものです。RTMPはもともと、比較的安定したネットワークを前提に設計されたプロトコルです。

そのため、ネットワーク品質を完全にはコントロールできない現場では、SRTがより有力な選択肢になります。

RTMPとは？

RTMP は、Real-Time Messaging Protocol の略です。

もともとはMacromediaによって開発され、Flash PlayerとFlash Communication Serverの間で音声・映像・データを伝送するために使われていました。その後、AdobeがMacromediaを買収し、RTMPの仕様が公開されたことで、多くの配信サーバーやエンコーダーがRTMPに対応するようになりました。

現在でもRTMPは、ライブ配信のインジェスト用途で広く使われています。

RTMPの主なメリット

RTMPの強みは、何よりもシンプルで扱いやすいことです。

通常、配信者は以下の2つをエンコーダーに設定するだけで配信を開始できます。

• RTMP URL
• Stream Key

そのため、OBSなどのソフトウェアエンコーダーから、低価格なハードウェアエンコーダーまで、ほとんどの配信機材で簡単に利用できます。

また、多くの配信サーバーやクラウドサービスがRTMP ingestに対応しているため、既存システムとの接続もしやすいです。

RTMPの仕組み

RTMPの動作は、大きく3つのステップに分けられます。

1. ハンドシェイク

配信者が「Go Live」を押すと、エンコーダーとサーバーが最初に通信を開始します。

この段階で、RTMPのバージョンや時間同期などの情報を交換します。人間で言えば、会話を始める前に「こんにちは」と挨拶するようなものです。

2. コネクション確立

ハンドシェイクが完了すると、エンコーダーはサーバーに対して「これから配信を始めます」と伝えます。

サーバー側が受信準備を完了すると、映像と音声の送信が開始されます。

3. ストリーム送信

映像と音声は小さなチャンクに分割され、TCP接続上で連続的に送信されます。

音声、映像、メタデータ、制御メッセージなどが同じ接続上で送られるため、安定したネットワークでは同期が取りやすく、低遅延でスムーズな配信が可能です。

RTMPの限界

RTMPはTCPベースであるため、ネットワークが不安定になると弱点が出やすくなります。

TCPは、パケットを必ず順番通りに届けようとします。そのため、途中で1つのパケットが失われると、その後のパケットも処理を待つ必要があります。

これが head-of-line blocking です。

たとえば、1車線の道路をイメージすると分かりやすいです。先頭の車が止まると、後ろの車もすべて止まります。後ろの車が目的地に近づいていても、先頭が動かない限り前に進めません。

ライブ配信では、この待ち時間が映像の遅延、フリーズ、フレーム落ちとして現れます。

そのため、RTMPは以下のようなケースに向いています。

• スタジオ配信
• 固定回線を使った安定したライブ配信
• シンプルなワークフロー
• すばやく配信を立ち上げたい場合
• 予算や時間に制約がある場合

逆に、不安定な回線でミッションクリティカルな配信を行う場合は、SRTの検討が必要になります。

SRTとは？

SRT は、Secure Reliable Transport の略です。

SRTはUDPベースのプロトコルで、Haivisionによって開発されました。特に、品質をコントロールしにくいネットワーク上で、プロフェッショナルな映像伝送を行うために設計されています。

RTMPが安定したネットワーク向けに強いのに対し、SRTは不安定なネットワークに強いことが特徴です。

たとえば、以下のような環境で効果を発揮します。

• 4G/5G回線
• 公衆インターネット
• 衛星回線
• 遠隔地からの映像伝送
• スポーツ中継
• レース配信
• 屋外イベント
• リモートプロダクション

SRTがパケットロスに強い理由

SRTはUDPをベースにしています。

UDPはTCPと違い、パケットの到達や順序を保証しません。その代わり、非常に高速です。SRTはこのUDPの速さを活かしながら、独自の仕組みで信頼性を補っています。

代表的な仕組みが、ARQ と FEC です。

ARQ

ARQは、Automatic Repeat reQuest の略です。

受信側がパケットロスを検知すると、送信側に対して「このパケットをもう一度送ってください」と要求します。この要求にはNAKという信号が使われます。

TCPとの大きな違いは、SRTでは失われたパケットだけを再送する点です。他のパケットは止まらずに流れ続けます。

そのため、RTMP/TCPで起きやすいhead-of-line blockingを避けやすくなります。

FEC

FECは、Forward Error Correction の略です。

あらかじめ冗長なパケットを追加しておくことで、一部のパケットが失われても、受信側で復元できるようにする仕組みです。

特に、衛星回線や国際回線のようにRTTが大きい環境では、再送を待つよりもFECで補完した方が有効な場合があります。

SRTの暗号化

SRTは、プロトコル自体にAES暗号化を備えています。

対応する鍵長は以下です。

• AES-128
• AES-192
• AES-256

RTMPで暗号化を行う場合は、通常RTMPS、つまりTLSを使う必要があります。その場合、証明書やPKIの管理が必要になります。

一方、SRTはpassphraseを共有することで暗号化を利用できるため、運用面では比較的シンプルです。

スポーツ中継や有料コンテンツの映像伝送では、現場のエンコーダーからクラウド側のインジェストサーバーまでの contribution leg を保護することが重要です。SRTのネイティブ暗号化は、この区間の保護に役立ちます。

ただし、注意点もあります。

SRTの暗号化は、エンコーダーからインジェストサーバーまでの伝送区間を保護するものです。視聴者への最終配信、つまりHLSやアプリ側の保護には、DRMやHLS encryptionなど別の仕組みが必要です。

SRTのレイテンシ設定

SRTを理解するうえで重要なのが、レイテンシです。

SRTにおけるレイテンシは、単なる遅延ではありません。パケットロスが発生したときに、再送や復元のための時間を確保するために意図的に設けるバッファです。

つまり、SRTではレイテンシを調整することで、安定性と遅延のバランスを取ります。

一般的には、以下のような考え方になります。

• レイテンシを短くする：遅延は小さいが、パケットロスに弱くなる
• レイテンシを長くする：遅延は増えるが、パケットロスを吸収しやすくなる

スポーツ中継やイベント配信では、数百ミリ秒から数秒のcontribution latencyを許容することで、映像の安定性を大きく高められる場合があります。

最終視聴者にはHLS経由で配信されることが多く、もともと10秒から30秒程度の遅延があるため、contribution側で1〜2秒のレイテンシを追加しても、視聴体験にはほとんど影響しないケースもあります。

一方で、ゴールシーンやレースの重要場面で映像が止まることは大きな問題です。

そのため、SRTでは「わずかな遅延を許容して、安定性を高める」という考え方が重要になります。

RTMPとSRTの比較表

以下は、RTMPとSRTの実務的な比較です。

重要なのは、どちらかが絶対的に優れているわけではないということです。

RTMPは、今でも多くのライブ配信ワークフローで実用的です。特に、安定したネットワーク環境、シンプルな配信、短期間での立ち上げには強みがあります。

一方、SRTは、ネットワークが不安定な環境や、配信停止が許されないミッションクリティカルなライブイベントで力を発揮します。

SRTはOTTの最終配信フォーマットではない

ここは非常に重要です。

SRTという言葉を聞くと、「SRTで視聴者に配信する」と誤解されることがあります。しかし、ほとんどのOTTプラットフォームでは、SRTは視聴者への最終配信フォーマットではありません。

SRTやRTMPは、主にライブインジェストまたはコントリビューションで使われます。

一方、視聴者に届く映像は、多くの場合以下のような形式です。

• HLS
• Low-Latency HLS
• MPEG-DASH

典型的なOTTライブ配信ワークフローは、以下のようになります。

Encoder
 ↓ SRT / RTMP
Ingest Server
 ↓
Transcoder
 ↓
HLS Packager
 ↓
Origin / CDN
 ↓
Player on Web / Mobile / TV Apps

つまり、SRTが改善するのは主に「入力側」です。

最終的な視聴体験は、SRTだけでは決まりません。以下の要素がすべて関係します。

• トランスコーディング品質
• HLSセグメント長
• マニフェスト更新頻度
• CDNの性能
• プレイヤー側のバッファ戦略
• Web、モバイル、TVアプリごとの再接続処理
• 長時間再生時の安定性

そのため、「SRTに対応したから安心」という考え方は危険です。

本当に重要なのは、SRTを含めたOTTワークフロー全体を設計・検証することです。

SRT対応でOTTワークフローの何が変わるのか

SRTをOTTプラットフォームに追加する場合、変更点はインジェスト層だけではありません。

実際には、以下のような領域を確認・調整する必要があります。

1. エンコーダー設定

まず、現場側のエンコーダーがSRTに対応している必要があります。

確認すべき項目は以下です。

• SRT URL
• Caller / Listener mode
• Passphrase
• Latency buffer
• Encryption設定
• Firmwareのバージョン
• UDP通信への対応

RTMPでは、URLとStream Keyだけで配信できることが多いですが、SRTでは設定項目が増えます。

特に、Caller modeとListener modeの選択は重要です。

現場側がNATやFirewallの内側にある場合、エンコーダー側からクラウド側のサーバーへ接続するCaller modeの方が運用しやすいケースがあります。

2. インジェスト層

SRTはUDPを使うため、インジェストサーバー側ではUDPポートの設計が必要です。

確認すべき項目は以下です。

• UDPポートが開放されているか
• Firewall / NAT設定が正しいか
• Caller / Listenerの両方に対応するか
• 接続断時の再接続ロジック
• 複数入力時のフェイルオーバー
• パケットロスやジッターの監視

SRTでは、入力が一時的に不安定になっても、プロトコル側で回復できる場合があります。しかし、それを受けるシステム側が適切に設計されていなければ、下流のトランスコーディングやHLS出力に影響が出ます。

3. トランスコーディング

SRTで入力が安定していても、トランスコーディング側が不安定な入力変動に対応できなければ、最終的な出力は乱れます。

特に確認すべき点は以下です。

• 入力が一瞬途切れた場合の処理
• 音声・映像の同期
• ABR ladderの設計
• 入力ビットレートと出力ビットレートの整合性
• フレーム落ち発生時の処理

SRTはパケットロスに強いプロトコルですが、SRTを使ったからといって自動的にすべての出力が安定するわけではありません。

4. HLSパッケージング

OTT配信では、多くの場合、最終的にHLSへ変換されます。

このとき、HLSパッケージングの設計が視聴体験に大きく影響します。

確認すべき項目は以下です。

• HLSセグメント長
• マニフェスト更新頻度
• 入力断時のdiscontinuity処理
• Live edgeの管理
• Low-Latency HLSを使うかどうか
• 長時間ライブ時の安定性

たとえば、HLSセグメントが長すぎると、視聴者側の遅延が大きくなります。一方で、短すぎるとCDNやプレイヤー側の負荷が増える場合があります。

SRT導入時には、インジェストだけでなくHLS側の設計もセットで見直す必要があります。

5. CDN配信

CDNは、視聴者に安定して映像を届けるための重要な層です。

SRTで入力が安定しても、CDN設定が不適切であれば、視聴者側ではバッファや再接続が発生します。

確認すべき項目は以下です。

• Origin shield
• Live edgeのキャッシュ挙動
• Manifestのキャッシュ時間
• Purge運用
• 地域別のCDN性能
• 大規模同時視聴時のスケーラビリティ

スポーツ中継や大規模イベントでは、視聴者数が短時間で急増することがあります。SRTは入力側の安定性を高めますが、視聴者への配信品質にはCDN設計が大きく関係します。

6. プレイヤーとアプリ側

OTT配信では、最終的な視聴体験を決めるのはプレイヤーです。

特に、Web、iOS、Android、Android TV、Fire TV、Smart TVなど、デバイスごとに挙動が異なります。

確認すべき項目は以下です。

• バッファ戦略
• 再接続処理
• Manifestの再取得タイミング
• Discontinuity検知
• 長時間再生時のメモリ使用
• TVデバイスでのパフォーマンス
• ログ取得とデバッグ性

TVアプリは、Webやモバイルに比べてデバッグが難しいケースが多いです。ログが取りにくく、デバイス性能にも差があります。

そのため、SRT導入時には、Webやスマートフォンだけでなく、実際のTVデバイスでも検証する必要があります。

OTTcloudsでは、SRT導入時に複数のTVデバイスで実機テストを行い、長時間再生や再接続処理を確認することを重視しています。

7. 監視と運用

SRT導入後は、監視項目も変わります。

重要なのは、問題がどこで起きているかを切り分けられることです。

たとえば、視聴者から「映像が止まる」と報告があった場合、それが以下のどこで発生しているのかを判断する必要があります。

• SRT入力側のパケットロス
• インジェストサーバーの再接続
• トランスコーディングの問題
• HLSパッケージングの問題
• CDNのキャッシュ問題
• プレイヤー側のバッファ不足
• TVアプリ固有の問題

SRTは高度なプロトコルですが、運用チームがデバッグできなければ、安定したサービスにはつながりません。

NOCチームや運用担当者が、SRTの基本的な見方を理解していることも重要です。

RTMPからSRTへ移行する際のチェックリスト

RTMPからSRTへの移行を検討する場合は、以下を確認することをおすすめします。

1. 既存エンコーダーはSRTに対応しているか
2. 最新FirmwareでSRTが安定して動作するか
3. Caller / Listener modeのどちらを使うか
4. Firewall / NAT / UDPポートの設定は問題ないか
5. Latency bufferを何msに設定するか
6. RTTとpacket lossを事前に測定したか
7. Encryption / Passphraseは必要か
8. 入力断時の自動復旧・再接続はどう動くか
9. Transcoding側は不安定な入力に対応できるか
10. HLSセグメント長は安定しているか
11. ABR ladderは入力ビットレートに合っているか
12. CDNのLive edgeとManifestキャッシュは適切か
13. Web、iOS、Android、TVアプリで実機検証したか
14. 長時間再生テストを行ったか
15. Monitoringでingest側とplayer側の問題を切り分けられるか
16. 運用チームがSRTの基本的なトラブルシュートを理解しているか

SRT移行は、単なるプロトコル変更ではありません。

インジェスト、配信、再生、監視まで含めたOTTワークフロー全体の見直しとして考えるべきです。

RTMPを使うべきケース

RTMPは古いプロトコルというイメージを持たれることもありますが、今でも多くの場面で実用的です。

以下のようなケースでは、RTMPを使う価値があります。

• スタジオやオフィスなど安定したネットワークで配信する
• ワークフローがシンプルである
• すぐに配信を開始したい
• エンコーダーがRTMPのみに対応している
• 配信がミッションクリティカルではない
• 低コストで運用したい
• 複雑なネットワーク設定を避けたい

特に、社内イベント、簡易ライブ配信、小規模なセミナー、安定した固定回線を使った配信では、RTMPで十分な場合も多いです。

RTMPを無理にSRTへ置き換える必要はありません。

SRTを使うべきケース

一方、以下のようなケースではSRTを検討すべきです。

• 4G/5G回線で配信する
• 公衆インターネットを使って映像を伝送する
• 衛星回線を使う
• 屋外イベントや移動体から配信する
• スポーツ中継を行う
• レースやeSportsなど、止められない配信を行う
• 遠隔地から映像をクラウドへ送る
• パケットロスやジッターが発生しやすい
• 映像伝送区間の暗号化が必要
• 少しの遅延よりも安定性を優先したい

SRTは、特に「映像が止まることが許されない」ライブ配信で効果を発揮します。

スポーツ中継では、ゴールシーンや勝敗を左右する瞬間に映像が止まることは大きな問題です。レースやeSportsでも、重要な場面でのフリーズは視聴体験を大きく損ないます。

このようなケースでは、1〜2秒のcontribution latencyを許容してでも、安定性を高める価値があります。

OTTcloudsの視点：SRT対応はインジェストだけでは終わらない

OTTcloudsでは、SRTを単なる「新しいインジェストプロトコル」としては考えていません。

重要なのは、SRT入力を受けることではなく、視聴者に安定したライブ体験を届けることです。

そのためには、以下をend-to-endで設計・検証する必要があります。

• SRT ingest
• Transcoding
• HLS packaging
• CDN delivery
• Web player
• Mobile apps
• TV apps
• Monitoring
• Long-duration playback testing
• Real-device validation

SRT入力が安定していても、HLSセグメント設計が不適切であれば視聴者側で遅延やバッファが発生します。CDNのキャッシュ設定が適切でなければ、大規模イベント時に配信が不安定になる可能性があります。TVアプリの再接続処理が弱ければ、視聴者は映像停止や再読み込みに悩まされます。

つまり、SRTはOTT品質を高めるための重要な要素ですが、それだけで配信品質が保証されるわけではありません。

OTTcloudsでは、ライブインジェストから視聴アプリまで、OTTワークフロー全体を見たうえで、安定した配信設計を支援しています。

まとめ

RTMPとSRTは、どちらか一方が絶対的に優れているプロトコルではありません。

RTMPは、安定したネットワーク環境やシンプルなライブ配信ワークフローにおいて、今でも非常に実用的です。設定が簡単で、対応エンコーダーも多く、短期間で配信を開始できます。

一方、SRTは、不安定なネットワーク環境やミッションクリティカルなライブ配信で力を発揮します。4G/5G、公衆インターネット、衛星回線、スポーツ中継、レース、屋外イベント、リモートプロダクションなどでは、SRTのパケットロス耐性や暗号化、レイテンシ調整機能が大きな価値を持ちます。

ただし、SRTを導入する際に忘れてはいけないことがあります。

SRT対応は、インジェストだけで完結するものではありません。

OTT配信では、最終的な視聴体験は以下すべてに左右されます。

• エンコーダー設定
• インジェストサーバー
• トランスコーディング
• HLSパッケージング
• CDN配信
• プレイヤー挙動
• Web・モバイル・TVアプリでの検証
• 監視と運用

RTMPからSRTへ移行する場合は、単なるプロトコル変更ではなく、OTTワークフロー全体の見直しとして進めるべきです。安定したライブ配信を実現するためには、「SRTを受けられる」だけでは不十分です。
本当に必要なのは、SRTを含むend-to-endのOTT設計です。

FAQ

Q1. RTMPとSRTの違いは何ですか？

RTMPはTCPベースのライブ配信プロトコルで、安定したネットワーク環境でのインジェストに向いています。一方、SRTはUDPベースで、パケットロスやジッターが発生しやすい不安定なネットワークでも安定した映像伝送を目指せるプロトコルです。

Q2. SRTはRTMPの代わりになりますか？

完全な置き換えではありません。RTMPはシンプルな配信や安定したスタジオ環境で今でも有効です。SRTは、スポーツ中継、屋外イベント、4G/5G回線、衛星回線など、不安定なネットワークで特に有効です。

Q3. SRTは視聴者への最終配信にも使われますか？

通常は使われません。OTT配信では、SRTやRTMPは主にインジェストやコントリビューションで使われます。視聴者には、HLSやLow-Latency HLSなどの形式で配信されることが一般的です。

Q4. RTMPからSRTへ移行すると何が変わりますか？

エンコーダー設定、UDPポート、Firewall/NAT、インジェスト、トランスコーディング、HLSパッケージング、CDN配信、監視、プレイヤー挙動など、OTTワークフロー全体の確認が必要になります。

Q5. SRTはどのような配信に向いていますか？

SRTは、スポーツ中継、レース、eSports、屋外イベント、リモートプロダクション、4G/5G回線、衛星回線など、ネットワークが不安定で配信停止が許されないケースに向いています。

Q6. RTMPはもう古いので使わない方が良いですか？

いいえ。RTMPは現在でも多くのライブ配信で使われています。安定したネットワーク、シンプルな配信、短期間での立ち上げ、低コスト運用ではRTMPが適している場合も多くあります。

Q7. SRTを導入すれば視聴者側のバッファはなくなりますか？

必ずしもそうではありません。SRTは主に入力側、つまりエンコーダーからインジェストサーバーまでの品質改善に有効です。視聴者側のバッファを減らすには、HLS設計、CDN、プレイヤー、アプリ側の最適化も必要です。

RTMPからSRTへの移行や、より安定したライブ配信ワークフローを検討していますか？

OTTcloudsでは、インジェスト、トランスコーディング、HLSパッケージング、CDN配信、Web・モバイル・TVアプリのプレイヤー挙動まで、OTTワークフロー全体を評価し、最適な構成をご提案します。スポーツ中継、屋外イベント、リモートプロダクション、4G/5G回線を使ったライブ配信などで課題を感じている場合は、ぜひOTTcloudsにご相談ください。