RTMP配信の仕組みから 同時配信のやり方まで

RTMP（Real-Time Messaging Protocol）は、多くのエンコーダがライブ配信をサーバーに送るときの方式です。エンコーダはrtmp://で始まるアドレスに接続し、ストリームキーで身元を伝えたうえで、映像と音声を途切れなく送り続けます。通常はH.264の映像とAACの音声です。TCP（Webページと同じ種類の接続）の上で動きます。

RTMPSは、httpsにも使われる暗号化方式TLSでRTMPを包んだものです。途中でキーや映像を読み取られることはありません。StreamRoveのRTMPSアドレスはポート443、RTMPアドレスはポート1935を使います。YouTubeはRTMPSを推奨しており、Kickのサーバーアドレスもrtmps://で始まります。

StreamRoveは、各プラットフォームが示すアドレスに送ります。KickやFacebookのようにRTMPSを使うプラットフォームにはRTMPSで、Twitchのように標準のアドレスがRTMPのプラットフォームには暗号化なしのRTMPで送ります。エンコーダからStreamRoveまでの区間は、「RTMPS」タブを使えば常に暗号化されます。

映像はH.264の固定ビットレート、キーフレームは2秒ごと、音声はAACのステレオ128 kbps、解像度は1920 × 1080で30または60 fpsです。ビットレートは配信先によって変わり、TwitchかFacebookに送るなら6,000 kbps、Kickだけなら最大8,000 kbpsです。ビットレート計算ツールを使うと、配信先の組み合わせとアップロード速度に合った値がわかります。

はい。「カスタムRTMP」として、表示名、RTMP URL、ストリームキーを入力して追加します。サーバーが必要とする場合は、ユーザー名とパスワードも入力します。そのサーバーにも、プラットフォームと同じ配信が届きます。ブロードキャスト方式（ベータ版、Relayプラン以上）なら、Callerモードで接続するSRTの配信先にも送れます。

一部のプラットフォームはすでに対応しており、YouTubeもその1つです。StreamRoveへは、代わりにH.264の映像とAACの音声で送ってください。この組み合わせはどの配信先も受け付けます。StreamRoveのSRT・RTMP中継サーバーはこの2つ以外に対応しておらず、KickもH.264のみです。H.264なら、すべての配信先が同じ配信を再生できます。

原因はたいてい回線です。RTMPはTCPで動くため、データが失われる回線では止まりがちになり、やがて切断されます。ビットレートを下げる、Wi-Fiをやめて有線で接続する、SRTに切り替える、のいずれかを試してください。プラットフォームがすぐに配信を拒否する場合は、キーと設定を確認します。たとえばKickは、可変ビットレートとH.265を受け付けません。

いいえ。プラットフォームへ届ける最後の区間では、置き換わっていません。YouTube、Twitch、Kickは、ほとんどのエンコーダからRTMPまたはRTMPSで受け付けています。回線が不安定な会場から配信を送り出すなら、SRTのほうが向いていることが多いです。StreamRoveなら両方を使えます。入口はSRT、各プラットフォームへの出口はRTMPです。

StreamRoveが送っている配信を、そのプラットフォームが受け付けていない状態です。よくある原因は、キーのリセットや期限切れ、先に配信を作成しておく必要があるプラットフォーム（LinkedInはイベントごと、Instagramは配信ごとに新しいキーを発行します）、プラットフォームの制限に合っていない設定です。直している間も、ほかの配信先は配信を続けます。

まずRTMPSのアドレスを試してください。安全なWebサイトと同じポート443を使います。暗号化なしのRTMPが使うポート1935は、オフィスや学校のネットワークでブロックされていることがあります。どちらにも接続できない場合は、そのネットワークが配信を遮断しています。スマホのテザリングなど、別の回線を用意してください。