idnits 2.17.1 draft-ietf-avt-rfc3189bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC61834' ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE306M' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE314M' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE370M' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kobayashi 3 Internet-Draft AIST 4 Obsoletes: 3189 (if approved) K. Mishima 5 Intended status: Standards Track Keio University 6 Expires: September 8, 2010 S. Casner 7 Packet Design 8 C. Bormann 9 Universitaet Bremen TZI 10 March 7, 2010 12 RTP Payload Format for DV (IEC 61834) Video 13 draft-ietf-avt-rfc3189bis-04 15 Abstract 17 This document specifies the packetization scheme for encapsulating 18 the compressed digital video data streams commonly known as "DV" into 19 a payload format for the Real-Time Transport Protocol (RTP). This 20 document Obsoletes RFC 3189. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 8, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Termiology . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. The DV Format Encoding . . . . . . . . . . . . . . . . . . 4 77 2. RTP Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 5 79 2.2. Payload Structures . . . . . . . . . . . . . . . . . . . . 6 80 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 7 81 3.1. Media Type Registration . . . . . . . . . . . . . . . . . 7 82 3.1.1. Media Type Registration for DV Video . . . . . . . . . 7 83 3.1.2. Media Type Registration for DV Audio . . . . . . . . . 9 84 3.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 11 85 3.2.1. Mapping of Payload Type Parameters to SDP . . . . . . 11 86 3.2.2. Usage with the SDP Offer/Answer Model . . . . . . . . 12 87 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.3.1. Example for Unbundled Streams . . . . . . . . . . . . 13 89 3.3.2. Example for Bundled Streams . . . . . . . . . . . . . 13 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7. Major Changes from RFC 3189 . . . . . . . . . . . . . . . . . 15 94 8. Interoperability with Previous Implementations . . . . . . . . 16 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 This document specifies payload formats for encapsulating both 103 consumer- and professional-use DV format data streams into the Real- 104 time Transport Protocol (RTP), version 2 [RFC3550]. DV compression 105 audio and video formats were designed for a recording format on 106 helical- scan magnetic tape media. The DV standards for consumer- 107 market devices, the IEC 61883 and 61834 series, cover many aspects of 108 consumer-use digital video, including mechanical specifications of a 109 cassette, magnetic recording format, error correction on the magnetic 110 tape, DCT video encoding format, and audio encoding format 111 [IEC61834]. The digital interface part of IEC 61883 defines an 112 interface on IEEE 1394 system [IEC61883][IEEE1394]. This 113 specification set supports several video formats: SD-VCR (Standard 114 Definition), HD-VCR (High Definition), SDL- VCR (Standard Definition 115 - Long), PALPlus, DVB (Digital Video Broadcast) and ATV (Advanced 116 Television). North American formats are indicated with a number of 117 lines and "/60", while European formats use "/50". DV standards 118 extended for professional-use were published by SMPTE as 314M and 119 370M, for different sampling systems, higher color resolution, and 120 higher bit rates [SMPTE314M][SMPTE370M]. 122 There are two kinds of DV, one for consumer use and the other for 123 professional. The original "DV" specification designed for consumer- 124 use digital VCRs is approved as the IEC 61834 standard set. The 125 specifications for professional DV are published as SMPTE 314M and 126 370M. Both encoding formats are based on consumer DV and used in 127 SMPTE D-7, D-9, and D-12 video systems. The RTP payload format 128 specified in this document supports IEC 61834 consumer DV and 129 professional SMPTE 314M and 370M (DV-Based) formats. 131 IEC 61834 also includes magnetic tape recording for digital TV 132 broadcasting systems (such as DVB and ATV) that use MPEG2 encoding. 133 The payload format for encapsulating MPEG2 into RTP has already been 134 defined in RFC 2250 [RFC2250] and others. 136 Consequently, the payload specified in this document will support six 137 video formats of the IEC standard: SD-VCR (525/60, 625/50), HD-VCR 138 (1125/60, 1250/50) and SDL-VCR (525/60, 625/50), and seven of the 139 SMPTE standards: 314M 25Mbps (525/60, 625/50), 314M 50Mbps (525/60, 140 625/50), and 370M 100Mbps (1080/60i, 1080/50i, 720/60p, and 720/50p). 141 In the future it can be extended into other video formats managed by 142 80 byte DV DIF block. 144 Throughout this specification, we make extensive use of the 145 terminology of IEC and SMPTE standards. The reader should consult 146 the original references for definitions of these terms. 148 1.1. Termiology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 1.2. The DV Format Encoding 156 The DV format only uses the DCT compression technique within each 157 frame, contrasted with the interframe compression of the MPEG video 158 standards [ISO/IEC11172][ISO/IEC13818]. All video data, including 159 audio and other system data, are managed within the picture frame 160 unit of video. 162 The DV video encoding is composed of a three-level hierarchical 163 structure, i.e., DCT super block, DCT macro block, and DCT block. A 164 picture frame is divided into rectangle- or clipped- rectangle-shaped 165 DCT super blocks. DCT super blocks are divided into 27 rectangle- or 166 square-shaped DCT macro blocks, and each DCT macro block consists of 167 a number of DCT blocks. Each DCT block represents rectangle region 168 for each color, Y, Cb, and Cr, and DCT block consists of 8x8 pixels. 170 Audio data is encoded with PCM format. The sampling frequency is 32 171 kHz, 44.1 kHz or 48 kHz and the quantization is 12-bit non-linear, 172 16-bit linear or 20-bit linear. The number of channels may be up to 173 8. Only certain combinations of these parameters are allowed 174 depending upon the video format; the restrictions are specified in 175 each document. 177 A frame of data in the DV format stream is divided into several "DIF 178 sequences". A DIF sequence is composed of an integral number of 80- 179 byte DIF blocks. A DIF block is the primitive unit for all treatment 180 of DV streams. Each DIF block contains a 3-byte ID header that 181 specifies the type of the DIF block and its position in the DIF 182 sequence. Five types of DIF blocks are defined: DIF sequence header, 183 Subcode, Video Auxiliary information (VAUX), Audio, and Video. Audio 184 DIF blocks are composed of 5 bytes of Audio Auxiliary data (AAUX) and 185 72 bytes of audio data. 187 Each RTP packet starts with the RTP header as defined in RFC 3550 188 [RFC3550]. No additional payload-format-specific header is required 189 for this payload format. 191 2. RTP Payload Format 192 2.1. RTP Header Usage 194 The RTP header fields that have a meaning specific to the DV format 195 are described as follows: 197 Payload type (PT): The payload type is dynamically assigned by means 198 outside the scope of this document. If multiple DV encoding formats 199 are to be used within one RTP session, then multiple dynamic payload 200 types MUST be assigned, one for each DV encoding format. The sender 201 MUST change to the corresponding payload type whenever the encoding 202 format is changed. 204 Timestamp: 32-bit 90 kHz timestamp representing the time at which the 205 first data in the frame was sampled. All RTP packets within the same 206 video frame MUST have the same timestamp. The timestamp SHOULD 207 increment by a multiple of the nominal interval for one DV frame 208 time, as given in the following table: 210 +----------+----------------+---------------------------------------+ 211 | Mode | Frame rate | Increase of one DV frame in 90kHz | 212 | | (Hz) | timestamp | 213 +----------+----------------+---------------------------------------+ 214 | 525-60 | 29.97 | 3003 | 215 | 625-50 | 25 | 3600 | 216 | 1125-60 | 30 | 3000 | 217 | 1250-50 | 25 | 3600 | 218 | 1080-60i | 29.97 | 3003 | 219 | 1080-50i | 25 | 3600 | 220 | 720-60p | 59.94 | 3003(*) | 221 | 720-50p | 50 | 3600(*) | 222 +----------+----------------+---------------------------------------+ 224 Note that even in 720-line DV system, the data in two video frame 225 shall be processed within one DV frame duration of 1080-line system. 226 Audio data and subcode data in 720-line system are processed in the 227 same way as the 1080-line system. Therefore in 720-line system, the 228 increase of one DV frame corresponds two video frames time. 230 Marker bit (M): The marker bit of the RTP fixed header is set to one 231 on the last packet of a video frame, and otherwise, must be zero. 232 The M bit allows the receiver to know that it has received the last 233 packet of a frame so it can display the image without waiting for the 234 first packet of the next frame to arrive to detect the frame change. 235 However, detection of a frame change MUST NOT rely on the marker bit 236 since the last packet of the frame might be lost. Detection of a 237 frame change MUST be based on a difference in the RTP timestamp. 239 2.2. Payload Structures 241 Integral DIF blocks are placed into the RTP payload beginning 242 immediately after the RTP header. Any number of DIF blocks may be 243 packed into one RTP packet, except that all DIF blocks in one RTP 244 packet MUST be from the same video frame. DIF blocks from the next 245 video frame MUST NOT be packed into the same RTP packet even if more 246 payload space remains. This requirement stems from the fact that the 247 transition from one video frame to the next is indicated by a change 248 in the RTP timestamp. It also reduces the processing complexity on 249 the receiver. Since the RTP payload contains an integral number of 250 DIF blocks, the length of the RTP payload will be a multiple of 80 251 bytes. 253 Audio and video data may be transmitted as one bundled RTP stream or 254 in separate RTP streams (unbundled). The choice MUST be indicated as 255 part of the assignment of the dynamic payload type and MUST remain 256 unchanged for the duration of the RTP session to avoid complicated 257 procedures of sequence number synchronization. The RTP sender could 258 omit DIF-sequence header and subcode DIF blocks from a stream, in the 259 case of the information either is known out-of-band or is not be 260 required for the application. Note that time code in DIF blocks is 261 mandatory for professional video applications. When sending DIF- 262 sequence header and subcode DIF blocks with unbundled audio and video 263 streams, both types of blocks MUST be included in the video stream. 265 DV streams include "source" and "source control" packs that carry 266 information indispensable for proper decoding, such as video signal 267 type, frame rate, aspect ratio, picture position, quantization of 268 audio sampling, number of audio samples in a frame, number of audio 269 channels, audio channel assignment, and language of the audio. 270 However, describing all of these attributes with a signaling protocol 271 would require large descriptions to enumerate all the combinations. 272 Therefore, no Session Description Protocol (SDP) [RFC4566] parameters 273 for these attributes are defined in this document. Instead, the RTP 274 sender MUST transmit at least those VAUX DIF blocks and/or audio DIF 275 blocks with AAUX information bytes that include "source" and "source 276 control" packs containing the indispensable information for decoding. 278 In the case of one bundled stream, DIF blocks for both audio and 279 video are packed into RTP packets in the same order as they were 280 encoded. 282 In the case of an unbundled stream, only the header, subcode, video 283 and VAUX DIF blocks are sent within the video stream. Audio is sent 284 in a different stream if desired, using a different RTP payload type. 285 It is also possible to send audio duplicated in a separate stream, in 286 addition to bundling it in with the video stream. 288 When using unbundled mode, it is RECOMMENDED that the audio stream 289 data be extracted from the DIF blocks and repackaged into the 290 corresponding RTP payload format for the audio encoding (DAT12, L16, 291 L20) [RFC3551][RFC3190] in order to maximize interoperability with 292 non-DV- capable receivers while maintaining the original source 293 quality. 295 In the case of unbundled transmission where both audio and video are 296 sent in the DV format, the same timestamp SHOULD be used for both 297 audio and video data within the same frame to simplify the lip 298 synchronization effort on the receiver. Lip synchronization may also 299 be achieved using reference timestamps passed in RTCP as described in 300 RFC 3550. 302 The sender MAY reduce the video frame rate by discarding the video 303 data and VAUX DIF blocks for some of the video frames. The RTP 304 timestamp MUST still be incremented to account for the discarded 305 frames. The sender MAY alternatively reduce bandwidth by discarding 306 video data DIF blocks for portions of the image which are unchanged 307 from the previous image. To enable this bandwidth reduction, 308 receivers SHOULD implement an error concealment strategy to 309 accommodate lost or missing DIF blocks, e.g., repeating the 310 corresponding DIF block from the previous image. 312 3. Payload Format Parameters 314 This section specifies the parameters that MAY be used to select 315 optional features of the payload format and certain features of the 316 bitstream. The parameters are specified here as part of the media 317 type registration for the DV encoding. A mapping of the parameters 318 into the Session Description Protocol (SDP) [RFC4566] is also 319 provided for applications that use SDP. Equivalent parameters could 320 be defined elsewhere for use with control protocols that do not use 321 SDP. 323 3.1. Media Type Registration 325 This registration is done using the template defined in RFC 4288 326 [RFC4288] and following RFC 4855 [RFC4855]. 328 3.1.1. Media Type Registration for DV Video 330 Type name: video 331 Subtype name: DV 333 Required parameters: 335 encode: type of DV format. Permissible values for encode are SD- 336 VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60 HD-VCR/1250-50, SDL- 337 VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 338 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 339 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward 340 compatibility), and 306M/625-50 (for backward compatibility). 342 Optional parameters: 344 audio: whether the DV stream includes audio data or not. 345 Permissible values for audio are bundled and none. Defaults to 346 none. 348 Encoding considerations: 350 DV video can be transmitted with RTP as specified in RFCXXXX 351 (This document). Other transport methods are not specified. 353 Security considerations: 355 See Section 4 of RFCXXXX (This document). 357 Interoperability considerations: NONE 359 Public specification: 361 IEC 61834 Standard 363 SMPTE 314M 365 SMPTE 370M 367 RFCXXXX (This document) 369 SMPTE 314M (for backward compatibility). 371 Applications that use this media type: Audio and video streaming and 372 conferencing tools. 374 Additional information: NONE 375 Person & email address to contact for further information: 377 Katsushi Kobayashi 379 e-mail: ikob@ni.aist.go.jp 381 Intended usage: COMMON 383 Restrictions on usage: This media type depends on RTP framing, and 384 hence is only defined for transfer via RTP (RFC 3550). Transfer 385 within other framing protocols is not defined at this time. 387 Author: 389 Katsushi Kobayashi 391 Change controller: 393 IETF Audio/Video Transport working group delegated from the 394 IESG 396 3.1.2. Media Type Registration for DV Audio 398 Type name: audio 400 Subtype name: DV 402 Required parameters: 404 encode: type of DV format. Permissible values for encode are SD- 405 VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60 HD-VCR/1250-50, SDL- 406 VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 407 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 408 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward 409 compatibility), and 306M/625-50 (for backward compatibility). 411 Optional parameters: 413 audio: whether the DV stream includes audio data or not. 414 Permissible values for audio are bundled and none. Defaults to 415 none. 417 Encoding considerations: 419 DV video can be transmitted with RTP as specified in RFCXXXX 420 (This document). Other transport methods are not specified. 422 Security considerations: 424 See Section 4 of RFCXXXX (This document). 426 Interoperability considerations: NONE 428 Published specification: 430 IEC 61834 Standard 432 SMPTE 314M 434 SMPTE 370M 436 RFCXXXX (This document) 438 SMPTE 314M (for backward compatibility). 440 Applications that use this media type: Audio and video streaming and 441 conferencing tools. 443 Additional information: NONE 445 Person & email address to contact for further information: 447 Katsushi Kobayashi 449 e-mail: ikob@ni.aist.go.jp 451 Intended usage: COMMON 453 Restrictions on usage: This media type depends on RTP framing, and 454 hence is only defined for transfer via RTP (RFC 3550). Transfer 455 within other framing protocols is not defined at this time. 457 Author: 459 Katsushi Kobayashi 461 Change controller: 463 IETF Audio/Video Transport working group delegated from the 464 IESG 466 3.2. SDP Parameters 468 3.2.1. Mapping of Payload Type Parameters to SDP 470 The information carried in the media type specification has a 471 specific mapping to fields in the Session Description Protocol (SDP), 472 which is commonly used to describe RTP sessions. When SDP is used to 473 specify sessions employing the DV encoding, the mapping is as 474 follows: 476 o The media type ("video") goes in SDP "m=" as the media name. 478 o The media subtype ("DV") goes in SDP "a=rtpmap" as the encoding 479 name. The RTP clock rate in "a=rtpmap" MUST be 90000 which for 480 the payload format defined in this document is a 90kHz clock. 482 o Any remaining parameters go in the SDP "a=fmtp" attribute by 483 copying them directly from the media type string as a semicolon 484 separated list of parameter=value pairs. 486 Note that the examples in RFC3189 (older version of this document) 487 are incorrect on the SDP "a=fmtp" attribute describing. 489 In the DV video payload format, the a=fmtp line will be used to show 490 the encoding type within the DV video and will be used as below: 492 a=fmtp: encode= 494 The required parameter specifies which type of DV 495 format is used. The DV format name will be one of the following: 497 SD-VCR/525-60 499 SD-VCR/625-50 501 HD-VCR/1125-60 503 HD-VCR/1250-50 505 SDL-VCR/525-60 507 SDL-VCR/625-50 509 314M-25/525-60 511 314M-25/625-50 512 314M-50/525-60 514 314M-50/625-50 516 370M/1080-60i 518 370M/1080-50i 520 370M/720-60p 522 370M/720-50p 524 306M/525-60 (for backward compatibility) 526 306M/625-50 (for backward compatibility) 528 In order to show whether the audio data is bundled into the DV stream 529 or not, a format specific parameter is defined as below: 531 a=fmtp: audio=