One document matched: draft-ietf-mmusic-image-attributes-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3388 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3388.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5583.xml">
<!ENTITY rfc3016 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3016.xml">
<!ENTITY rfc3984 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3984.xml">
<!ENTITY rfc4587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4587.xml">
<!ENTITY rfc4629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4629.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mmusic-image-attributes-06"
ipr="trust200902">
<front>
<title abbrev="Image Attributes in SDP">Negotiation of Generic Image
Attributes in SDP</title>
<author fullname="Ingemar Johansson" initials="I." surname="Johansson">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Laboratoriegrand 11</street>
<city>SE-971 28 Luleå</city>
<country>SWEDEN</country>
</postal>
<phone>+46 73 0783289</phone>
<email>ingemar.s.johansson@ericsson.com</email>
</address>
</author>
<author fullname="Kyunghun Jung" initials="K." surname="Jung">
<organization>Samsung Electronics Co., Ltd.</organization>
<address>
<postal>
<street>Dong Suwon P.O. Box 105</street>
<street>416, Maetan-3Dong, Yeongtong-gu</street>
<city>Suwon-city, Gyeonggi-do</city>
<country>Korea 442-600</country>
</postal>
<phone>+82 10 9909 4743</phone>
<email>kyunghun.jung@samsung.com</email>
</address>
</author>
<date day="14" month="June" year="2010" />
<abstract>
<t>This document proposes a new generic session set up attribute to make
it possible to negotiate different image attributes such as image size.
A possible use case is to make it possible for a low-end hand-held
terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing power.
The draft also helps to maintain an optimal bitrate for video as only
the image size that is desired by the receiver is transmitted.</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>This document proposes a new attribute to make it possible to
negotiate different image attributes such as image size. The term image
size is defined here as it may differ from the physical screen size of
for instance a hand-held terminal. As an example it may be beneficial to
display a video image on a part of the physical screen and leave space
on the screen for other features such as menus and other info.</t>
<t>There are a number of benefits with a possibility to negotiate the
image size:<list style="symbols">
<t>Less image distortion: Rescaling of images introduces additional
distortion, something that can be avoided (at least on the receiver
side) if the image size can be negotiated.</t>
<t>Reduced receiver complexity: Image rescaling can be quite
computation intensive. For low end devices this can be a
problem.</t>
<t>Optimal quality for the given bitrate: The sender does not need
to encode an entire CIF (352x288) image if only an image size of
288x256 is displayed on the receiver screen. This alternatively
gives a saving in bitrate.</t>
<t>Memory requirement: The receiver device will know the size of the
image and can then allocate memory accordingly.</t>
<t>Optimal aspect ratio: The indication of the supported image sizes
and aspect ratio allows the receiver to select the most appropriate
combination based on its rescaling capabilities and the desired
rendering. For example, if a sender proposes three resolutions in
its SDP offer, 100x200, 200x100 and 100x100 with sar=1.0 (1:1) etc.
then the receiver can select the option that fits the receiver
screen best.</t>
</list></t>
<t>In cases where rescaling is not implemented (for example, rescaling
is not mandatory to implement in H.264 <xref target="H.264"></xref>),
the indication of the image attributes may still provide an optimal use
of bandwidth because the attribute will anyway give the encoder a better
indication about what image size is preferred and will thus help to
avoid wasting bandwidth by encoding with an unnecessarily large
resolution.</t>
<t>For implementers that are considering rescaling issues, it is worth
notice that there are several benefits to do it on the sender side:<list
style="symbols">
<t>Rescaling on the sender/encoder side is likely to be easier to do
as the camera related software/hardware already contains the
necessary functionality for zooming/cropping/trimming/sharpening the
video signal. Moreover, rescaling is generally done in RGB or YUV
domain and should not depend on the codecs used.</t>
<t>The encoder may be able to encode in a number of formats but may
not know which format to choose as, without the image attribute, it
does not know the receiver's performance or preference.</t>
<t>The quality drop due to digital domain rescaling using
interpolation is likely to be lower if it is done before the video
encoding rather than after the decoding especially when low bitrate
video coding is used.</t>
<t>If low-complexity rescaling operations such as simple cropping
must be performed, the benefit with having this functionality on the
sender side is that it is then possible to present a miniature "what
you send" image on the display to help the user to target the camera
correctly.</t>
</list></t>
<t>Several of the existing standards (<xref target="H.263"></xref>,
<xref target="H.264"></xref> and <xref target="MPEG-4"></xref>) have
support for different resolutions at different framerates. The purpose
of this document is to provide for a generic mechanism and is targeted
mainly at the negotiation of the image size but to make it more general
the attribute is named 'imageattr'.</t>
<t>This document is limited to unicast scenarios in general and more
specific point-to-point communication. The attribute may be used in
centralized conferencing scenarios as well but due to the abundance of
configuration options it may then be difficult to come up with a
configuration that fits all parties.</t>
<section title="Requirements">
<t>The design of the image attribute is based on the following
requirements which are listed only for informational purposes:<list
style="hanging">
<t hangText="REQ-1:">Support the indication of one or more set(s)
of image attributes that the SDP endpoint wish to receive or send.
Each image attribute set must include a specific image size.</t>
<t hangText="REQ-2:">Support set up/negotiation of image
attributes, meaning that each side in the Offer/Answer should be
able to negotiate the image attributes it prefers to send and
receive.</t>
<t hangText="REQ-3:">Interoperate with codec specific parameters
such as sprop-parameter-sets in <xref target="H.264"></xref> or
config in <xref target="MPEG-4"></xref>.</t>
<t hangText="REQ-4:">Make the attribute generic with as few codec
specific details/tricks as possible in order to be codec
agnostic.</t>
</list></t>
<t>Besides the above mentioned requirements, the requirement below may
be applicable.<list style="hanging">
<t hangText="OPT-1:">The image attribute should support the
description of image-related attributes for various types of
media, including video, pictures, images, etc.</t>
</list></t>
</section>
</section>
<section title="Conventions, Definitions and Acronyms">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="sec-definition"
title="Specification of the 'imageattr' SDP Attribute">
<t>This section defines the SDP image attribute 'imageattr', which can
be used in an SDP Offer/Answer exchange to indicate various image
attribute parameters. In this document, we define the following image
attribute parameters: image resolution, sample aspect ratio (sar),
allowed range in picture aspect ratio (par) and the preference of a
given parameter set over another (q). The attribute is extensible and
guidelines for defining additional parameters are provided in <xref
target="sec-add-params"></xref>.</t>
<section title="Attribute syntax">
<t>In this section the syntax of the 'imageattr' attribute is
described. The 'imageattr' attribute is a media-level attribute. The
section is split up in two parts, the first gives an overall view of
the syntax while the second describes how the syntax is used.</t>
<section anchor="sec-syntax-overall" title="Overall view of syntax">
<t>The syntax for the image attribute is in <xref
target="RFC5234">ABNF</xref>:</t>
<figure>
<artwork> ----
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
1*WSP attr-list )
PT = 1*DIGIT / "*"
attr-list = ( set *(1*WSP set) ) / "*"
----</artwork>
</figure>
<figure>
<artwork> ----
set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]"
; x is the horizontal image size range (pixel count)
; y is the vertical image size range (pixel count)
key-value = ( "sar=" srange )
/ ( "par=" prange )
/ ( "q=" qvalue )
; Key-value MAY be extended with other keyword parameters.
; At most one instance each of sar, par, or q in a set.
;
; sar (sample aspect ratio) is the sample aspect ratio
; associated with the set (optional and MAY be ignored)
; par (picture aspect ratio) is the allowed ratio
; between the display's x and y physical size (optional)
; q (optional with range [0.0..1.0], default value 0.5)
is the preference for the given set,
a higher value means a higher preference
</artwork>
</figure>
<figure>
<artwork> ----
onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
; Digit between 1 and 9
xyvalue = onetonine *5DIGIT
; Digit between 1 and 9 which is
; followed by 0 to 5 other digits
step = xyvalue
xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" )
; Range between a lower and an upper value
; with an optional step, default step = 1
; The rightmost occurence of xyvalue MUST have a
; higher value than the leftmost occurence.
/ ( "[" xyvalue 1*( "," xyvalue ) "]" )
; Discrete values separated by ','
/ ( xyvalue )
; A single value
spvalue = ( "0" "." onetonine *3DIGIT )
; Values between 0.1000 and 0.9999
/ ( onetonine "." 1*4DIGIT )
; Values between 1.0000 and 9.9999
srange = ( "[" spvalue 1*( "," spvalue ) "]" )
; Discrete values separated by ','.
; Each occurrence of spvalue MUST be
; greater than the previous occurrence.
/ ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive).
; The second occurence of spvalue MUST have a higher
; value than the first
/ ( spvalue )
; A single value
prange = ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive).
; The second occurence of spvalue MUST have a higher
; value than the first
qvalue = ( "0" "." 1*2DIGIT )
/ ( "1" "." 1*2("0") )
; Values between 0.00 and 1.00
----</artwork>
</figure>
<t><list style="symbols">
<t>The attribute typically contains a "send" and a "recv"
keyword. These specify the preferences for the media once the
session is set up, in the send and receive direction
respectively from the point of view of the sender of the session
description.</t>
<t>The "send" keyword and corresponding attribute list
(attr-list) MUST NOT occur more than once per image
attribute.</t>
<t>The "recv" keyword and corresponding attribute list
(attr-list) MUST NOT occur more than once per image
attribute.</t>
<t>PT is the payload type number, it MAY be set to * to indicate
that the attribute applies to all payload types in the media
description.</t>
<t>For sendrecv streams both of the send and recv directions
SHOULD BE present.</t>
<t>For inactive streams it is RECOMMENDED that both of the send
and recv directions are present.</t>
<t>For sendonly or recvonly streams one of the directions MAY be
omitted. See <xref target="sec-sendonly-recvonly"></xref>.</t>
</list></t>
<section title="Parameter rules">
<t>For the parameters the following rules apply.<list
style="hanging">
<t hangText="Payload type number (PT):">The image attribute is
bound to a specific codec by means of the payload type number.
A wild card (*) can be specified for the payload type number
to indicate that it applies to all payload types in the media
description. Several image attributes can be defined for
instance for different video codec alternatives conditioned
that the payload type number differs.</t>
<t hangText="Preference (q):">The preference for each set is
0.5 by default, setting the optional q parameter to another
value makes it possible to set different preferences for the
sets. A higher value gives a higher preference for the given
set.</t>
<t hangText="sar:">The sar parameter specifies the sample
aspect ratio associated to the given range of x and y values.
The sar parameter is defined as dx/dy where dx and dy is the
physical size of the pixels. Square pixels gives a sar=1.0.
The parameter sar MAY be expressed as a range or as a single
value. <vspace />If this parameter is not present a default
sar value of 1.0 is assumed. <vspace />The interpretation of
sar differs between the send and the receive directions. <list
style="symbols">
<t>In the send direction it defines a specific sample
aspect ratio associated to a given x and y image size
(range).</t>
<t>In the recv direction sar expresses that the receiver
of the given medium prefers to receive a given x and y
resolution with a given sample aspect ratio.</t>
</list>See <xref target="sec-sar-considerations"></xref> for
a more detailed discussion. <vspace />The sar parameter will
likely not solve all the issues that are related to different
sample aspect ratios but it can help to solve them and reduce
aspect ratio distortion.<vspace />The response MUST NOT
include a sar parameter if there is no acceptable value given.
The reason to this is that if the response includes a sar
parameter it is interpreted as "sar parameter accepted" while
removal of the sar parameter is treated as "sar parameter not
accepted", for this reason it is safer to remove an
unacceptable sar parameter altogether.</t>
<t hangText="par:">The par (width/height = x/y ratio)
parameter indicates a range of allowed ratios between x and y
physical size (picture aspect ratio). This is used to limit
the number of x and y image size combinations, par is given as
<figure>
<artwork> ----
par=[ratio_min-ratio_max]
----</artwork>
</figure>Where ratio_min and ratio_max are the min and max
allowed picture aspect ratios.<vspace />If sar and the sample
aspect ratio that the receiver actually uses in the display
are the same (or close), the relation between the x and y
pixel resolution and the physical size of the image is
straightforward. If however sar differs from the sample aspect
ratio of the receiver display this must be taken into
consideration when the x and y pixel resolution alternatives
are sorted out.</t>
</list></t>
</section>
<section anchor="sec-offer-answer" title="Offer/answer rules">
<t>In accordance with <xref target="RFC3264"></xref>, offer answer
exchange of the image attribute is as follows.<list
style="symbols">
<t>Offerer sending the offer:<list style="symbols">
<t>The offerer must be able to support the image
attributes that it offers. The exception is if the offerer
has expressed a wild card (*) in the attribute list.</t>
<t>It is recommended that a high end device which sees no
reason to use the image attribute, anyway includes the
attribute with wild cards (*) in the attribute lists for
the send and recv directions. An example of this looks
like:<figure>
<artwork> ----
a=imageattr:97 send * recv *
----</artwork>
</figure>This gives the answerer the possibility to
express its preferences.</t>
</list></t>
<t>Answerer receiving the offer and sending the answer:<list
style="symbols">
<t>The answerer may choose to keep the image attribute but
is not required to do so.</t>
<t>The answerer may, for its receive and send direction,
include one or more entries that it can support from the
set of entries proposed in the offer.</t>
<t>The answerer may also, for its receive and send
direction, replace the entries with a complete new set of
entries different from the original proposed by the
offerer. The implementor of this feature should however be
aware that this may cause extra offer/answer
exchanges.</t>
<t>The answerer may also remove its send direction
completely if it is deemed that it cannot support any of
the proposed entries.</t>
<t>The answerer should not on its own include an image
attribute in the answer.</t>
</list></t>
<t>Offerer receiving the answer:<list style="symbols">
<t>If the image attribute is not included in the SDP
answer the offerer SHOULD resort to other methods to
determine the appropriate image size.</t>
<t>If the image attribute is included in the SDP answer
but none of the entries are usablel or acceptable, the
offerer SHOULD resort to other methods to determine the
appropriate image size. In this case the offerer must also
issue a new offer/answer without the image attribute to
avoid misunderstandings between offerer and answerer.</t>
</list></t>
</list></t>
</section>
</section>
</section>
<section title="Considerations">
<section title="No imageattr in 1st offer">
<t>When the initial offer does not contain the 'imageattr'
attribute, the answerer MUST NOT then include 'imageattr' in the
answer. The reasons for this are: <list style="symbols">
<t>The offerer of the initial SDP is not likely to understand
the image attribute if it did not include it in the offer,
bearing in mind that <xref target="sec-syntax-overall"></xref>
recommends that the offerer provide the attribute with
wildcarded parameters if it has no preference.</t>
<t>Inclusion of the image attribute in the answer may come in
conflict with the rules in <xref
target="sec-offer-answer"></xref> esp. the rules that apply to
"offerer receiving the answer".</t>
</list>For the above reasons it is RECOMMENDED that a high end
device which sees no reason to use the image attribute, anyway
includes the attribute with wild cards (*) in the attribute lists
for the send and recv directions.</t>
</section>
<section title="Asymmetry">
<t>While the image attribute supports asymmetry there are some
limitations to this. One important limitation is that the codec
being used can only support up to a given maximum resolution for a
given profile level.</t>
<t>As an example H.264 <xref target="H.264"></xref> with profile
level 1.2 does not support higher resolution than 352x288 (CIF). The
offer/answer rules imply that the same profile level must be used in
both directions. This means that in an asymmetric scenario where
Alice wants an image size of 580x360 and Bob wants 150x120, profile
level 2.2 is needed in both directions even though profile level 1
would have been sufficient in one direction.</t>
<t>Currently, the only solution to this problem is to specify two
unidirectional media descriptions. Note however that the asymmetry
issue for the H.264 codec is solved by means of the
level-asymmetry-allowed parameter in <xref
target="RFC3984bis"></xref>.</t>
</section>
<section anchor="sec-sendonly-recvonly" title="sendonly and recvonly">
<t>If the directional attributes a=sendonly or a=recvonly are given
for a medium, there is of course no need to specify the image
attribute for both directions. Therefore one of the directions in
the attribute may be omitted. However it may be good to do the image
attribute negotiation in both directions in case the session is
updated for media in both directions at a later stage.</t>
</section>
<section anchor="sec-sar-considerations" title="Sample aspect ratio">
<t>The relationship between the sar parameter and the x and y pixel
resolution deserves some extra discussion. Consider the offer from
Alice to Bob (we set the recv direction aside for the moment):
<figure>
<artwork> ----
a=imageattr:97 send [x=720,y=576,sar=1.1]
----</artwork>
</figure>If the receiver display has square pixels the 720x576
image would need to be rescaled to for example 792x576 or 720x524 to
ensure a correct image aspect ratio. This in practice means that
rescaling would need to be performed on the receiver side, something
that is contrary to the spirit of this draft. <vspace />To avoid
this problem Alice may specify a range of values for the sar
parameter like:<figure>
<artwork> ----
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
----</artwork>
</figure>Meaning that Alice can encode with any of the mentioned
sample aspect ratios, leaving to Bob to decide which one he
prefers.</t>
</section>
<section title="SDPCapNeg support">
<t>The image attribute can be used within the SDP Capability
Negotiation <xref target="SDPCapNeg"></xref> framework and its use
is then specified using the "a=acap" parameter. An example is</t>
<figure>
<artwork> ----
a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
----</artwork>
</figure>
<t>For use with SDP Media Capability Negotiation extension <xref
target="SDPMedCapNeg"></xref>, where it is no longer possible to
specify payload type numbers, it is possible to use the parameter
substitution rule, an example of this is.</t>
<figure>
<artwork> ----
...
a=mcap:1 video H264/90000
a=acap:1 imageattr:%1% send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
...
----</artwork>
</figure>
<t>Where %1% maps to media capability number 1.</t>
</section>
<section title="Interaction with codec parameters">
<t>As the SDP for most codecs already specifies some kind of
indication of, for example, the image size, at session set up,
measures must be taken to avoid conflicts between the image
attribute and this already existing information.</t>
<t>The following subsections describe the most well known codecs and
how they define image-size related information.</t>
<section title="H.263">
<t>The payload format for H.263 <xref target="H.263"></xref> is
described in <xref target="RFC4629"></xref>.</t>
<t>H.263 defines (on the fmtp line) a list of image sizes and
their maximum frame rates (profiles) that the offerer can receive.
The answerer is not allowed to modify this list and must reject a
payload type that contains an unsupported profile. The CUSTOM
profile may be used for image size negotiation but support for
asymmetry requires the specification of two unidirectional media
descriptions using the sendonly/recvonly attributes.</t>
</section>
<section title="H.264">
<t>The payload format for H.264 <xref target="H.264"></xref> is
described in <xref target="RFC3984"></xref> and updated in <xref
target="RFC3984bis"></xref>.</t>
<t>H.264 defines image size related information in the fmtp line
by means of sprop-parameter-sets. According to the specification
several sprop-parameter-sets may be defined for one payload type.
The sprop-parameter-sets describe the image size (+ more) that the
offerer sends in the stream and need not be complete. This means
that this does not represent any negotiation. Moreover an answer
is not allowed to change the sprop-parameter-sets.</t>
<t>This configuration may be changed later inband if for instance
image sizes need to be changed or added.</t>
</section>
<section title="MPEG-4">
<t>The payload format for MPEG-4 <xref target="MPEG-4"></xref> is
described in <xref target="RFC3016"></xref>.</t>
<t>MPEG-4 defines a config parameter on the fmtp line which is a
hexadecimal representation of the MPEG-4 visual configuration
information. This configuration does not represent any negotiation
and the answer is not allowed to change the parameter.</t>
<t>It is not possible to change the configuration using inband
signaling.</t>
</section>
<section title="Possible solutions">
<t>The subsections above clearly indicate that this kind of
information must be aligned well with the image attribute to avoid
conflicts. There are a number of possible solutions:<list
style="symbols">
<t>Ignore payload format parameters: This may not work well in
the presence of bad channel conditions especially in the
beginning of a session. Moreover this is not a good option for
MPEG-4.</t>
<t>2nd session-wide offer/answer round: In the 2nd
offer/answer the codec payload format specific parameters are
defined based on the outcome of the 'imageattr' negotiation.
The drawback with this is that set up of the entire session
(including audio) may be delayed considerably, especially as
the 'imageattr' negotiation can already itself cost up to two
offer/answer rounds. Also the conflict between the 'imageattr'
negotiation and the payload format specific parameters is
still present after the first offer/anser round and a
fuzzy/buggy implementation may start media before the second
offer/answer is completed with unwanted results.</t>
<t>2nd session-wide offer/answer round only for video: This is
similar to the alternative above with the exception that set
up time for audio is not increased, moreover the port number
for video is set to 0 during the 1st offer answer round to
avoid that media flows. <vspace />This has the effect that
video will blend in some time after the audio is started (up
to 2 seconds delay). This alternative is likely the most
clean-cut and failsafe alternative. The drawback is, as the
port number in the first offer is always zero, the media
startup will always be delayed even though it would in fact
have been possible to start media already after the first
offer/answer round.</t>
</list></t>
</section>
</section>
<section title="Change of display in middle of session">
<t>A very likely scenario is that a user switches to another phone
during a video telephony call or plugs a cellphone into an external
monitor. In both cases it is very likely that a renegotiation is
initiated using the SIP-REFER or SIP-UPDATE methods. It is
RECOMMENDED to negotiate the image size during this
renegotiation.</t>
</section>
<section title="Use with layered codecs">
<t>As the image attribute is a media level attribute, its use with
layered codecs cause some concern. If the layers are transported in
different RTP streams the layers are specified on different media
descriptions and the relation is specified using the grouping
framework <xref target="RFC3388"></xref> and the depend attribute
<xref target="RFC5583"></xref>. As it is not possible to specify
only one image attribute for several media descriptions the solution
is either to specify the same image attribute for each media
description, or to only specify the image attribute for the base
layer.</t>
</section>
<section anchor="sec-add-params" title="Addition of parameters">
<t>The image attribute allows for the addition of parameters in the
future. To make backwards adaptation possible; an entity that
processes the attribute MUST remove parameters that are not
recognized before returning the attribute in the SDP answer.
Addition of future parameters that are not understood by the
receiving endpoint may lead to ambiguities if mutual dependencies
between parameters exist, therefore addition of parameters must be
done with great care.</t>
</section>
</section>
</section>
<section title="Examples">
<t>This section gives some more information on how to use the attribute
by means of a high-level example and a few detailed examples.</t>
<section title="A High-Level Example">
<t>Assume that Alice wishes to set up a session with Bob and that
Alice takes the first initiative. The syntactical white-space
delimiters (1*WSP) and double-quotes are removed to make reading
easier.</t>
<t>In the offer Alice provides information for both the send and
receive (recv) directions. For the send direction Alice provides a
list that the answerer can select from. For the receive direction
Alice may either specify a desired image size range right away or a *
to instruct Bob to reply with a list of image sizes that Bob can
support for sending. Using the overall high level syntax the image
attribute may then look like <figure>
<artwork> ----
a=imageattr:PT send attr-list recv attr-list
----</artwork>
</figure>or<figure>
<artwork> ----
a=imageattr:PT send attr-list recv *
----</artwork>
</figure>In the first alternative the recv direction may be a full
list of desired image size formats. It may however (and most likely)
just be a list with one alternative for the preferred x and y
resolution.</t>
<t>If Bob supports an x and y resolution in at least one of the X and
Y ranges given in the send attr-list and in the recv attr-list of the
offer, the answer from Bob will look like: <figure>
<artwork> ----
a=imageattr:PT send attr-list recv attr-list
----</artwork>
</figure>And the offer answer negotiation is done. Worth notice here
is that the attr-list will likely be pruned in the answer. While it
may contain many different alternatives in the offer it may in the end
contain just one or two alternatives.</t>
<t>If Bob does not support any x and y resolution in any of of the X
and Y ranges given in the send attr-list or in the recv attr-list, the
corresponding part is removed completely. In this case the answer from
Bob would look like:<figure>
<artwork> ----
a=imageattr:PT recv attr-list
----</artwork>
</figure>In the above example none of the offered alternatives in
the recv attr-list was supported. Again it is worth notice that the
attr-list for each direction is likely pruned depending on preferred
and supported options.</t>
</section>
<section title="Detailed Examples">
<t>This section gives a few detailed examples, it is assumed where
needed that Alice initiates a session with Bob</t>
<section title="Example 1">
<t>Two image resolution alternatives are offered with 800x640 with
sar=1.1 having the highest preference</t>
<t>It is also indicated that Alice wish to display video with a
resolution of 330x250 on her display</t>
<figure>
<artwork> ----
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250]
----</artwork>
</figure>
<t>In case Bob accepts the "recv [x=330,y=250]" the answer may look
like</t>
<figure>
<artwork> ----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=330,y=250]
----</artwork>
</figure>
<t>Indicating that the receiver (Bob) wish the encoder (on Alice's
side) to compensate for a sample aspect ratio of 1.1 (11:10) and
desires an image size on its screen of 800x640.</t>
<t>There is however a possibility that "recv [x=330,y=250]" is not
supported. If the case, Bob may completely remove this part or
replace it with a list of supported image sizes.</t>
<figure>
<artwork> ----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]]
----</artwork>
</figure>
<t>Alice can then select a valid image size which is closest to the
one that was originally desired (336x256) and performs a second
offer/answer</t>
<figure>
<artwork> ----
a=imageattr:97 send [x=800,y=640,sar=1.1] \
recv [x=336,y=256]
----</artwork>
</figure>
<t>Bob replies with:</t>
<figure>
<artwork> ----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=336,y=256]
----</artwork>
</figure>
</section>
<section title="Example 2">
<t>Two image resolution sets are offered with the first having a
higher preference (q=0.6).</t>
<figure>
<artwork> ----
a=imageattr:97 \
send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \
[x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \
recv *
----</artwork>
</figure>
<t>The x-axis resolution can take the values 480 to 800 in 16 pixels
steps and 176 to 208 in 8 pixels steps. The par parameter limits the
set of possible x and y screen resolution combinations such that
800x640 (ratio=1.25) is a valid combination while 720x608
(ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.</t>
<t>For the recv direction (Bob->Alice) Bob is requested to
provide with a list of supported image sizes</t>
</section>
<section title="Example 3">
<t>In this example a complete SDP offer is defined.</t>
<figure>
<artwork> ----
m=video 49154 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 \
send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] \
recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] [x=320,y=240]
----</artwork>
</figure>
<t>In the send direction, sprop-parameter-sets is defined for a
resolution of 320x240 which is the largest image size offered in the
send direction. This means that if 320x240 is selected, no
additional offer/answer is necessary. In the receive direction four
alternative image sizes are offered with 272x224 being the preferred
choice.</t>
<t>The answer may look like:</t>
<figure>
<artwork> ----
m=video 49154 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
----</artwork>
</figure>
<t>Indicating (in this example) that the image size is 320x240 in
both directions. Although the offerer preferred 272x224 for the
receive direction, the answerer might not be able to offer 272x224
or not allow encoding and decoding of video of different image sizes
simultaneously. The answerer sets new sprop-parameter-sets,
constructed for both send and receive directions at the restricted
conditions and image size of 320x240.</t>
</section>
<section title="Example 4">
<t>This example illustrates in more detail how compensation for
different sample aspect ratios can be negotiated with the image
attribute.</t>
<t>We set up a session between Alice and Bob, Alice is the offerer
of the session. The offer (from Alice) contains the image attribute
below:<figure>
<artwork> ----
a=imageattr:97 \
send [sar=[1.0-1.3],x=400:16:800],y=[320:16:640],par=[1.2-1.3]] \
recv [sar=1.1,x=800,y=600]
----</artwork>
</figure></t>
<t>First we consider the recv direction: The offerer (Alice)
explicitly states that she wish to receive the screen resolution
800x600, however she also indicates that the screen on her display
does not use square pixels, the sar value=1.1 means that Bob must
(preferably) compensate for this. <vspace />So.. If Bob's video
camera produces square pixels, and wish to satisfy Alice's sar
requirement, the image processing algorithm must rescale a 880x600
pixel image (880=800*1.1) to 800x600 pixels (could be done other
ways).</t>
<t>... and now the send direction: Alice indicates that she can (in
the image processing algorithms) rescale the image for sample aspect
ratios in the range 1.0 to 1.3. She can also provide with a number
of different image sizes (in pixels) ranging from 400x320 to
800x640. Bob inspects the offered sar and image sizes and responds
with the modified image attribute <figure>
<artwork> ----
a=imageattr:97 \
recv [sar=1.15,x=464,y=384] \
send [sar=1.1,x=800,y=600]
----</artwork>
</figure></t>
<t>Alice will, in order to satisfy Bob's request, need to rescale
the image from her video camera from 534x384 (534=464*1.15) to
464x384.</t>
<t>Neither part is required to rescale like this (sar may be
ignored), the consequence will of course be a distorted image.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>Following the guidelines in <xref target="RFC4566"></xref>, the IANA
is requested to register one new SDP attribute:<list hangIndent="20"
style="hanging">
<t hangText="Attribute name:">imageattr</t>
<t hangText="Long form name:">Image attribute</t>
<t hangText="Type of attribute:">Media-level</t>
<t hangText="Subject to charset:">No</t>
<t hangText="Purpose:">This attribute defines the ability to
negotiate various image attributes such as image sizes. The
attribute contains a number of parameters which can be modified in
and offer/answer exchange.</t>
<t hangText="Appropriate values:">See <xref
target="sec-syntax-overall"></xref> of RFCXXXX</t>
<t hangText="Contact name:">Authors of RFCXXXX</t>
</list></t>
<t>Note to RFC Editor: please replace "RFCXXXX" above with the RFC
number of this document, and remove this note.</t>
</section>
<section title="Security Considerations">
<t>This draft does not add any additional security issues other than
those already existing with currently specified offer/answer
procedures.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the people who has contributed with
objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to Clinton
Priddle, Roni Even, Randell Jesup, and Dan Wing.</t>
</section>
<section title="Changes">
<t>The main changes are:<list hangIndent="" style="hanging">
<t hangText="From WG -04 to WG -05"><list style="symbols">
<t>Review based on WGLC comments</t>
<t>ABNF improved</t>
<t>Change use of RFC2119 keywords (MUST, SHOULD, MAY) to
lowercase in some sections</t>
<t>Clarification on the directions send and recv in sendrecv,
inactive modes</t>
<t>Clarification around sar parameter added</t>
</list></t>
<t hangText="From WG -03 to WG -04"><list style="symbols">
<t>Rearrangement of text</t>
<t>Clarification of offer/answer rules</t>
<t>Cleaned IANA section</t>
</list></t>
<t hangText="From WG -02 to WG -03"><list style="symbols">
<t>Partial update based on review comments from Jean-Francois
Mule</t>
</list></t>
<t hangText="From WG -01 to WG -02"><list style="symbols">
<t>Added extra example that highlights the negotiation of
sar</t>
</list></t>
<t hangText="From WG -00 to WG -01"><list style="symbols">
<t>Added info about future addition of parameters and backwards
compatibility</t>
<t>Added IANA considerations</t>
</list></t>
<t hangText="From individual -02 to WG -00"><list style="symbols">
<t>Cleanup of syntax, ABNF form</t>
<t>Additional example</t>
</list></t>
<t hangText="From -01 to -02"><list style="symbols">
<t>Cleanup of the sar and par parameters to make them match the
established conventions</t>
<t>Requirement specification added</t>
<t>New bidirectional syntax</t>
<t>Interoperability considerations with well known video codecs
discussed</t>
</list></t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
&rfc3264;
&rfc3388;
&rfc4566;
&rfc5234;
&rfc5583;
</references>
<references title="Informative References">
&rfc3016;
&rfc3984;
&rfc4587;
&rfc4629;
<reference anchor="H.264">
<front>
<title>ITU-T Recommendation H.264,
http://www.itu.int/rec/T-REC-H.264-200711-I/en</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date />
</front>
</reference>
<reference anchor="H.263">
<front>
<title>ITU-T Recommendation H.263 (2005): "Video coding for low bit
rate communication"</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date />
</front>
</reference>
<reference anchor="MPEG-4">
<front>
<title>ISO/IEC 14496-2:2004: "Information technology - Coding of
audio-visual objects - Part 2: Visual"</title>
<author fullname="" initials="" surname="">
<organization>ISO/IEC</organization>
</author>
<date />
</front>
</reference>
<reference anchor="SDPCapNeg">
<front>
<title>SDP Capability Negotiation,
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation</title>
<author fullname="" initials="" surname="">
<organization>IETF</organization>
</author>
<date />
</front>
</reference>
<reference anchor="SDPMedCapNeg">
<front>
<title>SDP media capabilities Negotiation,
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities</title>
<author fullname="" initials="" surname="">
<organization>IETF</organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC3984bis">
<front>
<title>RTP Payload Format for H.264 Video,
http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/</title>
<author fullname="" initials="" surname="">
<organization>IETF</organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 11:52:27 |