idnits 2.17.1 draft-capelastegui-mmusic-3dv-sdp-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2012) is 4380 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) == Missing Reference: 'THIS DOC' is mentioned on line 632, but not defined == Missing Reference: 'THIS DOCUMENT' is mentioned on line 615, but not defined == Missing Reference: 'REF-1' is mentioned on line 620, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T H.264' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mmusic P. Capelastegui 3 Internet-Draft Universidad Politecnica de 4 Intended status: Standards Track Madrid 5 Expires: November 1, 2012 April 30, 2012 7 3D Video in the Session Description Protocol (SDP) 8 draft-capelastegui-mmusic-3dv-sdp-00 10 Abstract 12 This document defines a mechanism to describe 3D video streams in the 13 Session Description Protocol (SDP). This includes 3D video streams 14 composed of multiple video views, or of a combination of views and 15 depth maps. Several 3D video formats are supported, including 16 simulcast, video-plus-depth, and frame-packing. 18 A new decoding dependency, "3dd", is defined, describing the 19 association between media stream belonging to a 3D video stream. In 20 addition, a new SDP media-level attribute, "3dvFormat", is defined, 21 describing the format used by media streams within a 3D video stream. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 1, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Decoding dependency of 3D video streams . . . . . . . . . . . 4 61 4. The "3dvFormat" media attribute . . . . . . . . . . . . . . . 5 62 4.1. The "depth-map-simulcast" 3D format attribute . . . . . . 5 63 4.2. The "depth-map-metadata" 3D format attribute . . . . . . . 6 64 4.3. The "stereo-view" 3D format attribute . . . . . . . . . . 7 65 4.4. The "frame-pack" 3D format attribute . . . . . . . . . . . 8 66 5. Usage with SDP offer/answer model . . . . . . . . . . . . . . 9 67 5.1. Backward compatibility . . . . . . . . . . . . . . . . . . 10 68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Example session with single 3D video option . . . . . . . 10 70 6.2. Test Scenario: Multiple 3D options . . . . . . . . . . . . 11 71 7. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. "3dvFormat media attribute . . . . . . . . . . . . . . . . 13 73 7.2. "depth-map-simulcast" 3D format attribute . . . . . . . . 13 74 7.3. "depth-map-metadata" 3D format attribute . . . . . . . . . 13 75 7.4. "stereo-view" 3D format attribute . . . . . . . . . . . . 13 76 7.5. "frame-pack" 3D format attribute . . . . . . . . . . . . . 13 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 3D video applications convey depth information by showing a different 85 view for each eye of a user. In order to achieve this, 3D video 86 streams need to include additional information compared to 87 conventional 2D video streams, either in the form of extra views, or 88 auxiliary maps such as depth maps , or a combination thereof. These 89 views and maps can be transported in a variety of ways, including, 90 among others: as separate RTP streams (simulcast), frame-packed in a 91 single video stream [HDMIv1.4a], or using the video-plus-depth format 92 [ISO/IEC 23002-3]. 94 The Session Description Protocol (SDP) [RFC4566] lacks the means to 95 describe neither of these transport techniques for 3D video. This 96 document extends SDP to support the description of multimedia 97 sessions using 3D video encapsulated as simulcast streams, using 98 frame-packing techniques, or using the video-plus-depth format. 100 [RFC5583] defines a mechanism to signal the decoding dependency of 101 media descriptions in SDP. This document extends that mechanism by 102 defining a new SDP decoding dependency type, '3dd', describing the 103 association between media streams belonging to a 3D video stream. In 104 addition, a new SDP media-level attribute, '3dvFormat', is defined to 105 describe the format used by media streams composing a 3D video 106 stream. Several formats for 3D video are described in this 107 specification, including simulcast stereo video, simulcast video and 108 depth map, various frame-packing schemes, and streams using video- 109 plus-depth. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Definitions 119 3D video stream: A video stream that conveys depth information by 120 showing different perspectives of a scene to each 121 eye of an observing user. A 3D video stream is 122 typically composed of multiple video streams 123 ('views'), or a combination of video streams and 124 auxiliary data maps such as depth maps 126 2D video stream: A video stream that lacks 3D depth information. 127 View: A video stream that represents a specific point of 128 view of the scene in a 3D video stream. 129 Depth Map: An auxiliary data stream that associates a Z-value 130 to each pixel of a view within a 3D video stream. 131 Depth maps are often encoded as grey scale video 132 streams. 133 Simulcast: A method for the transmission of 3D video streams 134 that consists on sending additional views and 135 auxiliary data streams as a separate RTP streams. 136 Video-plus-depth: (also known as MPEG-C Part 3) A method for the 137 transmission of 3D video streams consisting on 138 encapsulating a depth map as metadata within a 2D 139 video stream. This mechanism, standardized in 140 [ISO/IEC 23002-3], is compatible with MPEG-2 and 141 H.264/AVC, and allows for backwards compatibility. 142 Frame-packing: A method for the transmission of 3D video streams 143 that consists on multiplexing several views and/or 144 auxiliary data within a single video stream, using 145 either spatial multiplexing or time multiplexing. 146 Frame-packing is supported by standards like 147 [HDMIv1.4a] and [ITU-T H.264]. 149 3. Decoding dependency of 3D video streams 151 The "depend" SDP attribute, defined in [RFC5583] describes the 152 decoding dependency between two or more media descriptions. This 153 specification defines a new dependency type for the "depend" 154 attribute: 156 o 3dd: 3D video dependency - indicates that the described media 157 stream belongs to a 3D video stream, and requires other media 158 streams to render the 3D video. When "3dd" is used, all required 159 media streams for the Operation Point MUST be identified by 160 identification-tag and fmt-dependency following the "3dd" string. 162 Like other dependency types, 3dd is used in combination with the 163 "DDP" grouping semantic, which is defined in [RFC5583], and based on 164 the SDP grouping framework [RFC5888]. Whenever a 3D video stream is 165 composed of multiple media descriptions, these media descriptions 166 MUST be included in the same DDP group. 168 The media decoding dependency terminology defined in [RFC5583] can be 169 applied to 3D video streams as follows: 171 o Media Bitstream: A 3D video stream is considered a Media Bitstream 172 for the purposes of 3dd decoding dependency. 173 o Media Partition: Each separate media description composing a 3D 174 video stream is considered a Media Partition. Note that each 175 Media Partition usually contains a single video view or depth map, 176 but can also include multiple of views/maps, e.g. when using 177 frame-packing techniques. 178 o Operation Point: A subset of a 3D Media Bitstream that includes 179 all Media Partitions required for reconstruction at a certain 180 point of quality, number of views or depth maps, or other 181 property. Note that a valid Operation Point for a 3D Media 182 Bitstream can be a 2D video lacking any depth information. 184 4. The "3dvFormat" media attribute 186 a=3dvFormat: : 188 This section defines a new media-level attribute for SDP, 189 "3dvFormat", which can be used to describe the transport format of a 190 media stream in a 3D video stream. This attribute can indicate that 191 a media description corresponds to a specific view within a 3D 192 stream, or to a depth map, or to a combination of views or depth maps 193 encapsulated with frame-packing techniques or with the video-plus- 194 depth mechanism. 196 A media description can have multiple "3dvFormat" attributes; each 197 attribute is mapped to a media format specified for the media, 198 indicated by . Only one "3dvFormat" attribute is allowed per 199 media format. 201 Each "3dvFormat" attribute indicates a property (known as a "3D 202 format attribute") associated to a media format of its media 203 description. The 3D format attribute consists on an attribute-value 204 pair, with the form ":". This specification 205 defines four 3D format attributes: "depth-map-simulcast", "depth-map- 206 metadata", "stereo-view", "and frame-pack". 208 New 3D format attributes can be defined, but they MUST be registered 209 with IANA, following the registry described in Section 9. 211 4.1. The "depth-map-simulcast" 3D format attribute 213 a=3dvFormat: depth-map-simulcast: 215 The 3D format attribute "depth-map-simulcast" indicates that a media 216 stream represents a depth map associated with a view within the same 217 3D video stream. A depth map described by this attribute is 218 transmitted as a separate transport stream from its corresponding 219 view. 221 is the media stream identification (the "a=mid" 222 attribute, as defined in [RFC5888]) of the video stream associated 223 with this depth map. 225 A media description with the "depth-map-simulcast" 3D format 226 attribute MUST be included in a DDP group. This group MUST include a 227 video stream representing the view associated with the depth map. 228 Finally, the depth map media description MUST include a "depend" 229 attribute with the "3dd" dependency type, indicating dependency to 230 one or more media formats within that video stream. 232 Example: 234 a=group:DDP 1 2 235 m=video 1111 RTP/AVP 99 236 a=rtpmap:99 H264/90000 237 a=mid:1 238 m=video 1112 RTP/AVP 99 239 a=rtpmap:99 H264/90000 240 a=3dvFormat:99 depth-map-simulcast:1 241 a=mid:2 242 a=depend:99 3dd 1:99 244 The example shows two media descriptions forming a 3D video stream, 245 of which the first one (mid:1) represents a video view, and the 246 second one (mid:2) the depth map for that view. The depth map cannot 247 be used without its corresponding view, and this is reflected in the 248 "depend" attribute. 250 4.2. The "depth-map-metadata" 3D format attribute 252 a=3dvFormat: depth-map-metadata: 254 The 3D format attribute "depth-map-metadata" indicates that a media 255 stream represents a depth map associated with a view within the same 256 3D video stream. A depth map described by this attribute is 257 transmitted as part of the same transport stream as its corresponding 258 view, in the form of metadata. If the view associated with this 259 depth map is a MPEG-2 or H.264/AVC video stream, the depth map 260 follows the format defined in MPEG-C part 3 [ISO/IEC 23002-3]. 262 is the media stream identification (the "a=mid" 263 attribute, as defined in [RFC5888]) of the video stream associated 264 with this depth map. 266 A media description with the "depth-map-simulcast" 3D format 267 attribute MUST be included in a DDP group. This group MUST include a 268 video stream representing the view associated with the depth map. 269 Finally, the depth map media description MUST include a "depend" 270 attribute with the "3dd" dependency type, indicating dependency to 271 that video stream. 273 It is important to note that, when a media format with a "depth-map- 274 metadata" is used, the transport information for that media stream 275 such as port, connection address or transport protocol MUST be 276 ignored. In this case, the depth map is transmitted as part of the 277 media stream of its associated view, rather than as a separate 278 stream. 280 Example: 282 a=group:DDP 1 2 283 m=video 1111 RTP/AVP 99 284 a=rtpmap:99 H264/90000 285 a=mid:1 286 m=video 1112 RTP/AVP 99 100 287 a=rtpmap:99 H264/90000 288 a=3dvFormat:99 depth-map-simulcast:1 289 a=rtpmap:100 H264/90000 290 a=3dvFormat:100 depth-map-metadata:1 291 a=mid:2 292 a=depend:99 3dd 1:99; 100 3dd 1:99 294 The example shows two media descriptions forming a 3D video stream, 295 of which the first one (mid:1) represents a video view, and the 296 second one (mid:2) the depth map for that view. Two possible 297 configurations for the depth map are offered, one using simulcast 298 (payload type 99), and the other transmitting the depth map as 299 metadata (payload type 100). If the depth map stream is configured 300 as metadata, the port specified in that media description (1112) will 301 be ignored, since the depth map will be transmitted within the video 302 view stream. On the other hand, if the simulcast option is used, the 303 depth map will be transmitted as a separate stream using the 304 specified port and transport, as usual. 306 4.3. The "stereo-view" 3D format attribute 308 a=3dvFormat: stereo-view: 310 The 3D format attribute "stereo-view" indicates whether a video 311 stream is associated with the left-eye view or the right-eye view of 312 a stereo 3D video stream. 314 indicates which view is associated with the media stream. 315 It can have the value "left", for the left-eye view, or "right", for 316 the right-eye view. 318 A media description with the "stereo-view" 3D format attribute MUST 319 be included in a DDP group. This group MUST also include another 320 video stream containing the "stereo-view" 3D format attribute with 321 the other stereo view as value. The media description for either of 322 the two stereo views MUST include a "depend" attribute with the "3dd" 323 dependency type, indicating dependency to the stream corresponding to 324 the other view. 326 Example: 328 a=group: DDP 1 2 329 m=video 1111 RTP/AVP 99 330 a=rtpmap:99 H264/90000 331 a=3dvFormat:99 stereo-view:left 332 a=mid:1 333 m=video 1112 RTP/AVP 99 334 a=rtpmap:99 H264/90000 335 a=3dvFormat:99 stereo-view:right 336 a=mid:2 337 a=depend:99 3dd 1:99 339 The example shows two media descriptions forming a stereo 3D video 340 stream, of which the first one (mid:1) represents the left view, and 341 the second one (mid:2) the right view. This Media Bitstream can be 342 configured as a 3D video stream composed of two stereo views, or as a 343 2D video stream including just the left eye view. 345 4.4. The "frame-pack" 3D format attribute 347 a=3dvFormat: frame-pack: 349 The 3d attribute indicates that frame-packing mechanisms are used in 350 a media stream, for the specified media format. 352 signals which frame-packing mode is applied. It has 353 three possible values: "side-by-side", "top-bottom", and "frame-seq". 355 Of these frame-pack modes, the first two are based on spatial 356 multiplexing, or dividing each video frame in the stream into two 357 sub-frames, and assigning one view to each sub-frame. In "side-by- 358 side" mode, the left sub-frame corresponds to the left eye view, and 359 the right sub-frame to the right eye view. In "top-bottom" mode, the 360 top sub-frame corresponds to the left eye view, and the lower sub- 361 frame to the right eye view. 363 On the "frame-seq" (frame sequential) frame-packing mode, time 364 multiplexing is used, so that half the video frames in a stream 365 correspond to the left eye view, and the other half to the right eye 366 view, in alternating order. In order to identify which frame 367 corresponds to each view, additional signalling is required; in 368 H.264/AVC video streams, this is achieved through supplemental 369 enhancement information (SEI) metadata [ITU-T H.264]. 371 5. Usage with SDP offer/answer model 373 When the extensions defined in this specification are used in the SDP 374 offer/answer model [RFC3264], the following rules apply. 376 The offerer MAY include more than one "3dvFormat" attribute per media 377 description, and the values of these "3dvFormat" can be different or 378 duplicated. However, each media format MUST NOT have more than one 379 "3dvFormat" attribute. 381 If the offerer includes a 3D video stream composed of more than one 382 media description, all media descriptions in the stream MUST be 383 included in a DDP group. If the 3D video stream includes streams 384 with 3D format attributes whose description specifies any stream 385 requirements or mandatory dependencies, those requirements or 386 dependencies MUST be respected. Each 3D video stream in the offer 387 SHOULD have at least one Operation Point consisting on a single 2D 388 video stream, as well as any number of Operation Points with 3D 389 video. 391 An answer MUST NOT include any "3dvFormat" attribute that is not 392 present in the offer. 394 When a media format in an offered media description has a "3dvFormat" 395 attribute, if the answer contains that media format it MUST also 396 include the "3dvFormat" attribute, with the same parameters as the 397 offer. 399 To simplify the processing of 3D video configurations, when the 400 answer includes a "3dvFormat" attribute in a media description, the 401 same RTP payload type number used in the offer should also be used in 402 the answer, and the answer MUST NOT include more than one media 403 format for that media description. 405 If the answerer understands the DDP semantics, it is necessary to 406 take the "depend" attribute into consideration in the Offer/Answer 407 procedure, as indicated in [RFC5583] 409 5.1. Backward compatibility 411 Depending on implementation, a node that does not understand DDP 412 grouping or "3d" attributes SHOULD respond to an offer using this 413 grouping or attributes either with a refusal to the request, or with 414 an answer that ignores the grouping or 3D video format attributes. 416 In case of a refused request, if the offerer has identified that the 417 refusal of the request is caused by the use of 3D video, and it still 418 wishes to initiate a session, it SHOULD generate a new offer without 419 any 3D video streams. 421 If the request is accepted but the answer is ignoring the grouping 422 attribute, the "depend" attribute, or a "3dvFormat", it should be 423 assumed that the answerer is unable to send or receive 3D video 424 streams. If the offerer still wishes to initiate a session, it 425 SHOULD generate a new offer without any 3D video streams. 426 Alternatively, if the answer does not include more than a single 427 video stream, the offerer MAY initiate the session without generating 428 a new offer, and send and receive that stream as a 2D video stream. 430 6. Examples 432 The following examples show SDP Offer/Answer exchanges for sessions 433 with 3D video streams. Only the media descriptions and grouping 434 attributes of the SDP are shown. For each example, two possible 435 answers are considered: one in which the answering device is 436 compatible with this specification, and one with a legacy answering 437 device. 439 6.1. Example session with single 3D video option 441 The example shows a session where the 3D video stream is transmitted 442 over a single media stream, so no grouping or decoding dependencies 443 are needed for the SDP. The calling user agent makes a SDP offer 444 with 2 options for configuring the 3D video stream: 446 o 2D video stream 447 o Single frame-packed video stream, with 2 views multiplexed side- 448 by-side 450 Offer SDP: 452 m=video 1111 RTP/AVP 99 100 453 a=rtpmap:99 H264/90000 454 a=rtpmap:100 H264/90000 455 a=3dvFormat:100 frame-pack:side-by-side 457 Answer SDP: 459 m=video 2222 RTP/AVP 100 460 a=rtpmap:100 H264/90000 461 a=3dvFormat:100 frame-pack:side-by-side 463 The initial offer includes a media description with two media 464 formats, with one corresponding to a 2D video stream(payload type 99) 465 and the other to a frame-packed 3D video stream (payload type 100). 466 Of these, the answering device chooses the frame-packed media format. 468 Alternate Answer SDP (legacy device): 470 m=video 2222 RTP/AVP 100 471 a=rtpmap:100 H264/90000 473 If this SDP offer is received by a legacy device and the session is 474 not rejected, the answer will ignore any 3D video format attributes. 475 In this case, the offerer can initiate the session treating the 476 selected media format as a 2D video stream. 478 6.2. Test Scenario: Multiple 3D options 480 The example shows a session where the 3D video stream is transmitted 481 over up to two media streams, and several options for the format of 482 the 3D video stream are offered: 484 o 2D video stream 485 o Single frame-packed video stream, with 2 views multiplexed side- 486 by-side 487 o Single video stream including a depth map as metadata 488 o 2 Simulcast streams, with video and depth map 489 o 2 Simulcast streams, with 2 stereo views. 491 Offer SDP: 493 a=group:DDP 1 2 494 m=video 1111 RTP/AVP 99 100 495 a=rtpmap:99 H264/90000 496 a=3dvFormat:99 stereo-view:left 497 a=rtpmap:100 H264/90000 498 a=3dvFormat:100 frame-pack:side-by-side 499 a=mid:1 500 m=video 1112 RTP/AVP 99 100 101 501 a=rtpmap:99 H264/90000 502 a=3dvFormat:99 depth-map-metadata:1 503 a=rtpmap:100 H264/90000 504 a=3dvFormat:100 depth-map-simulcast:1 505 a=rtpmap:101 H264/90000 506 a=3dvFormat:101 stereo-view:right 507 a=mid:2 508 a=depend:99 3dd 1:99; 100 3dd 1:99; 101 3dd 1:99 510 Answer SDP: 512 a=group:DDP 1 2 513 m=video 2222 RTP/AVP 99 514 a=rtpmap:99 H264/90000 515 a=3d:99 stereo-view:left 516 a=mid:1 517 m=video 2223 RTP/AVP 102 518 a=rtpmap:101 H264/90000 519 a=3d:101 stereo-view:right 520 a=mid:2 521 a=depend:101 3dd 1:99 523 The initial offer includes two media descriptions, the first of which 524 (mid 1) can be transmitted independently, either as a 2D video stream 525 (payload type 99) or as a frame-packed 3D stream (payload type 100). 526 The second media description (mid 2), on the other hand, depends on 527 the first one for all its media formats, and can be configured as a 528 depth map transmitted as metadata (payload type 99), as a simulcast 529 depth map stream (payload type 100), or as a right-eye stereo view 530 (payload-type 101). The answering device chooses the configuration 531 with 2 simulcast stereo views. 533 Alternate Answer SDP (legacy device) 535 m=video 2222 RTP/AVP 99 536 a=rtpmap:99 H264/90000 537 m=video 0 RTP/AVP 102 538 a=rtpmap:101 H264/90000 540 If this SDP offer is received by a legacy device and the session is 541 not rejected, the answer will ignore any 3D video format attributes, 542 as well as the grouping and dependency attributes. In the example 543 above, the answering device has selected a media format for the first 544 video stream, and disabled the second video stream. In this case, 545 the offerer can initiate the session treating the selected media 546 format as a 2D video stream. If the second video stream had not been 547 disabled, the offerer should send a new offer with a single video 548 stream. 550 7. Formal Grammar 552 The 3d attributes defined in this document use the following 553 Augmented Backus-Naur Form (ABNF) [RFC5234] grammar. 555 7.1. "3dvFormat media attribute 557 3dvformat-attribute = "a=3dvFormat:" fmt SP 3dvf-type 558 ; fmt is described in [RFC4566] 559 ; fmt is media format (usually RTP payload type) 561 3dvf-type= depth-scast / depth-meta / st-view / f-pack 563 7.2. "depth-map-simulcast" 3D format attribute 565 depth-scast = "depth-map-simulcast:" identification-tag 566 ; identification-tag is defined in [RFC5888] 568 7.3. "depth-map-metadata" 3D format attribute 570 depth-meta = "depth-map-metadata:" identification-tag 571 ; identification-tag is defined in [RFC5888] 573 7.4. "stereo-view" 3D format attribute 575 st-view = "stereo-view:" view-type 576 view-type= "left" / "right" 578 7.5. "frame-pack" 3D format attribute 580 f-pack = "frame-pack:" fp-format 581 fp-format= "side-by-side" / "top-bottom" / "frame-seq" 583 8. Security Considerations 585 No security issues have been identified for this specification. 587 9. IANA Considerations 589 The following contact information shall be used for all registrations 590 included here: 592 Contact: Pedro Capelastegui 593 email: Capelastegui@dit.upm.es 594 tel: +34 915 49 57 00 ext. 3024 596 This document defines the following new semantics for the "depend" 597 SDP attribute. The semantics are registered by IANA under "depend" 598 SDP Attribute Values under "Session Description Protocol (SDP) 599 Parameters": 601 Token Semantics Reference 602 ----- ------------------- --------- 603 3dd 3D video dependency [THIS DOC] 605 This document defines a new media-level SDP attribute, "3dvFormat". 606 The attribute is registered by IANA under "Session Description 607 Protocol (SDP) Parameters" under "att-field (media level only)". 609 Attribute name: 3dvFormat 610 Long form: 3D video format 611 Type of name: att-field 612 Type of attribute: media level only 613 Subject to charset: no 614 Purpose: [THIS DOCUMENT] 615 Reference: [THIS DOCUMENT] 616 Values: see this document and registrations below 618 Parameters of the "3dvFormat" SDP attribute MUST be registered under 619 IANA following the "Specification Required" policy [RFC5226]. This 620 document creates a new IANA registry called [REF-1] within the 621 "Session Description Protocol (SDP) Parameters" registry, for that 622 purpose. 624 The initial entries in the registry are shown below. 626 +---------------------+------------------------------+------------+ 627 | Token | Description | Reference | 628 +---------------------+------------------------------+------------+ 629 | depth-map-simulcast | depth map as separate stream | [THIS DOC] | 630 | depth-map-metadata | depth map as metadata | [THIS DOC] | 631 | stereo-view | left or right stereo view | [THIS DOC] | 632 | frame-pack | frame-packed video stream | [THIS DOC] | 633 +---------------------+------------------------------+------------+ 635 10. Normative References 637 [HDMIv1.4a] 638 HDMI, "HDMI Specification Version 1.4a", March 2010. 640 [ISO/IEC 23002-3] 641 ISO/IEC JTC1/SC29/WG11, "ISO/IEC FDIS 23002-3 642 Representation of Auxiliary Video and Supplemental 643 Information", Doc. N8768, January 2007. 645 [ITU-T H.264] 646 HDMI, "Advanced video coding for generic audiovisual 647 services", ITU-T Recommendation H.264 and ISO/ 648 IEC 14496-10, 2010. 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 654 with Session Description Protocol (SDP)", RFC 3264, 655 June 2002. 657 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 658 Description Protocol", RFC 4566, July 2006. 660 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 661 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 662 May 2008. 664 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 665 Specifications: ABNF", STD 68, RFC 5234, January 2008. 667 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 668 Dependency in the Session Description Protocol (SDP)", 669 RFC 5583, July 2009. 671 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 672 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 674 Author's Address 676 Pedro Capelastegui 677 Universidad Politecnica de Madrid 678 ETSI Telecomunicacion 679 Avenida Complutense, 30 680 Despacho B.203 681 Madrid 28040 682 Spain 684 Phone: +34 915 49 57 00 ext. 3024 685 Email: capelastegui@dit.upm.es