Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Standards Track May 20, 2008 Expires: November 21, 2008 Image attributes in SDP draft-johansson-mmusic-image-attributes-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 November 21, 2008. Abstract This draft proposes a new generic session setup 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 e.g a low-end hand- held terminal to display video without the need to resample the image, something that may consume large amounts of memory and processing power. 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]. Johansson Expires November 21, 2008 [Page 1] Internet-Draft Image attributes in SDP May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . . 3 3. Defintion of attribute . . . . . . . . . . . . . . . . . . . . 3 3.1. SDPCapNeg . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Example 4 (offer/answer) . . . . . . . . . . . . . . . . . 5 4.5. Example 5 (SDPCapNeg offer/answer) . . . . . . . . . . . . 6 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Normative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Johansson Expires November 21, 2008 [Page 2] Internet-Draft Image attributes in SDP May 2008 1. Introduction This draft 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 Possible for a e.g a low-end hand-held device to display video without the need to resample the image size o The device will know the size of the image and can then allocate memory accordingly Several of the existing standards (see [RFC4587], [RFC4629] and [RFC3984]) has support for enabling the receiver to ask for different resolutions at different framerates. The purpose of this memo is to provide for a generic mechanism and is targeted at the image size. 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 "imageattr" attribute is defined. The imageattr attribute contains a set of different image-resolution options that the offerer can provide. The receiver can then select the desired image size and has then the ability to avoid costly transform (e.g resampling) of the images. In this approach only the image resolution and optionally the framerate is handled but the framework makes it possible to extend with other image related attributes that makes sense. The syntax for the imageattr attribute is: a=imageattr: 1*WSP 1*WSP can have the values landscape or portrait is the payload type number proto-list = proto *(1*WSP proto) ; defined in RFC 4566 Johansson Expires November 21, 2008 [Page 3] Internet-Draft Image attributes in SDP May 2008 The proto field is defined by proto=[x=range,y=range] fr is the framerate range for the given set (optional). x is the horizontal image size range y is the vertical image size range range is (in matlab or octave syntax) given by range=value or range=value:value or range=value:step:value value is a positive integer value step is a positive or negative integer value. If step is left out in the syntax a stepsize of 1 is implied. The imageattr attribute is bound to a specific media by means of the payload type number. Several imageattr can be defined e.g for different video codec alternatives conditioned that the payload type number differs. The imageattr definitions has different preferences such that the leftmost (first) proto field has the highest preference. The landscape and portait definitions are used to reduce the number of odd image size options. In landscape only entries where x>=y are valid. In portrait only entries where y>=x are valid. The offerer MUST be able to support the image attributes that it offers. The receiver MAY accept the imageattr but is not required to do so. The receiver MUST only include a valid entry taken from the offer in the SDP answer. 3.1. SDPCapNeg For use with the SDP capability negotiation framework (SDPCapNeg) an extra attribute "imcap" is defined with the syntax: a=imcap: 1*WSP 1*WSP can have the values landscape or portrait is a number from 1 to 1^32-1 both included. proto-list = proto *(1*WSP proto) ; defined in RFC 4566 The proto field is defined as earlier in this text. The imcap attributes are referenced with the parameter "im" in the pcfg and acfg lines. Several imcap may be referenced in the Johansson Expires November 21, 2008 [Page 4] Internet-Draft Image attributes in SDP May 2008 potential configurations. The ability to support the imcap attribute MUST be specified with the "im-v0" identifier on the a=ccap line or using the "+" option on the pcfg line and optionally also on the a=csup line. 4. Examples A few examples to highlight the syntax 4.1. Example 1 a=imageattr:97 landscape [x=800,y=640] [x=480,y=320] Two image resolution alternatives (landscape) are offered with 800x600 having the highest preference 4.2. Example 2 a=imageattr:97 landscape [fr=[5:15],x=800,y=640] / [fr=[15:30],x=480,y=320] Two image resolution alternatives (landscape) with different framerates are offered with 800x600 having the highest preference. 4.3. Example 3 a=imageattr:98 landscape [x=800:-16:480,y=640:-16:320] / [x=208:-8:176,y=176:-8:144] Two image resolution ranges (landscape) are offered with 800x600 having the highest preference. The x-axis resolution can take the values 800 down to 480 in 16 pixels steps and 208 down to 176 in 8 pixels steps. Because of the 'landscape' definition only x and y combinations where x>=y are valid. 4.4. Example 4 (offer/answer) Given the offer from example 2 above a=imageattr:98 landscape [x=800:-16:480,y=640:-16:320] / [x=208:-8:176,y=176:-8:144] An answer to this offer may look like a=imageattr:98 landscape [x=192,y=160] Johansson Expires November 21, 2008 [Page 5] Internet-Draft Image attributes in SDP May 2008 Indicating that the answerer wish to render the video through a rectangular 192x160 block (image). 4.5. Example 5 (SDPCapNeg offer/answer) An offer using the SDPCapNeg formulation may look like m=video .... a=ccap:med-v0,im-v0 m=mcap:1 H_264 a=imcap:1 landscape [x=800:-16:480,y=640:-16:320] / [x=208:-8:176,y=176:-8:144] a=pcfg t=.. a=.. m=.. im=1 pt=1:97 The SDP answer may then look like m=video .... a=csup:med-v0,im-v0 a=imageattr:97 landscape [x=192,y=160] a=acfg t=.. a=.. m=.. im=1 pt=1:97 Note the inclusion of the "clear text" imageattr in the answer that gives the desired image size. 5. Issues Here is listed a few possible issues connected to the use of the imageattr SDP attribute : o Conflict with sprop-parameter-set: H.264 defines the sprop- parameter-set which may define features as defined in this draft. To avoid conflicts sessions that use the imageattr attribute MUST not specify similar features in sprop-parameter-set. o Image scaling on encoder side: e.g the H.264 codec is not mandated to rescale the video to fit a preferred receiver image size. If this is the case then a possible solution is that only a part of the input, corresponding to the preferred size, is encoded. Preferably this part is also displayed on the sender display as well to avoid that the important parts drop out of the image. o Odd resolution combinations: Given the format of the offered resolution there is a chance that the receiver may ask for an odd resolution like 800x176. These scenarios are however less likely and can also be avoided by specifying several ranges. Johansson Expires November 21, 2008 [Page 6] Internet-Draft Image attributes in SDP May 2008 6. IANA Considerations 7. Security Considerations 8. Acknowledgements 9. References 9.1. Informative References [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. 9.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 73 0783289 Email: ingemar.s.johansson@ericsson.com Johansson Expires November 21, 2008 [Page 7] Internet-Draft Image attributes in SDP May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Johansson Expires November 21, 2008 [Page 8]