StreamHouseブログsrt 配信 設定

SRTの配信先にライブ配信を送る方法

SRTの配信先には、RTMPより少し多くの情報が必要です。モード、ホストとポート、そして多くの場合ストリームID、パスフレーズ、レイテンシーです。srt:// URLの各部分の意味と、配信を接続するまでの手順を解説します。

読了目安:約9分

この記事の内容

SRTの配信先にライブ配信を送るには、受信側からsrt://アドレスを受け取り、どちらがlisten(待ち受け)してどちらがcall(接続)するかを確認し、受信側が求めるストリームID、パスフレーズ、レイテンシーに合わせます。そのうえで受信側のUDPポートを開放し、送信側を起動して、本番で頼る前に映像が届いていることを確認します。

SRTの設定は小さな不一致で失敗するため、すべての項目を正確に合わせてください。このプロトコルが初めての方は、まずSRT配信とは何かからご覧ください。

この記事のポイント

  • SRT接続では、一方がUDPポートで待ち受け、もう一方がそこへ接続します。
  • srt:// URLにはホストとポートに加え、mode、streamid、passphraseなどのオプションが含まれます。
  • 失敗の大半は、閉じたポート、両方がcaller、パスフレーズやストリームIDの不一致が原因です。
  • 24時間配信を本番の受信側に向ける前に、ローカルでテストしましょう。

SRTの配信先を実際に使っているのは誰か

一般的なSNSプラットフォームにSRTで配信することは通常ありません。SRTの配信先は、放送局、企業、パートナーが運用するシステムであることがほとんどです。

  • 放送のプレイアウトと制作。スタジオはSRTで素材映像を受け取り、ハードウェアデコーダー、スイッチャー、プレイアウトシステムに取り込みます。
  • メディアサーバー。自前で運用するメディアサーバーや商用のメディアサーバーはSRTを受け付け、プレーヤー向け、録画、さらなる配信用に再パッケージします。
  • パートナーへの受け渡し。ネットワーク、会場のスクリーン、配給会社に番組を供給するチャンネルは、SRTで届けることがよくあります。
  • クラウド動画サービス。プロ向けプラットフォームの中には、RTMPと並んでSRTのインジェストを提供しているものがあります。

いずれの場合も、受信側の運用者から接続情報が提供されるので、それに正確に合わせます。相手側がRTMPしか提供していない場合は、代わりにカスタムRTMPサーバーへの配信ガイドに従ってください。

caller、listener、rendezvousの各モード

SRT接続には必ず、待ち受ける側と接続しに行く側が必要です。

  • listenerはUDPポートにバインドして接続を待ちます。到達可能なアドレスと、ファイアウォールで開放されたポートが必要です。
  • callerはlistenerのホストとポートに接続します。外向きの接続なので、ほとんどのファイアウォールの内側からでも動作します。
  • rendezvousでは、双方が合意したポートで同時に相手へ接続します。どちらの側も内向きの通信を受け付けない場合に役立ちます。

モードは映像がどちら向きに流れるかとは関係ありません。クラウドサービスやエンコーダーがあなたのサーバーに映像を届ける場合、通常は送信側がcaller、受信側がlistenerになります。

よくある失敗は、両方がcaller、または両方がlistenerになっていることです。どちらの側もはっきりしたエラーを出さずに待ち続けるため、受信側の運用者とモードを確認してください。

srt:// URLを部分ごとに読み解く

SRTのアドレスは、通常次のような形をしています。

srt://ingest.example.com:9000?mode=caller&streamid=channel-main&passphrase=YOUR-LONG-SECRET

  • ホストとポート。受信側のホスト名またはIPアドレスと、待ち受けているUDPポートです。共通のデフォルトポートはないため、指定されたものを使ってください。
  • mode。自分の側の役割で、caller、listener、rendezvousのいずれかです。
  • streamid。一部の受信側が映像の振り分けや認証に使う識別子で、ストリームキーに似たものです。形式は受信側によって異なります。
  • passphrase。AES暗号化のための共有シークレットで、一般的に10〜79文字が求められます。両端で完全に一致している必要があります。
  • pbkeylen。任意の鍵長で、16、24、32バイト、つまりAES-128、192、256を意味します。
  • latency。パケット回復用のバッファーです。ミリ秒で指定するツールもあれば、FFmpegベースのソフトウェアのように一般的にマイクロ秒を想定するものもあるため、別の環境から数値をコピーする前に確認してください。

受信側を準備する

受信側を自分で運用する場合は、何かを送る前に準備しておきましょう。

  1. listenerを設定します。メディアサーバー、デコーダー、プレイアウトソフトウェアで、固定のUDPポートを使います。
  2. そのUDPポートを開放します。サーバーのファイアウォールに加え、手前にあるクラウドのセキュリティグループやルーターでも開放します。TCPのルールはSRTには適用されません。
  3. パスフレーズを決めます。ソフトウェアがストリームIDで振り分ける場合は、この映像用のIDも決めます。
  4. 経路に合ったレイテンシーを選びます。長距離や不安定な経路では大きめの値が必要です。
  5. フォーマットを確認します。SRTは通常、H.264の映像とAACの音声を含むMPEG-TSを運ぶため、受信側がそれを受け付けることを確認してください。
  6. ローカルでテストします。別のマシンのOBSやFFmpegから短い映像を送ってみましょう。

受信側が許可されたアドレスしか受け付けない場合は、送信側のアドレスも許可してください。

SRT接続が始まらないときのトラブルシューティング

SRTのエラーはあいまいなことが多いため、症状から診断しましょう。

  • 接続がタイムアウトする。UDPポートが閉じているかポート転送されていない、ホストが間違っている、あるいは双方が同じモードになっています。
  • 接続が拒否される。たいていは、パスフレーズの不一致、片側だけにパスフレーズが設定されている、または受信側が認識しないストリームIDが原因です。
  • 接続後にカクついたり切れたりする。レイテンシーがネットワーク経路に対して低すぎるか、帯域幅がビットレートと再送のオーバーヘッドを下回っています。まずレイテンシーを上げましょう。
  • 接続されるが映像も音声も出ない。受信側が別のコンテナやコーデックを想定しており、たいていはそのログに何が必要か書かれています。

動作したら、接続できたすべての値を記録しておきましょう。24時間配信をオンラインに保つ方法で紹介している一般的な習慣は、SRTの配信先にも当てはまります。

StreamHouseの配信にSRTの配信先を追加する

StreamHouseでは、SRTは組み込みのプラットフォームと並ぶカスタム配信先です。パスフレーズなど必須のオプションも含め、受信側のsrt:// URLをそのまま貼り付けます。ストリームIDやキーを別途受け取っている場合はストリームIDの欄に入力すると、URLにまだ含まれていなければ、StreamHouseがstreamidパラメーターとして追加します。URLにmodeが指定されていない場合、StreamHouseはcallerとして接続するため、受信側はlistenerにしてください。

エンコード済み動画のループプレイリストを受信側へ24時間送り続けることも、同じ配信にYouTube、Twitch、その他のRTMP配信先と並べてSRTを追加することもでき、配信枠を追加で消費しません。クラウド上で動作し、一時的な不具合があっても自動で再接続します。初めての配信はスタートガイドで手順を追って説明しています。

よくある質問

SRTはどのポートを使いますか?

決まった標準ポートはありません。listenerは空いている任意のUDPポートを使うことができ、どのポートかは受信側の運用者から伝えられます。そのポートは、送信側とlistenerの間にあるすべてのファイアウォールでUDP通信に対して開放されている必要があります。

SRTの送信側はcallerとlistenerのどちらにすべきですか?

通常は送信側がcallし、受信側がlistenします。受信側は固定アドレスと開放されたポートを持っていることが多く、送信側はファイアウォールの内側にいることが多いためです。双方が逆のモードを使うか、両方がrendezvousを使う限り、技術的にはどちらでも動作します。

SRT配信のレイテンシーはどう設定すればよいですか?

一般的な出発点は、送信側と受信側の間の往復時間の数倍で、パケットロスの多い回線や長距離の回線ではさらに増やします。最初は余裕を持たせた値にし、パケットの欠落を監視しながら少しずつ下げていきましょう。ツールがミリ秒とマイクロ秒のどちらを想定しているかも確認してください。

同じ配信からSRTとRTMPの両方を送れますか?

ツールが複数の出力に対応していれば可能です。クラウドサービスなら、公開プラットフォームへのRTMPとプライベートな受信側へのSRTを同時に届けられ、あなたの回線のアップロードが増えることもありません。ただし、配信先ごとに正しい接続情報が必要です。

次に読む