Real-time Transport Protocol
lastmod 2023-01-25created 2015-08-1931 edits
The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is widely used in communication and entertainment systems, including streaming media.
RTP was developed by the Audio/Video Transport Working Group of the Internet Engineering Task Force (IETF) and was first published in 1996 as RTC 1889, and in 2003 RFC 3550 took its place.
Packet header
| Bit offset | 0-1 | 2 | 3 | 4-7 | 8 | 9-15 | 16-31 | |||||||||||||||||||||||
| 0 | Version | P | X | CC | M | PT | Sequence number | |||||||||||||||||||||||
| 32 | Timestamp | |||||||||||||||||||||||||||||
| 64 | SSRC identifier | |||||||||||||||||||||||||||||
| 96 | CSRC identifiers | |||||||||||||||||||||||||||||
| 96+32×CC | Profile-specific extension header ID | Extension header length | ||||||||||||||||||||||||||||
| 128+32×CC | Extension header | |||||||||||||||||||||||||||||
Parameters
SDP - H.264 sprop-parameter-sets
sprop-parameter-sets contains information about sequence and picture parameters set for the incoming NAL stream. The value are Base64 encoded. A comma is used to separate any pair of parameter set in the list. For example, sprop-parameter-sets=Z2ASEW12 , AsaR3QD
In general, sprop-parameter-sets are the SPS and PPS of NAL unit needed to initialize the decoder. If you want to parse the sprop-parameter-sets, they are separated by a comma. The left hand side of the comma is SPS and the right hand side of the comma is PPS.
H264 frame type
- Stackoverflow - How to detect I/P/B frame from H264 RTP packet
- [Recommended] Stackoverflow - Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream
- [Recommended] Stackoverflow - Detect MPEG4/H264 I-Frame (IDR) in RTP stream
How is the RTP payload length calculated?
As described in RFC 3550 Section 11, there are situations where RTP requires an external framing mechanism, but this is not needed for the typical use of RTP over UDP. In general, the UDP length field of the packet can be used to determine the end of the payload data, and the payload data begins immediately after the fixed-size RTP header.
A few things can affect this, as follows.
- If the "padding" bit is set in the RTP header, some padding bytes that are not RTP payload data may be present at the end of the UDP packet. In this case, the last octet of the UDP packet data contains the number of padding octets (including itself). This moves the end of the payload data back by the specified amount of padding. Padding like this is typically used when encrypting RTP payload data with an algorithm that uses a fixed block size. See section 5.1 of RFC 3550 for more details on this.
- If the "extension" bit is set in the RTP header, a header extension follows the fixed RTP header, as described in section 5.3.1 of RFC 3550. The header extension has a length field indicating the number of additional bytes. Skipped to the start of the RTP payload data. Header extensions should be rare.
- Using a combination of the UDP packet length, the padding length (if any), and the extension header length (if any), it should be possible to determine the location and length of the RTP payload data without an external framing mechanism. This is because no profile or payload format combines multiple RTP packets into a single UDP packet.
Examples
- Github - ireader/media-server/librtp/source/rtp.c
- https://github.com/ireader/media-server/blob/master/librtp/source/rtp.c
- Windows C++ RTP Streaming from Cam using FFMPEG and OpenCV
- https://lazymankook.tistory.com/9
Libraries
- JRTPLIB
- oRTP
- Github - RTSP parser written in C
- PJSIP
- Github - cisco - Library for SRTP (Secure Realtime Transport Protocol)
Client player
- Github - yellowstone - The RTP/RTSP client for node.js
- Github - html5_rtsp_player - html5 player for rtsp stream
- Broadway.js
Local Download
- RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
- https://tools.ietf.org/html/rfc3550
-
Rfc3550.txt - Rfc3550-ko.txt.zip (Google translate: en -> ko)
- RFC 4103 - RTP Payload for Text Conversation
- https://tools.ietf.org/html/rfc4103
- RFC 3984 - RTP Payload Format for H.264 Video
- https://tools.ietf.org/html/rfc3984
- Rfc3984-ko.txt.zip (Google translate: en -> ko)
- RFC 6184 - RTP Payload Format for H.264 Video
- https://tools.ietf.org/html/rfc6184
See also
- RTCP
- RTSP
- SDP
- SRTP: RFC 3711 - The Secure Real-time Transport Protocol (SRTP)
- FFmpeg
- gStreamer
- live555
- JRTPLIB
- WebRTC
- GStreamer:RTP_RTSP
- rtpklvdepay - Extracts KLV (SMPTE ST 336) metadata from RTP packets
- rtpklvpay - Payloads KLV (SMPTE ST 336) metadata as RTP packets
Favorite site
- Wikipedia (en) description of RTP
- bcknightt - RTP(Real Time Protocol)
- ICT Terms Explained - RTP header format, RTP packet
- Network RTP packet header
- KLDP: Please recommend a usable open-source RTP/RTSP library
- RTSP/RTP streaming media server
- Slideshare - Streaming protocols
- RTP protocol 2
- Saram Saneun Sesang: RTP(Real Time Protocol)
- [Recommended] NExpert :: Understanding RTP
- Understanding RTP (packet analysis)
- Mint & Latte_. :: RTP (Real-time Transport Protocol)
- Linux Streaming Server Project(LSSP) final report
- [Recommended] RTP header format (ICT Terms Explained)
References
-
Rtp-parameters.txt.zip ↩