リアルタイム メッセージング プロトコル

リアルタイム メッセージング プロトコル
通信プロトコル
略語RTMP
目的ストリーミング
開発者マクロメディア
導入 （）
に基づくTCP
OSI層アプリケーション層（7）
ポートtcp/1935

リアルタイムメッセージングプロトコル（RTMP）は、インターネット経由で音声、動画、およびデータをストリーミングするための通信プロトコルです。元々はMacromedia社がFlash PlayerとFlash Communication Server間のストリーミング用に独自プロトコルとして開発しましたが、 Adobe社（Macromedia社を買収）は、このプロトコルの不完全な仕様を一般向けに公開しました。

RTMP プロトコルには複数のバリエーションがあります。

  1. RTMP 自体は、伝送制御プロトコル(TCP)上で動作し、デフォルトでポート番号 1935 を使用する「プレーン」プロトコルです。
  2. RTMPS は、トランスポート層セキュリティ(TLS/SSL) 接続を介した RTMP です。
  3. RTMPEは、Adobe独自のセキュリティメカニズムを用いてRTMPを暗号化したものです。実装の詳細はAdobe独自のものですが、このメカニズムは業界標準の暗号化プリミティブを使用しています。[ 1 ]
  4. RTMPTは、ファイアウォールを通過するためにHTTPリクエスト内にカプセル化されます。RTMPTは、TCPポート80および443でクリアテキストリクエストを利用することで、企業のトラフィックフィルタリングをバイパスすることがよくあります。カプセル化されたセッションは、プレーンなRTMP、RTMPS、またはRTMPEパケットを内部で伝送する場合があります。
  5. RTMFPは、 TCPではなくユーザーデータグラムプロトコル（UDP）を介したRTMPであり、RTMP Chunk Streamに代わるものです。Adobe Systemsによって開発されたセキュアなリアルタイムメディアフロープロトコルスイートは、エンドユーザー同士が直接接続して通信することを可能にします（P2P）。
  6. E-RTMP（Enhanced RTMP）は、既存のRTMPインフラストラクチャとの互換性を維持しながらストリーミング機能を向上させるように設計されたRTMPおよびFLV仕様の拡張機能です。[ 2 ] E-RTMPは、高度なタイムスタンプ精度、マルチトラック機能、拡張コーデックサポート、FourCCシグナリング、再接続要求機能などの機能を追加することでRTMPを強化します。

RTMP の主な目的はFlash Video を再生するためのプロトコルでしたが、 Adobe LiveCycle Data Services ESなどの他のアプリケーションでも使用されています。

基本操作

RTMPは、持続的な接続を維持し、低遅延通信を可能にするTCPベースのプロトコルです。ストリームをスムーズに配信し、可能な限り多くの情報を送信するために、ストリームをフラグメントに分割し、そのサイズはクライアントとサーバー間で動的にネゴシエートされます。フラグメントのサイズは変更されない場合もあります。デフォルトのフラグメントサイズは、オーディオデータの場合は64バイト、ビデオデータおよび他のほとんどのデータタイプの場合は128バイトです。異なるストリームからのフラグメントはインターリーブされ、単一の接続で多重化されます。したがって、データチャンクが長い場合、プロトコルはフラグメントごとに1バイトのヘッダーのみを伝送するため、オーバーヘッドはごくわずかです。ただし、実際には、個々のフラグメントは通常インターリーブされません。代わりに、インターリーブと多重化はパケットレベルで行われ、複数の異なるアクティブチャネルにまたがるRTMPパケットは、各チャネルが帯域幅、遅延、その他のサービス品質要件を満たすようにインターリーブされます。このようにインターリーブされたパケットは不可分なものとして扱われ、フラグメントレベルではインターリーブされません。

RTMPは、パケットを送受信できる複数の仮想チャネルを定義しており、これらのチャネルは互いに独立して動作します。例えば、RPCリクエストとレスポンスを処理するチャネル、ビデオストリームデータ用のチャネル、オーディオストリームデータ用のチャネル、帯域外制御メッセージ（フラグメントサイズネゴシエーションなど）用のチャネルなどがあります。一般的なRTMPセッションでは、複数のチャネルが同時にアクティブになる場合があります。RTMPデータがエンコードされると、パケットヘッダーが生成されます。パケットヘッダーには、送信先のチャネルのID、生成時刻のタイムスタンプ（必要な場合）、パケットのペイロードサイズなどが指定されます。このヘッダーの後には、パケットの実際のペイロードコンテンツが続きます。ペイロードコンテンツは、接続を介して送信される前に、合意されたフラグメントサイズに従ってフラグメント化されます。パケットヘッダー自体はフラグメント化されず、そのサイズはパケットの最初のフラグメントのデータにはカウントされません。つまり、実際のパケット ペイロード (メディア データ) のみが断片化の対象となります。

より高レベルでは、RTMPはMP3またはAACオーディオ、FLV1ビデオなどのマルチメディアストリームをカプセル化し、アクションメッセージフォーマット（Action Message Format ）を使用してリモートプロシージャコール（RPC）を行うことができます。必要なRPCサービスは、単一のクライアント/サーバー要求/応答モデルを使用して非同期的に実行されるため、リアルタイム通信は必要ありません。[ 3 ] [ 4 ]

暗号化

RTMP セッションは、次の 2 つの方法のいずれかを使用して暗号化できます。

  • 業界標準のTLS/SSLメカニズムを使用します。基盤となるRTMPセッションは、通常のTLS/SSLセッション内に単純にラップされます。
  • RTMP セッションをより軽量な暗号化レイヤーでラップする RTMPE を使用します。

HTTPトンネリング

RTMP Tunneled (RTMPT) では、RTMP データはカプセル化されてHTTP経由で交換され、クライアント (この場合はメディア プレーヤー) からのメッセージはサーバー上のポート 80 (HTTP のデフォルト) に送信されます。

RTMPT のメッセージは HTTP ヘッダーのため、同等の非トンネル RTMP メッセージよりも大きくなりますが、クライアントが非HTTP および非 HTTPS の送信トラフィックをブロックする ファイアウォールの背後にある場合など、非トンネル RTMP を使用できないシナリオでは、RTMPT によって RTMP の使用が容易になる場合があります。

このプロトコルは、POST URLを介してコマンドを送信し、POST本体を介してAMFメッセージを送信することで機能します。例を以下に示します。 

POST /open/1 HTTP/1.1

接続が開かれます。

仕様書と特許ライセンス

Adobeは2012年12月21日付でプロトコルのバージョン1.0の仕様を公開した。[ 5 ]この仕様のウェブランディングページには、「コンテンツを保護したい顧客の利益のため、オープンRTMP仕様にはAdobe独自のセキュアRTMP対策は含まれていない」と記載されている。[ 6 ]

Adobeの仕様に付随する文書では、プロトコルのすべての実装に対して「非独占的、ロイヤリティフリー、譲渡不可、再許諾不可、個人的、全世界的」な特許ライセンスを付与しているが、2つの制限がある。1つはストリーミングデータの傍受（「ストリーミングビデオ、オーディオ、および/またはデータコンテンツを傍受して任意のデバイスまたはメディアに保存するあらゆる技術」）への使用を禁止し、もう1つは「Adobeの安全なRTMP対策を含む、オーディオ、ビデオ、および/またはデータコンテンツを保護するための技術的対策」の回避を禁止している。[ 7 ]

Flashに関する著書を数冊執筆したステファン・リヒター氏は2008年に、Adobeはどの特許がRTMPに適用されるかについては曖昧だが、米国特許7,246,356がその1つであるようだと指摘した。[ 3 ]

2011年にAdobeはWowza Media Systemsを提訴し、RTMP特許の侵害などを主張した。[ 8 ] [ 9 ] [ 10 ] 2015年にAdobeとWowzaは訴訟が和解し、棄却されたと発表した。[ 11 ]

パケット構造

RTMPパケット図

パケットは、最初にクライアントとサーバーの間で確立される TCP 接続を介して送信されます。パケットにはヘッダーと本体が含まれ、接続コマンドと制御コマンドの場合は、アクション メッセージ フォーマット(AMF) を使用してエンコードされます。ヘッダーは、基本ヘッダー(図では他の部分から分離して表示) とチャンク メッセージ ヘッダーに分かれています。基本ヘッダーはパケットの唯一の不変部分で、通常は 1 つの複合バイトで構成され、最も重要な 2 つのビットはチャンク タイプ (仕様ではfmt ) で、残りはストリーム ID を形成します。前者の値に応じて、メッセージ ヘッダーの一部のフィールドを省略し、その値を以前のパケットから取得できます。一方、後者の値に応じて、基本ヘッダーは 1 つまたは 2 つの追加バイトで拡張できます (合計 3 バイトの図の場合 (c))。基本ヘッダー(BH)の残りの 6 ビット (最下位) の値が0 の場合、BH は 2 バイトで、ストリーム ID 64 から 319 (64+255) を表します。値が 1 の場合、BH は 3 バイト (最後の 2 バイトは 16 ビット リトルエンディアンとしてエンコード) で、ストリーム ID 64 から 65599 (64+65535) を表します。値が 2 の場合、BH は 1 バイトで、低レベルのプロトコル制御メッセージとコマンド用に予約されています。チャンク メッセージ ヘッダーには、メッセージ サイズ (バイト単位)、タイムスタンプ デルタ、メッセージ タイプなどのメタデータ情報が含まれます。この最後の値は 1 バイトで、パケットがオーディオ、ビデオ、コマンド、または RTMP Ping などの「低レベル」 RTMP パケットのいずれであるかを定義します。

以下に、フラッシュ クライアントが次のコードを実行したときにキャプチャされた例を示します。 

var stream : NetStream =新しいNetStream ( connectionObject );

これにより、次のチャンクが生成されます。

16進コードアスキー
03 00 0B 68 00 00 19 14 00 00 00 00 0200 0C63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂␀ ␌c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅

パケットは1 バイトの基本ヘッダー(0x03) で始まり、最上位 2 ビット (b 00 000011) はチャンク ヘッダー タイプ 0 を定義し、残りのビット (b00 000011 ) はチャンク ストリーム ID 3 を定義します。ヘッダー タイプには 4 つの値があり、その意味は次のとおりです。

  • b00 = 12 バイト ヘッダー (フル ヘッダー)。
  • b01 = 8 バイト - タイプ b00 と同様ですが、メッセージ ID (最後の 4 バイト) は含まれません。
  • b10 = 4 バイト - 基本ヘッダーとタイムスタンプ (3 バイト) が含まれます。
  • b11 = 1 バイト - 基本ヘッダーのみが含まれます。

最後のタイプ（b11）は、集約メッセージの場合に常に使用されます。上記の例では、2番目のメッセージはID 0xC3（b11000011）で始まり、すべてのメッセージヘッダーフィールドはストリームIDが3のメッセージ（そのすぐ上のメッセージ）から取得されることを意味します。ストリームIDを構成する最下位6ビットは、3から63までの値を取ります。一部の値には特別な意味があります。例えば、1は拡張ID形式を表し、その場合は2バイトが続きます。値2は、PingやSet Client Bandwidthなどの低レベルメッセージ用です。

RTMP ヘッダーの次のバイト (上記のサンプル パケットの値を含む) は次のようにデコードされます。

  • バイト #1 (0x03) = チャンク ヘッダー タイプ。
  • バイト #2～4 (0x000b68) = タイムスタンプのデルタ。
  • バイト #5～7 (0x000019) = パケット長 - この場合は 0x000019 = 25 バイトです。
  • バイト#8（0x14）=メッセージタイプID - 0x14（20）はAMF0でエンコードされたコマンドメッセージを定義します。
  • バイト #9～12 (0x00000000) = メッセージストリームID。リトルエンディアン順です。

メッセージタイプIDバイトは、パケットにオーディオ/ビデオデータ、リモートオブジェクト、またはコマンドが含まれているかどうかを定義します。可能な値は次のとおりです。

  • 0x01 = パケット サイズ メッセージの設定。
  • 0x02 = 中止。
  • 0x03 = 確認応答。
  • 0x04 = 制御メッセージ。
  • 0x05 = サーバー帯域幅
  • 0x06 = クライアント帯域幅。
  • 0x07 = 仮想コントロール。
  • 0x08 = オーディオ パケット。
  • 0x09 = ビデオ パケット。
  • 0x0F = 拡張データ。
  • 0x10 = コンテナ拡張。
  • 0x11 = コマンド拡張 (AMF3 タイプのコマンド)。
  • 0x12 = データ (Invoke (onMetaData 情報がそのまま送信されます))。
  • 0x13 = コンテナ。
  • 0x14 = コマンド (AMF0 タイプのコマンド)。
  • 0x15 = UDP
  • 0x16 = 集計
  • 0x17 = 存在

ヘッダーに続く0x02は、サイズが0x000Cで値が0x63、0x72、…、0x6D（「createStream」コマンド）の文字列を表します。その後ろには0x00（数値）があり、これは値が2.0のトランザクションIDです。最後のバイトは0x05（null）で、これは引数がないことを意味します。

呼び出しメッセージ構造 (0x14, 0x11)

上記で示したPingやSet Client/Server Bandwidthなどのメッセージタイプは、AMFエンコード形式を使用しない低レベルRTMPプロトコルメッセージとみなされます。一方、コマンドメッセージ（AMF0（メッセージタイプ0x14）またはAMF3（0x11））はAMFエンコード形式を使用し、一般的な形式は以下のとおりです。 

（文字列）<コマンド名> （数値）<取引ID> (混合) <引数> 例: Null、文字列、オブジェクト: {key1:value1、key2:value2 ... }

トランザクションIDは、応答可能なコマンドに使用されます。値は、上記の例のような文字列、またはキーと値のペアで構成される1つ以上のオブジェクトのいずれかになります。キーは常に文字列としてエンコードされ、値は配列などの複合型を含む任意のAMFデータ型になります。

制御メッセージ構造 (0x04)

制御メッセージはAMFエンコードされていません。ストリームIDは0x02で始まり、これは完全な（タイプ0）ヘッダーを意味し、メッセージタイプは0x04です。ヘッダーの後に6バイトが続き、以下のように解釈されます。

  • #0～1 - コントロールタイプ。
  • #2～3 - 2番目のパラメータ（特定のコントロールタイプで意味を持ちます）
  • #4～5 - 3番目のパラメータ（同じ）

メッセージ本文の最初の2バイトはPingタイプを定義し、明らかに6つの値を取ることができる[ 12 ]。

  • タイプ0 - クリアストリーム: 接続が確立され、それ以上のデータが伝送されないときに送信されます
  • タイプ 1 - バッファをクリアします。
  • タイプ 2 - 渓流乾燥。
  • タイプ3 - クライアントのバッファ時間。3番目のパラメータはミリ秒単位の値を保持します。
  • タイプ 4 - ストリームをリセットします。
  • タイプ6 - サーバーからクライアントにpingを実行します。2番目のパラメータは現在時刻です。
  • タイプ7 - クライアントからのPong応答。2番目のパラメータは、クライアントがPingを受信した時刻です。
  • タイプ 8 - UDP 要求。
  • タイプ 9 - UDP 応答。
  • タイプ 10 - 帯域幅制限。
  • タイプ 11 - 帯域幅。
  • タイプ 12 - スロットル帯域幅。
  • タイプ 13 - ストリームが作成されました。
  • タイプ 14 - ストリームが削除されました。
  • タイプ 15 - 読み取りアクセスを設定します。
  • タイプ 16 - 書き込みアクセスを設定します。
  • タイプ 17 - ストリーム メタ要求。
  • タイプ 18 - ストリーム メタ レスポンス。
  • タイプ 19 - セグメント境界を取得します。
  • タイプ 20 - セグメント境界を設定します。
  • タイプ 21 - 切断時。
  • タイプ 22 - クリティカルリンクの設定。
  • タイプ 23 - 切断。
  • タイプ 24 - ハッシュ更新。
  • タイプ 25 - ハッシュ タイムアウト。
  • タイプ 26 - ハッシュ要求。
  • タイプ 27 - ハッシュ応答。
  • タイプ 28 - 帯域幅を確認します。
  • タイプ 29 - オーディオ サンプル アクセスを設定します。
  • タイプ 30 - ビデオ サンプル アクセスを設定します。
  • タイプ31 - スロットル開始。
  • タイプ 32 - スロットル エンド。
  • タイプ 33 - DRM 通知。
  • タイプ 34 - RTMFP 同期。
  • タイプ 35 - IHello をクエリします。
  • タイプ36 - フォワードIHello。
  • タイプ 37 - IHello をリダイレクトします。
  • タイプ 38 - EOF を通知します。
  • タイプ 39 - プロキシ続行。
  • タイプ 40 - プロキシ アップストリームの削除。
  • タイプ 41 - RTMFP キープアライブを設定します。
  • タイプ 46 - セグメントが見つかりません。

Pongは Ping への応答の名前であり、使用される値は上記のとおりです。

ServerBw/ClientBw メッセージ構造 (0x05、0x06)

これは、クライアントのアップストリームおよびサーバーのダウンストリームのビットレートに関するメッセージです。本体は帯域幅の値を示す4バイトで構成され、制限タイプを設定する1バイトの拡張バイトが含まれる場合があります。制限タイプは、ハード、ソフト、またはダイナミック（ソフトまたはハード）の3つの値のいずれかになります。

チャンクサイズの設定 (0x01)

本文の4バイトで受信される値。デフォルト値は128バイトで、変更が必要な場合にのみメッセージが送信されます。

プロトコル

RTMPハンドシェイク図

ハンドシェーク

TCP接続を確立した後、まずRTMP接続が確立され、各側から3つのパケット（公式ドキュメントではチャンクとも呼ばれます）を交換することでハンドシェイクが行われます。公式仕様では、これらのパケットは、クライアント側が送信したパケットはC0-2、サーバー側はS0-2と呼ばれています。ハンドシェイク完了後にのみ交換可能なRTMPパケットとは混同しないでください。これらのパケットは独自の構造を持ち、C1には「エポック」タイムスタンプを設定するフィールドが含まれていますが、サードパーティの実装と同様に、この値は0に設定できるため、パケットは簡素化されます。クライアントは、現在のプロトコルバージョンを表す定数値0x03を含むC0パケットを送信することで接続を初期化します。S0の受信を待たずに、C1に直接送信されます。S0は1536バイトで構成され、最初の4バイトはエポックタイムスタンプ、次の4バイトはすべて0、残りはランダムです（サードパーティの実装では0に設定できます）。 C2とS2はそれぞれS1とC1のエコーですが、2番目の4バイトはそれぞれのメッセージが受信された時刻（0ではなく）です。C2とS2を受信すると、ハンドシェイクは完了したとみなされます。

接続する

この時点で、クライアントとサーバーはAMFエンコードされたメッセージを交換することで接続をネゴシエートできます。これらのメッセージには、接続を確立するために必要な変数に関連するキーと値のペアが含まれます。クライアントからのメッセージの例を以下に示します。 

(呼び出し) "connect" (トランザクションID ) 1.0 (オブジェクト 1 ) { app : "sample" 、flashVer : "MAC 10,2,153,2" 、swfUrl : null 、tcUrl : "rtmpt://127.0.0.1/sample " 、fpad : false 、capabilities : 9947.75 、audioCodecs : 3191 、videoCodecs : 252 、videoFunction : 1 、pageUrl : null 、objectEncoding : 3.0 }

Flash Media Serverやその他の実装では、「アプリ」という概念を用いて、オーディオ/ビデオなどのコンテンツを格納するコンテナを概念的に定義します。このコンテナは、ストリーミング配信されるメディアファイルを含むサーバールート上のフォルダとして実装されます。最初の変数には、このアプリの名前である「sample」が含まれています。これは、Wowza Serverがテスト用に提供した名前です。文字flashVer列は、ActionScriptgetversion()関数によって返されるものと同じです。audioCodecと はdouble型videoCodecとしてエンコードされており、その意味は元の仕様に記載されています。変数についても同様で、この場合はSUPPORT_VID_CLIENT_SEEK定数です。特に注目すべきは、残りの通信で拡張AMF3形式を使用するかどうかを定義する です。現在のデフォルトはバージョン3であるため、Flashクライアントは、AMF0が要求された場合、ActionScriptコードで明示的にAMF0を使用するように指示する必要があります。サーバーは、ServerBW、ClientBW、SetPacketSizeのメッセージシーケンスで応答し、最後にサンプルメッセージを含むInvokeが続きます。 videoFunctionobjectEncoding

(呼び出し) "_result" (トランザクションID ) 1.0 (オブジェクト1 ) { fmsVer : "FMS/3,5,5,2004" 、機能: 31.0 、モード: 1.0 } (オブジェクト2 ) {レベル: "status" 、コード: "NetConnection.Connect.Success" 、説明: "接続に成功しました" 、データ: (配列) {バージョン: "3,5,5,2004" }、クライアントID : 1728724019 、オブジェクトエンコーディング: 3.0 }

上記の値の一部は、汎用アクションスクリプトオブジェクトのプロパティにシリアル化され、NetConnectionイベントリスナーに渡されます。これにより、clientId接続によって開始されるセッションの番号が確立されます。オブジェクトのエンコーディングは、以前に設定された値と一致する必要があります。

ビデオを再生

ビデオストリームを開始するには、クライアントは「createStream」呼び出しを送信し、その後にpingメッセージを送信し、さらにファイル名を引数として「play」呼び出しを送信します。サーバーは、一連の「onStatus」コマンドと、RTMPメッセージにカプセル化されたビデオデータを返信します。

接続が確立されると、FLV タグの内容を、それぞれオーディオとビデオのタイプ 8 と 9 の RTMP メッセージにカプセル化してメディアが送信されます。

階層化されたプロトコル

HTTPトンネリング（RTMPT）

これは、プロトコルのHTTPトンネリングバージョンを指します。ポート80を介して通信し、AMFデータをHTTP POSTリクエストとレスポンスに含めて渡します。接続シーケンスは以下のとおりです。 

POST /fcs/ident2 HTTP / 1.1コンテンツタイプ: application/x-fcs\r\n HTTP/1.0 404 見つかりません 
POST /open/1 HTTP / 1.1コンテンツタイプ: application/x-fcs\r\n HTTP/1.1 200 OK コンテンツタイプ: application/x-fcs\r\n 1728724019

最初のリクエストには/fcs/ident2パスがあり、正しい応答は404 Not Foundエラーです。次にクライアントは/open/1リクエストを送信します。サーバーは200 okを返さなければなりません。この200 okには、当該通信のセッション識別子として使用される乱数が付加されます。この例では、レスポンスボディに1728724019が返されます。 

POST /idle/1728724019/0 HTTP / 1.1 HTTP/1.1 200 OK 0x01

ここからは/idle/<session id>/<sequence #>ポーリングリクエストとなり、セッションIDはサーバーから生成され返されます。シーケンスはリクエストごとに1ずつ増加する数値です。適切なレスポンスは200 OKで、ボディにはインターバル時間を示す整数が返されます。AMFデータは次のように送信されます。/send/<session id>/<sequence #>

ソフトウェア実装

RTMP は次の 3 つの段階で実装されます。

  • ライブビデオエンコーダー
  • ライブおよびオンデマンドのメディアストリーミングサーバー
  • ライブおよびオンデマンドクライアント

rtmpダンプ

オープンソースのRTMPクライアントコマンドラインツールrtmpdumpは、Adobeが暗号化に使用するRTMPEプロトコルを含む、完全なRTMPストリームを再生またはディスクに保存するように設計されています。RTMPdumpは、Linux、Android、Solaris、 Mac OS X、その他ほとんどのUnix系オペレーティングシステム、そしてMicrosoft Windowsで動作します。当初はWindows 98を含むすべての32ビットWindowsバージョンをサポートしていましたが、バージョン2.2以降はWindows XP以降でのみ動作します（ただし、それ以前のバージョンも引き続き完全に機能します）。

rtmpdumpソフトウェアスイートのパッケージは、主要なオープンソースリポジトリ（Linuxディストリビューション）で入手可能です。これには、フロントエンドアプリ「rtmpdump」、「rtmpsrv」、「rtmpsuck」が含まれます。

RTMPdumpの開発は2009年10月に米国外でMPlayerサイトで再開されました。[ 13 ]現在のバージョンでは機能が大幅に改善され、 Cプログラミング言語の利点を活かすように書き直されました。特に、主要な機能は他のアプリケーションで簡単に使用できるライブラリ（librtmp）に組み込まれました。 RTMPdumpの開発者は、MPlayer、FFmpeg、XBMC、cURL、VLC、その他多くのオープンソースソフトウェアプロジェクト向けにlibrtmpのサポートも作成しました。librtmpを使用することで、これらのプロジェクトは追加の開発作業なしで、あらゆるタイプのRTMPを完全にサポートできるようになります。

FLVストリーマー

FLVstreamerは、Adobeが米国でDMCAに違反していると主張するコードを含まないRTMPdumpのフォークです。これは、2008年にAdobeがRTMPdumpを抑制しようとしたことへの対応として開発されました。FLVstreamerは、ストリームで暗号化（RTMPE）が有効になっていない場合、任意のRTMPサーバーからのオーディオまたはビデオコンテンツのストリームをディスクに保存するRTMPクライアントです。

拡張機能

上記のバリエーションはRTMPをベースに追加されたものです。しかし、FLVとRTMPのコーデックの選択肢が限られているため、業界ではフォーマットとプロトコルに直接機能を追加する必要がありました。

アドホック拡張

RTMPは、サポートするコーデックのセットを識別するために、標準のFourCCではなく、独自の4ビット「コーデックID」を内部的に使用します。オーディオコーデックIDとビデオコーデックIDは異なる名前空間に属するとみなされるため、同じ値を使用しても競合は発生しません。例えば、Adobeのベースライン標準では、オーディオコーデック7はG.711A、ビデオコーデック7はH.264です。

中国では、Kingsoft Cloudが2018年にH.265をビデオコーデック「12」に割り当て、すぐにビリビリなどの業界関係者にも採用されました。2020年には、ZLMediaKitのXia ChuがOpusをオーディオコーデック「13」に割り当てました。[ 14 ]

E-RTMP により、コード化 ID フィールドへのアドホックな追加はすべて廃止されました。E-RTMP は ID 12 と 13 を再利用しないため、中国のアドホック拡張と互換性があります。

拡張RTMP

拡張RTMP（E-RTMP）は、リアルタイムメッセージングプロトコル（RTMP）とFLV仕様の拡張であり、既存のRTMPインフラストラクチャとの互換性を維持しながらストリーミングワークフローを近代化します。[ 2 ]オープン仕様として開発されたE-RTMPは、 Adobe、Google、Twitchなど の貢献により、Veoveraソフトウェア組織によって公開されました。

E-RTMP で導入された機能強化には次のものが含まれます。

  • 元のヘッダー形式の予約部分を使用してシグナルされる新しい FLV オーディオおよびビデオ ヘッダー形式。
    • 以前のヘッダーでは、コーデックの種類を識別するために4ビットの整数が使用されていたため、拡張性が制限されていました。新しい形式では、新しいコーデックを識別するために FourCC番号が使用されます。標準的な選択肢としては、オーディオの場合はAC-3、E-AC-3、Opus、FLAC、ビデオの場合はHDR対応のVP8、VP9、HEVC、AV1などがありますが、合意されたFourCC識別子を持つコーデックであればどれでも使用できます。
    • 新しいヘッダーには、最新のメディア形式との同期を向上させるためのナノ秒レベルのタイムスタンプが含まれています。
    • 新しいヘッダーには、マルチトラック構成を記述する機能が含まれており、単一のストリーム内でオーディオ、ビデオ、メタデータを同時に処理できます。
    • 新しいオーディオ ヘッダーでは、より柔軟なマルチチャンネル オーディオ構成を記述できます。
    • 新しいビデオヘッダーは、フレームタイプではなくパケットタイプを使用します。これらのタイプの一つである は、VideoPacketType.Metadataあらゆるビデオメタデータをアクションメッセージフォーマット（AMF）で書き込むことを可能にします。（AMFは、FLVビデオストリームの一部としてではなく、プロトコルメッセージング層の従来のRTMPで使用されます。）
  • FourCC 形式の新しいコーデック機能の宣伝。
  • RTMP (AMF の既存の使用) の既存のメタデータ メカニズムである onMetaData の新しいフィールド。
  • ストリーミング ワークフローにおける接続の安定性と回復力を向上させる再接続要求機能。

E-RTMPは、既存のRTMP実装との相互運用性を確保しながら、RTMPの機能を強化します。例えば、従来のデコーダーは予約済み（「新しい」）ヘッダーを含むフレームをデコードする方法を認識できませんが、それでも適切に転送することは可能です。

E-RTMPではFLVフォーマット層に多くの変更が加えられているため、E-RTMPにはE-RTMPとは独立して使用できるFLVファイルフォーマットの拡張機能も含まれています。ffmpegはこのフォーマットを「拡張FLV」と呼んでいます。[ 15 ]

実装

プロデューサー:

インジェスター:

インジェスター、拡張 FLV のみ:

  • e-flv-jsは、Veoveraによるflv-js（元々はBilibiliから派生）のフォークです。flv-jsの作者は、Enhanced-FLVをサポートした独自のフォークmpegts.jsも作成しています。[ 19 ]

参照

参考文献

  1. ^ "RTMPE" . Adob​​e Flash Lite 4 ヘルプ. Adob​​e. 2017年12月4日時点のオリジナルよりアーカイブ。2013年12月29日閲覧。
  2. ^ a b Lozben, Slavik (2025年1月21日). 「Enhanced RTMP (V2)」 . Veovera Software Organization . 2025年2月25日閲覧。
  3. ^ a b “TheRealTimeWeb.com: Adob​​e Patents RTMP” . therealtimeweb.com . 2020年2月21日時点のオリジナルよりアーカイブ。 2014年8月4日閲覧。
  4. ^ 「Flex Data Services 2でのRPCサービスの使用」。Adobe DevNet。Adobe。2007年4月3日時点のオリジナルよりアーカイブ。2007年4月16日閲覧。
  5. ^ H. Parmar、M. Thornburgh（編） Adobeのリアルタイムメッセージングプロトコル、Adobe、2012年12月21日
  6. ^ 「Real-Time Messaging Protocol (RTMP) specification」 . 2014年8月21日時点のオリジナルよりアーカイブ。2014年5月8日閲覧。
  7. ^ RTMP仕様ライセンス、2009年4月発行
  8. ^ Schumacher-Rasmussen, Eric (2011年5月27日). 「Wowza、Adobeの特許侵害疑惑を否定」streamingmedia.com .
  9. ^ Lawler, Ryan (2011年5月31日). 「Wowza、Flash特許訴訟でAdobeに反撃」gigaom.com . 2013年2月21日時点のオリジナルよりアーカイブ。
  10. ^ 「ADOBE SYSTEMS INCORPORATE - No. C 11-2243 CW. - 20120907565 - League.com 」。Leagle.com 。
  11. ^ Wowza Media Systems と Adob​​e Systems が特許訴訟で和解http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
  12. ^ Red5プロジェクト (2009) Ping。入手先: http://trac.red5.org/wiki/Documentation/Tutorials/Ping。2011年12月25日にアクセス。
  13. ^ "Updates:2009-11-01" . 2009年11月1日閲覧。
  14. ^
  15. ^ a b「拡張flv形式でHEVC VP9 AV1コーデックをサポート」 GitHub 2024年2月2日2024年4月1日閲覧。
  16. ^ 「YouTubeでRTMP経由でAV1、HEVCを有効にする」 GitHub 2023年3月25日2024年4月1日閲覧。
  17. ^ 「Ant Media Serverで拡張RTMPのパワーを解き放つ」 2024年9月26日。
  18. ^ 「Enhanced Broadcasting Beta の紹介」 GitHub 、 2024年1月8日、 2024年4月1日閲覧。
  19. ^ "xqq/mpegts.js" . 2025年10月22日.
「 https://en.wikipedia.org/w/index.php?title=Real-Time_Messaging_Protocol&oldid=1320331994」より取得