FFMPEGのRTPプロトコル（リアルタイムトランスポートプロトコル）01

1 RTPおよびRTCP制御プロトコル
1）RTPプロトコル機能：
ストリーミングメディア、ビデオ会議、TVサービスなど、ネットワーク上でオーディオおよびビデオデータをリアルタイムで送信するために使用される標準のデータパケット形式。

2）RTPをRTCPと組み合わせて使用する必要がある理由：
RTPは低遅延のデータ送信サービスを提供できますが、データパケットがクライアントに到着したときに順序を維持することを保証できないため、フロー制御と輻輳監視を完了するにはRTCPを使用する必要があります。

3）RTPにシリアル番号が必要なのはなぜですか？
OSI 7層モデルでは、RTPプロトコルはトランスポート層で実行され、他の基盤となるプロトコルもRTPで機能します。RTPデータパケットは、カプセル化ヘッダーを介して渡されるUDPであり、UDPパケットを形成します。
RTP自体にはサービス品質保証メカニズムが含まれていないため、RTPは受信データフィールドの同じ送信シーケンスを維持することも、基盤となるネットワークによって提供されるサービスが信頼できるかどうかを検証することもできません。RTPはデータパケットにシーケンス番号を追加します。これにより、受信者はデータパケットを受信した後にシーケンス番号を検出してデータパケットを並べ替えることができます。

4）RTPにタイムスタンプが必要なのはなぜですか？
ストリーミングメディアのデータ送信では、通常、同じ深刻な問題に直面します。つまり、クライアントへのデータ送信の時点は予測できませんが、ストリーミングメディアの送信では、データを適切なタイミングで宛先に配信できるようにする必要があります。データの正しい再生。
したがって、リアルタイムデータストリームの送信を制御するために、RTPプロトコルにはタイムスタンプやシリアル番号などの構造が含まれています。タイムスタンプは、ストリーミングメディア送信のプロセスで重要な役割を果たし、クライアントに重要なデータを提供します。RTPメッセージを送信する場合、送信者はサンプリング時間を記録するために使用するデータをタイムスタンプと呼ばれるデータパケットに配置します。データパケットがネットワークを介して受信側に到達した後、受信側はデータパケットからデータ端を抽出する必要があります。、それによると、元のデータシーケンスを復元します。RTPはトランスポートレイヤープロトコルにすぎず、同期の責任はありません。RTPは、機能のこの部分をアプリケーションレイヤーに任せて完了させ、データ処理を簡素化し、運用効率を向上させるという目的を達成しました。
RTPデータユニットはUDPパケットによって伝送されます。もちろん、RTPデータユニットをUDPパケットにカプセル化するだけでなく、データのフレームを複数のUDPパケットに分割して、同じデータフレームに属する送信を行います。 UDPパケットのタイムスタンプはまったく同じになります。

5）RTCPを使用する理由：
RTPセッション中、RTCPプロトコルの役割は、主に、データ送信の正しい速度を監視する交換制御情報を送信することです。セッション中、参加者は、送信されたデータパケットの数や配信できないデータパケットの数など、関連する統計情報を他のユーザーに送信します。これらの情報の送信は通常、同じ時間間隔で実行されます。セッション中に定期的に完了します。
サーバーはデータを解析し、それに応じてデータの送信速度を増減します。他のタイプのペイロードに切り替えることもできます。これらの変更は動的に行われます。RTPはRTCPと連携して動作し、制御情報を返し、帯域幅の消費を削減することで伝送効率を向上させ、データ伝送の遅延を最小限に抑えます。

6）
RTCPの4つの主な機能：RTCPには、主に4つの機能があります。輻輳制御、ネットワークモニタリング、および分散データの伝送品質をフィードバックすることによるネットワークの問題の診断です。SSRC（同期ソース識別）は静的ではないため、ネットワークの輻輳が発生した場合、または参加者のプログラムが変更された場合、SSRCが更新されます。RTPソースに追加のトランスポートレイヤーフラグを提供する必要があります。データパケットが受信側にスムーズに到達できるように、RTCPパケットの送信速度を調整する必要があるため、に基づく必要があります。調整を行うための参加者データ、セッション制御情報の転送。

2 RTPファイルヘッダー形式
RTPメッセージは、ヘッダーとペイロードの2つの部分で構成されています。ヘッダーの合計バイト数は12バイトです。

ここに写真の説明を挿入
バージョン番号（V）：2ビット、使用されるRTPバージョンをマークするために使用されます。
充填ビット（P）：1ビット。このビットが設定されている場合、RTPパケットの終わりには追加のパディングバイトが含まれます。
拡張ビット（X）：1ビット。このビットが設定されている場合、拡張ヘッダーの後にRTP固定ヘッダーが続きます。
CSRCカウンター（CC）：4ビット、SSRC後のCSRCの数。
マークビット（M）：1ビット、このビットの解釈は構成ファイル（プロファイル）を担当します。
PayloadType：7ビット。RTPペイロードのタイプを識別します。詳細は添え字で記入します。
シリアル番号（SN）：16ビット。RTPパケットが送信されるたびに、シリアル番号は1ずつ増加します。受信側はパケット損失を検出し、それに応じてパケットシーケンスを再構築できます。
タイムスタンプ：4バイト。パケット内のデータの最初のバイトのサンプリング時間を記録します。セッションの開始時に、タイムスタンプは初期値に初期化されます。送信する信号がない場合でも、タイムスタンプの値は時間の経過とともに増加し続けます。クロック周波数は負荷データ形式に依存し、プロファイルに記述されています。

同期ソース識別子（SSRC）：32ビット、同期ソースはRTPパケットストリームのソースを参照します。同じRTPセッションに2つの同一のSSRC値を含めることはできません。識別子はランダムに選択されますRFC1889推奨のMD5ランダムアルゴリズム。

コントリビューションソースリスト（CSRC）：RTPミキサーによって生成された新しいパケットにコントリビューションするすべてのRTPパケットのソースをマークするために使用される、それぞれ32ビットの0〜15項目。これらの寄与SSRC識別子は、ミキサーによってテーブルに挿入されます。SSRC IDはすべてリストされているため、受信側は会話の2つの当事者のIDを正しく示すことができます。

7ビットのペイロードタイプは次のとおりです
。RFC3551：
ここに写真の説明を挿入

3RTPヘッダー形式を実装するためのコード


#pragma pack(1)//1位字节对齐

//变量:数字表示位与操作，结构体字节的大小按照平时的方法计算即可
typedef struct RTP_FIXED_HEADER{
    
    
	/* byte 0 */
	unsigned char csrc_len:4;       /* expect 0 */
	unsigned char extension:1;      /* expect 1 */
	unsigned char padding:1;        /* expect 0 */
	unsigned char version:2;        /* expect 2 */
	/* byte 1 */
	unsigned char payload:7;
	unsigned char marker:1;        /* expect 1 */
	/* bytes 2, 3 */
	unsigned short seq_no;            
	/* bytes 4-7 */
	unsigned  long timestamp;        
	/* bytes 8-11 */
	unsigned long ssrc;            /* stream number is used here. */
} RTP_FIXED_HEADER;

FFMPEGのRTPプロトコル（リアルタイムトランスポートプロトコル）01

FFMPEGのRTPプロトコル（リアルタイムトランスポートプロトコル）01

おすすめ