RTP
A 12-byte header that puts timing and order onto live audio and video.
The header, with H.264 inside
The fixed 12 bytes, followed by the start of an H.264 fragment.
Whole frame
80 E0 12 34 00 12 D7 70 4C 1F 3A 92: a 12-byte header is all RTP adds. Sequence number for order and loss, timestamp for timing, SSRC for which stream.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| Version | Byte 0, bits 7–6 | 2 | Always 2 for the current RTP. |
| Padding | Byte 0, bit 5 | 0 | 1 if the packet ends with padding bytes (needed by some ciphers). 0 here. |
| Extension | Byte 0, bit 4 | 0 | 1 if a header extension follows the fixed header. |
| CSRC count | Byte 0, bits 3–0 | 0 | How many contributing-source IDs follow the header. Non-zero only when a mixer combines several sources. |
| Marker | Byte 1, bit 7 | 1 = last packet of the frame | Meaning depends on the payload. For video it is set on the last packet of a frame, so the receiver knows it can decode now without waiting for the next timestamp. |
| Payload type | Byte 1, bits 6–0 | 96 (dynamic, H.264 per SDP) | Which codec/format is inside. 0–95 are fixed assignments (0 = PCMU audio), 96–127 are dynamic: a session description (SDP) says what 96 means, here H.264. |
| Sequence number | Byte 2–3 | 4660 | +1 for every packet sent. The receiver uses it to spot loss (a gap) and to put packets back in order. It starts at a random value. |
| Timestamp | Byte 4–7 | 1234800 (13.720 s on the 90 kHz clock) | The sampling instant of the media, in clock ticks (90,000 per second for video). All packets of one frame share the same timestamp; 25 fps adds 3,600 per frame. It is media time, not wall-clock time: it drives playback timing and lip-sync. |
| SSRC | Byte 8–11 | 0x4C1F3A92 | Synchronization source: a random ID of this stream. Audio and video from the same sender have different SSRCs; the receiver separates streams by it. |
| FU indicator | Byte 12 | 0x7C = FU-A, NRI 3 | H.264 over RTP (RFC 6184) splits a large NAL unit into fragments called FU-A. The indicator keeps the original F and NRI bits and sets the type to 28, meaning 'fragment'. |
| FU header | Byte 13 | 0x45 = last fragment of an IDR slice | Says where this fragment sits in the original NAL unit, and what the original NAL type was. |
| H.264 data | Byte 14–17 | …slice data | The tail of the compressed slice. A full-HD key frame is tens of kilobytes, so it is spread over dozens of ~1,400-byte packets that share one timestamp. |
Overview
RTP (Real-time Transport Protocol) carries live media over UDP. UDP delivers packets in whatever order and timing the network gives, so RTP adds what a player needs: a sequence number to restore order and detect loss, a timestamp to play frames at the right moment, and an SSRC to say which stream a packet belongs to.
It is the foundation under video calls (WebRTC), IP cameras (RTSP), broadcast IP video (SMPTE ST 2110) and many more. RTCP, its companion, reports loss and jitter back to the sender.
Key facts
- Transport
- UDP (even port; RTCP on the next)
- Header
- 12 bytes (+ CSRCs)
- Video clock
- 90 kHz
- Delivery
- Best effort, no retransmission
- Companion
- RTCP, SDP
- Standard
- RFC 3550
Uncompressed video
The same header, now carrying raw pixels the way broadcast studios send them.
Whole frame
Same 12-byte RTP header, then a tiny video header that says which line and where on the line the pixels go. Studios use this format to carry broadcast video over plain Ethernet.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| Version | Byte 0, bits 7–6 | 2 | Always 2 for the current RTP. |
| Padding | Byte 0, bit 5 | 0 | 1 if the packet ends with padding bytes (needed by some ciphers). 0 here. |
| Extension | Byte 0, bit 4 | 0 | 1 if a header extension follows the fixed header. |
| CSRC count | Byte 0, bits 3–0 | 0 | How many contributing-source IDs follow the header. Non-zero only when a mixer combines several sources. |
| Marker | Byte 1, bit 7 | 0 | Meaning depends on the payload. For video it is set on the last packet of a frame, so the receiver knows it can decode now without waiting for the next timestamp. |
| Payload type | Byte 1, bits 6–0 | 96 (dynamic, H.264 per SDP) | Which codec/format is inside. 0–95 are fixed assignments (0 = PCMU audio), 96–127 are dynamic: a session description (SDP) says what 96 means, here H.264. |
| Sequence number | Byte 2–3 | 7001 | +1 for every packet sent. The receiver uses it to spot loss (a gap) and to put packets back in order. It starts at a random value. |
| Timestamp | Byte 4–7 | 1234800 (13.720 s on the 90 kHz clock) | The sampling instant of the media, in clock ticks (90,000 per second for video). All packets of one frame share the same timestamp; 25 fps adds 3,600 per frame. It is media time, not wall-clock time: it drives playback timing and lip-sync. |
| SSRC | Byte 8–11 | 0x4C1F3A92 | Synchronization source: a random ID of this stream. Audio and video from the same sender have different SSRCs; the receiver separates streams by it. |
| Extended sequence number | Byte 12–13 | 0 (low 16 bits are in the RTP header) | The high 16 bits of the sequence number. Uncompressed video sends so many packets per second that the normal 16-bit counter wraps in under a second; this extends it to 32 bits. |
| SRD length | Byte 14–15 | 8 bytes | A packet carries one or more Sample Row Data segments, each with its own 6-byte header. This one's pixel data is 8 bytes. |
| F (field) | Byte 16, bit 7 | 0 | Interlaced video: 0 = first field, 1 = second field. Progressive video always uses 0. |
| Line number | Bytes 16–17 | 100 | Which row of the picture this data belongs to, counted from 0 at the top. |
| C (continuation) | Byte 18, bit 7 | 0 | 1 if another SRD header follows this one in the same packet. 0 = last. |
| Pixel offset | Bytes 18–19 | 0 (start of the line) | The horizontal position, in pixels, where this data starts within the line. |
| Pixels (YCbCr 4:2:2, 8-bit) | Byte 20–27 | 4 white pixels | Raw pixels, four bytes per two pixels in the order Cb, Y0, Cr, Y1. 0x80 is neutral chroma and 0xEB (235) is video white, so these 4 pixels are white. A 1080-pixel-wide line is 3,840 bytes: the picture is not compressed at all. |
Packets, a lost one, and a report
How sequence numbers and timestamps expose loss and frame boundaries.
Whole exchange
RTP numbers and timestamps media packets but does not guarantee delivery. Loss is detected, not repaired: repair is left to the application, or to protocols like SRT.
1First packet of frame 1
A large frame is cut into packets that fit the network MTU. All of them carry the same timestamp (3,600) and consecutive sequence numbers.
2Last packet: marker set
M=1 says this completes frame 1. The decoder can decode and show it without waiting for a packet with a newer timestamp.
3Frame 2 begins
The timestamp jumps by 3,600 ticks = 40 ms at 90 kHz: 25 frames per second.
4A packet is lost
UDP does not retransmit. The packet with seq=103 never arrives.
5The gap shows
Sequence 104 follows 102: the receiver knows exactly one packet is missing, so frame 2 is damaged. It can conceal the error, show the previous frame, or ask for a new key frame.
6RTCP receiver report
Alongside the media, RTCP carries statistics (here 1 packet in 5 lost, plus jitter). The sender can adapt: lower the bitrate, add error correction, or send a key frame.
Where you meet it
- WebRTC video calls and conferencing
- IP cameras and surveillance (usually set up by RTSP)
- Broadcast and pro-AV over IP: SMPTE ST 2110, AES67, Dante-style audio
Watch out for
- The timestamp unit depends on the payload: 90,000 per second for video, the sample rate for audio. Never compare them directly.
- Packets bigger than the path MTU get fragmented by IP and lose together; keep them around 1,200–1,400 bytes.
- Firewalls and NAT often block RTP because its ports are negotiated per session: that is what STUN/TURN/ICE solve.
Standards
- RFC 3550: RTP
- RFC 6184: RTP Payload Format for H.264
- RFC 4175: RTP Payload Format for Uncompressed Video