Associating Time-Codes with RTP Streams
Extracted elements (23)
Both compact (24-bit binary) and full (64-bit SMPTE 12M) time-code forms are provided. Compact saves bandwidth for use cases such as compressed audio; full is necessary when the date component must be conveyed or when the RTP transport serves as a transparent pipe.
The initial mapping is not placed in SDP because SDP would need knowledge of the RTP random offset, which is undesirable. Embedding the mapping in all RTCP sender reports is considered sufficient; without time-codes, audio-video sync would also be unavailable.
Time-codes are carried inline within an existing RTP stream rather than as a separate RTP stream because the data rate is so low that a dedicated stream would be wasteful. Inline packing also preserves backwards compatibility with gateways already handling dual-stream sessions.
Two transmission modes are provided: RTCP for piecewise-continuous time-codes (very low bandwidth overhead, possibly zero for streams with no discontinuities) and RTP header extensions for streams where continuity is uncertain or absolute per-packet mapping is required.
If the payload type changes during a stream, especially between payloads with different clock rates, it is strongly recommended that the header extension be included on the first packet(s) of the new payload to explicitly set the time-code mapping for the new clock rate.
The compact 6-bit frames field can represent values 0–63, exceeding the SMPTE 12M BCD maximum of 29 (limited by a 2-bit tens digit). Implementations must not assume the compact and full forms carry equivalent frame-count ranges.
There is no mechanism defined in this document to detect that an RTCP mapping packet has been lost or that a mapping is being applied outside its intended range. Clients hold mappings until superseded and may need to buffer upcoming mappings.
If the recipient must ever calculate time-codes based on RTP times, setup information MUST be sent out-of-band, for example in a SIP offer/answer exchange.
In the case that a presentation contains more than one stream, senders MUST continue to send the standard RTP synchronization information in RTCP, even if the streams carry SMPTE time-codes that could be used for synchronization.
Receivers MUST support time-codes in both RTCP and RTP as well as both forms (compact and full) of the time-code.
The three signaling parameters (frame_duration, frames_per_tc_second, is-NTSC-drop-frame) MUST correspond with each other.
The value of the 'drop frame flag' in the full SMPTE 12M time-code MUST agree with the use of the 'drop' indicator in the SDP signaling.
Out-of-band SDP signaling uses the extension URI 'urn:ietf:params:rtp-hdrext:smpte-tc' and three ABNF-defined extension attributes: frame-duration (ticks per frame at a given clock rate), frames-per-tc-second, and optional '/drop' for NTSC drop-frame counting.
RTCP associations (packet type 194, SMPTETC) carry an RTP timestamp and an SMPTE time-code establishing the start of a calculable run. The mapping applies to all RTP times from the given timestamp onward until superseded by a later RTCP packet.
RTP header extensions (per RFC 5285) carry inline time-code associations when continuity is not guaranteed. The short form (3 bytes) maps a compact time-code to the packet's own RTP timestamp; the long form (12 bytes) carries a full SMPTE 12M time-code plus a signed 32-bit offset D, establishing an association for timestamp T+D.
The design models time-code delivery as segments in which the time-code counts up continuously. Given the RTP timestamp and SMPTE time-code at a segment start plus the frame counting parameters, the time-code at any subsequent RTP timestamp can be calculated without per-packet signaling.
IANA registered extension URI 'urn:ietf:params:rtp-hdrext:smpte-tc' with description 'SMPTE time-code mapping' in the RTP Compact Header Extensions sub-registry of the RTP Parameters registry.
IANA registered RTCP Control Packet type 194 with abbreviation 'SMPTETC' and name 'SMPTE time-code mapping' in the Real-Time Transport Protocol (RTP) Parameters registry.
SMPTE time-codes are only informative and there are no known security considerations from associating them with media streams.
Compact time-code: 24 bits total — sign (1 bit), hours (5 bits, 0–23), minutes (6 bits, 0–59), seconds (6 bits, 0–59), frames (6 bits, 0 to frames-per-tc-second minus 1). Uses binary fixed-width fields, not BCD.
Full time-code: 64 bits formatted exactly per SMPTE 12M sections 7 and 8, without the 16-bit syncword. Bit positions carry units/tens of frames (0–9, 8–9), seconds (16–26), minutes (32–42), hours (48–57), eight binary groups, drop frame flag (bit 10), color frame flag (bit 11), polarity correction (bit 27), and BGF flags (bits 43, 58, 59).
RTCP short-form packet (PT=194, length=3): four 32-bit words — common header, SSRC of packet sender, RTP timestamp, and compact time-code fields (S/hours/minutes/seconds/frames) with 8 reserved bits. Long form (length=4): five 32-bit words with the compact time-code word replaced by two words carrying the full 8-byte SMPTE 12M time-code.
RTP header extension long form: 12 bytes (96 bits) — a full 64-bit SMPTE 12M time-code followed by a signed 32-bit offset D from the packet's RTP timestamp T, establishing an association for RTP time T+D.