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

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

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

RTMP は、伝送制御プロトコル(TCP)上で動作し、デフォルトでポート番号 1935 を使用する「プレーン」プロトコルです。
RTMPS は、トランスポート層セキュリティ(TLS/SSL) 接続を介した RTMP です。
RTMPEはAdobe独自のセキュリティメカニズムを使用して暗号化されたRTMPです。実装の詳細は独自のものですが、メカニズムは業界標準の暗号化プリミティブを使用します。^[1]
RTMPT は、ファイアウォールを通過するために HTTP要求内にカプセル化されます。RTMPT は、TCPポート80 および 443 でクリアテキスト要求を使用して、ほとんどの企業トラフィックフィルタリングをバイパスすることがよくあります。カプセル化されたセッションは、プレーンな RTMP、RTMPS、または RTMPE パケットを内部で伝送する場合があります。
RTMFP は、 TCP ではなくユーザーデータグラムプロトコル(UDP)経由の RTMP であり、RTMP チャンクストリームに代わるものです。セキュアリアルタイムメディアフロープロトコルスイートは Adobe Systems によって開発され、エンドユーザーが直接接続して通信 (P2P) できるようにします。

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

基本操作

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

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

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

暗号化

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の仕様を公開しました。^[4]この仕様のWebランディングページには、「コンテンツを保護したい顧客の利益のために、オープンRTMP仕様にはAdobe独自のセキュアRTMP対策は含まれていません」と記載されています。^[5]

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

特許および関連訴訟

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

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

パケット構造

パケットは、最初にクライアントとサーバーの間で確立される 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 );

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

パケットは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 番目のメッセージは 0xC3 (b11000011) の ID で始まり、すべてのメッセージヘッダーフィールドはストリーム ID が 3 のメッセージ (そのすぐ上のメッセージ) から取得されることを意味します。ストリーム ID を形成する 6 つの最下位ビットは、3 から 63 までの値を取ることができます。一部の値には特別な意味があります。たとえば、1 は拡張 ID 形式を表し、その場合は 2 バイトが続きます。値 2 は、Ping やクライアント帯域幅の設定などの低レベルメッセージ用です。

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 = データ (呼び出し (onMetaData 情報がそのまま送信されます))。
0x13 = コンテナ。
0x14 = コマンド（AMF0 タイプのコマンド）。
0x15 = UDP
0x16 = 集計
0x17 = 存在

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

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

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

(文字列) <コマンド名>
(番号) <トランザクション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つの値を取ることができる^[11]。

タイプ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 バイトで、変更が必要な場合にのみメッセージが送信されます。

プロトコル

ハンドシェーク

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

接続する

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

(呼び出し) "connect" (トランザクションID ) 1.0 ( Object1 ) { 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 がテスト用に提供した名前です。文字列は、 flashVerAction-scriptgetversion()関数によって返されるものと同じです。audioCodecおよびはdoublevideoCodecとしてエンコードされ、その意味は元の仕様に記載されています。変数についても同様で、この場合は、説明不要の SUPPORT_VID_CLIENT_SEEK 定数です。特に興味深いのは、通信の残りの部分で拡張AMF3形式を使用するかどうかを定義するです。バージョン 3 が現在のデフォルトであるため、要求された場合は、Action-script コードで Flash クライアントに 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 経由で通信し、 HTTP POST 要求と応答内でAMFデータを渡します。接続のシーケンスは次のとおりです。

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 で応答する必要があります。この例では、応答本文に 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サイトで再開されました。^{[12]現在のバージョンでは機能が大幅に改善され、}Cプログラミング言語の利点を活かすように書き直されました。特に、主要な機能はライブラリ（librtmp）に組み込まれ、他のアプリケーションで簡単に使用できます。RTMPdumpの開発者は、 MPlayer、FFmpeg、XBMC、cURL、VLC、およびその他の多くのオープンソースソフトウェアプロジェクト用にlibrtmpのサポートも作成しました。librtmpを使用すると、これらのプロジェクトは追加の開発作業なしで、すべてのバリアントのRTMPを完全にサポートできます。

FLVストリーマー

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

強化されたRTMP

RTMPのFlashビデオコンテナは、ほとんどの実装でH264コーデックに制限されています。このため、 Adobe、Google、Twitch、Veriskopeを含むVeoveraソフトウェア組織は、 FlashビデオコンテナFLVに VP9、H265、AV1コーデックのサポートを追加する拡張RTMP仕様^[13]を公開しました。

実装

ffmpeg (6.1以降) ^[14]
OBSスタジオ29.1 ^[15]
YouTube (ベータ版、h264 と同じ取り込みパラメータ)
ツイッチ^[16]
アントメディアサーバー^[17]

参照

参考文献

^ 「RTMPE」。Adobe Flash Lite 4 ヘルプ。Adobe。2013年12 月 29 日閲覧。
^ ab "TheRealTimeWeb.com: Adobe Patents RTMP".リアルタイムウェブ.com。
^ 「Flex Data Services 2 での RPC サービスの使用」。2007 年 4 月 3 日時点のオリジナルよりアーカイブ。2007 年4 月 16 日に取得。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です
^ H. Parmar、M. Thornburgh (編) Adobe のリアルタイムメッセージングプロトコル、Adobe、2012 年 12 月 21 日
^ 「Real-Time Messaging Protocol (RTMP) 仕様」。2014年8月21日時点のオリジナルよりアーカイブ。 2014年5月8日閲覧。
^ RTMP 仕様ライセンス、2009 年 4 月発行
^ Schumacher-Rasmussen, Eric (2011 年 5 月 27 日). 「Wowza が Adobe の特許侵害の申し立てを否定」. streamingmedia.com .
^ Lawler, Ryan (2011 年 5 月 31 日). 「Wowza が Flash 特許訴訟で Adobe に反撃」. gigaom.com .
^ 「ADOBE SYSTEMS INCORPORATE - No. C 11-2243 CW. - 20120907565 - League.com」。leagle.com。
^ Wowza Media Systems と Adobe Systems が特許訴訟を和解 http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
^ Red5 プロジェクト (2009) Ping。入手先: http://trac.red5.org/wiki/Documentation/Tutorials/Ping。アクセス日: 2011 年 12 月 25 日
^ 「Updates:2009-11-01」。 2009年11月1日閲覧。
^ Lozben, Slavik (2024年2月2日). 「追加のビデオコーデックとHDRサポートによるRTMP、FLVの強化」. GitHub . 2024年4月1日閲覧。
^ 「拡張flv形式でHEVC VP9 AV1コーデックをサポート」GitHub。2024年2月2日。 2024年4月1日閲覧。
^ 「YouTube への RTMP 経由で AV1、HEVC を有効にする」。GitHub。2023年 3 月 25 日。2024 年4月 1 日閲覧。
^ 「Enhanced Broadcasting Beta の紹介」。GitHub。2024年1 月 8 日。2024 年4 月 1 日に閲覧。
^ 「Ant Media Server で拡張 RTMP のパワーを解き放つ」。2024 年 9 月 26 日。

外部リンク

Adobe 開発者ページ - RTMP - 公式仕様
OBS Studio を使用して RTMP ストリームを Wowza Streaming Cloud に送信する
オープンブロードキャスターソフトウェア: SRT または RIST プロトコルによるストリーミング

[RTMPE_overview-1] 「RTMPE」。Adobe Flash Lite 4 ヘルプ。Adobe。2013年12 月 29 日閲覧。

[:0-2] "TheRealTimeWeb.com: Adobe Patents RTMP".リアルタイムウェブ.com。

[3] 「Flex Data Services 2 での RPC サービスの使用」。2007 年 4 月 3 日時点のオリジナルよりアーカイブ。2007 年4 月 16 日に取得。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です

[4] H. Parmar、M. Thornburgh (編) Adobe のリアルタイムメッセージングプロトコル、Adobe、2012 年 12 月 21 日

[5] 「Real-Time Messaging Protocol (RTMP) 仕様」。2014年8月21日時点のオリジナルよりアーカイブ。 2014年5月8日閲覧。

[6] RTMP 仕様ライセンス、2009 年 4 月発行

[7] Schumacher-Rasmussen, Eric (2011 年 5 月 27 日). 「Wowza が Adobe の特許侵害の申し立てを否定」. streamingmedia.com .

[8] Lawler, Ryan (2011 年 5 月 31 日). 「Wowza が Flash 特許訴訟で Adobe に反撃」. gigaom.com .

[9] 「ADOBE SYSTEMS INCORPORATE - No. C 11-2243 CW. - 20120907565 - League.com」。leagle.com。

[10] Wowza Media Systems と Adobe Systems が特許訴訟を和解 http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases

[11] Red5 プロジェクト (2009) Ping。入手先: http://trac.red5.org/wiki/Documentation/Tutorials/Ping。アクセス日: 2011 年 12 月 25 日

[12] 「Updates:2009-11-01」。 2009年11月1日閲覧。

[13] Lozben, Slavik (2024年2月2日). 「追加のビデオコーデックとHDRサポートによるRTMP、FLVの強化」. GitHub . 2024年4月1日閲覧。

[14] 「拡張flv形式でHEVC VP9 AV1コーデックをサポート」GitHub。2024年2月2日。 2024年4月1日閲覧。

[15] 「YouTube への RTMP 経由で AV1、HEVC を有効にする」。GitHub。2023年 3 月 25 日。2024 年4月 1 日閲覧。

[16] 「Enhanced Broadcasting Beta の紹介」。GitHub。2024年1 月 8 日。2024 年4 月 1 日に閲覧。

[17] 「Ant Media Server で拡張 RTMP のパワーを解き放つ」。2024 年 9 月 26 日。