RTP Payload Format for DV (IEC 61834) Video
obsoletes
- rfc-3189 — RTP Payload Format for DV (IEC 61834) Video
Extracted elements (25)
DIF blocks from different video frames MUST NOT be mixed in one RTP packet because the transition between frames is indicated solely by an RTP timestamp change; mixing frames would also increase receiver processing complexity.
In the 720-line DV system, data for two video frames is processed within one 1080-line DV frame duration, so the timestamp increment for 720-line modes corresponds to two video frames rather than one, preserving alignment with the DIF block structure.
No SDP parameters are defined for DV 'source' and 'source control' attributes (video signal type, frame rate, aspect ratio, audio parameters) because describing all combinations would require excessively large signaling descriptions. Instead, this information is carried in-band via VAUX and AAUX DIF blocks.
SMPTE 306M format is covered by SMPTE 314M and SHOULD NOT be used; SMPTE 314M SHOULD be used instead. An RTP application may handle a 306M-identified stream as 314M encoding. Offers MAY include 306M for legacy system compatibility, and receivers SHOULD support this value.
The SDP examples in the obsoleted RFC 3189 provided incorrect 'a=fmtp' attribute usage; implementations should follow the corrected SDP mapping defined in RFC 6469.
All DIF blocks in one RTP packet MUST be from the same video frame. DIF blocks from the next video frame MUST NOT be packed into the same RTP packet even if more payload space remains.
All RTP packets within the same video frame MUST have the same RTP timestamp. The timestamp SHOULD increment by the nominal interval for one DV frame time (e.g., 3003 for 525-60 mode, 3600 for 625-50 mode) using a 90 kHz clock.
Any unknown parameter in an SDP offer MUST be ignored by the receiver and MUST NOT be included in the answer.
If multiple DV encoding formats are used within one RTP session, multiple dynamic payload types MUST be assigned, one for each DV encoding format, and the sender MUST change to the corresponding payload type whenever the encoding format changes.
If the SDP fmtp 'audio' parameter is not present, then audio data MUST NOT be bundled into the DV video stream.
The choice of bundled or unbundled audio/video transmission MUST be indicated as part of the dynamic payload type assignment and MUST remain unchanged for the duration of the RTP session to avoid complicated sequence number synchronization procedures.
The marker bit (M) MUST be set to one on the last packet of a video frame and MUST be zero on all other packets. However, detection of a frame change MUST NOT rely on the marker bit; it MUST be based on a difference in the RTP timestamp.
The RTP clock rate in 'a=rtpmap' MUST be 90000 (90 kHz) for the DV payload format.
The RTP sender MUST transmit at least those VAUX DIF blocks and/or audio DIF blocks with AAUX information bytes that include 'source' and 'source control' packs containing indispensable information for decoding (video signal type, frame rate, aspect ratio, etc.).
When the sender discards video frames to reduce frame rate, the RTP timestamp MUST still be incremented to account for the discarded frames.
When unbundled audio and video streams are sent, any DIF sequence header and subcode DIF blocks MUST be included and sent in the video stream.
When using unbundled mode, it is RECOMMENDED that audio stream data be extracted from DIF blocks and repackaged into the corresponding RTP payload format (DAT12, L16, L20) to maximize interoperability with non-DV-capable receivers.
A DIF block is the primitive 80-byte unit of DV streams, containing a 3-byte ID header specifying its type and position. Five types exist: DIF sequence header, Subcode, VAUX (Video Auxiliary), Audio, and Video.
Audio DIF blocks contain 5 bytes of AAUX (Audio Auxiliary) data and 72 bytes of audio data encoded as PCM at 32 kHz, 44.1 kHz, or 48 kHz with 12-bit non-linear, 16-bit linear, or 20-bit linear quantization for up to 8 channels.
The DV payload consists of integral 80-byte DIF blocks placed immediately after the RTP header with no additional payload-format-specific header. The payload length is always a multiple of 80 bytes.
The media type 'video/DV' requires the 'encode' parameter specifying the DV format (e.g., SD-VCR/525-60, 314M-50/625-50, 370M/1080-60i) and supports an optional 'audio' parameter with values 'bundled' or 'none' (default).
This document updates the IANA media type registrations for 'video/DV' and 'audio/DV', replacing those from RFC 3189, using the RFC 4855 registration template. Permissible encode values include IEC 61834 consumer formats, SMPTE 314M, 370M, and 306M (backward compatibility only).
A receiver may be overloaded by receipt of too many packets in multicast environments. Network-layer authentication may be used to discard unwanted sources; IGMPv3, MLDv2, LW-IGMPv3/LW-MLDv2, and multicast routing protocols can be used to select allowed sources.
Confidentiality of DV RTP streams is achieved by encryption, which can be applied after compression without conflict since compression is end-to-end. DV encoding does not exhibit significant non-uniform computational load, so pathological datagram injection for denial-of-service is not a significant concern.
The 90 kHz RTP timestamp increments per DV frame: 3003 for 525-60 and 1080-60i modes (29.97 Hz), 3600 for 625-50, 1250-50, and 1080-50i modes (25 Hz), 3000 for 1125-60 (30 Hz). For 720-line systems, the timestamp increment covers two video frames.