From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6469.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc6469.txt (limited to 'doc/rfc/rfc6469.txt') diff --git a/doc/rfc/rfc6469.txt b/doc/rfc/rfc6469.txt new file mode 100644 index 0000000..493f74b --- /dev/null +++ b/doc/rfc/rfc6469.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Kobayashi +Request for Comments: 6469 AICS, RIKEN +Obsoletes: 3189 K. Mishima +Category: Standards Track Keio University +ISSN: 2070-1721 S. Casner + Packet Design + C. Bormann + Universitaet Bremen TZI + December 2011 + + + RTP Payload Format for DV (IEC 61834) Video + +Abstract + + This document specifies the packetization scheme for encapsulating + the compressed digital video data streams commonly known as "DV" into + a payload format for the Real-Time Transport Protocol (RTP). This + document obsoletes RFC 3189. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6469. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Kobayashi, et al. Standards Track [Page 1] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................4 + 2. RTP Payload Format ..............................................4 + 2.1. The DV Format Encoding .....................................4 + 2.2. RTP Header Usage ...........................................5 + 2.3. Payload Structures .........................................6 + 3. Payload Format Parameters .......................................7 + 3.1. Media Type Registration ....................................7 + 3.1.1. Media Type Registration for DV Video ................8 + 3.1.2. Media Type Registration for DV Audio ................9 + 3.2. SDP Parameters ............................................11 + 3.2.1. Mapping of Payload Type Parameters to SDP ..........11 + 3.2.2. Usage with the SDP Offer/Answer Model ..............12 + 3.3. Examples ..................................................12 + 3.3.1. Example for Unbundled Streams ......................13 + 3.3.2. Example for Bundled Streams ........................13 + 4. Security Considerations ........................................14 + 5. Congestion Control .............................................14 + 6. IANA Considerations ............................................14 + 7. Major Changes from RFC 3189 ....................................15 + 8. Interoperability with Previous Implementations .................15 + 9. Acknowledgment .................................................16 + 10. References ....................................................16 + 10.1. Normative References .....................................16 + 10.2. Informative References ...................................17 + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 2] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + +1. Introduction + + This document specifies payload formats for encapsulating both + consumer- and professional-use Digital Video (DV) format data streams + into the Real-Time Transport Protocol (RTP) [RFC3550]. DV + compression audio and video formats were designed for a recording + format on helical-scan magnetic tape media. The DV standards for + consumer-market devices, the IEC 61883 and 61834 series, cover many + aspects of consumer-use digital video, including mechanical + specifications of a cassette, magnetic recording format, error + correction on the magnetic tape, Discrete Cosine Transform (DCT) + video encoding format, and audio encoding format [IEC61834]. The + digital interface part of IEC 61883 defines an interface on the IEEE + 1394 system [IEC61883][IEEE1394]. This specification set supports + several video formats: SD-VCR (Standard Definition), HD-VCR (High + Definition), SDL-VCR (Standard Definition - Long), PALPlus, DVB + (Digital Video Broadcast), and ATV (Advanced Television). North + American formats are indicated with a number of lines and "/60", + while European formats use "/50". DV standards extended for + professional use were published by the Society of Motion Picture and + Television Engineers (SMPTE) as 314M and 370M, for different sampling + systems, higher color resolution, and higher bit rates + [SMPTE314M][SMPTE370M]. + + In summary, there are two kinds of DV, one for consumer use and the + other for professional. The original "DV" specification designed for + consumer-use digital VCRs is approved as the IEC 61834 standard set. + The specifications for professional DV are published as SMPTE 314M + and 370M. Both encoding formats are based on consumer DV and used in + SMPTE D-7, D-9, and D-12 video systems. The RTP payload format + specified in this document supports IEC 61834 consumer DV and + professional SMPTE 314M and 370M (DV-based) formats. + + IEC 61834 also includes magnetic tape recording for digital TV + broadcasting systems (such as DVB and ATV) that use MPEG2 encoding. + The payload format for encapsulating MPEG2 into RTP has already been + defined in RFC 2250 [RFC2250] and elsewhere. + + Consequently, the payload specified in this document will support six + video formats of the IEC standard: SD-VCR (525/60, 625/50), HD-VCR + (1125/60, 1250/50), and SDL-VCR (525/60, 625/50). It also supports + eight of the SMPTE standards: 314M 25 Mbit/s (525/60, 625/50), 314M + 50 Mbit/s (525/60, 625/50), and 370M 100 Mbit/s (1080/60i, 1080/50i, + 720/60p, and 720/50p). In the future, it can be extended into other + video formats managed by the 80-byte DV Digital Interface Format + (DIF) block. + + + + + +Kobayashi, et al. Standards Track [Page 3] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + Throughout this specification, we make extensive use of the + terminology of IEC and SMPTE standards. The reader should consult + the original references for definitions of these terms. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. RTP Payload Format + +2.1. The DV Format Encoding + + The DV format only uses the DCT compression technique within each + frame, contrasted with the interframe compression of the MPEG video + standards [ISO/IEC11172][ISO/IEC13818]. All video data, including + audio and other system data, is managed within the picture frame unit + of video. + + The DV video encoding is composed of a three-level hierarchical + structure, i.e., DCT super block, DCT macro block, and DCT block. A + picture frame is divided into rectangle- or clipped-rectangle-shaped + DCT super blocks. DCT super blocks are divided into 27 rectangle- or + square-shaped DCT macro blocks, and each DCT macro block consists of + a number of DCT blocks. Each DCT block consists of 8x8 pixels and + represents a rectangle region for each color, Y, Cb, and Cr. + + Audio data is encoded in Pulse Code Modulation (PCM) format. The + sampling frequency is 32 kHz, 44.1 kHz, or 48 kHz and the + quantization is 12-bit non-linear, 16-bit linear, or 20-bit linear. + The number of channels may be up to 8. Only certain combinations of + these parameters are allowed, depending upon the video format; the + restrictions are specified in each document [IEC61834][SMPTE314M] + [SMPTE370M]. + + A frame of data in the DV format stream is divided into several "DIF + sequences". A DIF sequence is composed of an integral number of + 80-byte DIF blocks. A DIF block is the primitive unit for all + treatment of DV streams. Each DIF block contains a 3-byte ID header + that specifies the type of the DIF block and its position in the DIF + sequence. Five types of DIF blocks are defined: DIF sequence header, + Subcode, Video Auxiliary (VAUX) information, Audio, and Video. Audio + DIF blocks are composed of 5 bytes of Audio Auxiliary (AAUX) data and + 72 bytes of audio data. + + + + + + +Kobayashi, et al. Standards Track [Page 4] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + Each RTP packet starts with the RTP header as defined in RFC 3550 + [RFC3550]. No additional payload-format-specific header is required + for this payload format. + +2.2. RTP Header Usage + + The RTP header fields that have a meaning specific to the DV format + are described as follows: + + Payload type (PT): The payload type is dynamically assigned by means + outside the scope of this document. If multiple DV encoding formats + are to be used within one RTP session, then multiple dynamic payload + types MUST be assigned, one for each DV encoding format. The sender + MUST change to the corresponding payload type whenever the encoding + format is changed. + + Timestamp: 32-bit 90 kHz timestamp representing the time at which the + first data in the frame was sampled. All RTP packets within the same + video frame MUST have the same timestamp. The timestamp SHOULD + increment by a multiple of the nominal interval for one DV frame + time, as given in the following table: + + +----------+----------------+---------------------------------------+ + | Mode | Frame rate | Increase of 90 kHz timestamp per DV | + | | (Hz) | frame | + +----------+----------------+---------------------------------------+ + | 525-60 | 29.97 | 3003 | + | 625-50 | 25 | 3600 | + | 1125-60 | 30 | 3000 | + | 1250-50 | 25 | 3600 | + | 1080-60i | 29.97 | 3003 | + | 1080-50i | 25 | 3600 | + | 720-60p | 59.94 | 3003(*) | + | 720-50p | 50 | 3600(*) | + +----------+----------------+---------------------------------------+ + + (*) Note that even in the 720-line DV system, the data in two video + frames shall be processed within one DV frame duration of the 1080- + line system. Audio data and subcode data in the 720-line system are + processed in the same way as the 1080-line system. Therefore, in the + 720-line system, the timestamp increase given in the third column + corresponds to two video frames time. + + Marker bit (M): The marker bit of the RTP fixed header is set to one + on the last packet of a video frame; on other packets, it MUST be + zero. The M bit allows the receiver to know that it has received the + last packet of a frame so it can display the image without waiting + for the first packet of the next frame to arrive to detect the frame + + + +Kobayashi, et al. Standards Track [Page 5] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + change. However, detection of a frame change MUST NOT rely on the + marker bit since the last packet of the frame might be lost. + Detection of a frame change MUST be based on a difference in the RTP + timestamp. + +2.3. Payload Structures + + Integral DIF blocks are placed into the RTP payload beginning + immediately after the RTP header. Any number of DIF blocks may be + packed into one RTP packet, but 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. This requirement stems from the fact that the + transition from one video frame to the next is indicated by a change + in the RTP timestamp. It also reduces the processing complexity on + the receiver. Since the RTP payload contains an integral number of + DIF blocks, the length of the RTP payload will be a multiple of 80 + bytes. + + Audio and video data may be transmitted as one bundled RTP stream or + in separate RTP streams (unbundled). The choice MUST be indicated as + part of the assignment of the dynamic payload type and MUST remain + unchanged for the duration of the RTP session to avoid complicated + procedures of sequence number synchronization. The RTP sender could + omit the DIF sequence header and subcode DIF blocks from a stream + when the information either is known from out-of-band sources or is + not required for the application. Note that time code in DIF blocks + is mandatory for professional video applications. 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. + + DV streams include "source" and "source control" packs that carry + information indispensable for proper decoding, such as video signal + type, frame rate, aspect ratio, picture position, quantization of + audio sampling, number of audio samples in a frame, number of audio + channels, audio channel assignment, and language of the audio. + However, describing all of these attributes with a signaling protocol + would require large descriptions to enumerate all the combinations. + Therefore, no Session Description Protocol (SDP) [RFC4566] parameters + for these attributes are defined in this document. Instead, the RTP + sender MUST transmit at least those VAUX (Video Auxiliary) DIF blocks + and/or audio DIF blocks with AAUX (Audio Auxiliary) information bytes + that include "source" and "source control" packs containing the + indispensable information for decoding. + + In the case of one bundled stream, DIF blocks for both audio and + video are packed into RTP packets in the same order as they were + encoded. + + + +Kobayashi, et al. Standards Track [Page 6] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + In the case of an unbundled stream, only the header, subcode, video, + and VAUX DIF blocks are sent within the video stream. Audio is sent + in a different stream if desired, using a different RTP payload type. + It is also possible to send audio duplicated in a separate stream, in + addition to bundling it in with the video stream. + + When using unbundled mode, it is RECOMMENDED that the audio stream + data be extracted from the DIF blocks and repackaged into the + corresponding RTP payload format for the audio encoding (DAT12, L16, + L20) [RFC3551][RFC3190] in order to maximize interoperability with + non-DV-capable receivers while maintaining the original source + quality. + + In the case of unbundled transmission that is compelled to use both + audio and video in the DV format, the same timestamp SHOULD be used + for both audio and video data within the same frame to simplify the + lip synchronization effort on the receiver. Lip synchronization may + also be achieved using reference timestamps passed in RTP Control + Protocol (RTCP) as described in [RFC3550]. In this case, the audio + stream uses the 90 kHz clock rate, and the timestamp uses the same + clock rate as the video. + + The sender MAY reduce the video frame rate by discarding the video + data and VAUX DIF blocks for some of the video frames. The RTP + timestamp MUST still be incremented to account for the discarded + frames. The sender MAY alternatively reduce bandwidth by discarding + video data DIF blocks for portions of the image that are unchanged + from the previous image. To enable this bandwidth reduction, + receivers SHOULD implement an error-concealment strategy to + accommodate lost or missing DIF blocks, e.g., repeating the + corresponding DIF block from the previous image. + +3. Payload Format Parameters + + This section specifies the parameters that MAY be used to select + optional features of the payload format and certain features of the + bitstream. The parameters are specified here as part of the media + type registration for the DV encoding. A mapping of the parameters + into the Session Description Protocol (SDP) [RFC4566] is also + provided for applications that use SDP. Equivalent parameters could + be defined elsewhere for use with control protocols that do not use + SDP. + +3.1. Media Type Registration + + This registration is done using the template defined in RFC 4288 + [RFC4288] and following RFC 4855 [RFC4855]. + + + + +Kobayashi, et al. Standards Track [Page 7] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + +3.1.1. Media Type Registration for DV Video + + Type name: video + + Subtype name: DV + + Required parameters: + + encode: type of DV format. Permissible values for encode are: + SD-VCR/525-60 + SD-VCR/625-50 + HD-VCR/1125-60 + HD-VCR/1250-50 + SDL-VCR/525-60 + SDL-VCR/625-50 + 314M-25/525-60 + 314M-25/625-50 + 314M-50/525-60 + 314M-50/625-50 + 370M/1080-60i + 370M/1080-50i + 370M/720-60p + 370M/720-50p + 306M/525-60 (for backward compatibility) + 306M/625-50 (for backward compatibility) + + Optional parameters: + + audio: whether the DV stream includes audio data or not. + Permissible values for audio are bundled and none. Defaults to + none. + + Encoding considerations: + + DV video can be transmitted with RTP as specified in RFC 6469 + (this document). Other transport methods are not specified. + + Security considerations: + + See Section 4 of RFC 6469 (this document). + + Interoperability considerations: Interoperability with previous + implementations is discussed in Section 8. + + + + + + + + +Kobayashi, et al. Standards Track [Page 8] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + Public specifications: + + IEC 61834 Standard + SMPTE 314M + SMPTE 370M + RFC 6469 (this document) + SMPTE 306M (for backward compatibility) + + Applications that use this media type: Audio and video streaming and + conferencing tools. + + Additional information: NONE + + Person & email address to contact for further information: + + Katsushi Kobayashi + ikob@riken.jp + + Intended usage: COMMON + + Restrictions on usage: This media type depends on RTP framing and + hence is only defined for transfer via RTP [RFC3550]. Transfer + within other framing protocols is not defined at this time. + + Author: + + Katsushi Kobayashi + + Change controller: + + IETF Audio/Video Transport working group delegated from the + IESG + +3.1.2. Media Type Registration for DV Audio + + Type name: audio + + Subtype name: DV + + Required parameters: + + encode: type of DV format. Permissible values for encode are: + SD-VCR/525-60 + SD-VCR/625-50 + HD-VCR/1125-60 + HD-VCR/1250-50 + SDL-VCR/525-60 + SDL-VCR/625-50 + + + +Kobayashi, et al. Standards Track [Page 9] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + 314M-25/525-60 + 314M-25/625-50 + 314M-50/525-60 + 314M-50/625-50 + 370M/1080-60i + 370M/1080-50i + 370M/720-60p + 370M/720-50p + 306M/525-60 (for backward compatibility) + 306M/625-50 (for backward compatibility) + + Optional parameters: + + audio: whether the DV stream includes audio data or not. + Permissible values for audio are bundled and none. Defaults to + none. + + Encoding considerations: + + DV audio can be transmitted with RTP as specified in RFC 6469 + (this document). Other transport methods are not specified. + + Security considerations: + + See Section 4 of RFC 6469 (this document). + + Interoperability considerations: Interoperability with previous + implementations is discussed in Section 8. + + Published specifications: + + IEC 61834 Standard + SMPTE 314M + SMPTE 370M + RFC 6469 (this document) + SMPTE 306M (for backward compatibility). + + Applications that use this media type: Audio and video streaming and + conferencing tools. + + Additional information: NONE + + Person & email address to contact for further information: + + Katsushi Kobayashi + ikob@riken.jp + + Intended usage: COMMON + + + +Kobayashi, et al. Standards Track [Page 10] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + Restrictions on usage: This media type depends on RTP framing and + hence is only defined for transfer via RTP [RFC3550]. Transfer + within other framing protocols is not defined at this time. + + Author: + + Katsushi Kobayashi + + Change controller: + + IETF Audio/Video Transport working group delegated from the + IESG + +3.2. SDP Parameters + +3.2.1. Mapping of Payload Type Parameters to SDP + + The information carried in the media type specification has a + specific mapping to fields in the Session Description Protocol (SDP), + which is commonly used to describe RTP sessions. When SDP is used to + specify sessions employing the DV encoding, the mapping is as + follows: + + o The media type ("video") goes in SDP "m=" as the media name. + + o The media subtype ("DV") goes in SDP "a=rtpmap" as the encoding + name. The RTP clock rate in "a=rtpmap" MUST be 90000, which for + the payload format defined in this document is a 90 kHz clock. + + o Any remaining parameters go in the SDP "a=fmtp" attribute by + copying them directly from the media type string as a semicolon- + separated list of parameter=value pairs. + + In the DV video payload format, the "a=fmtp" line will be used to + show the encoding type within the DV video and will be used as below: + + a=fmtp: encode= + + The required parameter "encode" specifies which type of DV format is + used. The DV format name will be one of the following values: + + SD-VCR/525-60 + SD-VCR/625-50 + HD-VCR/1125-60 + HD-VCR/1250-50 + SDL-VCR/525-60 + SDL-VCR/625-50 + 314M-25/525-60 + + + +Kobayashi, et al. Standards Track [Page 11] + +RFC 6469 RTP Payload Format for DV Video December 2011 + + + 314M-25/625-50 + 314M-50/525-60 + 314M-50/625-50 + 370M/1080-60i + 370M/1080-50i + 370M/720-60p + 370M/720-50p + 306M/525-60 (for backward compatibility) + 306M/625-50 (for backward compatibility) + + In order to show whether or not the audio data is bundled into the DV + stream, a format-specific parameter is defined: + + a=fmtp: encode= audio=