One document matched: draft-greevenbosch-mmusic-signal-3d-format-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC2119 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3264 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC4566 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC5226 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5888 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.5888.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-greevenbosch-mmusic-signal-3d-format-01">
<front>
<title>Signal 3D format</title>
<author initials="B." surname="Greevenbosch" fullname="Bert Greevenbosch">
<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>Huawei Industrial Base</street>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone>+86-755-28978088</phone>
<email>bgreeven@huawei.com</email>
</address>
</author>
<author initials="Y." surname="Hui" fullname="Hui Yu">
<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>Huawei Nanjing R&D Center</street>
<street>101 Software Avenue</street>
<street>Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>P.R. China</country>
</postal>
<phone>+86-25-56620323</phone>
<email>huiyu@huawei.com</email>
</address>
</author>
<date month="May" year="2011"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>mmusic</workgroup>
<abstract>
<t>
This document introduces the SDP attribute "3dFormat",
which provides format description of stereoscopic 3D video.
In addition,
the grouping mechanism for SDP is extended to cater for stereoscopic 3D video.
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested,
and should be sent to mmusic@ietf.org.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
In stereoscopic 3D multimedia applications,
two views are displayed,
one for the left eye and one for the right eye.
</t>
<t>
There are various ways of formatting the views of Stereoscopic 3D video.
Examples of 3D formats are frame packing (see <xref target="HDMIv1.4a"/>)
and the combination of 2D video and auxiliary data such as depth maps
(see <xref target="ISO/IEC 23002-3"/>).
Stereoscopic 3D video may be carried over a single stream or over several streams,
depending on its 3D format.
</t>
<t>
In multimedia streaming applications,
the Session Description Protocol (SDP) <xref target="RFC4566"/>
can be used to provide to the receiver sufficient information about the media streams,
and to enable the receiver to join and participate in the session.
</t>
<t>
This document defines an extension to SDP that provides sufficient information about the format of stereoscopic 3D video carried in the media stream(s).
Before accessing the stream(s),
the receiver can use the 3D format description from SDP to determine whether it has the capability to receive and render the stereoscopic 3D video content,
and whether it can participate in the session.
</t>
<t>
The mentioned SDP extension is a new SDP attribute "3dFormat",
which provides the format description of stereoscopic 3D video.
The design of the attribute is based on the following requirements,
which are listed only for informational purposes:
<list style="symbols">
<t>
It MUST be possible to signal that the left and right views are carried in a single stream,
by the use of frame packing.
</t>
<t>
It MUST be possible to signal that 2D video and auxiliary video (such as depth maps) are carried in a single stream.
</t>
<t>
It MUST be possible to signal that the left and right views are carried in two separate streams.
</t>
<t>
It MUST be possible to signal that 2D video and auxiliary video (such as depth maps) are carried in separate streams.
</t>
</list>
</t>
<t>
To bind multiple video streams that carry a single stereoscopic 3D video,
this document also extends the SDP grouping mechanism from <xref target="RFC5888"/>.
</t>
</section>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "MUST",
"MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Definitions">
<t>
<list style="hanging">
<t hangText="2D video"><vspace/>
Video that does not in itself contain depth or parallax information.
</t>
<t hangText="auxiliary video"><vspace/>
A sequence of depth or parallax maps,
which are used to add depth to 2D video.
</t>
<t hangText="C-view"><vspace/>
The centre view:
a visual entity as seen from a viewpoint between the left and right eyes.
The C-view can be used to calculate the L- and R-views.
</t>
<t hangText="C-stream"><vspace/>
A 2D video stream consisting of a sequence of C-views.
</t>
<t hangText="depth map"><vspace/>
A two dimensional map,
each pixel of which defines the depth of one or more pixels in an associated 2D video frame.
</t>
<t hangText="depth map stream"><vspace/>
An auxiliary stream,
which contains a sequence of depth maps.
The depth map stream is synchronised with the associated 2D video stream.
</t>
<t hangText="frame packing"><vspace/>
A format that packs the L- and R-views into a single 2D video stream.
The packing may be done spatially,
where each video frame is divided into sub-frames,
one containing the L-view and one containing the R-view.
The packing can also be done sequentially,
where alternating video frames represent L- and R-views.
</t>
<t hangText="legacy answerer"><vspace/>
An answerer
(in the SDP offer/answer model <xref target="RFC3264"/>)
that does not support the "3dFormat" attribute.
The legacy answerer can be the streaming server or the streaming client,
but is not compliant to this document.
</t>
<t hangText="L-view"><vspace/>
A visual entity that is to be projected to the left eye.
</t>
<t hangText="L-stream"><vspace/>
A 2D video stream consisting of a sequence of L-views.
</t>
<t hangText="parallax map"><vspace/>
A two dimensional map,
each pixel of which defines the parallax of one or more pixels in an associated 2D video frame.
</t>
<t hangText="parallax map stream"><vspace/>
An auxiliary stream,
which contains a sequence of parallax maps.
The parallax map stream is synchronised with the associated 2D video stream.
</t>
<t hangText="R-view"><vspace/>
A visual entity that is to be projected to the right eye.
</t>
<t hangText="R-stream"><vspace/>
A 2D video stream consisting of a sequence of R-views.
</t>
<t hangText="stereoscopic 3D video"><vspace/>
The L- and R-streams,
ready to be projected to the viewer's left and right eyes.
</t>
<t hangText="sub-frame"><vspace/>
A part of a video frame.
</t>
</list>
</t>
</section>
<section title="The "3dFormat" attribute">
<t>
The media-level SDP attribute "3dFormat" signals the format of stereoscopic 3D video.
The attribute transfers this information through two parameters:
one indicating the format type of the stereoscopic 3D video carried in the media stream(s),
and the other indicating the type of the video component,
which is a constituent element of the stereoscopic 3D video.
The video component type depends on the format type of the stereoscopic 3D video.
The syntax of the attribute is defined as follows:
</t>
<figure title="">
<artwork align="center">
a=3dFormat:<Format Type> <Component Type>
</artwork>
</figure>
<t>
The <Format Type> can have the following values
(as indicated between the quotes):
<list style="hanging">
<t hangText=""FP"">Frame Packing<vspace/>
The L- and R-views are packed into a single stream.
The packing may use a side-by-side, top-and-bottom, interleaved, checkerboard or frame sequential format.
</t>
<t hangText=""SC"">Simulcast<vspace/>
The L- and R-streams are transmitted separately.
</t>
<t hangText=""2DA"">2D + auxiliary<vspace/>
2D video and auxiliary data (such as depth maps or parallax maps) are transmitted.
These can be transmitted in a single stream,
as well as in two separate streams.
</t>
</list>
</t>
<t>
The <Component Type> can have the following values
(as indicated between the quotes):
<list style="hanging">
<t hangText=""C"">
Centre view<vspace/>
The associated stream is a C-stream.
</t>
<t hangText=""CD"">
centre view and depth map<vspace/>
The associated stream contains both the C-view and depth map sequences.
</t>
<t hangText=""ChB"">
Checkerboard<vspace/>
The video frame consists of alternating pixels from the corresponding L- and R-views,
as illustrated by <xref target="checkerboard"/>.
</t>
<t hangText=""CP"">
Centre view and parallax map<vspace/>
The associated stream contains both the C-view and parallax map sequences.
</t>
<t hangText=""D"">
Depth map<vspace/>
The associated stream is a sequence of depth maps.
</t>
<t hangText=""L"">
Left view<vspace/>
The associated stream is the L-stream.
</t>
<t hangText=""LD"">
Left view and depth map<vspace/>
The associated stream contains both the L-view and depth map sequences.
</t>
<t hangText=""LIL"">
Line Interleaved<vspace/>
Each video frame consists of alternating scan lines from the L- and R-views.
</t>
<t hangText=""LP"">
Left view and parallax map<vspace/>
The associated stream contains both the L-view and parallax map sequences.
</t>
<t hangText=""P"">
Parallax map<vspace/>
The associated stream is a sequence of parallax maps.
</t>
<t hangText=""R"">
Right view<vspace/>
The associated stream is the R-stream.
</t>
<t hangText=""SbS"">
Side by Side<vspace/>
Each video frame is divided in two equally sized sub-frames,
spatially positioned side by side of each other.
One sub-frame contains the L-view,
whereas the other contains the R-view.
</t>
<t hangText=""Seq"">
Frame sequential<vspace/>
The single video stream consists of alternating frames from the L- and R-streams.
</t>
<t hangText=""TaB"">
Top and Bottom<vspace/>
Each video frame is divided in two equally sized sub-frames,
spatially positioned above each other.
One sub-frame contains the L-view,
whereas the other contains the R-view.
</t>
</list>
</t>
<figure anchor="checkerboard">
<artwork align="center">
+-+-+-+-+-+-+
|L|R|L|R|L|R|
+-+-+-+-+-+-+
|R|L|R|L|R|L|
+-+-+-+-+-+-+
|L|R|L|R|L|R|
+-+-+-+-+-+-+
</artwork>
<postamble>
The checkerboard pattern.
The transmitted video frame is composed of pixels from the L- and R-views.
Samples from the L-view are indicated with "L",
whereas samples from the R-view are indicated with "R".
</postamble>
</figure>
</section>
<section title="Grouping">
<t>
When multiple streams carry a single stereoscopic 3D video,
(e.g. C-stream and parallax map, or separately transmitted L- and R-streams),
the grouping mechanism from <xref target="RFC5888"/> MUST be used.
</t>
<t>
However,
to cater for the special requirements of 3D signalling,
the semantics are expanded:
</t>
<figure title="">
<artwork align="center">
group-attribute = "a=group:" semantics *(SP identification-tag)
semantics = "LS" / "FID" / "3DS" / semantics-extension
semantics-extension = token
</artwork>
</figure>
<t>
The grouping is needed when multiple streams carry a single stereoscopic 3D video.
This is the case when the <format type> is "SC",
or the <format type> is "2DA" and the 2D video and auxiliary data are transmitted as multiple streams.
A group with the "3Ds" semantics is called a "3DS group".
</t>
<t>
A 3DS group MUST NOT contain data that is (potentially) inconsistent with other data in the 3DS group:
<list style="symbols">
<t>
A 3DS group MUST NOT contain both a parallax map stream and a depth map stream.
</t>
<t>
A 3DS group MUST NOT contain more than one parallax map stream.
</t>
<t>
A 3DS group MUST NOT contain more than one depth map stream.
</t>
<t>
A 3DS group MUST contain at least one 2D video stream.
</t>
<t>
If a 3GS group contains an L- and an R-stream,
it MUST NOT contain a depth map or a parallax map.
</t>
<t>
If a 3DS group contains only one 2D video stream,
it MUST also contain a parallax map stream or a depth map stream.
</t>
<t>
If a 3DS group contains a parallax map stream or a depth map stream,
it MUST also contain a 2D video stream.
</t>
</list>
</t>
</section>
<section title="Combinations of attribute values and group usage">
<t>
The following table summarises the possible combinations of attribute values and grouping:
</t>
<texttable title="">
<ttcol align="center"></ttcol>
<ttcol align="center">FP</ttcol>
<ttcol align="center">SC</ttcol>
<ttcol align="center">2DA</ttcol>
<c>C</c>
<c></c>
<c></c>
<c>D/P,3DS</c>
<c>CD</c>
<c></c>
<c></c>
<c>T</c>
<c>ChB</c>
<c>T</c>
<c></c>
<c></c>
<c>CP</c>
<c></c>
<c></c>
<c>T</c>
<c>D</c>
<c></c>
<c></c>
<c>C/L,3DS</c>
<c>L</c>
<c></c>
<c>R,3DS</c>
<c>D/P,3DS</c>
<c>LD</c>
<c></c>
<c></c>
<c>T</c>
<c>LIL</c>
<c>T</c>
<c></c>
<c></c>
<c>LP</c>
<c></c>
<c></c>
<c>T</c>
<c>P</c>
<c></c>
<c></c>
<c>C/L,3DS</c>
<c>R</c>
<c></c>
<c>L,3DS</c>
<c></c>
<c>SbS</c>
<c>T</c>
<c></c>
<c></c>
<c>Seq</c>
<c>T</c>
<c></c>
<c></c>
<c>TaB</c>
<c>T</c>
<c></c>
<c></c>
</texttable>
<t>
The table is to be read as follows:
<list style="symbols">
<t>
The columns indicate <Format Type> values,
whereas the rows indicate <Component Type> values.
</t>
<t>
For one particular column,
we denote the <Format Type> value by "FT"
and the <Component Type> value by "CT".
</t>
<t>
When an entry in the table is empty,
it means that the corresponding combination of FT and CT is not allowed.
</t>
<t>
When an entry in the table contains a single <Component Type> value CTsec,
it means that another stream with the <Component Type> value CTsec and the same <Format Type> value FT is needed.
</t>
<t>
When multiple <Component Type> values are listed,
separated by a "/" symbol,
only one secondary stream is needed,
which must have one of the listed <Component Type> values,
and the same <Format Type> value FT.
</t>
<t>
When an entry contains "3DS",
it means that a 3DS group is needed.
</t>
<t>
When an entry in the table contains the letter "T" (true),
it means that the corresponding combination FT and CT is allowed,
that there is no required secondary stream,
and that a 3DS group is not needed.
</t>
</list>
</t>
</section>
<section title="SDP offer/answer with 3D support" anchor="sdpoffans">
<t>
This section describes how the SDP offer/answer model (see <xref target="RFC3264"/>) can be used to negotiate the 3D format.
It is assumed that both offerer and answerer are compliant to this document.
The case where the answerer is a legacy answerer is described in <xref target="backcomp"/>.
</t>
<t>
An example where the SDP offer/answer model can be used to negotiate the 3D format,
is the case where the offerer offers two representations of the same stereoscopic 3D video:
one frame packed and one as L/R simulcast.
In this case,
the answerer can select the format of its preference,
according to its capabilities or as a trade-off between bandwidth and video quality.
</t>
<t>
There may also be cases where the answerer prefers to receive a 2D version,
even when it supports stereoscopic 3D video and the "3dFormat" attribute.
For example,
this might happen when the user prefers to watch without glasses this time.
</t>
<t>
The following statements apply for the answerer:
<list style="symbols">
<t>
The answerer MUST NOT omit the "3dFormat" attribute for the accepted streams.
The answerer MAY omit the "3dFormat" attribute for the rejected streams.
</t>
<t>
The answerer MUST NOT change the value of the "3dFormat" attribute.
This means,
that the answerer can only choose between the 3D formats advertised in the offer.
</t>
<t>
In case the offer contains simulcast of the L- and R-view,
the answerer MAY choose just one view.
In this case, it MUST select only that view.
This means that the port number of unselected view MUST be set to zero in the answer.
</t>
<t>
In case the offer contains a 2D stream and an auxiliary stream as separate streams,
the answerer MAY choose only the 2D stream.
In this case, it MUST select the 2D stream,
and MUST NOT select the auxiliary stream.
This means that the port number of the auxiliary stream MUST be set to zero in the answer.
</t>
<t>
In case the offer contains a 2D stream and an auxiliary stream as a single stream,
the answerer MAY choose to reject the stream by setting the port number in the answer to zero.
</t>
<t>
In case of frame packing,
if the answerer prefers not to have frame packing,
it MUST reject the stream by setting the port number in the answer to zero.
</t>
<t>
The answerer SHOULD select only one 3D format.
If the answerer has no preference on the offered 3D formats,
it is RECOMMENDED that it selects the one that is first listed in the offer.
</t>
<t>
If the answerer selects multiple 3D formats,
it MUST be prepared to send/receive
(depending on whether it is a streaming server or client or both)
associated streams simultaneoulsy.
</t>
</list>
</t>
<t>
The following statements apply for the offerer:
<list style="symbols">
<t>
The offerer MUST check if the "3dFormat" attribute is included in the answer.
If it is not,
it SHOULD handle the answer as described in <xref target="backcomp"/>.
</t>
<t>
The offerer SHOULD list the 3D formats in order of preference.
</t>
<t>
When multiple 3D formats are selected,
the offerer MAY initiate all associated streams.
Alternatively,
it MAY update its offer with a reduced number of 3D formats.
</t>
<t>
If all 3D formats have been rejected,
the offerer MAY issue a new offer with 2D video instead.
</t>
<t>
If only an auxiliary stream is selected in the answer,
the offerer SHOULD update its offer with only the associated 2D video stream.
Alternatively,
it MAY update its offer advertising another 3D format.
</t>
</list>
</t>
</section>
<section title="SDP offer/answer without 3D support" anchor="backcomp">
<t>
The legacy answerer may reject the offer.
For example,
with SIP (see <xref target="RFC3261"/>),
it could send an "SIP 488 Not acceptable here" error with a "306 Attribute not understood" warning code.
In this case the offerer MAY send a new offer with only a 2D video stream.
</t>
<t>
On the other hand, it is also possible that the legacy answerer accepts the offer and omits the "3dFormat" attribute in the answer.
In this case the "3dFormat" attribute is omitted in the answer but the associated stream was accepted (see <xref target="RFC3264"/>),
the offerer is able to deduct that the answerer is a legacy answerer without 3D support.
In the following subsections,
we describe what the offerer still can do to provide a good user experience with a legacy answerer,
for each of the 3D format styles.
We assume that the offer was accepted,
but a legacy answerer was detected.
</t>
<section title="Frame packing">
<t>
In case the original offer contains frame packing,
and the answer does not contain the "3dFormat" attribute,
the offerer MAY update the offer with a 2D stream.
If the offerer is the streaming server,
it MAY choose to stream the frame packed video as it is.
</t>
</section>
<section title="2D and auxiliary as a single stream">
<t>
If the original offer contains a 2D video and an auxiliary video in a single stream,
and the answer does not contain the "3dFormat" attribute,
the offerer MAY update its offer by offering only a 2D video stream.
</t>
</section>
<section title="2D and auxiliary as two separate streams">
<t>
When the offerer sends an offer to a legacy answerer,
and the offer contains a 2D video and an auxiliary video in two separate streams,
there are the following possibilities:
<list style="symbols">
<t>
If the answerer selects only the 2D video steam
then 2D video streaming can be done as agreed.
</t>
<t>
If the answerer selects only the auxiliary video,
the offerer SHOULD update its offer without the auxiliary video.
</t>
<t>
If the answerer selects both video streams,
but omits the "3dFormat" attribute,
the offerer MAY update its offer without the auxiliary video.
</t>
</list>
In case the offerer updates its offer by setting the port for auxiliary video to zero,
it MUST NOT include the "3dFormat" attribute or use "3DS" grouping for the 2D stream.
</t>
</section>
<section title="Simulcast of L- and R-views">
<t>
When the offerer sends an offer to simulcast the L- and R-view to the legacy answerer,
we have the following possibilities:
<list style="symbols">
<t>
If the answerer selects only one video stream,
the offerer MAY stream the 2D video as agreed.
</t>
<t>
If the answerer selects both video streams,
but omits the "3dFormat" attribute,
the offerer MAY update its offer with only the L- or the R-stream.
</t>
</list>
In case the offerer updates its offer with only the L- or R-stream by setting one of the ports to zero,
it MUST NOT include the "3dFormat" attribute or use "3DS" grouping for the offered stream.
</t>
</section>
</section>
<section title="Examples">
<section title="One single frame compatible stream">
<t>
The following is an example of an SDP description of a session
which contains a single stream,
in which the L- and R-streams are packed,
in side by side fashion.
</t>
<figure title="">
<artwork align="center">
v=0
o=Alice 2890844526 2890842807 IN IP4 131.163.72.4
s=The technology of 3D-TV
c=IN IP4 131.164.74.2
t=0 0
m=video 49170 RTP/AVP 99
a=rtpmap:99 H264/90000
a=3dFormat:FP SbS
m=audio 52890 RTP/AVP 10
a=rtpmap:10 L16/16000/2
</artwork>
</figure>
</section>
<section title="Two separate streams">
<t>
The following is an example of an SDP description of a session with
an audio stream, an L-stream and an R-stream.
</t>
<figure title="">
<artwork align="center">
v=0
o=Alice 2890844526 2890842807 IN IP4 131.163.72.4
s=The technology of 3D-TV
c=IN IP4 131.164.74.2
t=0 0
a=group:3DS 1 2
m=video 49170 RTP/AVP 99
a=rtpmap:99 H264/90000
a=3dFormat:SC L
a=mid:1
m=video 49172 RTP/AVP 101
a=rtpmap:101 H264/90000
a=3dFormat:SC R
a=mid:2
m=audio 52890 RTP/AVP 10
a=rtpmap:10 L16/16000/2
</artwork>
</figure>
</section>
<section title="C-stream and depth map stream" anchor="depthMapEx">
<t>
The following is an example of an SDP description of a session with
an audio stream, a C-stream and a depth map stream.
</t>
<figure title="">
<artwork align="center">
v=0
o=Alice 2890844526 2890842807 IN IP4 131.163.72.4
s=The technology of 3D-TV
c=IN IP4 131.164.74.2
t=0 0
a=group:3DS 1 2
m=video 49170 RTP/AVP 99
a=rtpmap:99 H264/90000
a=3dFormat:2DA C
a=mid:1
m=video 49172 RTP/AVP 101
a=rtpmap:101 H264/90000
a=3dFormat:2DA D
a=mid:2
m=audio 52890 RTP/AVP 10
a=rtpmap:10 L16/16000/2
</artwork>
</figure>
</section>
<section title="Stereoscopic 3D video with two different formats">
<t>
In the following example,
there are two different formats for stereoscopic 3D video.
One consists of stream 1 (C-stream) and stream 2 (parallax map stream),
whereas the other consists of stream 3 (L-stream) and stream 4 (R-stream).
There also is an audio stream,
which can be used with both formats.
</t>
<figure title="">
<artwork align="center">
v=0
o=Alice 2890844526 2890842807 IN IP4 131.163.72.4
s=The technology of 3D-TV
c=IN IP4 131.164.74.2
t=0 0
a=group:3DS 1 2
a=group:3DS 3 4
m=video 49170 RTP/AVP 99
a=rtpmap:99 H264/90000
a=3dFormat:2DA C
a=mid:1
m=video 49172 RTP/AVP 101
a=rtpmap:101 H264/90000
a=3dFormat:2DA P
a=mid:2
m=video 49174 RTP/AVP 103
a=rtpmap:103 H264/90000
a=3dFormat:SC L
a=mid:3
m=video 49176 RTP/AVP 105
a=rtpmap:105 H264/90000
a=3dFormat:SC R
a=mid:4
m=audio 52890 RTP/AVP 10
a=rtpmap:10 L16/16000/2
</artwork>
</figure>
</section>
</section>
<section title="Formal ABNF grammar of the "3dFormat" attribute">
<t>
This section contains the formal ABNF grammar of the "3dFormat" attribute.
</t>
<figure title="">
<artwork align="center">
3dFormat-attribute = "a=3dFormat:" formatType componentType
formatType = "FP"/"SC"/"2DA"/formatType-extension
formatType-extension = token
componentType = "C"/"CD"/"ChB"/"CP"/"D"/"L"/"LD"/
"LIL"/"LP"/"P"/"R"/"SbS"/"Seq"/"TaB"/
componentType-extension
componentType-extension = token
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>
The authors foresee no security issues in addition to those already listed in <xref target="RFC4566"/>.
</t>
</section>
<section title="IANA Considerations">
<section title=""3dFormat" attribute">
<t>
Following the guidelines in <xref target="RFC4566"/>,
the SDP attribute has to be registered at IANA:
</t>
<t>
<list style="symbols">
<t>
Contact name/email: authors of this RFC
</t>
<t>
Attribute name: 3dFormat
</t>
<t>
Long-form attribute name:
Attribute for signalling the format of a stereoscopic 3D video carried in the media stream(s).
</t>
<t>
Type of attribute: media level
</t>
<t>
Subject to charset: no
</t>
</list>
</t>
<t>
The "3dFormat" SDP media-level attribute is used to signal the format of stereoscopic 3D video,
carried in one or more media stream(s).
</t>
<t>
The attribute has the following syntax:
</t>
<figure title="">
<artwork align="center">
a=3dFormat:<Format Type> <Component Type>
</artwork>
</figure>
<t>
The <Format Type> indicates the format type of the stereoscopic 3D video carried in the media stream(s).
It indicates whether the stereoscopic 3D video is frame packed,
simulcast or consists of a 2D video stream and an auxiliary stream.
The <Format Type> can have the following values (as indicated between the quotes):
</t>
<figure title="">
<artwork align="left">
"FP" frame packed
"SC" simulcast
"2DA" 2D + auxiliary
</artwork>
</figure>
<t>
The <Component Type> indicates the type of the video component,
which is a constituent element of the stereoscopic 3D video.
It can have the following values:
<figure title="">
<artwork align="left">
"C" centre view
"CD" centre view and depth map
"ChB" checkerboard
"CP" centre view and parallax map
"D" depth map
"L" left view
"LD" left view and depth map
"LIL" line interleaved
"LP" left view and parallax map
"P" parallax map
"R" right view
"SbS" side by side
"Seq" frame sequential
"TaB" top and bottom
</artwork>
</figure>
</t>
</section>
<section title=""3DS" value for "group" semantics">
<t>
Following the standards action policy from <xref target="RFC5226"/>,
the following semantics have to be registered with IANA in the
"Semantics for the "group" SDP Attribute" registry under "SDP Parameters":
</t>
<texttable title="">
<ttcol align="center">Semantics</ttcol>
<ttcol align="center">Token</ttcol>
<ttcol align="center">Reference</ttcol>
<c>3D synchronised</c>
<c>3DS</c>
<c>this RFC</c>
</texttable>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="HDMIv1.4a">
<front>
<title>HDMI Specification Version 1.4a </title>
<author>
<organization>HDMI</organization>
</author>
<date day="4" month="March" year="2010"/>
</front>
</reference>
<reference anchor="ISO/IEC 23002-3">
<front>
<title>MPEG video technologies part 3: Representation of auxiliary video and supplemental information</title>
<author>
<organization>MPEG</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="ISO/IEC FDIS" value="23002-3:2007(E)"/>
</reference>
&RFC2119;
&RFC3261;
&RFC3264;
&RFC4566;
&RFC5226;
&RFC5888;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:00:22 |