RTP
ライブの音声・映像に、順序と時刻を与える 12 バイトのヘッダ。
ヘッダと、中の H.264
固定の 12 バイトと、そのあとに続く H.264 の断片の先頭です。
フレーム全体
80 E0 12 34 00 12 D7 70 4C 1F 3A 92: RTP が足すのは 12 バイトのヘッダだけ。順序と損失のためのシーケンス番号、タイミングのためのタイムスタンプ、どのストリームかを示す SSRC です。
| フィールド | 位置 | 例の値 | 意味 |
|---|---|---|---|
| バージョン | 0 バイト目の bits 7–6 | 2 | 現在の RTP では常に 2。 |
| パディング | 0 バイト目の bit 5 | 0 | 末尾にパディングがあれば 1（一部の暗号方式で必要）。ここでは 0。 |
| 拡張ヘッダ | 0 バイト目の bit 4 | 0 | 固定ヘッダの後に拡張ヘッダが続くなら 1。 |
| CSRC 数 | 0 バイト目の bits 3–0 | 0 | ヘッダの後に続く寄与ソース ID の数。ミキサが複数のソースを混ぜるときだけ 0 でなくなります。 |
| マーカー | 1 バイト目の bit 7 | 1 = last packet of the frame | 意味はペイロードの種類によります。映像では 1 フレームの最後のパケットで立ち、次のタイムスタンプを待たずにデコードを始められることを示します。 |
| ペイロード種別 | 1 バイト目の bits 6–0 | 96 (dynamic, H.264 per SDP) | 中身がどの符号化・形式か。0〜95 は固定割り当て（0 = PCMU 音声）、96〜127 は動的で、セッション記述（SDP）が 96 の意味（ここでは H.264）を決めます。 |
| シーケンス番号 | 2–3 バイト目 | 4660 | パケットを送るたびに +1。受信側は欠番で損失を検出し、順序を並べ直します。初期値はランダムです。 |
| タイムスタンプ | 4–7 バイト目 | 1234800 (13.720 s on the 90 kHz clock) | メディアの採取時刻をクロック刻みで表します（映像は毎秒 90,000）。1 フレームの全パケットは同じ値で、25 fps ならフレームごとに 3,600 増えます。壁時計ではなくメディア上の時刻で、再生タイミングや口パク同期に使います。 |
| SSRC | 8–11 バイト目 | 0x4C1F3A92 | 同期ソース識別子。このストリーム固有のランダムな ID です。同じ送信元の音声と映像でも SSRC は別で、受信側はこれでストリームを分けます。 |
| FU インジケータ | 12 バイト目 | 0x7C = FU-A, NRI 3 | RTP 上の H.264（RFC 6184）は、大きな NAL ユニットを FU-A と呼ぶ断片に分けます。インジケータは元の F と NRI を残し、種別を 28（= 断片）にします。 |
| FU ヘッダ | 13 バイト目 | 0x45 = last fragment of an IDR slice | この断片が元の NAL ユニットのどこにあたるか、元の NAL 種別が何かを示します。 |
| H.264 データ | 14–17 バイト目 | …slice data | 圧縮されたスライスの末尾部分です。フルHD のキーフレームは数十 KB あり、同じタイムスタンプを持つ 1,400 バイト前後のパケット数十個に分かれます。 |
概要
RTP（Real-time Transport Protocol）は、ライブのメディアを UDP の上で運びます。UDP はネットワークまかせの順序とタイミングで届けるので、RTP は再生側に必要なものを足します。順序の復元と損失検出のためのシーケンス番号、正しい瞬間に再生するためのタイムスタンプ、どのストリームかを示す SSRC です。
ビデオ通話（WebRTC）、IP カメラ（RTSP）、放送用の IP 映像（SMPTE ST 2110）など、多くの土台になっています。仲間の RTCP は、損失やジッタを送信側へ報告します。
基本情報
- トランスポート
- UDP (even port; RTCP on the next)
- ヘッダ
- 12 バイト（+ CSRC）
- 映像のクロック
- 90 kHz
- 配送
- ベストエフォート、再送なし
- 対になるもの
- RTCP, SDP
- 規格
- RFC 3550
非圧縮の映像
同じヘッダが、放送局が送るのと同じ形で、生の画素を運びます。
フレーム全体
同じ 12 バイトの RTP ヘッダの後に、画素がどのラインのどこに入るかを示す小さな映像ヘッダが続きます。放送局は、この形式で放送用映像を普通の Ethernet に流しています。
| フィールド | 位置 | 例の値 | 意味 |
|---|---|---|---|
| バージョン | 0 バイト目の bits 7–6 | 2 | 現在の RTP では常に 2。 |
| パディング | 0 バイト目の bit 5 | 0 | 末尾にパディングがあれば 1（一部の暗号方式で必要）。ここでは 0。 |
| 拡張ヘッダ | 0 バイト目の bit 4 | 0 | 固定ヘッダの後に拡張ヘッダが続くなら 1。 |
| CSRC 数 | 0 バイト目の bits 3–0 | 0 | ヘッダの後に続く寄与ソース ID の数。ミキサが複数のソースを混ぜるときだけ 0 でなくなります。 |
| マーカー | 1 バイト目の bit 7 | 0 | 意味はペイロードの種類によります。映像では 1 フレームの最後のパケットで立ち、次のタイムスタンプを待たずにデコードを始められることを示します。 |
| ペイロード種別 | 1 バイト目の bits 6–0 | 96 (dynamic, H.264 per SDP) | 中身がどの符号化・形式か。0〜95 は固定割り当て（0 = PCMU 音声）、96〜127 は動的で、セッション記述（SDP）が 96 の意味（ここでは H.264）を決めます。 |
| シーケンス番号 | 2–3 バイト目 | 7001 | パケットを送るたびに +1。受信側は欠番で損失を検出し、順序を並べ直します。初期値はランダムです。 |
| タイムスタンプ | 4–7 バイト目 | 1234800 (13.720 s on the 90 kHz clock) | メディアの採取時刻をクロック刻みで表します（映像は毎秒 90,000）。1 フレームの全パケットは同じ値で、25 fps ならフレームごとに 3,600 増えます。壁時計ではなくメディア上の時刻で、再生タイミングや口パク同期に使います。 |
| SSRC | 8–11 バイト目 | 0x4C1F3A92 | 同期ソース識別子。このストリーム固有のランダムな ID です。同じ送信元の音声と映像でも SSRC は別で、受信側はこれでストリームを分けます。 |
| 拡張シーケンス番号 | 12–13 バイト目 | 0 (low 16 bits are in the RTP header) | シーケンス番号の上位 16 ビットです。非圧縮映像は毎秒のパケット数が多く、通常の 16 ビットでは 1 秒足らずで一周してしまうため、32 ビットに拡張します。 |
| SRD 長 | 14–15 バイト目 | 8 bytes | 1 つのパケットは Sample Row Data（SRD）を 1 つ以上運び、それぞれに 6 バイトのヘッダが付きます。この SRD の画素データは 8 バイトです。 |
| F（フィールド） | 16 バイト目の bit 7 | 0 | インターレース映像では 0 = 第 1 フィールド、1 = 第 2 フィールド。プログレッシブでは常に 0。 |
| ライン番号 | 16–17 バイト目にまたがる | 100 | この画素データが画面の何行目か（上端が 0）。 |
| C（継続） | 18 バイト目の bit 7 | 0 | 同じパケットに次の SRD ヘッダが続くなら 1。0 = これが最後。 |
| 画素オフセット | 18–19 バイト目にまたがる | 0 (start of the line) | ラインの中で、このデータが始まる水平位置（画素数）。 |
| 画素（YCbCr 4:2:2、8 ビット） | 20–27 バイト目 | 4 white pixels | 生の画素です。2 画素で 4 バイト、順序は Cb・Y0・Cr・Y1。0x80 は無彩色、0xEB（235）が映像の白なので、この 4 画素は白です。幅 1920 画素の 1 ラインは 3,840 バイトで、映像はまったく圧縮されません。 |
パケット、欠けた 1 つ、そして報告
シーケンス番号とタイムスタンプが、損失とフレームの境目をどう見せるか。
やり取りの全体
RTP はメディアのパケットに番号とタイムスタンプを付けますが、配送は保証しません。損失は検出するだけで、修復はアプリケーションか SRT のようなプロトコルの役目です。
1フレーム 1 の最初のパケット
大きなフレームは、ネットワークの MTU に収まるパケットに切られます。すべて同じタイムスタンプ（3,600）で、シーケンス番号は連番です。
2最後のパケット: マーカーを立てる
M=1 は、これでフレーム 1 がそろったことを示します。デコーダは、新しいタイムスタンプのパケットを待たずにデコードして表示できます。
3フレーム 2 が始まる
タイムスタンプが 3,600 刻み（90 kHz で 40 ms）進みます。毎秒 25 フレームです。
4パケットが失われる
UDP は再送しません。seq=103 のパケットは届きません。
5欠番で気づく
102 の次に 104 が来たので、受信側は「ちょうど 1 つ欠けた」と分かります。フレーム 2 は壊れているため、誤りの隠蔽、直前のフレームの再表示、新しいキーフレームの要求などで対処します。
6RTCP 受信レポート
メディアと並行して、RTCP が統計（ここでは 5 つに 1 つの損失とジッタ）を運びます。送信側はビットレートを下げる、誤り訂正を足す、キーフレームを送るなどで適応できます。
使われる場面
- WebRTC のビデオ通話・会議
- IP カメラ・監視（多くは RTSP で設定）
- 放送・業務用 AV の IP 化: SMPTE ST 2110、AES67 など
つまずきやすい点
- タイムスタンプの単位はペイロードにより異なります（映像は毎秒 90,000、音声はサンプルレート）。そのまま比べてはいけません。
- 経路 MTU を超えるパケットは IP で分割され、まとめて失われやすくなります。1,200〜1,400 バイト程度に収めます。
- RTP のポートはセッションごとに交渉するため、ファイアウォールや NAT に阻まれがちです。STUN/TURN/ICE がその解決策です。
出典・規格
- RFC 3550: RTP
- RFC 6184: RTP Payload Format for H.264
- RFC 4175: RTP Payload Format for Uncompressed Video