idnits 2.17.1 draft-ietf-payload-rfc3189bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (October 20, 2011) is 4565 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kobayashi 3 Internet-Draft AICS, RIKEN 4 Obsoletes: 3189 (if approved) K. Mishima 5 Intended status: Standards Track Keio University 6 Expires: April 22, 2012 S. Casner 7 Packet Design 8 C. Bormann 9 Universitaet Bremen TZI 10 October 20, 2011 12 RTP Payload Format for DV (IEC 61834) Video 13 draft-ietf-payload-rfc3189bis-03 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 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 22, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. RTP Payload Format . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. The DV Format Encoding . . . . . . . . . . . . . . . . . . 5 72 2.2. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 73 2.3. Payload Structures . . . . . . . . . . . . . . . . . . . . 7 74 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 75 3.1. Media Type Registration . . . . . . . . . . . . . . . . . 8 76 3.1.1. Media Type Registration for DV Video . . . . . . . . . 8 77 3.1.2. Media Type Registration for DV Audio . . . . . . . . . 10 78 3.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 12 79 3.2.1. Mapping of Payload Type Parameters to SDP . . . . . . 12 80 3.2.2. Usage with the SDP Offer/Answer Model . . . . . . . . 13 81 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.3.1. Example for Unbundled Streams . . . . . . . . . . . . 14 83 3.3.2. Example for Bundled Streams . . . . . . . . . . . . . 14 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 7. Major Changes from RFC 3189 . . . . . . . . . . . . . . . . . 16 88 8. Interoperability with Previous Implementations . . . . . . . . 16 89 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 This document specifies payload formats for encapsulating both 98 consumer- and professional-use Digital Video (DV) format data streams 99 into the Real-Time Transport Protocol (RTP) [RFC3550]. DV 100 compression audio and video formats were designed for a recording 101 format on helical-scan magnetic tape media. The DV standards for 102 consumer-market devices, the IEC 61883 and 61834 series, cover many 103 aspects of consumer-use digital video, including mechanical 104 specifications of a cassette, magnetic recording format, error 105 correction on the magnetic tape, Discrete Cosine Transform (DCT) 106 video encoding format, and audio encoding format [IEC61834]. The 107 digital interface part of IEC 61883 defines an interface on IEEE 1394 108 system [IEC61883][IEEE1394]. This specification set supports several 109 video formats: SD-VCR (Standard Definition), HD-VCR (High 110 Definition), SDL-VCR (Standard Definition - Long), PALPlus, DVB 111 (Digital Video Broadcast) and ATV (Advanced Television). North 112 American formats are indicated with a number of lines and "/60", 113 while European formats use "/50". DV standards extended for 114 professional use were published by SMPTE as 314M and 370M, for 115 different sampling systems, higher color resolution, and higher bit 116 rates [SMPTE314M][SMPTE370M]. 118 In summary, there are two kinds of DV, one for consumer use and the 119 other for professional. The original "DV" specification designed for 120 consumer use digital VCRs is approved as the IEC 61834 standard set. 121 The specifications for professional DV are published as SMPTE 314M 122 and 370M. Both encoding formats are based on consumer DV and used in 123 SMPTE D-7, D-9, and D-12 video systems. The RTP payload format 124 specified in this document supports IEC 61834 consumer DV and 125 professional SMPTE 314M and 370M (DV-Based) formats. 127 IEC 61834 also includes magnetic tape recording for digital TV 128 broadcasting systems (such as DVB and ATV) that use MPEG2 encoding. 129 The payload format for encapsulating MPEG2 into RTP has already been 130 defined in RFC 2250 [RFC2250] and others. 132 Consequently, the payload specified in this document will support six 133 video formats of the IEC standard: SD-VCR (525/60, 625/50), HD-VCR 134 (1125/60, 1250/50) and SDL-VCR (525/60, 625/50), and seven of the 135 SMPTE standards: 314M 25Mbps (525/60, 625/50), 314M 50Mbps (525/60, 136 625/50), and 370M 100Mbps (1080/60i, 1080/50i, 720/60p, and 720/50p). 137 In the future it can be extended into other video formats managed by 138 80 byte DV Digital Interface Format (DIF) block. 140 In the future it can be extended into other video formats that are 141 based on DV's 80-byte DIF blocks. Throughout this specification, we 142 make extensive use of the terminology of IEC and SMPTE standards. 144 The reader should consult the original references for definitions of 145 these terms. 147 1.1. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2. RTP Payload Format 155 2.1. The DV Format Encoding 157 The DV format only uses the DCT compression technique within each 158 frame, contrasted with the interframe compression of the MPEG video 159 standards [ISO/IEC11172][ISO/IEC13818]. All video data, including 160 audio and other system data, are managed within the picture frame 161 unit of video. 163 The DV video encoding is composed of a three-level hierarchical 164 structure, i.e., DCT super block, DCT macro block, and DCT block. A 165 picture frame is divided into rectangle- or clipped-rectangle-shaped 166 DCT super blocks. DCT super blocks are divided into 27 rectangle- or 167 square-shaped DCT macro blocks, and each DCT macro block consists of 168 a number of DCT blocks. Each DCT block represents a rectangle region 169 for each color, Y, Cb, and Cr, and DCT block consists of 8x8 pixels. 171 Audio data is encoded in Pulse Code Modulation (PCM) format. The 172 sampling frequency is 32 kHz, 44.1 kHz or 48 kHz and the quantization 173 is 12-bit non-linear, 16-bit linear or 20-bit linear. The number of 174 channels may be up to 8. Only certain combinations of these 175 parameters are allowed depending upon the video format; the 176 restrictions are specified in each document. 178 A frame of data in the DV format stream is divided into several "DIF 179 sequences". A DIF sequence is composed of an integral number of 80- 180 byte DIF blocks. A DIF block is the primitive unit for all treatment 181 of DV streams. Each DIF block contains a 3-byte ID header that 182 specifies the type of the DIF block and its position in the DIF 183 sequence. Five types of DIF blocks are defined: DIF sequence header, 184 Subcode, Video Auxiliary information (VAUX), Audio, and Video. Audio 185 DIF blocks are composed of 5 bytes of Audio Auxiliary data (AAUX) and 186 72 bytes of audio data. 188 Each RTP packet starts with the RTP header as defined in RFC 3550 189 [RFC3550]. No additional payload-format-specific header is required 190 for this payload format. 192 2.2. 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 90 kHz timestamp per DV | 212 | | (Hz) | frame | 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 the 720-line DV system, the data in two video 225 frames shall be processed within one DV frame duration of the 1080- 226 line system. Audio data and subcode data in 720-line system are 227 processed in the same way as the 1080-line system. Therefore in the 228 720-line system, the timestamp increase given in the third column 229 corresponds to two video frames time. 231 Marker bit (M): The marker bit of the RTP fixed header is set to one 232 on the last packet of a video frame, and otherwise, MUST be zero. 233 The M bit allows the receiver to know that it has received the last 234 packet of a frame so it can display the image without waiting for the 235 first packet of the next frame to arrive to detect the frame change. 236 However, detection of a frame change MUST NOT rely on the marker bit 237 since the last packet of the frame might be lost. Detection of a 238 frame change MUST be based on a difference in the RTP timestamp. 240 2.3. Payload Structures 242 Integral DIF blocks are placed into the RTP payload beginning 243 immediately after the RTP header. Any number of DIF blocks may be 244 packed into one RTP packet, except that all DIF blocks in one RTP 245 packet MUST be from the same video frame. DIF blocks from the next 246 video frame MUST NOT be packed into the same RTP packet even if more 247 payload space remains. This requirement stems from the fact that the 248 transition from one video frame to the next is indicated by a change 249 in the RTP timestamp. It also reduces the processing complexity on 250 the receiver. Since the RTP payload contains an integral number of 251 DIF blocks, the length of the RTP payload will be a multiple of 80 252 bytes. 254 Audio and video data may be transmitted as one bundled RTP stream or 255 in separate RTP streams (unbundled). The choice MUST be indicated as 256 part of the assignment of the dynamic payload type and MUST remain 257 unchanged for the duration of the RTP session to avoid complicated 258 procedures of sequence number synchronization. The RTP sender could 259 omit DIF-sequence header and subcode DIF blocks from a stream, when 260 the information either is known out-of-band or is not required for 261 the application. Note that time code in DIF blocks is mandatory for 262 professional video applications. When unbundled audio and video 263 streams are sent, any DIF sequence header and subcode DIF blocks MUST 264 be sent included in the video stream. 266 DV streams include "source" and "source control" packs that carry 267 information indispensable for proper decoding, such as video signal 268 type, frame rate, aspect ratio, picture position, quantization of 269 audio sampling, number of audio samples in a frame, number of audio 270 channels, audio channel assignment, and language of the audio. 271 However, describing all of these attributes with a signaling protocol 272 would require large descriptions to enumerate all the combinations. 273 Therefore, no Session Description Protocol (SDP) [RFC4566] parameters 274 for these attributes are defined in this document. Instead, the RTP 275 sender MUST transmit at least those VAUX (Video AUXiliary) DIF blocks 276 and/or audio DIF blocks with AAUX (Audio AUXiliary) information bytes 277 that include "source" and "source control" packs containing the 278 indispensable information for decoding. 280 In the case of one bundled stream, DIF blocks for both audio and 281 video are packed into RTP packets in the same order as they were 282 encoded. 284 In the case of an unbundled stream, only the header, subcode, video 285 and VAUX DIF blocks are sent within the video stream. Audio is sent 286 in a different stream if desired, using a different RTP payload type. 287 It is also possible to send audio duplicated in a separate stream, in 288 addition to bundling it in with the video stream. 290 When using unbundled mode, it is RECOMMENDED that the audio stream 291 data be extracted from the DIF blocks and repackaged into the 292 corresponding RTP payload format for the audio encoding (DAT12, L16, 293 L20) [RFC3551][RFC3190] in order to maximize interoperability with 294 non-DV-capable receivers while maintaining the original source 295 quality. 297 In the case of unbundled transmission which is compelled to use both 298 audio and video in the DV format, the same timestamp SHOULD be used 299 for both audio and video data within the same frame to simplify the 300 lip synchronization effort on the receiver. Lip synchronization may 301 also be achieved using reference timestamps passed in RTCP as 302 described in RFC 3550. In this case, the audio stream uses the 90kHz 303 clock rate, and the timestamp uses the same clock rate as the video. 305 The sender MAY reduce the video frame rate by discarding the video 306 data and VAUX DIF blocks for some of the video frames. The RTP 307 timestamp MUST still be incremented to account for the discarded 308 frames. The sender MAY alternatively reduce bandwidth by discarding 309 video data DIF blocks for portions of the image which are unchanged 310 from the previous image. To enable this bandwidth reduction, 311 receivers SHOULD implement an error concealment strategy to 312 accommodate lost or missing DIF blocks, e.g., repeating the 313 corresponding DIF block from the previous image. 315 3. Payload Format Parameters 317 This section specifies the parameters that MAY be used to select 318 optional features of the payload format and certain features of the 319 bitstream. The parameters are specified here as part of the media 320 type registration for the DV encoding. A mapping of the parameters 321 into the Session Description Protocol (SDP) [RFC4566] is also 322 provided for applications that use SDP. Equivalent parameters could 323 be defined elsewhere for use with control protocols that do not use 324 SDP. 326 3.1. Media Type Registration 328 This registration is done using the template defined in RFC 4288 329 [RFC4288] and following RFC 4855 [RFC4855]. 331 3.1.1. Media Type Registration for DV Video 332 Type name: video 334 Subtype name: DV 336 Required parameters: 338 encode: type of DV format. Permissible values for encode are 339 SD-VCR/525-60, 340 SD-VCR/625-50, 341 HD-VCR/1125-60, 342 HD-VCR/1250-50, 343 SDL-VCR/525-60, 344 SDL-VCR/625-50, 345 314M-25/525-60, 346 314M-25/625-50, 347 314M-50/525-60, 348 314M-50/625-50, 349 370M/1080-60i, 350 370M/1080-50i, 351 370M/720-60p, 352 370M/720-50p, 353 306M/525-60 (for backward compatibility), 354 and 306M/625-50 (for backward compatibility). 356 Optional parameters: 358 audio: whether the DV stream includes audio data or not. 359 Permissible values for audio are bundled and none. Defaults to 360 none. 362 Encoding considerations: 364 DV video can be transmitted with RTP as specified in RFCXXXX 365 (This document). Other transport methods are not specified. 367 Security considerations: 369 See Section 4 of RFCXXXX (This document). 371 Interoperability considerations: Interoperability with Previous 372 Implementations is discussed in Section 8. 374 Public specification: 376 IEC 61834 Standard 377 SMPTE 314M 378 SMPTE 370M 379 RFCXXXX (This document) 380 SMPTE 306M (for backward compatibility). 382 Applications that use this media type: Audio and video streaming and 383 conferencing tools. 385 Additional information: NONE 387 Person & email address to contact for further information: 389 Katsushi Kobayashi 391 e-mail: ikob@ni.aist.go.jp 393 Intended usage: COMMON 395 Restrictions on usage: This media type depends on RTP framing, and 396 hence is only defined for transfer via RTP (RFC 3550). Transfer 397 within other framing protocols is not defined at this time. 399 Author: 401 Katsushi Kobayashi 403 Change controller: 405 IETF Audio/Video Transport working group delegated from the 406 IESG 408 3.1.2. Media Type Registration for DV Audio 410 Type name: audio 412 Subtype name: DV 414 Required parameters: 416 encode: type of DV format. Permissible values for encode are 417 SD-VCR/525-60, 418 SD-VCR/625-50, 419 HD-VCR/1125-60, 420 HD-VCR/1250-50, 421 SDL-VCR/525-60, 422 SDL-VCR/625-50, 423 314M-25/525-60, 424 314M-25/625-50, 425 314M-50/525-60, 426 314M-50/625-50, 427 370M/1080-60i, 428 370M/1080-50i, 429 370M/720-60p, 430 370M/720-50p, 431 306M/525-60 (for backward compatibility), 432 and 306M/625-50 (for backward compatibility). 434 Optional parameters: 436 audio: whether the DV stream includes audio data or not. 437 Permissible values for audio are bundled and none. Defaults to 438 none. 440 Encoding considerations: 442 DV audio can be transmitted with RTP as specified in RFCXXXX 443 (This document). Other transport methods are not specified. 445 Security considerations: 447 See Section 4 of RFCXXXX (This document). 449 Interoperability considerations: Interoperability with Previous 450 Implementations is discussed in Section 8. 452 Published specification: 454 IEC 61834 Standard 455 SMPTE 314M 456 SMPTE 370M 457 RFCXXXX (This document) 458 SMPTE 306M (for backward compatibility). 460 Applications that use this media type: Audio and video streaming and 461 conferencing tools. 463 Additional information: NONE 465 Person & email address to contact for further information: 467 Katsushi Kobayashi 469 e-mail: ikob@ni.aist.go.jp 471 Intended usage: COMMON 472 Restrictions on usage: This media type depends on RTP framing, and 473 hence is only defined for transfer via RTP (RFC 3550). Transfer 474 within other framing protocols is not defined at this time. 476 Author: 478 Katsushi Kobayashi 480 Change controller: 482 IETF Audio/Video Transport working group delegated from the 483 IESG 485 3.2. SDP Parameters 487 3.2.1. Mapping of Payload Type Parameters to SDP 489 The information carried in the media type specification has a 490 specific mapping to fields in the Session Description Protocol (SDP), 491 which is commonly used to describe RTP sessions. When SDP is used to 492 specify sessions employing the DV encoding, the mapping is as 493 follows: 495 o The media type ("video") goes in SDP "m=" as the media name. 497 o The media subtype ("DV") goes in SDP "a=rtpmap" as the encoding 498 name. The RTP clock rate in "a=rtpmap" MUST be 90000 which for 499 the payload format defined in this document is a 90kHz clock. 501 o Any remaining parameters go in the SDP "a=fmtp" attribute by 502 copying them directly from the media type string as a semicolon 503 separated list of parameter=value pairs. 505 In the DV video payload format, the a=fmtp line will be used to show 506 the encoding type within the DV video and will be used as below: 508 a=fmtp: encode= 510 The required parameter "encode" specifies which type of DV format is 511 used. The DV format name will be one of the following value: 513 SD-VCR/525-60 514 SD-VCR/625-50 515 HD-VCR/1125-60 516 HD-VCR/1250-50 517 SDL-VCR/525-60 518 SDL-VCR/625-50 519 314M-25/525-60 520 314M-25/625-50 521 314M-50/525-60 522 314M-50/625-50 523 370M/1080-60i 524 370M/1080-50i 525 370M/720-60p 526 370M/720-50p 527 306M/525-60 (for backward compatibility) 528 306M/625-50 (for backward compatibility) 530 In order to show whether the audio data is bundled into the DV stream 531 or not, a format specific parameter is defined as below: 533 a=fmtp: encode= audio=