Protocol: RTP Video ( Real-time Transport Protocol Video )

RTP Video ( Real-time Transport Protocol Video )

Update: 2007-02-26 11:44:38 I have words to say about this protocol

On this page

SUMMARY
DESCRIPTION
EXAMPLES
PROTOCOL RELATIONS
GLOSSARY
REFERENCES
OTHER PROTOCOLS

SUMMARY
Protocol	:	Real-time Transport Protocol Video
Layer	:	Application Layer
SNMP MIBs	:	iso.org.dod.internet.mgmt.mib-2.rtpMIB (1.3.6.1.2.1.10.87). iso.org.dod.internet.mgmt.mib-2.rohcRtpMIB (1.3.6.1.2.1.114)
Ports	:	5004 (UDP).
Related protocols	:	RTP, UDP, TCP, RTSP, RTCP
Working groups	:	AVT, Audio/Video Transport.

DESCRIPTION

All of these video encodings use an RTP timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended rate for future video encodings used within this profile, other rates may be used. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet. The timestamp resolution must also be sufficient for the jitter estimate contained in the receiver reports.

For most of these video encodings, the RTP timestamp encodes the sampling instant of the video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp is the same on all of those packets. Packets from different video images are distinguished by their different timestamps.

Most of these video encodings also specify that the marker bit of the RTP header should be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed.

CelB
The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The Cell image compression algorithm is a variable bit-rate video coding scheme. It provides "high" quality, low bit-rate image compression at low computational cost. The bytestream that is produced by the Cell encoder consists of instructional codes and information about the compressed image.

Currently, there are two versions of the Cell compression technology: CellA and CellB. CellA is primarily designed for the encoding of stored video intended for local display, and will not be discussed in this memo.

CellB, derived from CellA, has been optimized for network-based video applications. It is computationally symmetric in both encode and decode. CellB utilizes a fixed colormap and vector quantization techniques in the YUV color space to achieve compression.

JPEG
The encoding is specified in ISO Standards 10918-1 and 10918-2. The Joint Photographic Experts Group (JPEG) standard defines a family of compression algorithms for continuous-tone, still images. This still image compression standard can be applied to video by compressing each frame of video as an independent still image and transmitting them in series. Video coded in this fashion is often called Motion-JPEG.

The JPEG standard defines four modes of operation: the sequential DCT mode, the progressive DCT mode, the lossless mode, and the hierarchical mode. Depending on the mode, the image is represented in one or more passes. Each pass (called a frame in the JPEG standard) is further broken down into one or more scans. Within each scan, there are one to four components, which represent the three components of a color signal (e.g., "red, green, and blue", or a luminance signal and two chrominance signals). These components can be encoded as separate scans or interleaved into a single scan.

Each frame and scan is preceded with a header containing optional definitions for compression parameters like quantization tables and Huffman coding tables. The headers and optional parameters are identified with "markers" and comprise a marker segment; each scan appears as an entropy-coded bit stream within two marker segments. Markers are aligned to byte boundaries and (in general) cannot appear in the entropy-coded segment, allowing scan boundaries to be determined without parsing the bit stream.

Compressed data is represented in one of three formats: the interchange format, the abbreviated format, or the table-specification format. The interchange format contains definitions for all the tables used by the entropy-coded segments, while the abbreviated format might omit some assuming they were defined out-of-band or by a "previous" image.

The JPEG standard does not define the meaning or format of the components that comprise the image. Attributes like the color space and pixel aspect ratio must be specified out-of-band with respect to the JPEG bit stream. The JPEG File Interchange Format (JFIF) is a de-facto standard that provides this extra information using an application marker segment (APP0). Note that a JFIF file is simply a JPEG interchange format image along with the APP0 segment. In the case of video, additional parameters must be defined out-of-band (e.g., frame rate, interlaced vs. non-interlaced, etc.).

H261
The H.261 information is carried as payload data within the RTP protocol. The following fields of the RTP header are specified:

The payload type should specify H.261 payload format (see the companion RTP profile document RFC 1890).

The RTP timestamp encodes the sampling instant of the first video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp will be the same on all of those packets. Packets from different video images must have different timestamps so that frames may be distinguished by the timestamp. For H.261 video streams, the RTP timestamp is based on a 90kHz clock. This clock rate is a multiple of the natural H.261 frame rate (i.e. 30000/1001 or approx. 29.97 Hz). That way, for each frame time, the clock is just incremented by the multiple and this removes inaccuracy in calculating the timestamp. Furthermore, the initial value of the timestamp is random (unpredictable) to make known-plaintext attacks on encryption more difficult, see RTP [1]. Note that if multiple frames are encoded in a packet (e.g. when there are very little changes between two images), it is necessary to calculate display times for the frames after the first using the timing information in the H.261 frame header. This is required because the RTP timestamp only gives the display time of the first frame in the packet.

The marker bit of the RTP header is set to one in the last packet of a video frame, and otherwise, must be zero. Thus, it is not necessary to wait for a following packet (which contains the start code that terminates the current frame) to detect that a new frame should be displayed.

H263
The encoding is specified in the 1996 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2190.

H.263 is based on the ITU-T Recommendation H.261 (referred to as H.261 in this document). Compared to H.261, H.263 employs similar techniques to reduce both temporal and spatial redundancy, but there are several major differences between the two algorithms that affect the design of packetization schemes significantly. This section summarizes those differences.

H263-1998
The encoding is specified in the 1998 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2429. Because the 1998 version of H.263 is a superset of the 1996 syntax, this payload format can also be used with the 1996 version of H.263, and is recommended for this use by new implementations. This payload format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 MUST use the payload format described in RFC 2429.

MPV
MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in RFC 2250, Section 3.

The MIME registration for MPV in RFC 3555 specifies a parameter that MAY be used with MIME or SDP to restrict the selection of the type of MPEG video.

MP2T
MP2T designates the use of MPEG-2 transport streams, for either audio or video. The RTP payload format is described in RFC 2250.

Top of Page

EXAMPLES

Top of Page

PROTOCOL RELATIONS

■ Parent layer
■ Child layer

Top of Page

GLOSSARY

CSRC
CSRC (Contributing source) is a source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. An example application is audio conferencing where a mixer indicates all the talkers whose speech was combined to produce the outgoing packet, allowing the receiver to indicate the current talker, even though all the audio packets contain the same SSRC identifier.

H.323
H.323 is an umbrella recommendation from the ITU-T, that defines the protocols to provide audio-visual communication sessions on any packet network. It is currently implemented by various Internet real-time applications such as NetMeeting and GnomeMeeting. It is a part of the H.32x series of protocols which also address communications over ISDN, PSTN or SS7. H.323 is commonly used in Voice over IP (VoIP) and IP-based videoconferencing.

Mixer
Mixer is an intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source.

Monitor
Monitor is an application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current quality of service for distribution monitoring, fault diagnosis and long-term statistics. The monitor function is likely to be built into the application(s) participating in the session, but may also be a separate application that does not otherwise participate and does not send or receive the RTP data packets. These are called third party monitors.

Non-RTP means
Non-RTP means are protocols and mechanisms that may be needed in addition to RTP to provide a usable service. In particular, for multimedia conferences, a control protocol may distribute multicast addresses and keys for encryption, negotiate the encryption algorithm to be used, and define dynamic mappings between RTP payload type values and the payload formats they represent for formats that do not have a predefined payload type value.

RTCP
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets.

RTCP packet
RTCP packet is a control packet consisting of a fixed header part similar to that of RTP data packets, followed by structured elements that vary depending upon the RTCP packet type. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet.

RTP
RTP (Real-Time Transport Protocol) is an Internet protocol for transmitting real-time data such as audio and video. RTP itself does not guarantee real-time delivery of data, but it does provide mechanisms for the sending and receiving applications to support streaming data. Typically, RTP runs on top of the UDP protocol, although the specification is general enough to support other transport protocols.

RTP packet
RTP packet is a data packet consisting of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined.

SIP
Session Initiated Protocol (SIP) is an application-layer control protocol; a signaling protocol for Internet Telephony. SIP can establish sessions for features such as audio/videoconferencing, interactive gaming, and call forwarding to be deployed over IP networks, thus enabling service providers to integrate basic IP telephony services with Web, e-mail, and chat services.

SSRC
Synchronization source (SSRC) is the source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback.

Translator
Translator is an intermediate system that forwards RTP packets with their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application- level filters in firewalls.

Transport address
The Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol).

UDP
UDP (User Datagram Protocol) is a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network. It's used primarily for broadcasting messages over a network.

Unicast
Unicast is a communication that takes place over a network between a single sender and a single receiver.

Top of Page

REFERENCES

RFCs:
[RFC 2029] RTP Payload Format of Sun's CellB Video Encoding.

[RFC 2032] RTP Payload Format for H.261 Video Streams.

[RFC 2190] RTP Payload Format for H.263 Video Streams.

[RFC 2198] RTP Payload for Redundant Audio Data.

[RFC 2250] RTP Payload Format for MPEG1/MPEG2 Video.
                Obsoletes: RFC 2038.

[RFC 2343] RTP Payload Format for Bundled MPEG.

[RFC 2429] RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+).

[RFC 2431] RTP Payload Format for BT.656 Video Encoding.

[RFC 2435] RTP Payload Format for JPEG-compressed Video.
                Obsoletes: RFC 2035.

[RFC 2508] Compressing IP/UDP/RTP Headers for Low-Speed Serial Links.

[RFC 2658] RTP Payload Format for PureVoice(tm) Audio.

[RFC 2733] An RTP Payload Format for Generic Forward Error Correction.

[RFC 2736] Guidelines for Writers of RTP Payload Format Specifications.

[RFC 2762] Sampling of the Group Membership in RTP.

[RFC 2833] RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.

[RFC 2862] RTP Payload Format for Real-Time Pointers.

[RFC 2959] Real-Time Transport Protocol Management Information Base.
                Defines SNMP MIB iso.org.dod.internet.mgmt.mib-2.rtpMIB (1.3.6.1.2.1.10.87).

[RFC 3009] Registration of parityfec MIME types.

[RFC 3016] RTP Payload Format for MPEG-4 Audio/Visual Streams.

[RFC 3047] RTP Payload Format for ITU-T Recommendation G.722.1.

[RFC 3095] RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed.

[RFC 3119] A More Loss-Tolerant RTP Payload Format for MP3 Audio.

[RFC 3158] RTP Testing Strategies.

[RFC 3189] RTP Payload Format for DV (IEC 61834) Video.

[RFC 3190] RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio.

[RFC 3267] Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs.

[RFC 3389] Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN).
                Defines MIME media subtype audio/CN.
                Defines RTP payload type CN.

[RFC 3497] RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video.
                Defines MIME media subtype video/SMPTE292M.

[RFC 3558] RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV).
                Defines MIME media subtypes audio/EVRC, audio/EVRC0, audio/SMV and audio/SMV0.

[RFC 3545] Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering.

[RFC 3550] RTP: A Transport Protocol for Real-Time Applications.
                Obsoletes: RFC 1889.

[RFC 3551] RTP Profile for Audio and Video Conferences with Minimal Control.
                Obsoletes: RFC 1890.

[RFC 3555] MIME Type Registration of RTP Payload Formats.
                Updated by: RFC 3625.

[RFC 3557] RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding.
                Defines MIME media subtype audio/dsr-es201108.

[RFC 3640] RTP Payload Format for Transport of MPEG-4 Elementary Streams.

[RFC 3711] The Secure Real-time Transport Protocol (SRTP).
                Defines RTP profile RTP/SAVP.

[RFC 3816] Definitions of Managed Objects for RObust Header Compression (ROHC).
                iso.org.dod.internet.mgmt.mib-2.rohcMIB (1.3.6.1.2.1.112)
                iso.org.dod.internet.mgmt.mib-2.rohcUncmprMIB (1.3.6.1.2.1.113)
                iso.org.dod.internet.mgmt.mib-2.rohcRtpMIB (1.3.6.1.2.1.114)

[RFC 3952] Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech.
                Defines MIME media subtype audio/iLBC.

[RFC 3984] RTP Payload Format for H.264 Video.
                Defines MIME media subtype video/H264.

[RFC 4040] RTP Payload Format for a 64 kbit/s Transparent Call.
                Defines MIME media subtype audio/clearmode.

[RFC 4060] RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding.
                Defines MIME media subtypes audio/dsr-es202050, audio/dsr-es202211 and audio/dsr-es202212.

[RFC 4103] RTP Payload for Text Conversation.
                Defines MIME media subtype text/t140.
                Obsoletes: RFC 2793.

[RFC 4170] Tunneling Multiplexed Compressed RTP (TCRTP).
                BCP: 110.

[RFC 4175] RTP Payload Format for Uncompressed Video.
                Defines MIME media subtype video/raw.

[RFC 4184] RTP Payload Format for AC-3 Audio.

[RFC 4298] RTP Payload Format for BroadVoice Speech Codecs.
                Defines MIME media subtypes audio/BV16 and audio/BV32.

[RFC 4348] Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec.
                Category: Standards Track.
                Defines MIME media subtype audio/VMR-WB.

[RFC 4351] Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream.
                Category: Historic.
                Defines MIME media subtype audio/t140c.

[RFC 4352] RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec.
                Category: Standards Track.
                Defines MIME media subtype audio/amr-wb+.

Obsolete RFCs:
[RFC 1889] RTP: A Transport Protocol for Real-Time Applications.
                Obsoleted by: RFC 3550.

[RFC 1890] RTP Profile for Audio and Video Conferences with Minimal Control.
                Obsoleted by: RFC 3551.

[RFC 2035] RTP Payload Format for JPEG-compressed Video.
                Obsoleted by: RFC 2435.

[RFC 2038] RTP Payload Format for MPEG1/MPEG2 Video.
                Obsoleted by: RFC 2250.

[RFC 2793] RTP Payload for Text Conversation.
                Obsoleted by: RFC 4103.
                Defines MIME media subtype text/t140.

Top of Page

OTHER PROTOCOLS OF TCP/IP SUITE