記事ディレクトリ
序文
このセクションでは主に RTSP プロトコルについて説明し、Wireshark パケット キャプチャを通じてプロトコルを分析します。
1. RTSP はオンデマンドでライブ ブロードキャストを自分で構築します
テストツール: VLC
データソース: ファイルまたはローカルカメラ
テスト機能: オンデマンドでの RTSP ライブブロードキャスト
再生アドレス: rtsp://127.0.0.1:554/test
サーバー: プッシュ ストリーミング
クライアント: プル ストリーミング
1. データソースはビデオファイルです
以前のブログ「オーディオとビデオ開発のための共通ツール」の下の図を参照してください。
2. データソースはカメラです
①. RTSPストリーミングメディアサーバーの構築
<1>、[メディア] -> [ストリーム] をクリックします。
<2>、キャプチャ デバイスを選択します。ビデオ デバイスにはラップトップの内蔵カメラ、電撃ストリーミングを選択します。<3>、[
次へ] をクリックします
。<4>、[RTSP] を選択します。新しいターゲットをクリックし、追加
<5> をクリックしてパスを変更し、次の
<6> をクリックして、構成ファイルとしてビデオ - H.264 + MP3 (TS) を選択し、次の
<7> をクリックしてストリーム
<8> をクリックします。このように進行状況バーが動き始めるのがわかります。RTSP ストリーミング メディア サーバーがセットアップされ、現在プッシュされています。
②. クライアントストリーミング
<1>、別の VLC メディア プレーヤーを開き、メディアを選択します -> ネットワーク ストリーミングを開きます
<2>、ネットワーク URL を rtsp://:8554/test2 に変更し、再生をクリックします
<3>、下の図の左側はサーバーはストリーミングをプッシュし、右側はストリームをプルするクライアントです
上の 2 つの例では、データ ソースがそれぞれファイルとカメラの場合に、RTSP ライブ オン デマンド機能を実装しています。
2. RTSPプロトコルの概要
RTSP (Real Time Streaming Protocol)、RFC2326、リアルタイム ストリーミング プロトコルは、TCP/IP プロトコル システムのアプリケーション層プロトコルで、コロンビア大学、Netscape、RealNetworks によって提出された IETF RFC 標準です。このプロトコルは、1 対多のアプリケーションがIP ネットワーク上でマルチメディア データを効率的に送信する方法を定義します。RTSP は、オーディオまたはビデオの制御に使用されるマルチメディア ストリーミングプロトコルであり、複数のストリーミング要件を同時に制御できます。
RTSP は、アーキテクチャ的に RTP および RTCP の上に位置し、TCP または UDP を使用してデータ送信を完了します。
HTTP RTSP と比較すると、HTTP リクエストはクライアントによって発行され、サーバーが応答します。RTSP を使用する場合、クライアントとサーバーの両方がリクエストを発行でき、つまり RTSP は双方向になります。
ライブストリーミングセッションプロトコル
- SDP (セッション記述プロトコル) セッション記述プロトコル
- RTP (リアルタイム転送プロトコル) リアルタイム転送プロトコル: オーディオおよびビデオのストリーミング
RTSP は、ISO10646 文字セットとUTF-8 エンコードスキームを使用するテキストベースのプロトコルです。
行は、メッセージ タイプ、メッセージ ヘッダー、メッセージ本文、メッセージ長を含む CRLF (\r\n:10,13:0x0A,0x0D) によって中断されます。ただし、受信機自体は CR と LF を行。テキストベースのプロトコルにより、自己記述的な方法でオプションのパラメータを簡単に追加でき、インターフェイスの記述言語としてSDPが使用されます。
RTSP は、リアルタイム データの送信を制御するアプリケーション レベルのプロトコルです。
RTSP は、オーディオやビデオなどのリアルタイム データの制御されたオンデマンド ストリーミングを可能にする拡張可能なフレームワークを提供します。データ ソースには、ライブ データとクリップに保存されたデータが含まれます。このプロトコルの目的は、複数のデータ送信接続を制御し、UDP、マルチキャスト UDP、TCP などの送信チャネルを選択する方法を提供し、RTP に基づいて送信メカニズムを選択する方法を提供することです。
RTSP プロトコルは以下をサポートします。
- メディアサーバーからメディアを取得する
- メディアサーバーからの会議への招待
- 既製のレクチャーにメディアを追加する
3. RTSP プロトコルをハンドシュレッドする
RTSP プロトコルを分析したいので、まず対応するパケットをキャプチャし、次にそのパケットに基づいて RTSP プロトコルを分析します。
1. Wireshark パケット キャプチャ
①.環境構築
仮想マシン( 192.168.137.128 ): VLC を使用して
Windows ホスト( 192.168.167.176 ) をプッシュします: VLC を使用してストリームをプルします
②、Wiresharkパケットキャプチャ
仮想マシンのネットワーク カードを選択すると、
次のようにキャプチャされたメッセージの一部が表示されます。
2. RTSP インタラクションプロセス
データを取得するために RTSP サーバーにリクエストを送信するとします。基本的なプロセスは次のとおりです。
①、オプション
- C -> S: クライアントは OPTIONS をサーバーに送信して、利用可能なメソッドを要求します。
- S -> C: サーバーはクライアントに応答し、メッセージには現在使用可能なメソッドが含まれます。
②、説明する
- C -> S: クライアントはサーバーにメディア記述ファイルを要求します。
- S -> C: サーバーはクライアントの SDP ファイルに応答し、サーバーが持つオーディオおよびビデオ ストリームと、コーデック情報、フレーム レートなどの属性をクライアントに伝えます。
SDP テキストの簡単な分析は次のとおりです。完全な情報は次のとおりです。
- (v): 0 //プロトコルのバージョンを示します
- (o):- 16771609170375560276 16771609170375560276 IN IP4 lpvm //セッション所有者に関連する 6 つのパラメータ
- 最初のパラメータ: セッション イニシエータの名前を示します。このパラメータは入力する必要はありません。入力する場合は、SIP メッセージの from ヘッダーの内容と一致している必要があります。
- 2 番目のパラメータ: 発信者のセッション識別子
- 3 番目のパラメータ: 発信者のセッションのバージョン セッション データが変更されると、バージョン番号が増加します。
- 4 番目のパラメータ: ネットワーク タイプを定義します。IN はインターネット ネットワーク タイプを表します。現在、このネットワーク タイプのみが定義されています。
- 5 番目のパラメータ: アドレス タイプ。現在、IPV4 と IPV6 の 2 つのアドレス タイプをサポートしています。
- 6 番目のパラメータ: Address: セッション イニシエータの IP アドレスを示します。このアドレスは、シグナリング プレーンの IP アドレスです。シグナリング PDP がアクティブ化されると、携帯電話に割り当てられます。
- (s): Unnamed // このセッションのタイトル、またはセッションの名前を示します
- (i): N/A //セッションの説明
- (c): IN IP4 0.0.0.0 //行 c には、マルチメディア セッション用に確立された接続に関する情報が含まれており、実際のメディア ストリームで使用される IP アドレスを示します。
- 最初のパラメータはネットワーク タイプです。現在、INTERNET ネットワーク タイプのみが定義されています。「IN」で表す
- 2 番目のパラメータはアドレス タイプです。現在、IPV4 と IPV6 の 2 つのアドレス タイプがサポートされています。
- 3 番目のパラメータはアドレスで、マルチメディア ストリームで使用される IP アドレスです。
- (t): 0 0 //セッションの開始時刻と終了時刻を示します
- (m): audio 0 RTP/AVP 14 //メディア行とも呼ばれる m 行は、送信者がサポートするメディア タイプとその他の情報を記述します。
- 最初のパラメータはメディア名で、サポートされているオーディオ タイプを示します。
- 2 番目のパラメータはポート番号で、UE がローカル ポート 0 でオーディオ ストリームを送信することを示します。
- 3 番目のパラメータは送信プロトコルで、通常は RTP/AVP プロトコルです。
- パラメータ 4 ～ 7 は、サポートされている 4 つのペイロード タイプの番号です。
- (a): rtpmap:14 MPA/90000/2 //a は行動メディアの属性行で、属性名:属性値の形式で表されます。
- 形式は次のとおりです: a=rtpmap:<ペイロード タイプ><エンコーディング名>
③、セットアップ
オーディオおよびビデオデータ送信用のチャネルを準備する
- C -> S: クライアントはサーバーへの接続確立要求を開始し、セッション接続の確立を要求し、音声およびビデオ データの受信開始の準備をします。要求情報には、音声およびビデオ データ パケットの送信が期待されているかどうかが記述されます。 UDP または TCP で、RTP、RTCP ポート、ユニキャストかマルチキャストかなどの情報を指定します。
- S -> C: クライアントの要求を受信した後、サーバーは、クライアントが要求したポート番号に従って、制御データを送信するポートとオーディオおよびビデオ データを送信するポートを決定します。
④、遊ぶ
- C -> S: クライアントはサーバーにメディアの再生を要求します。
- S -> C: サーバーはクライアントに 200 OK! で応答します。次に、SETUP で指定したポートを介してデータの送信を開始します。
⑤、ティアダウン
- C -> S: 再生を終了するとき、クライアントはサーバーに対して終了リクエストを開始します。
- S -> C: メッセージ受信後、サーバーはクライアントに 200 OK を送信して切断します。
手順③と④は必須です。手順① サーバーとクライアントが使用可能なメソッドに同意している限り、オプション要求を行う必要はありません。ステップ 2. メディア初期化記述情報を取得する他の方法 (http 要求など) がある場合は、rtsp の記述要求を通じてそれを完了する必要はありません。
上述的流程基本涵盖了 RTSP 的流程，当然，RTSP 除此之外，还有 PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER 等参数。
3. 契約書式
RTSP のすべての操作は、サーバーとクライアントのメッセージ応答メカニズムを通じて完了します。メッセージには、 要求 と 応答 が含まれます。RTSPは対称プロトコルであり、クライアントとサーバーの両方が要求を送信し、応答することができます。
RTSP は、 UTF-8エンコード (RFC2279) とISO10646文字シーケンスを使用し、RFC882 で定義されたユニバーサル メッセージ形式を使用するテキストベースのプロトコルです。各ステートメント行はCRLF (\r\n)で終了します。RTSP メッセージにはリクエストとレスポンスが含まれます。
①.リクエストメッセージ
リクエスト メッセージは、リクエスト行、ヘッダー行のさまざまなヘッダー フィールド、および本文エンティティで構成されます。リクエストメッセージの形式は次のとおりです。
- メソッド: OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN など。
- URL : 受信者のアドレス、例: rtsp://192.168.137.128:8554/test
- RTSP バージョン: 通常 RTSP/1.0
- CRLF : 各行の後の CRLF はキャリッジ リターンとライン フィードを表し、受信側で対応する解析が必要です。最後のメッセージ ヘッダーには 2 つの CRLF が必要です。
- エンティティ本文:メッセージ本文はオプションであり、一部のリクエスト メッセージにはメッセージ本文が含まれません。
②.応答メッセージ
応答メッセージの開始行はステータス行で、RTSP 応答メッセージの形式は次のとおりです。
- ステータスコード: リクエストメッセージの実行結果を示す数値です。たとえば、成功を示す 200 などです。
- フレーズ: ステータスコードに対応するテキストの説明
4. メソッドの定義
注： P----演示， S----流， C----用户端， S----服务器端
| 方法 | 方向 | 物体 | 必要とする | 意味 |
|---|---|---|---|---|
| 説明する | C -> S | 追伸 | 推薦する | プレゼンテーションまたはメディア オブジェクトの説明をチェックし、受信ヘッダーを使用してユーザーが理解できる説明形式を指定することもできます。DESCRIBE の応答/応答構成メディア RTSP 初期フェーズ |
| 発表する | C -> S S -> C |
追伸 | オプション | ANNOUNCE は、ユーザーからサーバーに送信されると、リクエスト URL で指定されたプレゼンテーションまたはメディア オブジェクトの説明をサーバーに送信し、逆に、ANNOUNCE は接続の説明をリアルタイムで更新します。新しいメディア ストリームがデモに追加されると、添付されたコンポーネントだけでなく、デモの説明全体が再送信され、コンポーネントを削除できるようになります。 |
| GET_PARAMETER | C -> S S -> C |
追伸 | オプション | GET_PARAMETER リクエストは、URL で指定されたデモとメディアのパラメータ値をチェックします。GET_PARAMETER は、エンティティがない場合にサーバーへのユーザーの接続をテストするために使用できます。 |
| オプション | C -> S S -> C |
追伸 | 必要とする | OPTIONS リクエストはいつでも発行でき、ユーザーが標準以外のリクエストを試みても、サーバーのステータスには影響しません。 |
| 一時停止 | C -> S | 追伸 | 推薦する | PAUSE リクエストにより、ストリーム配信が一時的に中断されます。リクエスト URL がストリームを指定している場合は、再生と録音のみが停止されます。リクエスト URL がプレゼンテーションまたはストリーム グループを指定している場合は、プレゼンテーションまたはグループ内で現在アクティブなストリーム配信がすべて停止されます。再生または録音を再開した後は、同期を維持する必要があります。SETUP メッセージの接続ヘッダーのタイムアウト パラメーターで指定された期間一時停止された後、サーバーのリソースは予約されますが、サーバーは接続を閉じてリソースを解放することがあります。 |
| 遊ぶ | C -> S | 追伸 | 必要とする | PLAY は、SETUP で指定されたメカニズムを使用してデータの送信を開始するようにサーバーに指示します。クライアントは、いくつかの SETUP リクエストが正常に応答されるまで、PLAY リクエストを発行できません。PLAY リクエストは、通常の再生時間を指定範囲の先頭に設定し、範囲の末尾までストリーミング データを送信します。PLAY リクエストはキューに入れることができ、サーバーは PLAY リクエストをキューに入れ、順番に実行します。 |
| 記録 | C -> S | 追伸 | オプション | このメソッドは、デモンストレーションの説明に従ってメディア データの記録範囲を初期化し、タイム スケールには開始時刻と終了時刻が反映されます。時間範囲が指定されていない場合は、デモンストレーションの説明によって提供される開始時刻と終了時刻が使用されます。接続が開始されている場合は、すぐに記録が開始されます。サーバー データ リクエスト URL またはその他の URL によって、記録されたデータを保存するかどうかが決まります。サーバーが URL リクエストを使用しない場合、応答は 201 (作成) であり、次の内容を記述するエンティティが含まれている必要があります。リクエストのステータスと新しいリソースの参照 位置ヘッダー。ライブ プレゼンテーションの録画をサポートするメディア サーバーは、クロック レンジ形式をサポートする必要があります。smpte 形式は意味がありません。 |
| リダイレクト | S -> C | 追伸 | オプション | リダイレクト要求は、クライアントに別のサーバー アドレスに接続するように通知します。これには、クライアントに URL リクエストの発行を指示する必須のヘッダー アドレスが含まれており、リダイレクトがいつ有効になるかを示すパラメータ範囲も含まれる場合があります。クライアントが URL メディアの送受信を継続したい場合、クライアントは、指定されたホストへの現在の接続に TEARDOWN リクエストを送信し、新しい接続に SETUP リクエストを送信する必要があります。 |
| 設定 | C -> S | 追伸 | オプション | URL への SETUP リクエストは、ストリーミング メディアに使用されるトランスポート メカニズムを指定します。クライアントは、再生中のストリームに対して SETUP リクエストを発行して、サーバーによって許可されているトランスポート パラメータを変更します。これが許可されていない場合、応答エラーは「455 Method Not Valid In This State」となります。ファイアウォールを通過するには、クライアントは、これらのパラメータに影響がない場合でも、トランスポート パラメータを指定する必要があります。 |
| SET_PARAMETER | C -> S S -> C |
追伸 | 必要とする | このメソッドは、デモまたは URL 指定ストリームのパラメーター値の設定を要求します。リクエストにはパラメータを 1 つだけ含めて、特定のリクエストが失敗した理由をクライアントが判断できるようにする必要があります。リクエストに複数のパラメータが含まれている場合、すべてのパラメータを正常に設定でき、サーバーはこのリクエストに対してのみ動作する必要があります。サーバーは、パラメータを同じ値に繰り返し設定できるようにする必要がありますが、パラメータ値を変更することはできません。注: メディア ストリーミング パラメータは、SETUP コマンドを使用して設定する必要があります。ファイアウォールでセットアップ転送パラメータを SETUP に制限すると便利です。パラメータを規則的な配置に分割し、より意味のあるエラー表示を実現します |
| 取り壊す | C -> S | 追伸 | 必要とする | TEARDOWN は、指定された URL ストリームの送信を停止し、関連リソースを解放するように要求します。URL がこのデモ URL である場合、RTSP 接続識別子は無効になります。すべてのトランスポート パラメータが接続の説明で定義されていない限り、接続を再度再生するには、SETUP リクエストを発行する必要があります。 |
5. ステータス
RTSP ステート マシン
RTSP は、制御チャネルとは独立して、別のプロトコルを介して送信されるデータ フローを制御します。たとえば、RTSP 制御は TCP 接続経由で、データ フローは UDP 経由で行うことができます。したがって、メディア サーバーがリクエストを受信しなくても、データは送信され続けます。接続の有効期間中、さまざまな TCP 接続シーケンスでリクエストを発行することで、個々のメディア ストリームを制御できます。したがって、サーバーは RTSP リクエストによる接続状態の通信ストリームを維持する必要があります。RTSP の多くのメソッドは状態とは関係ありませんが、次のメソッドはサーバー ストリーム リソースの割り当てとアプリケーションを定義する際に重要な役割を果たします。
- セットアップ: サーバーにリソースをストリームに割り当てさせ、RTSP 接続を開始させます。
- PLAY および RECORD: SETUP 割り当てストリームのデータ送信を開始します。
- PAUSE: サーバーリソースを解放せずにストリームを一時的に停止します。
- TEARDOWN: ストリームのリソースを解放し、RTSP 接続を停止します。
RTSP ステータスを識別する方法では、接続ヘッダー フィールドを使用して RTSP 接続を識別し、SETUP リクエストに応答して、サーバー接続が接続 ID を生成します。
4. RTSPとHTTP
リアルタイム ストリーミング プロトコルは構文と操作が HTTP/1.1 に似ているため、HTTP のほとんどの拡張メカニズムを RTSP に追加できます。ただし、RTSP は多くの重要な点で HTTP とは異なります。
- RTSP は多数の新しいメソッドを導入し、異なるプロトコル識別子を持ちます
- ほとんどの場合、HTTP のステートレスとは対照的に、RTSP サーバーはデフォルトの状態を維持する必要があります。
- RTSP では、クライアントとサーバーの両方がリクエストを行うことができます
- ほとんどの場合、データは異なるプロトコルで送信されます
- RTSP は、現在の国際標準 HTML と一致するように、ISO 8859-1 の代わりに ISO 10646 (UTF-8) を使用します。
- URL リクエストには常に絶対 URL が含まれます。過去のバグとの互換性を保つため、HTTP/1.1 はリクエスト中に絶対パスのみを送信し、ホスト名を追加のヘッダー フィールドに置きます。
私のqq：2442391036、コミュニケーションへようこそ！