RTP Payload Format for DV (IEC 61834) Video
obsoleted by
- rfc-6469 — RTP Payload Format for DV (IEC 61834) Video
Extracted elements (25)
DV uses intra-frame DCT compression only, not interframe compression as in MPEG. All video data including audio and system data are managed within the picture-frame unit, which is why the RTP packetization keeps all DIF blocks within a single frame per packet.
No SDP parameters are defined for DV 'source' and 'source control' pack attributes (aspect ratio, audio channels, etc.) because describing all combinations would require very large SDP descriptions. Instead, these attributes are carried in-band in VAUX/AAUX DIF blocks.
The sender is permitted to reduce bandwidth by discarding video data DIF blocks for unchanged image regions. This design choice shifts the burden of handling missing blocks to receiver-side error concealment rather than requiring retransmission.
When reducing frame rate, the RTP timestamp must still be incremented to account for discarded frames. This preserves the timing relationship required for synchronization even when video content is omitted.
In unbundled mode, it is RECOMMENDED that audio be extracted from DIF blocks and repackaged into the corresponding RTP payload format for the audio encoding (DAT12, L16, or L20) to maximize interoperability with non-DV-capable receivers.
When sending unbundled DV audio and video, the same RTP timestamp SHOULD be used for both streams within the same frame to simplify lip synchronization. Lip sync may also be achieved via RTCP reference timestamps per RFC 1889.
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 payload space remains, because frame transitions are signaled by a timestamp change.
All RTP packets within the same video frame MUST carry the same timestamp. The timestamp SHOULD increment by the nominal interval for one frame time as given in the format-specific table.
If multiple DV encoding formats are used within one RTP session, multiple dynamic payload types MUST be assigned, one per encoding format. The sender MUST change to the corresponding payload type whenever the encoding format changes.
If the SDP fmtp audio parameter is not present, audio data MUST NOT be bundled into the DV video stream.
Receivers SHOULD implement an error concealment strategy to accommodate lost or missing DIF blocks, for example by repeating the corresponding DIF block from the previous image, enabling the sender's optional bandwidth reduction by discarding unchanged blocks.
The choice to transmit audio and video as one bundled or as separate (unbundled) RTP streams MUST be indicated as part of the dynamic payload type assignment and MUST remain unchanged for the duration of the RTP session to avoid sequence number synchronization complications.
The RTP marker bit is set to one on the last packet of a video frame and zero otherwise. However, detection of a frame change MUST NOT rely on the marker bit (which may be lost); detection MUST be based on a difference in the RTP timestamp.
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, which carry indispensable decoding information such as aspect ratio, audio quantization, and channel assignment.
The sender MAY omit DIF-sequence header and subcode DIF blocks from a stream. However, when they are sent, both types of blocks MUST be included in the video stream together.
When using SDP for negotiation of RTP payload information, the format described in this document SHOULD be used, with separate m= lines for video and audio in unbundled mode.
A DV frame is divided into DIF sequences composed of 80-byte DIF blocks. Each DIF block carries a 3-byte ID header specifying its type and position. Five DIF block types are defined: DIF sequence header, Subcode, VAUX, Audio, and Video.
DV audio is encoded as PCM at sampling frequencies of 32 kHz, 44.1 kHz, or 48 kHz with 12-bit non-linear, 16-bit linear, or 20-bit linear quantization, supporting up to 8 channels. Allowed combinations depend on the video format.
SDP signaling uses encoding name 'DV' with a 90000 Hz clock rate (a=rtpmap). The required a=fmtp 'encode' parameter specifies the DV variant, accepting 12 values such as SD-VCR/525-60, HD-VCR/1125-60, 306M/625-50, and 314M-50/525-60.
The optional SDP a=fmtp 'audio' parameter indicates whether audio data is bundled into the DV video stream. Permissible values are 'bundled' and 'none', with 'none' as the default.
This document registers two MIME types: video/DV and audio/DV, both requiring an 'encode' parameter specifying the DV format variant and both referencing IEC 61834, SMPTE 306M, SMPTE 314M, and RFC 3189 as published specifications.
A potential denial-of-service threat exists from flooding a receiver with too many packets. Network-layer authentication may discard packets from undesired sources, though the authentication processing cost itself may be prohibitive. DV encoding does not exhibit significant non-uniform decoder load, mitigating the computational DoS vector.
Confidentiality of DV media streams is achieved by encryption per the RTP security model. Since DV compression is applied end-to-end, encryption may be performed after compression with no conflict between the two operations.
The RTP payload begins immediately after the RTP header with no additional payload-format-specific header. The payload contains an integral number of 80-byte DIF blocks, making the payload length always a multiple of 80 bytes.
The RTP timestamp is a 32-bit 90 kHz value representing the sampling time of the first data in the frame. Nominal increments per frame are: 3003 (525-60 at 29.97 Hz), 3600 (625-50 at 25 Hz), 3000 (1125-60 at 30 Hz), and 3600 (1250-50 at 25 Hz).