Network Working Group I. Johansson
Internet-Draft Ericsson AB
Intended status: Standards Track K. Jung
Expires: August 10, 2009 Samsung Electronics Co., Ltd.
Feb 6, 2009
Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2009.
Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document proposes a new generic session setup attribute to make
Johansson & Jung Expires August 10, 2009 [Page 1]
Internet-Draft Image Attributes in SDP Feb 2009
it possible to negotiate different image attributes such as image
size. A possible use case is to make it possible for a e.g 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.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5
3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 8
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 9
3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10
3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10
3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11
3.3.6. Interaction with codec parameters . . . . . . . . . . 11
3.3.7. Change of display in middle of session . . . . . . . . 13
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Informative References . . . . . . . . . . . . . . . . . . 16
10.2. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Johansson & Jung Expires August 10, 2009 [Page 2]
Internet-Draft Image Attributes in SDP Feb 2009
1. Introduction
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 e.g a hand-held terminal. For instance it may be beneficial
to display a video image on a part of the physical screen and leave
space on the screen for e.g menus and other info.
There are a number of benefits with a possibility to negotiate the
image size:
o 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.
o Reduced complexity: Image rescaling can be quite computation
intensive. For low end devices this can be a problem.
o 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 gives
alternatively a saving in bitrate.
o Memory requirement: The receiver device will know the size of the
image and can then allocate memory accordingly.
o Optimal aspect ratio: If rescaling of the image is possible on the
receiver side one can imagine that the offer contains three
resolutions 100x200, 200x100 and 100x100 with sar=1.0 (1:1). If
the receiver screen has the resolution 200x200 with sar=1 then the
obvious is to select 100x100 and scale the image by a factor 2.
If on the other hand the screen has the resolution 100x200 with
sar=2 (2:1) then the obvious is again to select 100x100 and scale
the image by a factor 2 in the x-axis.
The cautious reader may however object that the rescaling issue has
been moved to the sender and also that codecs such as H.264 are not
mandated to support the rescaling of the video image size. This
potentially reduces the number of valid arguments to only 1 (optimal
use of bandwidth).
However, what must then be considered is that:
o 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
Johansson & Jung Expires August 10, 2009 [Page 3]
Internet-Draft Image Attributes in SDP Feb 2009
YUV domain and should not depend on the codecs used.
o The encoder may be able to encode in a number of formats but may
not know which format to choose.
o 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 esp. when low bitrate
video coding is used.
o If low-complexity rescaling operations such as cropping only must
be performed after all, 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.
Several of the existing standards ([H.263], [H.264] and [MPEG-4])
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". A problem statement
and discussion that gives a motivation to this document can be found
in [S4-080144].
The draft is limited to unicast scenarios in general and more
specific peer to peer situations. 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.
2. Conventions, Definitions and Acronyms
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.
3. Defintion of Attribute
A new image attribute is defined with the name "imageattr". The
image attribute contains a set of different image-resolution options
that the offerer can provide. The receiver can then select the
desired image attribute (e.g image size) and may then have the
ability to avoid costly transformations (e.g rescaling) of the
images. In this approach only the image resolution and optionally
sample aspect ratio, allowed range in picture aspect ratio and
preference is covered but the framework makes it possible to extend
Johansson & Jung Expires August 10, 2009 [Page 4]
Internet-Draft Image Attributes in SDP Feb 2009
with other image related attributes that make sense.
3.1. Requirements
The new image attribute should meet the following requirements:
REQ-1: Support the offer of a specific image size on the receiver
display or in other words, reduce or avoid the need for rescaling
images in the receiver to fit a given portion of the screen.
REQ-2: Support asymmetric setups i.e the very likely scenario where
Alice prefers an image size of 320x240 for her display while Bob
prefers an image size of 176x144.
REQ-3: Interoperate with codec specific parameters such as sprop-
parameter-sets in H.264 or config in MPEG4.
REQ-3: Make the attribute generic with as little codec specific
details/tricks as possible. Ideally the attribute should not care
about the codec specific features.
OPT-1: Make it possible to use attribute for other purposes than
video. One possible use case may be distributed white-board
presentations which are based on transmission of compressed bitmap
images where rescaling often produce very poor results.
3.2. Attribute syntax
In this section the syntax of the image attribute is described. 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.
3.2.1. Overall view of syntax
The syntax for the image attribute is in ABNF:
----
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
1*WSP attr_list )
PT = 1*DIGIT / "*"
attr_list = ( set *(1*WSP set) ) / "*"
see below for a definition of set.
----
o Maximum one occurrence of the "send" keyword and corresponding
attr_list is allowed per image attribute.
Johansson & Jung Expires August 10, 2009 [Page 5]
Internet-Draft Image Attributes in SDP Feb 2009
o Maximum one occurrence of the "recv" keyword and corresponding
attr_list is allowed per image attribute.
o PT is the payload type number, it can be set to * to indicate that
the attribute applies to all payload types in the media
description.
o For sendonly or recvonly streams one of the directions MAY be
omitted. See Section 3.3.3, moreover the order of the send and
recv directions is not important.
The syntax for the set is given by:
----
set= "[" "x=" range "," "y=" range [",sar="range]
[",par=" range] [",q=" value] "]"
x is the horizontal image size range
y is the vertical image size range
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 ratios between the
displays 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 higher
preference from the sender point of view
range is expressed in a few different formats
1) range= value
a single value
2) range= "[" value1 ":" [ step ":" ] value2 "]"
values between value1 and value2 inclusive,
if step is omitted a stepsize of 1 is implied.
3) range= "[" value 1*( "," value ) "]"
any value from the list of values
4) range= "[" value1 "-" value2 "]"
any real value between value1 and value2 inclusive
value is a positive integer or real value
step is a positive integer or real value
If step is left out in the syntax a stepsize of 1 is implied.
Note the use of brackets [..] if more that one value specified.
----
Some further guidelines for the use of the attribute is given below:
o The image attribute is bound to a specific media 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
Johansson & Jung Expires August 10, 2009 [Page 6]
Internet-Draft Image Attributes in SDP Feb 2009
defined e.g for different video codec alternatives conditioned
that the payload type number differs.
o 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.
o 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 size of the pixels. Square pixels
gives a sar=1.0. The parameter sar MAY be expressed as a range.
The interpretation of sar differs between the send and the receive
directions.
* In the send direction it defines a specific sample aspect
ration associated to a given x and y image size (range).
* In the recv direction sar expresses that the receiver of the
given media prefers to receive a given x and y resolution with
a given sample aspect ratio.
See Section 3.3.4 for a more detailed discussion.
o 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
----
par=[ratio_min-ratio_max]
----
Where ratio_min and ratio_max are the min and max allowed picture
aspect ratios.
If sar and the display sample aspect ration is 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.
o The offerer MUST be able to support the image attributes that it
offers.
o The answerer MAY choose to keep imageattr but is not required to
do so. If the attribute is kept in the SDP answer, the answerer
MUST for its receive direction only include one or more valid
entries taken from the offer. The answer for the answerers send
direction MAY be modified.
Johansson & Jung Expires August 10, 2009 [Page 7]
Internet-Draft Image Attributes in SDP Feb 2009
o The answerer MUST for its receive direction only pick one or more
valid entries from the multidimensional solution space spanned by
the offer.
3.2.2. Syntax description
In the description of the syntax we here assume that Alice wish to
setup 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.
In the offer Alice provides with information for both the send and
receive (recv) directions using syntax version 1. For the send
direction Alice provides with 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 fill with a
list of image size that Bob can support to send. Using the overall
high level syntax the image attribute may then look like
----
a=imageattr:PT send attr_list recv attr_list
----
or
----
a=imageattr:PT send attr_list recv *
----
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.
If Bob supports an x and y resolution in the given x and y range the
answer from Bob will look like:
----
a=imageattr:PT send attr_list recv attr_list
----
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 in the end.
If Bob does not support any x and y resolution in the given x and y
range in attr_list or a * was given for the recv direction then he
MUST either:
o Provide with another list of options (attr_list). The answer from
Bob may then look like:
----
a=imageattr:PT recv attr_list send attr_list
----
Johansson & Jung Expires August 10, 2009 [Page 8]
Internet-Draft Image Attributes in SDP Feb 2009
In this case the offer/answer negotiation is not quite done. To
complete the offer/answer Alice sends another offer that looks
like:
----
a=imageattr:PT send attr_list recv attr_list
----
Bob MAY send back an answer to complete the 2nd offer/answer but
this is not necessary.
o Remove the corresponding part completely in which case the answer
from bob would look like:
----
a=imageattr:PT recv attr_list
----
Again it is worth notice that the attr_list for each direction is
likely pruned depending on preferred and supported options.
If the 1st offer (from Alice) already defines a desired image size
for the recv direction the answerer can do one of the following:
1. Accept the image size and return it in the answer.
2. Replace with a list of options in the answer.
3. Remove the corresponding part completely. This may happen if it
is deemed that it is unlikely that the list of options is
supported. The answer will then lack a description for the send
direction and will look like:
----
a=imageattr:PT recv attr_list
----
3.3. Considerations
3.3.1. No imageattr in 1st offer
A high end device (Alice) may not see any need for the image
attribute as it most likely has the processing capacity to rescale
incoming video and may therefore not include the attribute in the
offer as it otherwise does not see any use for it. The answerer
(Bob) MAY include imageattr in the answer. This has two
implications:
o Longer session setup time due to extra offer/answer exchanges
o There is a risk that Alice does not recognize or support imageattr
and will thus anyway ignore the attribute.
Johansson & Jung Expires August 10, 2009 [Page 9]
Internet-Draft Image Attributes in SDP Feb 2009
3.3.2. Asymmetry
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.
As an example H.264 with profile level 1.2 does not support higher
resolution than 352x288 (CIF). The offer/answer rules essentially
gives that the same profile level must be used in both directions.
This means that for 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 enough in
one direction. [Ed. Note. This is currently being changed with the
RFC3984bis draft].
Currently, the only solution to this problem is to specify two
unidirectional media descriptions.
3.3.3. sendonly and recvonly
If the directional attributes a=sendonly or a=recvonly are given for
a media, there is of course no need to specify the image attribute
for both directions. Therefore one of 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.
3.3.4. Sample aspect ratio
The sar parameter in relation to 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):
----
a=imageattr:97 send [x=720,y=576,sar=1.1]
----
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.
To avoid this problem Alice MAY specify a range of values for the sar
parameter like:
----
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
----
Meaning that Alice can encode with any of the mentioned sample aspect
ratios, leaving to Bob to decide which one he prefers.
Johansson & Jung Expires August 10, 2009 [Page 10]
Internet-Draft Image Attributes in SDP Feb 2009
The response MUST not include the sar parameter if there is no
acceptable value given.
3.3.5. SDPCapNeg support
The image attribute can be used within the SDP Capability Negotiation
[SDPCapNeg] framework and its use is then specified using the
"a=acap" parameter. An example is
----
a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
----
For use with SDP Media Capability Negotiation extension
[SDPMedCapNeg], 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.
----
...
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]]
...
----
Where %1% maps to media capability number 1.
3.3.6. Interaction with codec parameters
As most codecs specifies some kind of indication of e.g. the image
size already at session setup some measures must be taken to avoid
that the image attribute conflicts with this already existing
information.
The following subsections describes the most well known codecs and
how they define image-size related information.
3.3.6.1. H.263
The payload format for H.263 is described in [RFC4629].
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.
Johansson & Jung Expires August 10, 2009 [Page 11]
Internet-Draft Image Attributes in SDP Feb 2009
3.3.6.2. H.264
The payload format for H.264 is described in [RFC3984]. [Ed. Note :
This format is currently being changed].
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.
This configuration may be changed later inband if for instance image
sizes need to be changed or added.
3.3.6.3. MPEG-4
The payload format for MPEG-4 is described in [RFC3016].
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.
Currently it is not possible to change the configuration using inband
signaling.
3.3.6.4. Possible solutions
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:
o Ignore payload format parameters: This may not work well e.g in
the presence of bad channel conditions esp. in the beginning of a
session. Moreover this is not a good option for MPEG-4.
o 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 setup 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.
Johansson & Jung Expires August 10, 2009 [Page 12]
Internet-Draft Image Attributes in SDP Feb 2009
o 2nd session-wide offer/answer round only for video: This is
similar to the alternative above with the exception that setup
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.
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.
3.3.7. Change of display in middle of session
A very likely scenario is that a user switches to another phone
during e.g a video telephony call or plugs the cellphone into an
external monitor. In both cases it is very likely that a
renegotiation is initiated using e.g the SIP-REFER or SIP-UPDATE
methods. It is RECOMMENDED to negotiate the image size during this
renegotiation.
4. Examples
A few examples to highlight the syntax, here is assumed where needed
that Alice initiates a session with Bob
4.1. Example 1
----
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250]
----
Two image resolution alternatives are offered with 800x640 with
sar=1.1 having the highest preference
The example also indicates that Alice wish to display video with a
resolution of 330x250 on her display
In case Bob accepts the "recv [x=330,y=250]" the answer may look like
----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=330,y=250]
----
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
Johansson & Jung Expires August 10, 2009 [Page 13]
Internet-Draft Image Attributes in SDP Feb 2009
image size on its screen of 800x640.
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.
----
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]]
----
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
----
a=imageattr:97 send [x=800,y=640,sar=1.1] \
recv [x=336,y=256]
----
Bob replies with (actually not necessary):
----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=336,y=256]
----
4.2. Example 2
----
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 *
----
Two image resolution sets are offered with the first having a higher
preference (q=0.6). 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.
For the recv direction (Bob->Alice) Bob is requested to provide with
a list of supported image sizes
4.3. Example 3
In this example is defined a complete SDP offer for the video media
part
Johansson & Jung Expires August 10, 2009 [Page 14]
Internet-Draft Image Attributes in SDP Feb 2009
----
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]
----
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.
The answer may look like:
----
m=video 49154 RTP/AVPF 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]
----
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.
5. Issues
Here is listed a few possible issues and observations connected to
the use of the image attribute :
o An SDP answer MAY modify the image attribute for the answerers
send direction. Can this cause trouble ?
6. IANA Considerations
T.B.D
Johansson & Jung Expires August 10, 2009 [Page 15]
Internet-Draft Image Attributes in SDP Feb 2009
7. Security Considerations
This draft does not add any additional security issues other than
those already existing with currently specified offer/answer
procedures.
8. Acknowledgements
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.
9. Changes
The main changes are:
From individual -02 to WG -00
* Cleanup of syntax, ABNF form
* Additional example
From -01 to -02
* Cleanup of the sar and par parameters to make them match the
established conventions
* Requirement specification added
* New bidirectional syntax
* Interoperability considerations with well known video codecs
discussed
10. References
10.1. Informative References
[H.264] ITU-T, "ITU-T Recommendation H.264,
http://www.itu.int/rec/T-REC-H.264-200711-I/en".
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual
Streams", RFC 3016, November 2000.
Johansson & Jung Expires August 10, 2009 [Page 16]
Internet-Draft Image Attributes in SDP Feb 2009
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R.
Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007.
[S4-080144]
3GPP, "Signaling of Image Size: Combining Flexibility and
Low Cost, http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/
TSGS4_48/Docs/S4-080144.zip".
[SDPCapNeg]
IETF, "SDP Capability Negotiation, http://tools.ietf.org/
wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation".
[SDPMedCapNeg]
IETF, "SDP media capabilities Negotiation, http://
tools.ietf.org/wg/mmusic/
draft-ietf-mmusic-sdp-media-capabilities".
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Johansson & Jung Expires August 10, 2009 [Page 17]
Internet-Draft Image Attributes in SDP Feb 2009
Authors' Addresses
Ingemar Johansson
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
SWEDEN
Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com
Kyunghun Jung
Samsung Electronics Co., Ltd.
Dong Suwon P.O. Box 105
416, Maetan-3Dong, Yeongtong-gu
Suwon-city, Gyeonggi-do
Korea 442-600
Phone: +82 10 9909 4743
Email: kyunghun.jung@samsung.com
Johansson & Jung Expires August 10, 2009 [Page 18]
