SRT配信とは？SRTとRTMPの違いを解説

SRT（Secure Reliable Transport）は、公衆インターネットのような予測できないネットワーク上でライブ映像を送るためのオープンソースのプロトコルです。UDP上で動作し、失われたパケットを再要求し、信頼性と引き換えにどれだけの遅延を許容するかを選べ、配信を暗号化することもできます。放送事業者は、拠点間で高品質な映像を送るためにSRTを使っています。

あらゆる場面でRTMPの代わりになるわけではありませんが、特定の問題を非常にうまく解決します。仕組みと、使う価値がある場面を解説します。

この記事のポイント

• SRTはUDPを使い、あなたが設定したレイテンシの範囲内で失われたパケットを回復します。
• 遠隔地の会場や素材伝送など、長距離や損失の多い回線に適しています。
• ほとんどのクリエイター向けプラットフォームは、今もRTMPまたはRTMPSでの取り込みを案内しています。
• 共有パスフレーズを使ったAES暗号化が、伝送中のSRT映像を保護します。

SRTの成り立ちと、SRTが解決する問題

SRTは映像技術企業のHaivisionが開発し、2017年にオープンソースとして公開されました。現在では、OBSやFFmpegを含め、幅広いエンコーダー、デコーダー、メディアサーバー、ソフトウェアが対応しています。

SRTが対象とする問題は簡単に説明できます。公衆インターネットでは、特に長距離、混雑したWi-Fi、モバイル回線で、パケットが失われたり順番が入れ替わったりします。従来の放送回線は、専用回線や衛星の帯域を使ってこれを回避していました。SRTは、そうではなく一般的なインターネット回線で放送品質の信頼性を実現することを目指しています。

しかも、配信の中身をほとんど気にせずにそれを実現します。SRTは映像フォーマットではなく伝送方式であり、最も一般的には、H.264またはHEVCの映像とAACの音声を含むMPEGトランスポートストリームを運びます。この柔軟性が、プロの制作現場での素早い採用を後押ししました。

パケット回復とレイテンシバッファの仕組み

RTMPはTCPの上で動作します。TCPは失われたデータを再送しますが、損失を検知するたびに接続全体の速度を落とします。損失の多い長距離回線では、それが停止やバッファリングとして表れます。

SRTはUDPを使い、回復を自前で処理します。受信側はパケットを短いバッファに保持し、順番に欠けを見つけると、送信側に欠けたパケットだけを再送するよう求めます。映像のその瞬間がバッファから出ていく前に代わりのパケットが届けば、その先にいる誰も気づきません。

このバッファの大きさがレイテンシの設定です。値を大きくすると遅延と引き換えに劣悪なネットワークにも耐えられ、小さくすると遅延は抑えられますが、遅れて届いたパケットは破棄されます。一般的な出発点は、送信側と受信側の間の往復時間の数倍で、不安定な回線ではそれを引き上げます。ツールによってレイテンシの単位が異なるため、ドキュメントを確認してください。

暗号化、ストリームID、接続モード

SRTには、RTMP単体では提供されない機能があります。

• 暗号化。両端で共有するパスフレーズを使ったAES暗号化で、128、192、256ビットの鍵を使います。RTMPを暗号化するには、別のRTMPSという派生版が必要です。
• ストリームID。任意の識別子で、1つの受信ポートで複数の映像を受け付け、それぞれを正しく振り分けられるようにします。ストリームキーに少し似ています。
• 接続モード。一方がポートで待ち受け（リスナー）、もう一方がそこへ接続（コーラー）します。3つ目のモードであるランデブーでは両側が同時に接続し、両方がファイアウォールの内側にある場合に役立つことがあります。

SRTはUDPを使うため、外向きのTCP接続を使うRTMPとは違い、経路上のすべてのファイアウォールでリスナーのUDPポートを開けておく必要があります。RTMP側については、RTMPの仕組みとRTMPとRTMPSの違いをご覧ください。

SRTとRTMP：それぞれが優れている場面

どちらのプロトコルも単純に優れているわけではなく、得意な仕事が異なります。

• 素材伝送ではSRTが優れています。遠隔地の会場、現場の撮影クルー、モバイル回線から制作拠点へ映像を送る場面こそ、パケット回復が真価を発揮します。プレイアウトシステム、デコーダー、メディアサーバーに映像を送る放送のチェーンでも同様です。
• SRTは距離に強い。損失やジッターのある大陸間回線では、調整したレイテンシバッファのほうが、TCPベースのRTMPよりも安定した結果を出すのが普通です。
• 互換性ではRTMPが優れています。ほぼすべてのエンコーダー、サービス、プラットフォームが対応しており、設定もURLとキーだけで済みます。
• 導入が簡単なのはRTMPです。UDPポート、レイテンシの調整、パスフレーズを相手と調整する必要がありません。

実用的なルールとしては、あなたやパートナーが管理するシステム間ではSRTを使い、公開プラットフォームへの最後の区間ではRTMPまたはRTMPSを使いましょう。

YouTube、Twitch、ほとんどのプラットフォームが今もRTMPを求める理由

SRTがそれほど強いなら、なぜ主要なクリエイター向けプラットフォームは今もRTMPとRTMPSでの取り込みを案内し続けているのでしょうか？

第一に互換性です。プラットフォームはスマホアプリから古いハードウェアエンコーダーまで、すべての配信者に接続してほしいと考えており、そのすべてが話せるプロトコルがRTMPです。第二に、ほとんどのクリエイターは自宅から近くの取り込みサーバーへ送信しており、そこではTCPでも十分な性能が出ます。第三に、プラットフォームは長年かけて、認証、キー管理、監視の仕組みをRTMPを中心に築いてきました。

その状況は変わりつつあります。一部のプラットフォームや多くのプロ向け映像サービスは、SRTやその他の新しい取り込みプロトコルを受け付けています。とはいえ執筆時点では、主流のSNSやゲーム配信プラットフォームから渡されるのは、通常RTMPまたはRTMPSのURLです。そうした配信先の仕組みはカスタムRTMP配信ガイドで解説しています。

同じクラウド配信からRTMPとSRTを送る

多くの環境では、両方のプロトコルを同時に使う必要があります。公開プラットフォームにはRTMP、スタジオ、プレイアウトサーバー、パートナーの受信機にはSRTです。自宅のエンコーダーからだと、出力が2つになりアップロードも倍になります。

StreamHouseはそれをクラウドで処理します。RTMPまたはRTMPSでYouTube、Twitch、Kickを追加し、さらに受信機に向けたカスタムSRT出力を同じ配信に加えます。1つの配信ですべてに届き、配信先を増やしても追加の配信枠は消費しません。

録画済みの番組なら、動画をアップロードすると事前に一貫したエンコードプロファイルに揃えて準備されるので、プレイリストを作って開始するか予約するだけです。配信は24時間365日ループし、ネットワークの瞬断後は自動で再接続し、パソコンの電源を切ったままでも動き続けます。

よくある質問

配信にはSRTとRTMPのどちらが優れていますか？

長距離や不安定なネットワーク経路なら、通常はSRTです。接続全体を止めることなく失われたパケットを回復できるからです。ただし、主流のプラットフォームはRTMPかRTMPSしか提供していないことが多いため、正しい選択は映像をどこへ送るかによって決まります。

SRTはRTMPより遅延が少ないですか？

そうなる場合もあります。SRTの伝送遅延はおおよそ設定したレイテンシバッファの大きさで、良好なネットワークでは小さくできます。ただし、視聴者が感じる全体の遅延はプラットフォームの処理や再生にも左右されるため、プロトコルを切り替えても必ず速く感じられるとは限りません。

OBSでSRT配信はできますか？

はい。OBSでカスタムサーバーとしてsrt://のアドレスを入力し、モード、レイテンシ、パスフレーズなどのパラメーターをURLに含めます。受信側のサーバーやサービスがSRTに対応し、接続を受け付けるよう設定されている必要があります。

SRTは既定で暗号化されていますか？

パスフレーズを設定した場合だけです。両側で同じパスフレーズを使うと、SRTは128、192、256ビットの鍵を使ったAESで映像を暗号化します。設定しなければ暗号化されずに送られるため、公衆インターネットを通る映像には必ず設定してください。

次に読む

• RTMPの仕組みを学ぶ
• あらゆるRTMP配信先に配信する
• RTMPとSRTの出力を見る
• 配信プランを比較する