summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6469.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6469.txt')
-rw-r--r--doc/rfc/rfc6469.txt1011
1 files changed, 1011 insertions, 0 deletions
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:<payload type> encode=<DV-video encoding>
+
+ 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:<payload type> encode=<DV-video encoding> audio=<audio
+ bundled>
+
+ The optional parameter "audio" will be one of the following values:
+
+ bundled
+ none (default)
+
+ If the fmtp "audio" parameter is not present, then audio data MUST
+ NOT be bundled into the DV video stream.
+
+3.2.2. Usage with the SDP Offer/Answer Model
+
+ The following considerations apply when using SDP offer/answer
+ procedures [RFC3264] to negotiate the use of the DV payload in RTP:
+
+ o The "encode" parameter can be used for sendrecv, sendonly, and
+ recvonly streams. Each encode type MUST use a separate payload
+ type number.
+
+ o Any unknown parameter in an offer MUST be ignored by the receiver
+ and MUST NOT be included in the answer.
+
+ In an offer for unbundled streams, the group attribute as defined in
+ the Session Description Protocol (SDP) Grouping Framework [RFC5888]
+ can be used in order to associate the related audio and video. The
+ example usage of SDP grouping is detailed in [RFC5888].
+
+3.3. Examples
+
+ Some example SDP session descriptions utilizing DV encoding formats
+ follow.
+
+
+
+
+
+
+Kobayashi, et al. Standards Track [Page 12]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+3.3.1. Example for Unbundled Streams
+
+ When using unbundled mode, the RTP streams for video and audio will
+ be sent separately to different ports or different multicast groups.
+ When unbundled audio and video streams are sent, SDP carries several
+ "m=" lines, one for each media type of the session (see [RFC4566]).
+
+ An example SDP description using these attributes is:
+
+ v=0
+ o=ikob 2890844526 2890842807 IN IP4 192.0.2.1
+ s=POI Seminar
+ i=A Seminar on how to make Presentations on the Internet
+ u=http://www.example.net/~ikob/POI/index.html
+ e=ikob@example.net (Katsushi Kobayashi)
+ c=IN IP4 233.252.0.1/127
+ t=2873397496 2873404696
+ m=audio 49170 RTP/AVP 112
+ a=rtpmap:112 L16/32000/2
+ m=video 50000 RTP/AVP 113
+ a=rtpmap:113 DV/90000
+ a=fmtp:113 encode=SD-VCR/525-60 audio=none
+
+ This describes a session where audio and video streams are sent
+ separately. The session is sent to a multicast group 233.252.0.1.
+ The audio is sent using L16 format, and the video is sent using
+ SD-VCR 525/60 format, which corresponds to NTSC format in consumer
+ DV.
+
+3.3.2. Example for Bundled Streams
+
+ When sending a bundled stream, all the DIF blocks including system
+ data will be sent through a single RTP stream.
+
+ An example SDP description for a bundled DV stream is:
+
+ v=0
+ o=ikob 2890844526 2890842807 IN IP4 192.0.2.1
+ s=POI Seminar
+ i=A Seminar on how to make Presentations on the Internet
+ u=http://www.example.net/~ikob/POI/index.html
+ e=ikob@example.net (Katsushi Kobayashi)
+ c=IN IP4 233.252.0.1/127
+ t=2873397496 2873404696
+ m=video 49170 RTP/AVP 112 113
+ a=rtpmap:112 DV/90000
+ a=fmtp:112 encode=SD-VCR/525-60 audio=bundled
+ a=fmtp:113 encode=314M-50/525-60 audio=bundled
+
+
+
+Kobayashi, et al. Standards Track [Page 13]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+ This SDP record describes a session where audio and video streams are
+ sent bundled. The session is sent to a multicast group 233.252.0.1.
+ The video is sent using both 525/60 consumer DV and SMPTE standard
+ 314M 50 Mbit/s formats, when the payload type is 112 and 113,
+ respectively.
+
+4. Security Considerations
+
+ RTP packets using the payload format defined in this specification
+ are subject to the security considerations discussed in the RTP
+ specification [RFC3550] and any appropriate RTP profile. This
+ implies that confidentiality of the media streams is achieved by
+ encryption. Because the data compression used with this payload
+ format is applied end-to-end, encryption may be performed after
+ compression so there is no conflict between the two operations.
+
+ A potential denial-of-service threat exists for data encodings using
+ compression techniques that have non-uniform receiver-end
+ computational load. The attacker can inject pathological datagrams
+ into the stream that are complex to decode and cause the receiver to
+ be overloaded. However, this encoding does not exhibit any
+ significant non-uniformity.
+
+ As with any IP-based protocol, in some circumstances, a receiver may
+ be overloaded simply by the receipt of too many packets, either
+ desired or undesired. Network-layer authentication may be used to
+ discard packets from undesired sources, but the processing cost of
+ the authentication itself may be too high. In a multicast
+ environment, mechanisms for joining and pruning of specific sources
+ are specified in IGMPv3, Multicast Listener Discovery Version 2
+ (MLDv2) [RFC3376][RFC3810] or Lightweight-IGMPv3 (LW-IGMPv3),
+ LW-MLDv2 [RFC5790] and in multicast routing protocols to allow a
+ receiver to select which sources are allowed to reach it [RFC4607].
+
+5. Congestion Control
+
+ The general congestion control considerations for transporting RTP
+ data apply; see RTP [RFC3550] and any applicable RTP profile like
+ Audio-Visual Profile (AVP) [RFC3551].
+
+6. IANA Considerations
+
+ This document obsoletes [RFC3189], and some registration forms have
+ been updated by this document. The registration forms (based on the
+ RFC 4855 [RFC4855] definition) for the media types for both video and
+ audio are shown in Section 3.1.
+
+
+
+
+
+Kobayashi, et al. Standards Track [Page 14]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+7. Major Changes from RFC 3189
+
+ The changes from [RFC3189] are:
+
+ 1. Specified that support for SMPTE 306M is only for backward
+ interoperability, since it is covered by SMPTE 314M format.
+
+ 2. Added SMPTE 370M 100 Mbit/s High Definition Television (HDTV)
+ (1080/60i, 1080/50i, 720/60p, and 720/50p) format.
+
+ 3. Incorporated the Source-Specific Multicast (SSM) specification
+ for avoiding overloaded traffic source in multicast usage. Added
+ a reference to the Source-Specific Multicast (SSM) specification
+ as a way to reduce unwanted traffic in a multicast application.
+
+ 4. Clarified the case where a sender omits subcode DIF block data
+ from the stream.
+
+ 5. Added considerations for the offer/answer model.
+
+ 6. Revised media types registration form based on new registration
+ rule [RFC4855].
+
+8. Interoperability with Previous Implementations
+
+ In this section, we discuss interoperability with implementations
+ based on [RFC3189], which is obsoleted by this document.
+
+ [RFC3189] regards SMPTE 306M [SMPTE306M] and SMPTE 314M [SMPTE314M]
+ as different encoding formats, although the format of SMPTE 306M is
+ already covered by SMPTE 314M. Therefore, this document recommends
+ that the definition depending on SMPTE 306M SHOULD NOT be used, and
+ SMPTE 314M SHOULD be used instead. An RTP application could handle a
+ stream identified in SMPTE 306M encoding as SMPTE 314M encoding
+ instead.
+
+ An offer MAY include SMPTE 306M encoding coming from a legacy system,
+ and receivers SHOULD support this value.
+
+ If an initial offer that did not include SMPTE 306M was rejected, the
+ offerer MAY try a new offer with SMPTE 306M. For this case, an RTP
+ application MAY handle a stream identified in SMPTE 306M encoding as
+ SMPTE 314M encoding instead.
+
+ In addition, the SDP examples in [RFC3189] provide incorrect SDP
+ "a=fmtp" attribute usage.
+
+
+
+
+
+Kobayashi, et al. Standards Track [Page 15]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+9. Acknowledgment
+
+ Thanks to Akimichi Ogawa, a former author of this document.
+
+10. References
+
+10.1. Normative References
+
+ [IEC61834] IEC, "IEC 61834, Helical-scan digital video cassette
+ recording system using 6,35 mm magnetic tape for
+ consumer use (525-60, 625-50, 1125-60 and 1250-50
+ systems)".
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3190] Kobayashi, K., Ogawa, A., Casner, S., and C. Bormann,
+ "RTP Payload Format for 12-bit DAT Audio and 20- and
+ 24-bit Linear Sampled Audio", RFC 3190, January 2002.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
+ Model with Session Description Protocol (SDP)",
+ RFC 3264, June 2002.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+ and Video Conferences with Minimal Control", STD 65,
+ RFC 3551, July 2003.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
+ and Registration Procedures", BCP 13, RFC 4288,
+ December 2005.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
+ Session Description Protocol", RFC 4566, July 2006.
+
+ [RFC4855] Casner, S., "Media Type Registration of RTP Payload
+ Formats", RFC 4855, February 2007.
+
+ [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session
+ Description Protocol (SDP) Grouping Framework",
+ RFC 5888, June 2010.
+
+ [SMPTE306M] SMPTE, "SMPTE 306M, 6.35-mm Type D-7 Component Format
+ - Video Compression at 25Mb/s - 525/60 and 625/50".
+
+
+
+Kobayashi, et al. Standards Track [Page 16]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+ [SMPTE314M] SMPTE, "SMPTE 314M, Data Structure for DV-Based Audio
+ and Compressed Video - 25 and 50Mb/s".
+
+ [SMPTE370M] SMPTE, "SMPTE 370M, Data Structure for DV-Based
+ Audio, Data and Compressed Video at 100 Mb/s 1080/
+ 60i, 1080/50i, 720/60p, and 720/50p".
+
+10.2. Informative References
+
+ [IEC61883] IEC, "IEC 61883, Consumer audio/video equipment -
+ Digital interface".
+
+ [IEEE1394] IEEE, "IEEE Std 1394-1995, Standard for a High
+ Performance Serial Bus".
+
+ [ISO/IEC11172] ISO/IEC, "ISO/IEC 11172, Coding of moving pictures
+ and associated audio for digital storage media up to
+ about 1,5 Mbit/s".
+
+ [ISO/IEC13818] ISO/IEC, "ISO/IEC 13818, Generic coding of moving
+ pictures and associated audio information".
+
+ [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M.
+ Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video",
+ RFC 2250, January 1998.
+
+ [RFC3189] Kobayashi, K., Ogawa, A., Casner, S., and C. Bormann,
+ "RTP Payload Format for DV (IEC 61834) Video",
+ RFC 3189, January 2002.
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
+ A. Thyagarajan, "Internet Group Management Protocol,
+ Version 3", RFC 3376, October 2002.
+
+ [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
+ Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+ [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
+ for IP", RFC 4607, August 2006.
+
+ [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight
+ Internet Group Management Protocol Version 3 (IGMPv3)
+ and Multicast Listener Discovery Version 2 (MLDv2)
+ Protocols", RFC 5790, February 2010.
+
+
+
+
+
+
+
+Kobayashi, et al. Standards Track [Page 17]
+
+RFC 6469 RTP Payload Format for DV Video December 2011
+
+
+Authors' Addresses
+
+ Katsushi Kobayashi
+ Advanced Institute for Computational Science, RIKEN
+ 7-1-26 Minatojima-minami
+ Chuo-ku, Kobe, Hyogo 760-0045
+ Japan
+
+ EMail: ikob@riken.jp
+
+
+ Kazuhiro Mishima
+ Keio University
+ 5322 Endo
+ Fujisawa, Kanagawa 252-8520
+ Japan
+
+ EMail: three@sfc.wide.ad.jp
+
+
+ Stephen L. Casner
+ Packet Design
+ 2455 Augustine Drive
+ Santa Clara, CA 95054
+ United States
+
+ EMail: casner@acm.org
+
+
+ Carsten Bormann
+ Universitaet Bremen TZI
+ Postfach 330440
+ D-28334, Bremen
+ Germany
+
+ Phone: +49 421 218 63921
+ Fax: +49 421 218 7000
+ EMail: cabo@tzi.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kobayashi, et al. Standards Track [Page 18]
+