Internet DRAFT - draft-capelastegui-mmusic-3dv-sdp

draft-capelastegui-mmusic-3dv-sdp






mmusic                                                   P. Capelastegui
Internet-Draft                                Universidad Politecnica de
Intended status: Standards Track                                  Madrid
Expires: November 1, 2012                                 April 30, 2012


           3D Video in the Session Description Protocol (SDP)
                  draft-capelastegui-mmusic-3dv-sdp-00

Abstract

   This document defines a mechanism to describe 3D video streams in the
   Session Description Protocol (SDP).  This includes 3D video streams
   composed of multiple video views, or of a combination of views and
   depth maps.  Several 3D video formats are supported, including
   simulcast, video-plus-depth, and frame-packing.

   A new decoding dependency, "3dd", is defined, describing the
   association between media stream belonging to a 3D video stream.  In
   addition, a new SDP media-level attribute, "3dvFormat", is defined,
   describing the format used by media streams within a 3D video stream.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 1, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Capelastegui            Expires November 1, 2012                [Page 1]

Internet-Draft               3D Video in SDP                  April 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Decoding dependency of 3D video streams  . . . . . . . . . . .  4
   4.  The "3dvFormat" media attribute  . . . . . . . . . . . . . . .  5
     4.1.  The "depth-map-simulcast" 3D format attribute  . . . . . .  5
     4.2.  The "depth-map-metadata" 3D format attribute . . . . . . .  6
     4.3.  The "stereo-view" 3D format attribute  . . . . . . . . . .  7
     4.4.  The "frame-pack" 3D format attribute . . . . . . . . . . .  8
   5.  Usage with SDP offer/answer model  . . . . . . . . . . . . . .  9
     5.1.  Backward compatibility . . . . . . . . . . . . . . . . . . 10
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Example session with single 3D video option  . . . . . . . 10
     6.2.  Test Scenario: Multiple 3D options . . . . . . . . . . . . 11
   7.  Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  "3dvFormat media attribute . . . . . . . . . . . . . . . . 13
     7.2.  "depth-map-simulcast" 3D format attribute  . . . . . . . . 13
     7.3.  "depth-map-metadata" 3D format attribute . . . . . . . . . 13
     7.4.  "stereo-view" 3D format attribute  . . . . . . . . . . . . 13
     7.5.  "frame-pack" 3D format attribute . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15


















Capelastegui            Expires November 1, 2012                [Page 2]

Internet-Draft               3D Video in SDP                  April 2012


1.  Introduction

   3D video applications convey depth information by showing a different
   view for each eye of a user.  In order to achieve this, 3D video
   streams need to include additional information compared to
   conventional 2D video streams, either in the form of extra views, or
   auxiliary maps such as depth maps , or a combination thereof.  These
   views and maps can be transported in a variety of ways, including,
   among others: as separate RTP streams (simulcast), frame-packed in a
   single video stream [HDMIv1.4a], or using the video-plus-depth format
   [ISO/IEC 23002-3].

   The Session Description Protocol (SDP) [RFC4566] lacks the means to
   describe neither of these transport techniques for 3D video.  This
   document extends SDP to support the description of multimedia
   sessions using 3D video encapsulated as simulcast streams, using
   frame-packing techniques, or using the video-plus-depth format.

   [RFC5583] defines a mechanism to signal the decoding dependency of
   media descriptions in SDP.  This document extends that mechanism by
   defining a new SDP decoding dependency type, '3dd', describing the
   association between media streams belonging to a 3D video stream.  In
   addition, a new SDP media-level attribute, '3dvFormat', is defined to
   describe the format used by media streams composing a 3D video
   stream.  Several formats for 3D video are described in this
   specification, including simulcast stereo video, simulcast video and
   depth map, various frame-packing schemes, and streams using video-
   plus-depth.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Definitions

   3D video stream:  A video stream that conveys depth information by
                     showing different perspectives of a scene to each
                     eye of an observing user.  A 3D video stream is
                     typically composed of multiple video streams
                     ('views'), or a combination of video streams and
                     auxiliary data maps such as depth maps







Capelastegui            Expires November 1, 2012                [Page 3]

Internet-Draft               3D Video in SDP                  April 2012


   2D video stream:  A video stream that lacks 3D depth information.
   View:             A video stream that represents a specific point of
                     view of the scene in a 3D video stream.
   Depth Map:        An auxiliary data stream that associates a Z-value
                     to each pixel of a view within a 3D video stream.
                     Depth maps are often encoded as grey scale video
                     streams.
   Simulcast:        A method for the transmission of 3D video streams
                     that consists on sending additional views and
                     auxiliary data streams as a separate RTP streams.
   Video-plus-depth: (also known as MPEG-C Part 3) A method for the
                     transmission of 3D video streams consisting on
                     encapsulating a depth map as metadata within a 2D
                     video stream.  This mechanism, standardized in
                     [ISO/IEC 23002-3], is compatible with MPEG-2 and
                     H.264/AVC, and allows for backwards compatibility.
   Frame-packing:    A method for the transmission of 3D video streams
                     that consists on multiplexing several views and/or
                     auxiliary data within a single video stream, using
                     either spatial multiplexing or time multiplexing.
                     Frame-packing is supported by standards like
                     [HDMIv1.4a] and [ITU-T H.264].


3.  Decoding dependency of 3D video streams

   The "depend" SDP attribute, defined in [RFC5583] describes the
   decoding dependency between two or more media descriptions.  This
   specification defines a new dependency type for the "depend"
   attribute:

   o  3dd: 3D video dependency - indicates that the described media
      stream belongs to a 3D video stream, and requires other media
      streams to render the 3D video.  When "3dd" is used, all required
      media streams for the Operation Point MUST be identified by
      identification-tag and fmt-dependency following the "3dd" string.

   Like other dependency types, 3dd is used in combination with the
   "DDP" grouping semantic, which is defined in [RFC5583], and based on
   the SDP grouping framework [RFC5888].  Whenever a 3D video stream is
   composed of multiple media descriptions, these media descriptions
   MUST be included in the same DDP group.

   The media decoding dependency terminology defined in [RFC5583] can be
   applied to 3D video streams as follows:






Capelastegui            Expires November 1, 2012                [Page 4]

Internet-Draft               3D Video in SDP                  April 2012


   o  Media Bitstream: A 3D video stream is considered a Media Bitstream
      for the purposes of 3dd decoding dependency.
   o  Media Partition: Each separate media description composing a 3D
      video stream is considered a Media Partition.  Note that each
      Media Partition usually contains a single video view or depth map,
      but can also include multiple of views/maps, e.g. when using
      frame-packing techniques.
   o  Operation Point: A subset of a 3D Media Bitstream that includes
      all Media Partitions required for reconstruction at a certain
      point of quality, number of views or depth maps, or other
      property.  Note that a valid Operation Point for a 3D Media
      Bitstream can be a 2D video lacking any depth information.


4.  The "3dvFormat" media attribute

      a=3dvFormat:<fmt> <attribute>:<value>

   This section defines a new media-level attribute for SDP,
   "3dvFormat", which can be used to describe the transport format of a
   media stream in a 3D video stream.  This attribute can indicate that
   a media description corresponds to a specific view within a 3D
   stream, or to a depth map, or to a combination of views or depth maps
   encapsulated with frame-packing techniques or with the video-plus-
   depth mechanism.

   A media description can have multiple "3dvFormat" attributes; each
   attribute is mapped to a media format specified for the media,
   indicated by <fmt>.  Only one "3dvFormat" attribute is allowed per
   media format.

   Each "3dvFormat" attribute indicates a property (known as a "3D
   format attribute") associated to a media format of its media
   description.  The 3D format attribute consists on an attribute-value
   pair, with the form "<attribute>:<value>".  This specification
   defines four 3D format attributes: "depth-map-simulcast", "depth-map-
   metadata", "stereo-view", "and frame-pack".

   New 3D format attributes can be defined, but they MUST be registered
   with IANA, following the registry described in Section 9.

4.1.  The "depth-map-simulcast" 3D format attribute

      a=3dvFormat:<fmt> depth-map-simulcast:<associated_video>

   The 3D format attribute "depth-map-simulcast" indicates that a media
   stream represents a depth map associated with a view within the same
   3D video stream.  A depth map described by this attribute is



Capelastegui            Expires November 1, 2012                [Page 5]

Internet-Draft               3D Video in SDP                  April 2012


   transmitted as a separate transport stream from its corresponding
   view.

   <associated-video> is the media stream identification (the "a=mid"
   attribute, as defined in [RFC5888]) of the video stream associated
   with this depth map.

   A media description with the "depth-map-simulcast" 3D format
   attribute MUST be included in a DDP group.  This group MUST include a
   video stream representing the view associated with the depth map.
   Finally, the depth map media description MUST include a "depend"
   attribute with the "3dd" dependency type, indicating dependency to
   one or more media formats within that video stream.

   Example:

      a=group:DDP 1 2
      m=video 1111 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=mid:1
      m=video 1112 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 depth-map-simulcast:1
      a=mid:2
      a=depend:99 3dd 1:99

   The example shows two media descriptions forming a 3D video stream,
   of which the first one (mid:1) represents a video view, and the
   second one (mid:2) the depth map for that view.  The depth map cannot
   be used without its corresponding view, and this is reflected in the
   "depend" attribute.

4.2.  The "depth-map-metadata" 3D format attribute

      a=3dvFormat:<fmt> depth-map-metadata:<associated_video>

   The 3D format attribute "depth-map-metadata" indicates that a media
   stream represents a depth map associated with a view within the same
   3D video stream.  A depth map described by this attribute is
   transmitted as part of the same transport stream as its corresponding
   view, in the form of metadata.  If the view associated with this
   depth map is a MPEG-2 or H.264/AVC video stream, the depth map
   follows the format defined in MPEG-C part 3 [ISO/IEC 23002-3].

   <associated-video> is the media stream identification (the "a=mid"
   attribute, as defined in [RFC5888]) of the video stream associated
   with this depth map.




Capelastegui            Expires November 1, 2012                [Page 6]

Internet-Draft               3D Video in SDP                  April 2012


   A media description with the "depth-map-simulcast" 3D format
   attribute MUST be included in a DDP group.  This group MUST include a
   video stream representing the view associated with the depth map.
   Finally, the depth map media description MUST include a "depend"
   attribute with the "3dd" dependency type, indicating dependency to
   that video stream.

   It is important to note that, when a media format with a "depth-map-
   metadata" is used, the transport information for that media stream
   such as port, connection address or transport protocol MUST be
   ignored.  In this case, the depth map is transmitted as part of the
   media stream of its associated view, rather than as a separate
   stream.

   Example:

      a=group:DDP 1 2
      m=video 1111 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=mid:1
      m=video 1112 RTP/AVP 99 100
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 depth-map-simulcast:1
      a=rtpmap:100 H264/90000
      a=3dvFormat:100 depth-map-metadata:1
      a=mid:2
      a=depend:99 3dd 1:99; 100 3dd 1:99

   The example shows two media descriptions forming a 3D video stream,
   of which the first one (mid:1) represents a video view, and the
   second one (mid:2) the depth map for that view.  Two possible
   configurations for the depth map are offered, one using simulcast
   (payload type 99), and the other transmitting the depth map as
   metadata (payload type 100).  If the depth map stream is configured
   as metadata, the port specified in that media description (1112) will
   be ignored, since the depth map will be transmitted within the video
   view stream.  On the other hand, if the simulcast option is used, the
   depth map will be transmitted as a separate stream using the
   specified port and transport, as usual.

4.3.  The "stereo-view" 3D format attribute

      a=3dvFormat:<fmt> stereo-view:<view-type>

   The 3D format attribute "stereo-view" indicates whether a video
   stream is associated with the left-eye view or the right-eye view of
   a stereo 3D video stream.




Capelastegui            Expires November 1, 2012                [Page 7]

Internet-Draft               3D Video in SDP                  April 2012


   <view-type> indicates which view is associated with the media stream.
   It can have the value "left", for the left-eye view, or "right", for
   the right-eye view.

   A media description with the "stereo-view" 3D format attribute MUST
   be included in a DDP group.  This group MUST also include another
   video stream containing the "stereo-view" 3D format attribute with
   the other stereo view as value.  The media description for either of
   the two stereo views MUST include a "depend" attribute with the "3dd"
   dependency type, indicating dependency to the stream corresponding to
   the other view.

   Example:

      a=group: DDP 1 2
      m=video 1111 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 stereo-view:left
      a=mid:1
      m=video 1112 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 stereo-view:right
      a=mid:2
      a=depend:99 3dd 1:99

   The example shows two media descriptions forming a stereo 3D video
   stream, of which the first one (mid:1) represents the left view, and
   the second one (mid:2) the right view.  This Media Bitstream can be
   configured as a 3D video stream composed of two stereo views, or as a
   2D video stream including just the left eye view.

4.4.  The "frame-pack" 3D format attribute

   a=3dvFormat:<fmt> frame-pack:<fp-format>

   The 3d attribute indicates that frame-packing mechanisms are used in
   a media stream, for the specified media format.

   <fp-format> signals which frame-packing mode is applied.  It has
   three possible values: "side-by-side", "top-bottom", and "frame-seq".

   Of these frame-pack modes, the first two are based on spatial
   multiplexing, or dividing each video frame in the stream into two
   sub-frames, and assigning one view to each sub-frame.  In "side-by-
   side" mode, the left sub-frame corresponds to the left eye view, and
   the right sub-frame to the right eye view.  In "top-bottom" mode, the
   top sub-frame corresponds to the left eye view, and the lower sub-
   frame to the right eye view.



Capelastegui            Expires November 1, 2012                [Page 8]

Internet-Draft               3D Video in SDP                  April 2012


   On the "frame-seq" (frame sequential) frame-packing mode, time
   multiplexing is used, so that half the video frames in a stream
   correspond to the left eye view, and the other half to the right eye
   view, in alternating order.  In order to identify which frame
   corresponds to each view, additional signalling is required; in
   H.264/AVC video streams, this is achieved through supplemental
   enhancement information (SEI) metadata [ITU-T H.264].


5.  Usage with SDP offer/answer model

   When the extensions defined in this specification are used in the SDP
   offer/answer model [RFC3264], the following rules apply.

   The offerer MAY include more than one "3dvFormat" attribute per media
   description, and the values of these "3dvFormat" can be different or
   duplicated.  However, each media format MUST NOT have more than one
   "3dvFormat" attribute.

   If the offerer includes a 3D video stream composed of more than one
   media description, all media descriptions in the stream MUST be
   included in a DDP group.  If the 3D video stream includes streams
   with 3D format attributes whose description specifies any stream
   requirements or mandatory dependencies, those requirements or
   dependencies MUST be respected.  Each 3D video stream in the offer
   SHOULD have at least one Operation Point consisting on a single 2D
   video stream, as well as any number of Operation Points with 3D
   video.

   An answer MUST NOT include any "3dvFormat" attribute that is not
   present in the offer.

   When a media format in an offered media description has a "3dvFormat"
   attribute, if the answer contains that media format it MUST also
   include the "3dvFormat" attribute, with the same parameters as the
   offer.

   To simplify the processing of 3D video configurations, when the
   answer includes a "3dvFormat" attribute in a media description, the
   same RTP payload type number used in the offer should also be used in
   the answer, and the answer MUST NOT include more than one media
   format for that media description.

   If the answerer understands the DDP semantics, it is necessary to
   take the "depend" attribute into consideration in the Offer/Answer
   procedure, as indicated in [RFC5583]





Capelastegui            Expires November 1, 2012                [Page 9]

Internet-Draft               3D Video in SDP                  April 2012


5.1.  Backward compatibility

   Depending on implementation, a node that does not understand DDP
   grouping or "3d" attributes SHOULD respond to an offer using this
   grouping or attributes either with a refusal to the request, or with
   an answer that ignores the grouping or 3D video format attributes.

   In case of a refused request, if the offerer has identified that the
   refusal of the request is caused by the use of 3D video, and it still
   wishes to initiate a session, it SHOULD generate a new offer without
   any 3D video streams.

   If the request is accepted but the answer is ignoring the grouping
   attribute, the "depend" attribute, or a "3dvFormat", it should be
   assumed that the answerer is unable to send or receive 3D video
   streams.  If the offerer still wishes to initiate a session, it
   SHOULD generate a new offer without any 3D video streams.
   Alternatively, if the answer does not include more than a single
   video stream, the offerer MAY initiate the session without generating
   a new offer, and send and receive that stream as a 2D video stream.


6.  Examples

   The following examples show SDP Offer/Answer exchanges for sessions
   with 3D video streams.  Only the media descriptions and grouping
   attributes of the SDP are shown.  For each example, two possible
   answers are considered: one in which the answering device is
   compatible with this specification, and one with a legacy answering
   device.

6.1.  Example session with single 3D video option

   The example shows a session where the 3D video stream is transmitted
   over a single media stream, so no grouping or decoding dependencies
   are needed for the SDP.  The calling user agent makes a SDP offer
   with 2 options for configuring the 3D video stream:

   o  2D video stream
   o  Single frame-packed video stream, with 2 views multiplexed side-
      by-side

   Offer SDP:

      m=video 1111 RTP/AVP 99 100
      a=rtpmap:99 H264/90000





Capelastegui            Expires November 1, 2012               [Page 10]

Internet-Draft               3D Video in SDP                  April 2012


      a=rtpmap:100 H264/90000
      a=3dvFormat:100 frame-pack:side-by-side

   Answer SDP:

      m=video 2222 RTP/AVP 100
      a=rtpmap:100 H264/90000
      a=3dvFormat:100 frame-pack:side-by-side

   The initial offer includes a media description with two media
   formats, with one corresponding to a 2D video stream(payload type 99)
   and the other to a frame-packed 3D video stream (payload type 100).
   Of these, the answering device chooses the frame-packed media format.

   Alternate Answer SDP (legacy device):

      m=video 2222 RTP/AVP 100
      a=rtpmap:100 H264/90000

   If this SDP offer is received by a legacy device and the session is
   not rejected, the answer will ignore any 3D video format attributes.
   In this case, the offerer can initiate the session treating the
   selected media format as a 2D video stream.

6.2.  Test Scenario: Multiple 3D options

   The example shows a session where the 3D video stream is transmitted
   over up to two media streams, and several options for the format of
   the 3D video stream are offered:

   o  2D video stream
   o  Single frame-packed video stream, with 2 views multiplexed side-
      by-side
   o  Single video stream including a depth map as metadata
   o  2 Simulcast streams, with video and depth map
   o  2 Simulcast streams, with 2 stereo views.

   Offer SDP:

      a=group:DDP 1 2
      m=video 1111 RTP/AVP 99 100
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 stereo-view:left
      a=rtpmap:100 H264/90000
      a=3dvFormat:100 frame-pack:side-by-side
      a=mid:1





Capelastegui            Expires November 1, 2012               [Page 11]

Internet-Draft               3D Video in SDP                  April 2012


      m=video 1112 RTP/AVP 99 100 101
      a=rtpmap:99 H264/90000
      a=3dvFormat:99 depth-map-metadata:1
      a=rtpmap:100 H264/90000
      a=3dvFormat:100 depth-map-simulcast:1
      a=rtpmap:101 H264/90000
      a=3dvFormat:101 stereo-view:right
      a=mid:2
      a=depend:99 3dd 1:99; 100 3dd 1:99; 101 3dd 1:99

   Answer SDP:

      a=group:DDP 1 2
      m=video 2222 RTP/AVP 99
      a=rtpmap:99 H264/90000
      a=3d:99 stereo-view:left
      a=mid:1
      m=video 2223 RTP/AVP 102
      a=rtpmap:101 H264/90000
      a=3d:101 stereo-view:right
      a=mid:2
      a=depend:101 3dd 1:99

   The initial offer includes two media descriptions, the first of which
   (mid 1) can be transmitted independently, either as a 2D video stream
   (payload type 99) or as a frame-packed 3D stream (payload type 100).
   The second media description (mid 2), on the other hand, depends on
   the first one for all its media formats, and can be configured as a
   depth map transmitted as metadata (payload type 99), as a simulcast
   depth map stream (payload type 100), or as a right-eye stereo view
   (payload-type 101).  The answering device chooses the configuration
   with 2 simulcast stereo views.

   Alternate Answer SDP (legacy device)

      m=video 2222 RTP/AVP 99
      a=rtpmap:99 H264/90000
      m=video 0 RTP/AVP 102
      a=rtpmap:101 H264/90000

   If this SDP offer is received by a legacy device and the session is
   not rejected, the answer will ignore any 3D video format attributes,
   as well as the grouping and dependency attributes.  In the example
   above, the answering device has selected a media format for the first
   video stream, and disabled the second video stream.  In this case,
   the offerer can initiate the session treating the selected media
   format as a 2D video stream.  If the second video stream had not been
   disabled, the offerer should send a new offer with a single video



Capelastegui            Expires November 1, 2012               [Page 12]

Internet-Draft               3D Video in SDP                  April 2012


   stream.


7.  Formal Grammar

   The 3d attributes defined in this document use the following
   Augmented Backus-Naur Form (ABNF) [RFC5234] grammar.

7.1.  "3dvFormat media attribute

      3dvformat-attribute = "a=3dvFormat:" fmt SP 3dvf-type
      ; fmt is described in [RFC4566]
      ; fmt is media format (usually RTP payload type)

      3dvf-type= depth-scast / depth-meta / st-view / f-pack

7.2.  "depth-map-simulcast" 3D format attribute

      depth-scast = "depth-map-simulcast:" identification-tag
      ; identification-tag is defined in [RFC5888]

7.3.  "depth-map-metadata" 3D format attribute

      depth-meta = "depth-map-metadata:" identification-tag
      ; identification-tag is defined in [RFC5888]

7.4.  "stereo-view" 3D format attribute

      st-view = "stereo-view:" view-type
      view-type= "left" / "right"

7.5.  "frame-pack" 3D format attribute

      f-pack = "frame-pack:" fp-format
      fp-format= "side-by-side" / "top-bottom" / "frame-seq"


8.  Security Considerations

   No security issues have been identified for this specification.


9.  IANA Considerations

   The following contact information shall be used for all registrations
   included here:





Capelastegui            Expires November 1, 2012               [Page 13]

Internet-Draft               3D Video in SDP                  April 2012


   Contact:  Pedro Capelastegui
   email:    Capelastegui@dit.upm.es
   tel:      +34 915 49 57 00 ext. 3024

   This document defines the following new semantics for the "depend"
   SDP attribute.  The semantics are registered by IANA under "depend"
   SDP Attribute Values under "Session Description Protocol (SDP)
   Parameters":

   Token        Semantics                  Reference
   -----        -------------------        ---------
   3dd          3D video dependency       [THIS DOC]

   This document defines a new media-level SDP attribute, "3dvFormat".
   The attribute is registered by IANA under "Session Description
   Protocol (SDP) Parameters" under "att-field (media level only)".

   Attribute name:       3dvFormat
   Long form:            3D video format
   Type of name:         att-field
   Type of attribute:    media level only
   Subject to charset:   no
   Purpose:              [THIS DOCUMENT]
   Reference:            [THIS DOCUMENT]
   Values:               see this document and registrations below

   Parameters of the "3dvFormat" SDP attribute MUST be registered under
   IANA following the "Specification Required" policy [RFC5226].  This
   document creates a new IANA registry called [REF-1] within the
   "Session Description Protocol (SDP) Parameters" registry, for that
   purpose.

   The initial entries in the registry are shown below.

    +---------------------+------------------------------+------------+
    |        Token        |          Description         |  Reference |
    +---------------------+------------------------------+------------+
    | depth-map-simulcast | depth map as separate stream | [THIS DOC] |
    |  depth-map-metadata |     depth map as metadata    | [THIS DOC] |
    |     stereo-view     |   left or right stereo view  | [THIS DOC] |
    |      frame-pack     |   frame-packed video stream  | [THIS DOC] |
    +---------------------+------------------------------+------------+


10.  Normative References

   [HDMIv1.4a]
              HDMI, "HDMI Specification Version 1.4a", March 2010.



Capelastegui            Expires November 1, 2012               [Page 14]

Internet-Draft               3D Video in SDP                  April 2012


   [ISO/IEC 23002-3]
              ISO/IEC JTC1/SC29/WG11, "ISO/IEC FDIS 23002-3
              Representation of Auxiliary Video and Supplemental
              Information", Doc. N8768, January 2007.

   [ITU-T H.264]
              HDMI, "Advanced video coding for generic audiovisual
              services", ITU-T Recommendation H.264 and ISO/
              IEC 14496-10, 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
              Dependency in the Session Description Protocol (SDP)",
              RFC 5583, July 2009.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.


Author's Address

   Pedro Capelastegui
   Universidad Politecnica de Madrid
   ETSI Telecomunicacion
   Avenida Complutense, 30
   Despacho B.203
   Madrid  28040
   Spain

   Phone: +34 915 49 57 00 ext. 3024
   Email: capelastegui@dit.upm.es




Capelastegui            Expires November 1, 2012               [Page 15]