idnits 2.17.1 draft-johansson-mmusic-image-attributes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The response MUST not include the sar parameter if there is no acceptable value given. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sep 19, 2008) is 5691 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MPEG-4' is mentioned on line 147, but not defined == Unused Reference: 'RFC3264' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC4587' is defined on line 698, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3016 (Obsoleted by RFC 6416) -- Obsolete informational reference (is this intentional?): RFC 3984 (Obsoleted by RFC 6184) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Johansson 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track K. Jung 5 Expires: March 23, 2009 Samsung Electronics Co., Ltd. 6 Sep 19, 2008 8 Negotiation of Generic Image Attributes in SDP 9 draft-johansson-mmusic-image-attributes-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 23, 2009. 36 Abstract 38 This document proposes a new generic session setup attribute to make 39 it possible to negotiate different image attributes such as image 40 size. A possible use case is to make it possible for a e.g a low-end 41 hand-held terminal to display video without the need to rescale the 42 image, something that may consume large amounts of memory and 43 processing power. The draft also helps to maintain an optimal 44 bitrate for video as only the image size that is desired by the 45 receiver is transmitted. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 57 3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 61 3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 7 62 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 9 63 3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 9 64 3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 9 65 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10 66 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10 67 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 10 68 3.3.6. Interaction with codec parameters . . . . . . . . . . 10 69 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 79 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Intellectual Property and Copyright Statements . . . . . . . . . . 17 83 1. Introduction 85 This document proposes a new attribute to make it possible to 86 negotiate different image attributes such as image size. The term 87 image size is defined here as it may differ from the physical screen 88 size of e.g a hand-held terminal. For instance it may be beneficial 89 to display a video image on a part of the physical screen and leave 90 space on the screen for e.g menus and other info. 92 There are a number of benefits with a possibility to negotiate the 93 image size: 95 o Less image distortion: Rescaling of images introduces additional 96 distortion, something that can be avoided (at least on the 97 receiver side) if the image size can be negotiated. 99 o Reduced complexity: Image rescaling can be quite computation 100 intensive. For low end devices this can be a problem. 102 o Optimal quality for the given bitrate: The sender does not need to 103 encode an entire CIF (352x288) image if only an image size of 104 288x256 is displayed on the receiver screen. This gives 105 alternatively a saving in bitrate. 107 o Memory requirement: The receiver device will know the size of the 108 image and can then allocate memory accordingly. 110 o Optimal aspect ratio: If rescaling of the image is possible on the 111 received side one can imagine that the offer contains three 112 resolutions 100x200, 200x100 and 100x100 with sar=1.0 (1:1). If 113 the receiver screen has the resolution 200x200 with sar=1 then the 114 obvious is to select 100x100 and scale the image by a factor 2. 115 If on the other hand the screen has the resolution 100x200 with 116 sar=2 (2:1) then the obvious is again to select 100x100 and scale 117 the image by a factor 2 in the x-axis. 119 The cautious reader may however object that the rescaling issue has 120 been moved to the sender and also that codecs such as H.264 are not 121 mandated to support the rescaling of the video image size. This 122 potentially reduces the number of valid arguments to only 1 (optimal 123 use of bandwidth). 125 However, what must then be considered is that: 127 o Rescaling on the sender/encoder side is likely to be easier to do 128 as the camera related software/hardware already contains the 129 necessary functionality for zooming/cropping/trimming/sharpening 130 the video signal. Moreover, rescaling is generally done in RGB or 131 YUV domain and should not depend on the codecs used. 133 o The encoder may be able to encode in a number of formats but may 134 not know which format to choose. 136 o The quality drop due to digital domain rescaling using 137 interpolation is likely to be lower if it is done before the video 138 encoding rather than after the decoding esp. when low bitrate 139 video coding is used. 141 o If low-complexity rescaling operations such as cropping only must 142 be performed after all, the benefit with having this functionality 143 on the sender side is that it is then possible to present a 144 miniature "what you send" image on the display to help the user to 145 target his camera correctly. 147 Several of the existing standards ([H.263], [H.264] and [MPEG-4]) 148 have support for different resolutions at different framerates. The 149 purpose of this document is to provide for a generic mechanism and is 150 targeted mainly at the negotiation of the image size but to make it 151 more general the attribute is named "imageattr". A problem statement 152 and discussion that gives a motivation to this document can be found 153 in [S4-080144]. 155 2. Conventions, Definitions and Acronyms 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119. 161 3. Defintion of Attribute 163 A new image attribute is defined with the name "imageattr". The 164 image attribute contains a set of different image-resolution options 165 that the offerer can provide. The receiver can then select the 166 desired image attribute (e.g image size) and may then have the 167 ability to avoid costly transformations (e.g rescaling) of the 168 images. In this approach only the image resolution and optionally 169 sample aspect ratio, allowed range in picture aspect ratio and 170 preference is covered but the framework makes it possible to extend 171 with other image related attributes that make sense. 173 3.1. Requirements 175 The new image attribute should meet the following requirements: 177 REQ-1: Support the offer of a specific image size on the receiver 178 display or in other words, reduce or avoid the need for rescaling 179 images in the receiver to fit a given portion of the screen. 181 REQ-2: Support asymmetric setups i.e the very likely scenario where 182 Alice prefers an image size of 320x240 for her display while Bob 183 prefers an image size of 176x144. 185 REQ-3: Interoperate with codec specific parameters such as sprop- 186 parameter-sets in H.264 or config in MPEG4. 188 REQ-3: Make the attribute generic with as little codec specific 189 details/tricks as possible. Ideally the attribute should not care 190 about the codec specific features. 192 OPT-1: Make it possible to use attribute for other purposes than 193 video. One possible use case may be distributed white-board 194 presentations which are based on transmission of compressed bitmap 195 images where rescaling often produce very poor results. 197 3.2. Attribute syntax 199 In this section the syntax of the image attribute is described. The 200 section is split up in two parts, the first gives an overall view of 201 the syntax while the second describes how the syntax is used. 203 3.2.1. Overall view of syntax 205 The syntax for the image attribute is: 206 ---- 207 a=imageattr:PT 1*WSP send 1*WSP attr_list \ 208 1*WSP recv 1*WSP attr_list|* 209 attr_list = set *(1*WSP set) 210 see below for a definition of set. 211 ---- 213 o PT is the payload type number, can be set to * . 215 o The backslash '\' is used in this document for formatting reasons 216 only. 218 o For sendonly or recvonly streams one of the directions MAY be 219 omitted. See Section 3.3.3, moreover the order of the send and 220 recv directions is not important. 222 The syntax for the set is given by: 224 ---- 225 set=[x=range,y=range<,sar=range><,par=range><,q=value>] 226 x is the horizontal image size range 227 y is the vertical image size range 228 sar is the sample aspect ratio associated with the set 229 (optional and MAY be ignored) 230 par is the allowed ratios between the displays x and y physical size 231 a.k.a picture aspect ratio (optional) 232 q (optional with range [0.0..1.0], default value 0.5) 233 is the preference for the given set, a higher value means higher 234 preference from the sender point of view 236 range is expressed in a few different forms 237 1) range=value 238 2) range=[value1:value2] 239 (any value between value1 and value2 inclusive) 240 3) range=[value1:step:value2] 241 (every 'step' value between value1 and value2 inclusive) 242 4) range=[value1,value2...valueN] 243 (any value from the list of values) 244 5) range=[value1-value2] 245 (any real value between value1 and value2 inclusive) 247 value is a positive integer or real value 248 step is a positive integer or real value 249 If step is left out in the syntax a stepsize of 1 is implied. 250 Note the use of brackets [..] if more that one value specified. 251 ---- 253 Some guidelines for the use of the syntax is given below: 255 o The image attribute is bound to a specific media by means of the 256 payload type number. A wild card (*) can be specified for the 257 payload type number to indicate that it applies to all payload 258 types in the media description. Several image attributes can be 259 defined e.g for different video codec alternatives conditioned 260 that the payload type number differs. 262 o The preference for each set is 0.5 by default, setting the 263 optional q parameter to another value makes it possible to set 264 different preferences for the sets. A higher value gives a higher 265 preference for the given set. 267 o The sar parameter specifies the sample aspect ratio associated to 268 the given range of x and y values. The sar parameter is defined 269 as dx/dy where dx and dy is the size of the pixels. Square pixels 270 gives a sar=1.0. The parameter sar MAY be expressed as a range. 271 The interpretation of sar differs between the send and the receive 272 directions. In the send direction it defines a specific sample 273 aspect ration associated to a given x and y image size (range). 274 In the recv direction sar expresses that the receiver of the given 275 media prefers to receive a given x and y resolution with a given 276 sample aspect ratio. See Section 3.3.4 for a more detailed 277 discussion. 279 o The par (width/height = x/y ratio) parameter indicates a range of 280 allowed ratios between x and y physical size (picture aspect 281 ratio). This is used to limit the number of x and y image size 282 combinations, par is given as 283 ---- 284 par=[ratio_min-ratio_max] 285 ---- 286 Where ratio_min and ratio_max are the min and max allowed picture 287 aspect ratios. 288 If sar and the display sample aspect ration is the same (or close) 289 the relation between the x and y pixel resolution and the physical 290 size of the image is straightforward. If however sar differs from 291 the sample aspect ratio of the receiver display this must be taken 292 into consideration when the x and y pixel resolution alternatives 293 are sorted out. 295 o The offerer MUST be able to support the image attributes that it 296 offers. 298 o The answerer MAY choose to keep imageattr but is not required to 299 do so. The answerer MUST in this case only include one or more 300 valid entries taken from the offer in the SDP answer, the 301 exception to this is the case above where the 1st offer defines a 302 desired image size for the receive direction. 304 o The answerer MUST only pick one or more valid entries from the 305 multidimensional solution space spanned by the offer. 307 3.2.2. Syntax description 309 In the description of the syntax we here assume that Alice wish to 310 setup a session with Bob and that Alice takes the first initiative. 311 The syntactical white-space delimiters (1*WSP) are removed to make 312 reading easier. 314 In the offer Alice provides with information for both the send and 315 receive (recv) directions using syntax version 1. For the send 316 direction Alice provides with a list that the answerer can select 317 from. For the receive direction Alice may either specify a desired 318 image size range right away or a * to instruct Bob to fill with a 319 list of image size that Bob can support to send. Using the overall 320 high level syntax the image attribute may then look like 321 ---- 322 a=imageattr:PT send attr_list recv attr_list 323 ---- 324 or 325 ---- 326 a=imageattr:PT send attr_list recv * 327 ---- 328 In the first alternative the recv direction may be a full list of 329 desired image size formats. It may however (and most likely) just be 330 a list with one alternative for the preferred x and y resolution. 332 If Bob supports an x and y resolution in the given x and y range the 333 answer from Bob will look like (syntax version 2): 334 ---- 335 a=imageattr:PT send attr_list recv attr_list 336 ---- 337 And the offer answer negotiation is done. Worth notice here is that 338 the attr_list will likely be pruned in the answer. While it may 339 contain many different alternatives in the offer it may in the end 340 contain just one or two alternatives in the end. 342 If Bob does not support any x and y resolution in the given x and y 343 range in attr_list or a (*) was given for the recv direction then he 344 MUST either: 346 o Provide with another list of options (attr_list). The answer from 347 Bob may then look like (syntax version 3): 348 ---- 349 a=imageattr:PT recv attr_list send attr_list 350 ---- 351 In this case the offer/answer negotiation is not quite done. To 352 complete the offer/answer Alice sends another offer that looks 353 like: 354 ---- 355 a=imageattr:PT send attr_list recv attr_list 356 ---- 357 Bob MAY send back an answer to complete the 2nd offer/answer but 358 this is not necessary. 360 o Remove the corresponding part completely in which case the answer 361 from bob would look like: 362 ---- 363 a=imageattr:PT recv attr_list 364 ---- 365 Again it is worth notice that the attr_list for each direction is 366 likely pruned depending on preferred and supported options. 368 If the 1st offer (from Alice) already defines a desired image size 369 for the recv direction the answerer can do one of the following: 371 1. Accept the image size and return it in the answer. 373 2. Replace with a list of options in the answer. 375 3. Remove the corresponding part completely. This may happen if it 376 is deemed that it is unlikely that the list of options is 377 supported. The answer will then lack a description for the send 378 direction and will look like: 379 ---- 380 a=imageattr:PT recv attr_list 381 ---- 383 3.3. Considerations 385 3.3.1. No imageattr in 1st offer 387 A high end device (Alice) may not see any need for the image 388 attribute as it most likely has the processing capacity to rescale 389 incoming video and may therefore not include the attribute in the 390 offer as it otherwise does not see any use for it. The answerer 391 (Bob) MAY include imageattr in the answer. This has two 392 implications: 394 o Longer session setup time due to extra offer/answer exchanges 396 o There is a risk that Alice does not recognize or support imageattr 397 and will thus anyway ignore the attribute. 399 3.3.2. Asymmetry 401 While the image attribute supports asymmetry there are some 402 limitations to this. One important limitation is that the codec 403 being used can only support up to a given maximum resolution for a 404 given profile level. 406 As an example H.264 with profile level 1.2 does not support higher 407 resolution than 352x288 (CIF). The offer/answer rules essentially 408 gives that the same profile level must be used in both directions. 409 This means that for an asymmetric scenario where Alice wants an image 410 size of 580x360 and Bob wants 150x120 profile level 2.2 is needed in 411 both directions even though profile level 1 would have been enough in 412 one direction. 414 Currently, the only solution to this problem is to specify two 415 unidirectional media descriptions. 417 3.3.3. sendonly and recvonly 419 If the directional attributes a=sendonly or a=recvonly are given for 420 a media, there is of course no need to specify the image attribute 421 for both directions. Therefore one of directions in the attribute 422 MAY be omitted. However it may be good to do the image attribute 423 negotiation in both directions in case the session is updated for 424 media in both directions at a later stage. 426 3.3.4. Sample aspect ratio 428 The sar parameter in relation to the x and y pixel resolution 429 deserves some extra discussion. Consider the offer from Alice to Bob 430 (we set the recv direction aside for the moment): 431 ---- 432 a=imageattr:97 send [sar=1.1,x=720,y=576] 433 ---- 434 If the receiver display has square pixels the 720x576 image would 435 need to be rescaled to for example 792x576 or 720x524 to ensure a 436 correct image aspect ratio. This in practice means that rescaling 437 would need to be performed on the receiver side, something that is 438 contrary to the spirit of this draft. 439 To avoid this problem Alice MAY specify a range of values for the sar 440 parameter like: 441 ---- 442 a=imageattr:97 send [sar=[0.91,1.0,1.09,1.45],x=720,y=576] 443 ---- 444 Meaning that Alice can encode with any of the mentioned sample aspect 445 ratios, leaving to Bob to decide which one he prefers. 447 The response MUST not include the sar parameter if there is no 448 acceptable value given. 450 3.3.5. SDPCapNeg support 452 T.B.D when the rest is settled. 454 3.3.6. Interaction with codec parameters 456 As most codecs specifies some kind of indication of eg. the image 457 size already at session setup some measures must be taken to avoid 458 that the image attribute conflicts with this already existing 459 information. 461 The following subsections describes the most well known codecs and 462 how they define image-size related information. 464 3.3.6.1. H.263 466 The payload format for H.263 is described in [RFC4629]. 468 H.263 defines (on the fmtp line) a list of image sizes and their 469 maximum frame rates (profiles) that the offerer can receive. The 470 answerer is not allowed to modify this list and must reject a payload 471 type that contains an unsupported profile. The CUSTOM profile may be 472 used for image size negotiation but support for asymmetry requires 473 the specification of two unidirectional media descriptions using the 474 sendonly/recvonly attributes. 476 3.3.6.2. H.264 478 The payload format for H.264 is described in [RFC3984]. This format 479 is subject to change and the update is described in [ref. to 480 RFC3984bis and other H.264 ext drafts] 482 H.264 defines image size related information in the fmtp line by 483 means of sprop-parameter-sets. According to the specification 484 several sprop-parameter-sets may be defined for one payload type. 485 The sprop-parameter-sets describe the image size (+ more) that the 486 offerer sends in the stream and need not be complete. This means 487 that this does not represent any negotiation. Moreover an answer is 488 not allowed to change the sprop-parameter-sets. 490 This configuration may be changed later inband if for instance image 491 sizes need to be changed or added. 493 3.3.6.3. MPEG-4 495 The payload format for MPEG-4 is described in [RFC3016]. 497 MPEG-4 defines a config parameter on the fmtp line which is a 498 hexadecimal representation of the MPEG-4 visual configuration 499 information. This configuration does not represent any negotiation 500 and the answer is not allowed to change the parameter. 502 Currently it is not possible to change the configuration using inband 503 signaling. 505 3.3.6.4. Possible solutions 507 The subsections above clearly indicate that this kind of information 508 must be aligned well with the image attribute to avoid conflicts. 509 There are a number of possible solutions: 511 o Ignore payload format parameters: This may not work well e.g in 512 the presence of bad channel conditions esp. in the beginning of a 513 session. Moreover this is not a good option for MPEG-4. 515 o 2nd session-wide offer/answer round: In the 2nd offer/answer the 516 codec payload format specific parameters are defined based on the 517 outcome of the imageattr negotiation. The drawback with this is 518 that setup of the entire session (including audio) may be delayed 519 considerably, especially as the imageattr negotiation can already 520 itself cost up to two offer/answer rounds. Also the conflict 521 between the imageattr negotiation and the payload format specific 522 parameters is still present after the first offer/anser round and 523 a fuzzy/buggy implementation may start media before the second 524 offer/answer is completed with unwanted results. 526 o 2nd session-wide offer/answer round only for video: This is 527 similar to the alternative above with the exception that setup 528 time for audio is not increased, moreover the port number for 529 video is set to 0 during the 1st offer answer round to avoid that 530 media flows. 531 This has the effect that video will blend in some time after the 532 audio is started (up to 2 seconds delay). This alternative is 533 likely the most clean-cut and failsafe alternative. The drawback 534 is, as the port number in the first offer is always zero, the 535 media startup will always be delayed even though it would in fact 536 have been possible to start media already after the first offer/ 537 answer round. 539 4. Examples 541 A few examples to highlight the syntax, here is assumed where needed 542 that Alice initiates a session with Bob 544 4.1. Example 1 545 ---- 546 a=imageattr:97 send [sar=1.1,x=800,y=640,q=0.6] [x=480,y=320] \ 547 recv [x=330,y=250] 548 ---- 550 Two image resolution alternatives are offered with 800x640 with 551 sar=1.1 having the highest preference 553 The example also indicates that Alice wish to display video with a 554 resolution of 330x250 on her display 556 In case Bob accepts the "recv [x=330,y=250]" the answer may look like 557 ---- 558 a=imageattr:97 recv [sar=1.1,x=800,y=640] \ 559 send [x=330,y=250] 560 ---- 562 Indicating that the receiver (Bob) wish the encoder (on Alice's side) 563 to compensate for a sample aspect ratio of 1.1 (11:10) and desires an 564 image size on its screen of 800x640. 566 There is however a possibility that "recv [x=330,y=250]" is not 567 supported. If the case, Bob may completely remove this part or 568 replace it with a list of supported image sizes. 569 ---- 570 a=imageattr:97 recv [sar=1.1,x=800,y=640] \ 571 send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]] 572 ---- 574 Alice can then select a valid image size which is closest to the one 575 that was originally desired (336x256) and performs a second offer/ 576 answer 577 ---- 578 a=imageattr:97 send [sar=1.1,x=800,y=640] \ 579 recv [x=336,y=256] 580 ---- 582 Bob replies with (actually not necessary): 583 ---- 584 a=imageattr:97 recv [sar=1.1,x=800,y=640] \ 585 send [x=336,y=256] 586 ---- 588 4.2. Example 2 589 ---- 590 a=imageattr:97 \ 591 send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \ 592 [x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \ 593 recv * 594 ---- 596 Two image resolution sets are offered with the first having a higher 597 preference (q=0.6). The x-axis resolution can take the values 480 to 598 800 in 16 pixels steps and 176 to 208 in 8 pixels steps. The par 599 parameter limits the set of possible x and y screen resolution 600 combinations such that 800x640 (ratio=1.25) is a valid combination 601 while 720x608 (ratio=1.18) or 800x608 (ratio=1.31) are invalid 602 combinations. 604 For the recv direction (Bob->Alice) Bob is requested to provide with 605 a list of supported image sizes 607 5. Issues 609 Here is listed a few possible issues and observations connected to 610 the use of the image attribute : 612 o Sample aspect ratios: Should it be possible to specify several 613 different values for sar? 615 o interlace parameter: It should be possible to include an interlace 616 parameter with the two values true and false for each set. 618 o Change of display during session: There are roughly speaking two 619 scenarios: 621 * The user plugs in an external monitor 623 * The user moves the call to another unit (SIP-REFER) 625 Likely these scenarios involve some kind of renegotiation. 627 o The syntax description may need to be improved. 629 o Image sharpening: In normal cases image sharpening is to be 630 performed after rescaling on the sender side, this also yields the 631 best possible image quality. There may however occur cases where 632 it is preferable to do the sharpening on the receiver side 633 instead. Big question is if this document should worry about this 634 as it has traditionally been up to the sender and/or receiver side 635 to determine if sharpening should be applied. 637 o Multiparty sessions: Currently only point-to-point scenarios is 638 considered, it is however possible that this formulation is used 639 for multiparty sessions with a mixer/transcoding device in the 640 middle. It should be possible to use imageattr for the latter 641 scenario but this must be studied more. 643 6. IANA Considerations 645 T.B.D 647 7. Security Considerations 649 This draft does not add any additional security issues other than 650 those already existing with currently specified offer/answer 651 procedures. 653 8. Acknowledgements 655 The authors would like to thank the people who has contributed with 656 objections and suggestions to this draft and provided with valuable 657 guidance in the amazing video-coding world. Special thanks go to 658 Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. 660 9. Changes 662 The main changes are: 664 From -01 to -02 666 * Cleanup of the sar and par parameters to make them match the 667 established conventions 669 * Requirement specification added 671 * New bidirectional syntax 673 * Interoperability considerations with well known video codecs 674 discussed 676 10. References 678 10.1. Informative References 680 [H.264] ITU-T, "ITU-T Recommendation H.264, 681 http://www.itu.int/rec/T-REC-H.264-200711-I/en". 683 [RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. 684 Kimata, "RTP Payload Format for MPEG-4 Audio/Visual 685 Streams", RFC 3016, November 2000. 687 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 688 with Session Description Protocol (SDP)", RFC 3264, 689 June 2002. 691 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 692 M., and D. Singer, "RTP Payload Format for H.264 Video", 693 RFC 3984, February 2005. 695 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 696 Description Protocol", RFC 4566, July 2006. 698 [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", 699 RFC 4587, August 2006. 701 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 702 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 703 January 2007. 705 [S4-080144] 706 3GPP, "Signaling of Image Size: Combining Flexibility and 707 Low Cost, http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/ 708 TSGS4_48/Docs/S4-080144.zip". 710 10.2. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, March 1997. 715 Authors' Addresses 717 Ingemar Johansson 718 Ericsson AB 719 Laboratoriegrand 11 720 SE-971 28 Lulea 721 SWEDEN 723 Phone: +46 73 0783289 724 Email: ingemar.s.johansson@ericsson.com 726 Kyunghun Jung 727 Samsung Electronics Co., Ltd. 728 Dong Suwon P.O. Box 105 729 416, Maetan-3Dong, Yeongtong-gu 730 Suwon-city, Gyeonggi-do 731 Korea 442-600 733 Phone: +82 10 9909 4743 734 Email: kyunghun.jung@samsung.com 736 Full Copyright Statement 738 Copyright (C) The IETF Trust (2008). 740 This document is subject to the rights, licenses and restrictions 741 contained in BCP 78, and except as set forth therein, the authors 742 retain all their rights. 744 This document and the information contained herein are provided on an 745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 752 Intellectual Property 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed to 756 pertain to the implementation or use of the technology described in 757 this document or the extent to which any license under such rights 758 might or might not be available; nor does it represent that it has 759 made any independent effort to identify any such rights. Information 760 on the procedures with respect to rights in RFC documents can be 761 found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use of 766 such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository at 768 http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at 774 ietf-ipr@ietf.org.