目次
RTMP(Real-Time Messaging Protocol、リアルタイムメッセージングプロトコル)は、相互接続されたシステム間で音声、映像、データを伝送するためのアプリケーション層プロトコルです。
現在のライブストリーミングでは、RTMPは主に、ハードウェアまたはソフトウェアエンコーダーからメディアサーバーやストリーミングプラットフォームへライブ信号を送信するために使用されています。その後、メディアプラットフォームが信号をトランスコード、パッケージ化、保護、配信し、HLS、DASH、HTTP-FLV、WebRTCなどの視聴者向けプロトコルで再生できるようにします。
従来のRTMP仕様では、RTMPは、適切なトランスポートプロトコル、通常はTCP上でマルチメディアストリームを多重化し、チャンクに分割して伝送するアプリケーション層プロトコルと説明されています。
RTMPはかつてAdobe Flashでの再生と強く結び付いていました。Adobeは2020年12月31日にFlash Playerのサポートを終了しました。また、現在のブラウザでは通常、RTMPストリームを直接再生できません。ただし、多くのエンコーダー、ストリーミングプラットフォーム、メディア配信システムがRTMP、または暗号化されたRTMPSを引き続きサポートしているため、RTMPは配信取り込みプロトコルとして今も重要な役割を担っています。
要点
-
RTMPはストリーミングプロトコルです。RTMPサーバー、URL、ストリームキーは、いずれもRTMPワークフローを構成する要素です。
-
RTMPは、エンコーダーからメディアプラットフォームへライブ信号を送信するライブ配信の取り込み用途で広く使用されています。
-
RTMPとHLSは併用されることがよくあります。RTMPが入力ストリームを伝送し、HLSが処理済みの映像を視聴者に配信します。
-
RTMPSではTLS暗号化が追加されます。エンコーダーとストリーミングサービスの両方が対応している場合は、通常RTMPSを優先します。
-
Enhanced RTMP(E-RTMP)は、最新コーデックのシグナリング、マルチトラックストリーミング、再接続機能、高精度な時間制御によってRTMPの機能を拡張しています。
RTMPとは
RTMPは、クライアントとサーバーの間で、タイムスタンプ付きの音声、映像、データ、コマンド、制御情報を伝送する双方向メッセージングプロトコルです。
RTMPは、クライアントとサーバーの間で持続的な接続を維持します。同じ接続上で異なる種類のメッセージを多重化できるため、音声、映像、メタデータ、プロトコル制御情報を1つのストリーミングセッション内で伝送できます。
現在のライブストリーミングワークフローでは、通常、RTMPクライアントとしてエンコーダーが使用されます。エンコーダーは映像ソースを取得または受信し、圧縮してRTMP取り込みエンドポイントに配信します。
一般的な現在のRTMPワークフローは次のとおりです。
カメラまたは映像ソース → エンコーダー → RTMPまたはRTMPS取り込み → メディアサーバー → トランスコードとパッケージ化 → CDN → 視聴者
通常、視聴者が元のRTMP接続を直接受信することはありません。メディアプラットフォームは、視聴者が使用するブラウザ、アプリ、デバイス、ネットワーク環境に適した再生形式へ信号を変換またはパッケージ化します。
Flashの提供終了後もRTMPが利用され続けている理由は、この役割の違いにあります。現在のRTMPは、主にストリーミングワークフローにおける信号伝送や配信取り込みの段階で使用されています。
RTMPストリーミングとは
RTMPストリーミングとは、配信クライアントとサーバーの間のRTMP接続を通じて、ライブまたは録画済みのメディアを伝送することです。
ライブストリーミングワークフローでは、通常、ソフトウェアまたはハードウェアエンコーダーが配信クライアントになります。エンコーダーがソース映像を取り込み、音声と映像を圧縮し、エンコード済みの信号をRTMP取り込みエンドポイントへ送信します。
RTMPでは、次の情報を伝送できます。
- 映像データ
- 音声データ
- ストリームのメタデータ
- コマンドとステータスメッセージ
- 時間情報
- アプリケーションデータ
メディアサーバーは、これらのメッセージを受信し、対応するメディアストリームを識別して、ストリーミングサービスに必要な処理を実行します。処理には、トランスコード、録画、パッケージ化、モニタリング、アクセス制御、配信などが含まれます。
RTMPストリーミングの仕組み
RTMPストリーミングでは、最初にエンコーダーとサーバーの間で接続を確立します。その後、論理的なメディアストリームを作成し、チャンク化された音声、映像、メタデータを継続的に伝送します。
1. ソース信号を取り込み、エンコードする
カメラ、画面キャプチャアプリケーション、制作システム、ゲーム機、その他のソースから、エンコーダーへ未圧縮の音声と映像が送られます。
エンコーダーはソース信号を圧縮し、伝送できる状態にします。一般的な設定項目は次のとおりです。
- 映像および音声コーデック
- 解像度
- フレームレート
- 映像ビットレート
- 音声ビットレートとサンプリングレート
- キーフレーム間隔
- ビットレート制御方式
適切な設定は、受信側プラットフォームによって異なります。エンコーダーの設定がプラットフォームの対応範囲を超えている場合、配信が拒否されたり、処理や再生が不安定になったりすることがあります。
2. エンコーダーがRTMPサーバーに接続する
エンコーダーは、ストリーミングプラットフォームから提供されたRTMPまたはRTMPSサーバーのアドレスを使用します。ストリームキーやその他の認証情報が必要になる場合もあります。
RTMP接続では、最初にクライアントとサーバーがハンドシェイクを行います。ハンドシェイク完了後、クライアントはconnectコマンドを送信し、サーバー上の特定のアプリケーションへのアクセスを要求します。
続いてクライアントが論理ストリームを作成し、メディアを配信します。RTMP仕様では、connect、createStream、publishなどのコマンドが、このワークフローの一部として定義されています。
3. RTMPがメディアをメッセージとチャンクに分けて伝送する
RTMPは、音声、映像、データ、コマンド、制御情報をメッセージとして伝送します。
サイズの大きなメッセージは、伝送前に小さなチャンクへ分割できます。チャンク化により、異なる種類の情報を同じ接続上で交互に伝送できます。たとえば音声、映像、制御メッセージは、大きなメッセージの伝送完了を待つことなく、同じ伝送経路を共有できます。
各メッセージには時間情報とストリーム情報が含まれており、受信側はコンテンツを正しく識別、並べ替え、処理できます。
4. メディアプラットフォームが信号を処理し、配信する
メディアストリームを受信したプラットフォームでは、次のような処理を実行できます。
- 配信元の認証と検証
- 複数の解像度とビットレートへのトランスコード
- アダプティブビットレート構成の生成
- HLS、DASH、WebRTC、その他の配信形式へのパッケージ化
- ライブコンテンツの録画またはアーカイブ
- アクセス制御とコンテンツ保護の適用
- 取り込み品質と再生品質のモニタリング
- CDNを通じたメディアストリームの配信
このように、ストリーミングは複数の段階から成るワークフローです。RTMPは入力信号の受信を担当し、その他の技術が後続処理と視聴者向け配信を担います。
RTMP取り込みとは
RTMP取り込みは、ライブ取り込みとも呼ばれ、エンコーダーからメディアサーバーへRTMPを使用してライブの音声・映像信号を送信するプロセスです。
取り込みは、ライブストリーミングワークフローにおけるアップリンク段階にあたります。信号が処理され、視聴者へ配信される前に、配信者やコンテンツ制作者をストリーミングインフラストラクチャへ接続します。
RTMP取り込みサーバーは、エンコーダーから送信される入力ストリームを受信するサーバーまたはサービスエンドポイントです。システム構成によっては、配信元の認証、メディアストリームの識別、接続の監視、オリジンサーバーまたはメディア処理システムへのルーティングを行います。
一般的なRTMP取り込みワークフローは次のとおりです。
- 制作チームがRTMPまたはRTMPSサーバーのアドレスとストリームキーをエンコーダーに設定します。
- エンコーダーがライブ信号を取り込みサーバーへ配信します。
- メディアプラットフォームがメディアストリームを受信し、処理します。
- メディアストリームが視聴者のデバイスに対応した形式へパッケージ化されます。
- CDNが処理済みコンテンツを視聴者へ配信します。
RTMP取り込みは、放送アプリケーション、ハードウェアエンコーダー、企業イベント向けプラットフォーム、ライブストリーミングサービスで幅広くサポートされています。
RTMPSとは
RTMPSは、TLSで暗号化された接続上で伝送されるRTMPです。
RTMPSを使用すると、エンコーダーと取り込みサーバーの間を移動するメディアストリームと接続情報を保護できます。
GoogleはRTMPSを、Transport Layer Security、つまりTLS/SSL接続上で伝送されるRTMPと説明しています。YouTubeでは、RTMPSを使用して取り込み中のライブストリームデータを暗号化できます。
RTMPSは、次のような他のセキュリティ対策を代替するものではありません。
- アカウントのセキュリティ
- ストリームキーの保護
- 配信元の認証
- 視聴者の認可
- デジタル著作権管理
- 再生レイヤーの暗号化
- アクセス制御ポリシー
RTMPとRTMPSの両方を利用できる場合、一般に、公共ネットワークを使用する本番ライブ配信にはRTMPSが適しています。
RTMPストリーミングのメリットと制約
RTMPストリーミングのメリット
-
幅広い互換性:RTMPは、多くの放送アプリケーション、ハードウェアエンコーダー、メディアサーバー、制作システム、ストリーミングプラットフォームと連携できます。異なるベンダーの技術を接続する際にも実用的です。
-
成熟した取り込みワークフロー:多くのストリーミングチームは、すでにRTMPエンコーダープリセット、認証システム、監視ツール、配信プロセスを運用しています。これにより、導入の複雑さを抑え、大規模なRTMPワークフローを運用しやすくなります。
-
持続的なメディア伝送接続:RTMPはエンコーダーとサーバーの間でアクティブな接続を維持し、同じセッション内で映像、音声、メタデータ、コマンド、制御情報を伝送できます。
-
柔軟なマルチプロトコル配信:プラットフォームはRTMPでメディアストリームを受信し、HLS、DASH、WebRTC、HTTP-FLV、その他の再生形式に変換できます。配信者は使い慣れたRTMPエンコーダーを利用しながら、ブラウザ、モバイルアプリ、スマートテレビ、CDNに適した形式でコンテンツを配信できます。
-
充実したメディア処理機能:RTMPストリームを受信したプラットフォームでは、コンテンツのトランスコード、録画、パッケージ化、監視、保護、配信を実行できます。
RTMPストリーミングの制約
-
標準RTMPは暗号化されない:通常のRTMPでは、伝送中のデータは暗号化されません。伝送セキュリティが必要なワークフローでは、エンコーダーと取り込みプラットフォームの両方が対応している場合、RTMPSを使用します。
-
ブラウザでの再生サポートが限定的:現在のブラウザでは通常、RTMPをネイティブ再生できません。従来のブラウザ再生はAdobe Flash Playerに依存していましたが、Flash Playerのサポートは2020年に終了しました。そのため、通常はRTMPストリームをHLS、DASH、WebRTC、HTTP-FLV、その他のブラウザ対応形式へ変換します。
-
ネットワーク状態が悪いと遅延が発生することがある:RTMPは一般にTCP上で動作します。TCPは失われたデータを再送し、パケットを順番どおりに処理します。パケット損失や輻輳が発生すると、再送によって遅延が増えることがあります。アップロード帯域幅、往復遅延、エンコーダーのバッファリング、ネットワーク輻輳、パケット損失、サーバー設定などが実際のパフォーマンスに影響します。
-
エンドツーエンド遅延を保証できない:RTMPだけでは、視聴者がどれだけ早くストリームを受信できるかは決まりません。総遅延は、エンコーダー設定、ネットワーク距離、トランスコード、パッケージ化、セグメント長、CDN配信、プレーヤーのバッファリング、視聴者側のネットワーク状態にも左右されます。
総合的に見ると、RTMPはライブ信号の伝送や取り込みに適した安定性の高い選択肢です。ただし、安全でブラウザ互換性があり、低遅延な再生環境を実現するには、通常、最新の配信プロトコルと組み合わせて使用します。
RTMPとHLS、SRT、RTSP、WebRTCの違い
ストリーミングプロトコルは、それぞれワークフロー内の異なる役割を担います。どのプロトコルを選ぶべきかは、取り込み、信号伝送、配信、セッション制御、リアルタイム通信のどれが必要かによって異なります。
| プロトコル | 主な用途 | 一般的な接続方法 | 主なメリット | 主な注意点 |
|---|---|---|---|---|
| RTMPまたはRTMPS | ライブ配信の取り込み | エンコーダーからメディアサーバーへの接続 | さまざまな配信ツールとの高い互換性 | 通常のRTMPは暗号化されない |
| HLS | 視聴者向け再生とコンテンツ配信 | サーバーからプレーヤーへの接続 | HTTPベースの大規模配信 | セグメント化とバッファリングが遅延に影響する |
| SRT | 信号伝送とバックホール | ソースからメディアインフラストラクチャへの接続 | 不安定なネットワークでも伝送を復旧できる | 通信の両端がSRTに対応している必要がある |
| RTSP | セッションの確立と制御 | クライアントからメディアサーバーへの接続 | メディアセッションを制御できる | 通常は別の伝送方式と組み合わせて使用する |
| WebRTC | 双方向のリアルタイム通信 | ブラウザ、アプリ、ピア間の通信 | ブラウザやアプリでリアルタイムの双方向通信が可能 | スケーリングやアーキテクチャ設計が複雑になる場合がある |
RTMPとHLSは併用されることがよくあります。RTMPが取り込みを担当し、HLSが視聴者への配信を担当します。
不安定なネットワークを経由する長距離の信号伝送には、SRTが適している場合があります。RTSPはIPカメラや管理されたメディアセッションでよく使用されます。WebRTCは、ブラウザやアプリ上のインタラクティブな体験に適しています。
RTMPが適しているケース
次のような場合、RTMPまたはRTMPSは実用的な選択肢です。
- 幅広くサポートされているソフトウェアまたはハードウェアエンコーダーから配信する場合
- 受信側プラットフォームがRTMP取り込みエンドポイントを提供している場合
- RTMP取り込みとHLSまたはDASH配信を組み合わせたワークフローを使用する場合
- 既存の放送ツールとの互換性が必要な場合
- アップリンクネットワークが比較的安定している場合
- ライブウェビナー、企業イベント、エンターテインメント番組、スポーツ中継、ゲーム配信、ライブコマースで使用する場合
受信側プラットフォームが対応している場合は、通常、RTMPSを優先します。
不安定なネットワークや長距離ネットワークを経由してコンテンツを伝送する場合は、SRTが適していることがあります。
高い双方向性が求められる場合は、WebRTCが適していることがあります。
幅広いデバイス互換性とHTTPベースの視聴者向け配信が必要な場合は、HLSが一般的な選択肢です。
RTMPストリームの信頼性を高める方法
RTMPストリームの信頼性は、制作環境とネットワーク環境全体によって決まります。
-
適切な取り込みエンドポイントを選択する:
エンコーダーからエンドポイントまでのネットワーク経路が安定している接続先を選び、実際の経路品質、パケット損失、アップロード性能をテストします。 -
プラットフォームのエンコード要件に従う:
プラットフォームがサポートするコーデック、解像度、フレームレート、ビットレート、キーフレーム間隔、音声設定を使用します。 -
十分なアップロード帯域幅を確保する:
利用可能なアップロード帯域幅は、設定したメディアストリームのビットレートを上回る必要があります。 -
RTMPSを優先する:
プラットフォームが対応している場合は暗号化されたエンドポイントを使用し、プロトコルの種類、ホスト名、ポート、アプリケーションパスを確認します。 -
ストリームキーを保護する:
配信認証情報へのアクセスを制限し、漏えいしたキーは再発行します。 -
冗長構成を用意する:
重要なライブ配信では、予備のエンコーダー、ネットワーク接続、電源、取り込みエンドポイント、補助信号ソースが必要になる場合があります。 -
ワークフロー全体を監視する:
エンコーダー、アップロード接続、取り込み状態、メディア処理、CDN配信、視聴者側の再生状況を継続的に監視します。
エンコーダーの接続が成功していても、視聴者が問題なく再生できるとは限りません。
CDNetworksによるRTMP取り込みとライブストリーミングのサポート
ライブストリーミングでは、取り込み、メディア処理、コンテンツ配信など、複数の技術が連携して動作します。RTMPは成熟したエンコーダーやライブ配信ワークフローと統合できるため、現在も幅広く使用されている取り込み方式です。
CDNを利用したRTMPストリーミングワークフローでは、CDNetworksのメディア配信サービスがRTMP取り込みと分散型メディア配信を接続します。
CDNetworksのEnhanced RTMP/FLVサポートは、次のような目的で設計されています。
- OBSやVLCなど、主要なストリーミングソフトウェアとの互換性を維持する
- より幅広いメディア形式に対応する
- プロトコルの置き換えや追加の変換処理を減らす
- 低遅延ストリーミングをサポートする
- サービスプロバイダーが視聴体験とストリーミングコストのバランスを取りやすくする
これらの機能により、既存のRTMPワークフローを簡素化し、必要性がない場合に配信アーキテクチャを再設計する手間を抑えられます。
CDNetworksのメディア配信サービスについて詳しく確認するか、エンターテインメント向けライブストリーミングソリューションをご覧ください。
よくある質問
RTMPとは何の略ですか?
RTMPはReal-Time Messaging Protocolの略で、日本語ではリアルタイムメッセージングプロトコルと呼ばれます。相互接続されたクライアントとサーバーの間で、タイムスタンプ付きの音声、映像、メタデータ、コマンド、制御情報を伝送するアプリケーション層プロトコルです。
RTMPストリーミングとは何ですか?
RTMPストリーミングは、RTMP接続を通じてライブまたは録画済みのメディアを伝送する仕組みです。一般的には、ソフトウェアまたはハードウェアエンコーダーからメディアサーバーやストリーミングプラットフォームへストリームを送信します。
RTMP取り込みとは何ですか?
RTMP取り込みは、エンコーダーからメディアサーバーへライブの音声・映像信号を送信するプロセスです。サーバーは受信したメディアストリームを処理、トランスコード、パッケージ化し、視聴者向けに配信します。
RTMPサーバーとは何ですか?
RTMPサーバーは、RTMPストリームの受信、処理、ルーティング、配信、再生を行うサーバーです。RTMP取り込みサーバーは、ソフトウェアまたはハードウェアエンコーダーから送信される入力ストリームの受信に特化しています。
RTMP URLとストリームキーの違いは何ですか?
RTMP URLは、取り込みサーバーとアプリケーションパスを識別します。ストリームキーは、個別のメディアストリームを識別したり、そのストリームの配信権限を付与したりするために使用します。エンコーダーによっては、この2つを別々に入力する場合と、1つの配信アドレスとしてまとめて入力する場合があります。
RTMPは安全ですか?
RTMPSはTLS暗号化を使用し、エンコーダーと取り込みサーバーの間のRTMP通信を保護します。標準のRTMPにはこの保護がないため、通信の両端が対応している場合は、通常RTMPSを優先します。
RTMPではどのポートを使用しますか?
RTMPでは一般にTCPの1935番ポートを使用します。一部のRTMPSサービスではTCPの443番ポートを使用しますが、配信者は必ずストリーミングプラットフォームから提供された接続情報に従って設定する必要があります。
現在のブラウザでRTMPを再生できますか?
現在のブラウザでは通常、RTMPを直接再生できません。一般にストリーミングプラットフォームがRTMP入力ストリームをHLS、DASH、WebRTC、HTTP-FLV、その他のブラウザやアプリに対応した形式へ変換します。
RTMPはHLSより優れていますか?
RTMPとHLSは異なる役割を担います。RTMPは通常、エンコーダーからライブ入力ストリームを受信するために使用され、HLSは処理済みの映像を視聴者へ配信するために使用されます。多くのライブストリーミングワークフローでは、両方を組み合わせて使用します。
RTMPは現在でも重要ですか?
RTMPは現在でも重要です。多くのエンコーダー、メディアサーバー、ストリーミングプラットフォームが、ライブ配信の取り込み方式としてRTMPをサポートしています。現在の主な用途は、ブラウザで直接再生することではなく、ストリーミングインフラストラクチャへ信号を送信することです。
