idnits 2.17.1 draft-greevenbosch-mmusic-sdp-3d-format-01.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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4194 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mmusic B. Greevenbosch 3 Internet-Draft Y. Hui 4 Intended status: Standards Track Huawei 5 Expires: April 25, 2013 October 22, 2012 7 Signal 3D format 8 draft-greevenbosch-mmusic-sdp-3d-format-01 10 Abstract 12 This document introduces the SDP attribute "3dFormat", which provides 13 format description of stereoscopic 3D video. In addition, the 14 grouping mechanism for SDP is extended to cater for stereoscopic 3D 15 video. 17 Note 19 Discussion and suggestions for improvement are requested, and should 20 be sent to mmusic@ietf.org. 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 25, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. The "3dFormat" attribute . . . . . . . . . . . . . . . . . . . 8 60 5. Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6. Combinations of attribute values and group usage . . . . . . . 12 62 7. SDP offer/answer with 3D support . . . . . . . . . . . . . . . 14 63 8. SDP offer/answer without 3D support . . . . . . . . . . . . . 16 64 8.1. Frame packing . . . . . . . . . . . . . . . . . . . . . . 16 65 8.2. 2D and auxiliary as a single stream . . . . . . . . . . . 16 66 8.3. 2D and auxiliary as two separate streams . . . . . . . . . 16 67 8.4. Simulcast of L- and R-views . . . . . . . . . . . . . . . 17 68 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. One single frame compatible stream . . . . . . . . . . . . 18 70 9.2. Two separate streams . . . . . . . . . . . . . . . . . . . 18 71 9.3. C-stream and depth map stream . . . . . . . . . . . . . . 18 72 9.4. Stereoscopic 3D video with two different formats . . . . . 19 73 10. Formal ABNF grammar of the "3dFormat" attribute . . . . . . . 21 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 76 12.1. "3dFormat" attribute . . . . . . . . . . . . . . . . . . . 23 77 12.2. "3DS" value for "group" semantics . . . . . . . . . . . . 24 78 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 79 14. Normative References . . . . . . . . . . . . . . . . . . . . . 26 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 82 1. Introduction 84 In stereoscopic 3D multimedia applications, two views are displayed, 85 one for the left eye and one for the right eye. 87 There are various ways of formatting the views of Stereoscopic 3D 88 video. Examples of 3D formats are frame packing (see [HDMIv1.4a] and 89 [ISO/IEC 14496-10]) and the combination of 2D video and auxiliary 90 data such as depth maps or parallax maps (for both, see [ISO/IEC 91 23002-3]). Stereoscopic 3D video may be carried over a single stream 92 or over several streams, depending on its 3D format. 94 In multimedia streaming applications, the Session Description 95 Protocol (SDP) [RFC4566] can be used to provide to the receiver 96 sufficient information about the media streams, and to enable the 97 receiver to join and participate in the session. 99 This document defines an extension to SDP that provides sufficient 100 information about the format of stereoscopic 3D video carried in the 101 media stream(s). Before accessing the stream(s), the receiver can 102 use the 3D format description from SDP to determine whether it has 103 the capability to receive and render the stereoscopic 3D video 104 content, and whether it can participate in the session. 106 The mentioned SDP extension is a new SDP attribute "3dFormat", which 107 provides the format description of stereoscopic 3D video. The design 108 of the attribute is based on the following requirements, which are 109 listed only for informational purposes: 111 o It MUST be possible to signal that the left and right views are 112 carried in a single stream, by the use of frame packing. 114 o It MUST be possible to signal that 2D video and auxiliary video 115 (such as depth maps) are carried in a single stream. 117 o It MUST be possible to signal that the left and right views are 118 carried in two separate streams. 120 o It MUST be possible to signal that 2D video and auxiliary video 121 (such as depth maps) are carried in separate streams. 123 To bind multiple video streams that carry a single stereoscopic 3D 124 video, this document also extends the SDP grouping mechanism from 125 [RFC5888]. 127 2. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Definitions 135 2D video 136 Video that does not in itself contain depth or parallax 137 information. 139 auxiliary video 140 A sequence of depth or parallax maps, which are used to add depth 141 to 2D video. 143 C-view 144 The centre view: a visual entity as seen from a viewpoint between 145 the left and right eyes. The C-view can be used to calculate the 146 L- and R-views. 148 C-stream 149 A 2D video stream consisting of a sequence of C-views. 151 depth map 152 A two dimensional map, each pixel of which defines the depth of 153 one or more pixels in an associated 2D video frame. 155 depth map stream 156 An auxiliary stream, which contains a sequence of depth maps. The 157 depth map stream is synchronised with the associated 2D video 158 stream. 160 frame packing 161 A format that packs the L- and R-views into a single 2D video 162 stream. The packing may be done spatially, where each video frame 163 is divided into sub-frames, one containing the L-view and one 164 containing the R-view. The packing can also be done sequentially, 165 where alternating video frames represent L- and R-views. 167 legacy answerer 168 An answerer (in the SDP offer/answer model [RFC3264]) that does 169 not support the "3dFormat" attribute. The legacy answerer can be 170 the streaming server or the streaming client, but is not compliant 171 to this document. 173 L-view 174 A visual entity that is to be projected to the left eye. 176 L-stream 177 A 2D video stream consisting of a sequence of L-views. 179 parallax map 180 A two dimensional map, each pixel of which defines the parallax of 181 one or more pixels in an associated 2D video frame. 183 parallax map stream 184 An auxiliary stream, which contains a sequence of parallax maps. 185 The parallax map stream is synchronised with the associated 2D 186 video stream. 188 R-view 189 A visual entity that is to be projected to the right eye. 191 R-stream 192 A 2D video stream consisting of a sequence of R-views. 194 stereoscopic 3D video 195 The L- and R-streams, ready to be projected to the viewer's left 196 and right eyes. 198 sub-frame 199 A part of a video frame. 201 4. The "3dFormat" attribute 203 The media-level SDP attribute "3dFormat" signals the format of 204 stereoscopic 3D video. The attribute transfers this information 205 through two parameters: one indicating the format type of the 206 stereoscopic 3D video carried in the media stream(s), and the other 207 indicating the type of the video component, which is a constituent 208 element of the stereoscopic 3D video. The video component type 209 depends on the format type of the stereoscopic 3D video. The syntax 210 of the attribute is defined as follows: 212 a=3dFormat: 214 The can have the following values (as indicated between 215 the quotes): 217 "FP" Frame Packing 218 The L- and R-views are packed into a single stream. The packing 219 may use a side-by-side, top-and-bottom, interleaved, checkerboard 220 or frame sequential format. 222 "SC" Simulcast 223 The L- and R-streams are transmitted separately. 225 "2DA" 2D + auxiliary 226 2D video and auxiliary data (such as depth maps or parallax maps) 227 are transmitted. These can be transmitted in a single stream, as 228 well as in two separate streams. 230 The can have the following values (as indicated 231 between the quotes): 233 "C" Centre view 234 The associated stream is a C-stream. 236 "CD" centre view and depth map 237 The associated stream contains both the C-view and depth map 238 sequences. 240 "ChB" Checkerboard 241 The video frame consists of alternating pixels from the 242 corresponding L- and R-views, as illustrated by Figure 1. 244 "CP" Centre view and parallax map 245 The associated stream contains both the C-view and parallax map 246 sequences. 248 "D" Depth map 249 The associated stream is a sequence of depth maps. 251 "L" Left view 252 The associated stream is the L-stream. 254 "LD" Left view and depth map 255 The associated stream contains both the L-view and depth map 256 sequences. 258 "LIL" Line Interleaved 259 Each video frame consists of alternating scan lines from the L- 260 and R-views. 262 "LP" Left view and parallax map 263 The associated stream contains both the L-view and parallax map 264 sequences. 266 "P" Parallax map 267 The associated stream is a sequence of parallax maps. 269 "R" Right view 270 The associated stream is the R-stream. 272 "SbS" Side by Side 273 Each video frame is divided in two equally sized sub-frames, 274 spatially positioned side by side of each other. One sub-frame 275 contains the L-view, whereas the other contains the R-view. 277 "Seq" Frame Sequential 278 The single video stream consists of alternating frames from the L- 279 and R-streams. Additional signalling, e.g. AVC SEI messages 280 [ISO/IEC 14496-10], is needed to signal which frames contain L- 281 and which contain R-views. 283 "TaB" Top and Bottom 284 Each video frame is divided in two equally sized sub-frames, 285 spatially positioned above each other. One sub-frame contains the 286 L-view, whereas the other contains the R-view. 288 +-+-+-+-+-+-+ 289 |L|R|L|R|L|R| 290 +-+-+-+-+-+-+ 291 |R|L|R|L|R|L| 292 +-+-+-+-+-+-+ 293 |L|R|L|R|L|R| 294 +-+-+-+-+-+-+ 296 The checkerboard pattern. The transmitted video frame is composed of 297 pixels from the L- and R-views. Samples from the L-view are 298 indicated with "L", whereas samples from the R-view are indicated 299 with "R". 301 Figure 1 303 5. Grouping 305 When multiple streams carry a single stereoscopic 3D video, (e.g. 306 C-stream and parallax map, or separately transmitted L- and 307 R-streams), the grouping mechanism from [RFC5888] MUST be used. 309 However, to cater for the special requirements of 3D signalling, the 310 semantics are expanded: 312 group-attribute = "a=group:" semantics *(SP identification-tag) 313 semantics = "LS" / "FID" / "3DS" / semantics-extension 314 semantics-extension = token 316 The grouping is needed when multiple streams carry a single 317 stereoscopic 3D video. This is the case when the is 318 "SC", or the is "2DA" and the 2D video and auxiliary 319 data are transmitted as multiple streams. A group with the "3Ds" 320 semantics is called a "3DS group". 322 A 3DS group MUST NOT contain data that is (potentially) inconsistent 323 with other data in the 3DS group: 325 o A 3DS group MUST NOT contain both a parallax map stream and a 326 depth map stream. 328 o A 3DS group MUST NOT contain more than one parallax map stream. 330 o A 3DS group MUST NOT contain more than one depth map stream. 332 o A 3DS group MUST contain at least one 2D video stream. 334 o If a 3GS group contains an L- and an R-stream, it MUST NOT contain 335 a depth map or a parallax map. 337 o If a 3DS group contains only one 2D video stream, it MUST also 338 contain a parallax map stream or a depth map stream. 340 o If a 3DS group contains a parallax map stream or a depth map 341 stream, it MUST also contain a 2D video stream. 343 6. Combinations of attribute values and group usage 345 The following table summarises the possible combinations of attribute 346 values and grouping: 348 +-----+----+-------+---------+ 349 | | FP | SC | 2DA | 350 +-----+----+-------+---------+ 351 | C | | | D/P,3DS | 352 | | | | | 353 | CD | | | T | 354 | | | | | 355 | ChB | T | | | 356 | | | | | 357 | CP | | | T | 358 | | | | | 359 | D | | | C/L,3DS | 360 | | | | | 361 | L | | R,3DS | D/P,3DS | 362 | | | | | 363 | LD | | | T | 364 | | | | | 365 | LIL | T | | | 366 | | | | | 367 | LP | | | T | 368 | | | | | 369 | P | | | C/L,3DS | 370 | | | | | 371 | R | | L,3DS | | 372 | | | | | 373 | SbS | T | | | 374 | | | | | 375 | Seq | T | | | 376 | | | | | 377 | TaB | T | | | 378 +-----+----+-------+---------+ 380 The table is to be read as follows: 382 o The columns indicate values, whereas the rows 383 indicate values. 385 o For one particular column, we denote the value by 386 "FT" and the value by "CT". 388 o When an entry in the table is empty, it means that the 389 corresponding combination of FT and CT is not allowed. 391 o When an entry in the table contains a single 392 value CTsec, it means that another stream with the value CTsec and the same value FT is needed. 395 o When multiple values are listed, separated by a 396 "/" symbol, only one secondary stream is needed, which must have 397 one of the listed values, and the same value FT. 400 o When an entry contains "3DS", it means that a 3DS group is needed. 402 o When an entry in the table contains the letter "T" (true), it 403 means that the corresponding combination FT and CT is allowed, 404 that there is no required secondary stream, and that a 3DS group 405 is not needed. 407 7. SDP offer/answer with 3D support 409 This section describes how the SDP offer/answer model (see [RFC3264]) 410 can be used to negotiate the 3D format. It is assumed that both 411 offerer and answerer are compliant to this document. The case where 412 the answerer is a legacy answerer is described in Section 8. 414 An example where the SDP offer/answer model can be used to negotiate 415 the 3D format, is the case where the offerer offers two 416 representations of the same stereoscopic 3D video: one frame packed 417 and one as L/R simulcast. In this case, the answerer can select the 418 format of its preference, according to its capabilities or as a 419 trade-off between bandwidth and video quality. 421 There may also be cases where the answerer prefers to receive a 2D 422 version, even when it supports stereoscopic 3D video and the 423 "3dFormat" attribute. For example, this might happen when the user 424 prefers to watch without glasses this time. 426 The following statements apply for the answerer: 428 o The answerer MUST NOT omit the "3dFormat" attribute for the 429 accepted streams. The answerer MAY omit the "3dFormat" attribute 430 for the rejected streams. 432 o The answerer MUST NOT change the value of the "3dFormat" 433 attribute. This means, that the answerer can only choose between 434 the 3D formats advertised in the offer. 436 o In case the offer contains simulcast of the L- and R-view, the 437 answerer MAY choose just one view. In this case, it MUST select 438 only that view. This means that the port number of the other view 439 MUST be set to zero in the answer. 441 o In case the offer contains a 2D stream and an auxiliary stream as 442 separate streams, the answerer MAY choose only the 2D stream. In 443 this case, it MUST select the 2D stream, and MUST NOT select the 444 auxiliary stream. This means that the port number of the 445 auxiliary stream MUST be set to zero in the answer. 447 o In case the offer contains a 2D stream and an auxiliary stream as 448 a single stream, the answerer MAY choose to reject the stream by 449 setting the port number in the answer to zero. 451 o In case of frame packing, if the answerer prefers not to have 452 frame packing, it MUST reject the stream by setting the port 453 number in the answer to zero. 455 o If the answerer selects multiple 3D formats, it MUST be prepared 456 to send/receive (depending on whether it is a streaming server or 457 client or both) associated streams simultaneously. 459 The following statements apply for the offerer: 461 o The offerer MUST check if the "3dFormat" attribute is included in 462 the answer. If it is not, it SHOULD handle the answer as 463 described in Section 8. 465 o The offerer SHOULD list the 3D formats in order of preference. 467 o When multiple 3D formats are selected, the offerer MAY initiate 468 all associated streams. Alternatively, it MAY update its offer 469 with a reduced number of 3D formats. 471 o If all 3D formats have been rejected, the offerer MAY issue a new 472 offer with 2D video instead. 474 o If only an auxiliary stream is selected in the answer, the offerer 475 SHOULD update its offer with only the associated 2D video stream. 476 Alternatively, it MAY update its offer advertising another 3D 477 format. 479 8. SDP offer/answer without 3D support 481 Since a legacy answerer does not support the "3dFormat" attribute, it 482 might reject the offer. In this case the offerer MAY send a new 483 offer with only a 2D video stream. 485 On the other hand, it is also possible that the legacy answerer 486 accepts the offer but omits the "3dFormat" attribute in the answer. 487 In this case the offerer is able to deduct that the answerer is a 488 legacy answerer without 3D support. In the following subsections, we 489 describe what the offerer still can do to provide a good user 490 experience with a legacy answerer, for each of the 3D format styles. 491 We assume that the offer was accepted, but a legacy answerer was 492 detected. 494 8.1. Frame packing 496 In case the original offer contains frame packing, and the answer 497 does not contain the "3dFormat" attribute, the offerer SHOULD treat 498 that media stream as a 2D stream. 500 Note: in some cases, the answerer may be a legacy device that is 501 capable of rendering a frame packed 3D stream, but does not 502 understand the "3dFormat" attribute. For example, the user may be 503 able to switch manually to 3D. Therefore, the server MAY stream the 504 frame packed video as it is. 506 8.2. 2D and auxiliary as a single stream 508 If the original offer contains a 2D video and an auxiliary video in a 509 single stream, and the answer does not contain the "3dFormat" 510 attribute, the offerer SHOULD treat that media stream as a 2D stream. 512 8.3. 2D and auxiliary as two separate streams 514 When the offerer sends an offer to a legacy answerer, and the offer 515 contains a 2D video and an auxiliary video in two separate streams, 516 there are the following possibilities: 518 o If the answerer selects only the 2D video stream then 2D video 519 streaming can be done as agreed. 521 o If the answerer selects only the auxiliary video, the offerer MAY 522 treat that stream as a 2D video stream. If it does not, the 523 offerer SHOULD update its offer without the auxiliary video. 525 o If the answerer selects both video streams, but omits the 526 "3dFormat" attribute, the offerer MAY update its offer without the 527 auxiliary video. 529 In case the offerer updates its offer by setting the port for 530 auxiliary video to zero, it MUST NOT include the "3dFormat" attribute 531 or use "3DS" grouping for the 2D stream. 533 8.4. Simulcast of L- and R-views 535 When the offerer sends an offer to simulcast the L- and R-view to the 536 legacy answerer, we have the following possibilities: 538 o If the answerer selects only one video stream, the offerer MAY 539 stream the 2D video as agreed. 541 o If the answerer selects both video streams, but omits the 542 "3dFormat" attribute, the offerer MAY update its offer with only 543 the L- or the R-stream. 545 In case the offerer updates its offer with only the L- or R-stream by 546 setting one of the ports to zero, it MUST NOT include the "3dFormat" 547 attribute or use "3DS" grouping for the offered stream. 549 9. Examples 551 9.1. One single frame compatible stream 553 The following is an example of an SDP description of a session which 554 contains a single stream, in which the L- and R-streams are packed, 555 in side by side fashion. 557 v=0 558 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 559 s=The technology of 3D-TV 560 c=IN IP4 131.164.74.2 561 t=0 0 562 m=video 49170 RTP/AVP 99 563 a=rtpmap:99 H264/90000 564 a=3dFormat:FP SbS 565 m=audio 52890 RTP/AVP 10 566 a=rtpmap:10 L16/16000/2 568 9.2. Two separate streams 570 The following is an example of an SDP description of a session with 571 an audio stream, an L-stream and an R-stream. 573 v=0 574 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 575 s=The technology of 3D-TV 576 c=IN IP4 131.164.74.2 577 t=0 0 578 a=group:3DS 1 2 579 m=video 49170 RTP/AVP 99 580 a=rtpmap:99 H264/90000 581 a=3dFormat:SC L 582 a=mid:1 583 m=video 49172 RTP/AVP 101 584 a=rtpmap:101 H264/90000 585 a=3dFormat:SC R 586 a=mid:2 587 m=audio 52890 RTP/AVP 10 588 a=rtpmap:10 L16/16000/2 590 9.3. C-stream and depth map stream 592 The following is an example of an SDP description of a session with 593 an audio stream, a C-stream and a depth map stream. 595 v=0 596 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 597 s=The technology of 3D-TV 598 c=IN IP4 131.164.74.2 599 t=0 0 600 a=group:3DS 1 2 601 m=video 49170 RTP/AVP 99 602 a=rtpmap:99 H264/90000 603 a=3dFormat:2DA C 604 a=mid:1 605 m=video 49172 RTP/AVP 101 606 a=rtpmap:101 H264/90000 607 a=3dFormat:2DA D 608 a=mid:2 609 m=audio 52890 RTP/AVP 10 610 a=rtpmap:10 L16/16000/2 612 9.4. Stereoscopic 3D video with two different formats 614 In the following example, there are two different formats for 615 stereoscopic 3D video. One consists of stream 1 (C-stream) and 616 stream 2 (parallax map stream), whereas the other consists of stream 617 3 (L-stream) and stream 4 (R-stream). There also is an audio stream, 618 which can be used with both formats. 620 v=0 621 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 622 s=The technology of 3D-TV 623 c=IN IP4 131.164.74.2 624 t=0 0 625 a=group:3DS 1 2 626 a=group:3DS 3 4 627 m=video 49170 RTP/AVP 99 628 a=rtpmap:99 H264/90000 629 a=3dFormat:2DA C 630 a=mid:1 631 m=video 49172 RTP/AVP 101 632 a=rtpmap:101 H264/90000 633 a=3dFormat:2DA P 634 a=mid:2 635 m=video 49174 RTP/AVP 103 636 a=rtpmap:103 H264/90000 637 a=3dFormat:SC L 638 a=mid:3 639 m=video 49176 RTP/AVP 105 640 a=rtpmap:105 H264/90000 641 a=3dFormat:SC R 642 a=mid:4 643 m=audio 52890 RTP/AVP 10 644 a=rtpmap:10 L16/16000/2 646 10. Formal ABNF grammar of the "3dFormat" attribute 648 This section contains the formal ABNF grammar of the "3dFormat" 649 attribute. 651 3dFormat-attribute = "a=3dFormat:" formatType componentType 652 formatType = "FP"/"SC"/"2DA"/formatType-extension 653 formatType-extension = token 654 componentType = "C"/"CD"/"ChB"/"CP"/"D"/"L"/"LD"/ 655 "LIL"/"LP"/"P"/"R"/"SbS"/"Seq"/"TaB"/ 656 componentType-extension 657 componentType-extension = token 659 11. Security Considerations 661 The authors foresee no security issues in addition to those already 662 listed in [RFC4566]. 664 12. IANA Considerations 666 12.1. "3dFormat" attribute 668 Following the guidelines in [RFC4566], the SDP attribute has to be 669 registered at IANA: 671 o Contact name/email: authors of this RFC 673 o Attribute name: 3dFormat 675 o Long-form attribute name: Attribute for signalling the format of a 676 stereoscopic 3D video carried in the media stream(s). 678 o Type of attribute: media level 680 o Subject to charset: no 682 The "3dFormat" SDP media-level attribute is used to signal the format 683 of stereoscopic 3D video, carried in one or more media stream(s). 685 The attribute has the following syntax: 687 a=3dFormat: 689 The indicates the format type of the stereoscopic 3D 690 video carried in the media stream(s). It indicates whether the 691 stereoscopic 3D video is frame packed, simulcast or consists of a 2D 692 video stream and an auxiliary stream. The can have the 693 following values (as indicated between the quotes): 695 "FP" frame packed 696 "SC" simulcast 697 "2DA" 2D + auxiliary 699 The indicates the type of the video component, which 700 is a constituent element of the stereoscopic 3D video. It can have 701 the following values: 703 "C" centre view 704 "CD" centre view and depth map 705 "ChB" checkerboard 706 "CP" centre view and parallax map 707 "D" depth map 708 "L" left view 709 "LD" left view and depth map 710 "LIL" line interleaved 711 "LP" left view and parallax map 712 "P" parallax map 713 "R" right view 714 "SbS" side by side 715 "Seq" frame sequential 716 "TaB" top and bottom 718 12.2. "3DS" value for "group" semantics 720 Following the standards action policy from [RFC5226], the following 721 semantics have to be registered with IANA in the "Semantics for the 722 "group" SDP Attribute" registry under "SDP Parameters": 724 +-----------------+-------+-----------+ 725 | Semantics | Token | Reference | 726 +-----------------+-------+-----------+ 727 | 3D synchronised | 3DS | this RFC | 728 +-----------------+-------+-----------+ 730 13. Acknowledgements 732 The authors would like to thank Stephen Botzko, Imed Bouazizi, Pedro 733 Capelastegui, Roni Even, Miguel Garcia, Ted Hardie, Jonathan Lennox, 734 Yue Peiyu and Tian Linyi for their review comments. 736 14. Normative References 738 [HDMIv1.4a] 739 HDMI, "HDMI Specification Version 1.4a", March 2010. 741 [ISO/IEC 23002-3] 742 MPEG, "MPEG video technologies part 3: Representation of 743 auxiliary video and supplemental information", ISO/IEC 744 FDIS 23002-3:2007(E), December 2002. 746 [ISO/IEC 14496-10] 747 MPEG, "H.264/MPEG-4 Part 10: Advanced video coding for 748 generic audiovisual services", ISO/IEC FDIS 14496-10:2010, 749 March 2010. 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, March 1997. 754 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 755 with Session Description Protocol (SDP)", RFC 3264, 756 June 2002. 758 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 759 Description Protocol", RFC 4566, July 2006. 761 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 762 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 763 May 2008. 765 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 766 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 768 Authors' Addresses 770 Bert Greevenbosch 771 Huawei Technologies Co., Ltd. 772 Huawei Industrial Base 773 Bantian, Longgang District 774 Shenzhen 518129 775 P.R. China 777 Phone: +86-755-28978088 778 Email: bert.greevenbosch@huawei.com 780 Hui Yu 781 Huawei Technologies Co., Ltd. 782 Huawei Nanjing R&D Center 783 101 Software Avenue 784 Yuhuatai District 785 Nanjing 210012 786 P.R. China 788 Phone: +86-25-56620323 789 Email: huiyu@huawei.com