idnits 2.17.1 draft-alvestrand-constraints-resolution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 26, 2012) is 4259 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-burnett-rtcweb-constraints-registry-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-05) exists of draft-lennox-mmusic-sdp-source-selection-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Informational August 26, 2012 5 Expires: February 27, 2013 7 Resolution Constraints in Web Real Time Communications 8 draft-alvestrand-constraints-resolution-00 10 Abstract 12 This document specifies the constraints necessary for a Javascript 13 application to successfully indicate to a browser that supports 14 WebRTC what resolutions it desires on a video stream. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 27, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Disposition of this text . . . . . . . . . . . . . . . . . 3 58 2. Usage considerations . . . . . . . . . . . . . . . . . . . . . 3 59 3. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Examples with GetUserMedia . . . . . . . . . . . . . . . . 4 61 3.2. Possible SDP mappings . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 There are a number of scenarios where it's useful for a WebRTC 73 application to indicate to the WebRTC implementation in the supported 74 browser what the desired characteristics of a video stream are. 75 These include, but are not limited to: 77 o Specifying a minimum desired resolution for a given application, 78 in order to control the user experience or resource tradeoffs made 79 by the browser to favour a particular stream 81 o Specifying a maximum desired resolution for a given stream, in 82 order to save some resource (bandwidth, CPU....), possibly outside 83 of the browser where the browser can't tell that it's exceeding a 84 constraint 86 o Specifying resolutions that are a reasonable fit for the current 87 usage of the video stream, for instance fitting with the number of 88 pixels available on the part of a device's display surface that is 89 devoted to displaying this video stream 91 o Specifying the shape of a video stream, in order to fit the video 92 onto a display surface without the need for black bars or image 93 distortion 95 Similar considerations apply for framerate. 97 1.1. Disposition of this text 99 This draft is written in order to get something specific out to refer 100 to during spec-writing and implementation. The text may eventually 101 get merged into either the IETF document on SDP usage by RTCWEB, or 102 the W3C WEBRTC document on PeerConnection. 104 2. Usage considerations 106 These constraints are usable in several places: 108 o As constraints to the getUserMedia call 109 [W3C.WD-mediacapture-streams-20120628], where they serve to guide 110 the configuration of the camera obtained, and may influence the 111 choice of camera. 113 o As constraints to the addStream call on a PeerConnection 114 [W3C.WD-webrtc-20120821], where they serve to guide the 115 configuration of the codec that encodes the video content for 116 transmission. 118 o As constraints applied to an existing local video stream using the 119 "change constraints" API, where it may cause the video engine to 120 reconfigure the device or codec for that particular stream. 122 o As constraints applied to an incoming video stream using the 123 "change constrains" API on a MediaStreamTrack, where it serves to 124 inform the video engine about the desirable properties of the 125 video track, which may lead to the video engine choosing to 126 reencode the video and/or signal a remote video source that it 127 wishes certain constraints to be put in place. 129 All of the constraints may be meaningful in both "mandatory" and 130 "optional" forms. 132 3. Usage examples 134 See Section 4 for the actual definition of the constraints used here. 136 3.1. Examples with GetUserMedia 138 A constraint saying that we absolutely must have a minimum resolution 139 of 1024x768: 141 getUserMedia({ 142 video: { mandatory: { minWidth: 1024, minHeight: 768 } } 143 }, successCallback, errorCallback); 145 A constraint saying that we'd prefer 60 frames per second, if 146 available, and if we can get that, we'd like to limit the max 147 resolution, but in all cases, the screen must be clamped to a 4:3 148 aspect ratio - 16:9 or odd aspect ratios are not acceptable to this 149 application: 151 getUserMedia({ 152 video: { 153 mandatory: { minAspectRatio: 1.333, maxAspectRatio: 1.334 }, 154 optional [ 155 { minFrameRate: 60 }, 156 { maxWidth: 640 }, 157 { maxHeigth: 480 } 158 ] 159 } 160 }, successCallback, errorCallback); 162 3.2. Possible SDP mappings 164 This document does not specify or constrain how constraints get 165 reflected into SDP (if they do); that's an implementor decision. 167 The examples below are thought exercises, based on 168 [I-D.lennox-mmusic-sdp-source-selection] and 169 [I-D.alvestrand-rtcweb-resolution]. 171 An optional constraint has been applied to an incoming stream where 172 both upper and lower are constrained to 320x200. The stream has been 173 assigned to a hardware video decoder that can decode most resolutions 174 up to 1024x768, in any aspect ratio, but only if all divisions are 175 divisible by 4. The incoming stream has SSRC 1234. 177 Line breaks are added for readability. 179 m=video 180 a=remote-ssrc:1234 imageattr:* [x=320,y=200,q=1.0] \ 181 [x=[120:4:1024],y=[100:4:768],q=0.2] 183 4. IANA Considerations 185 This document requests IANA to register constraints in the "RTCWeb 186 Media Constraints" registry created by 187 [I-D.burnett-rtcweb-constraints-registry]. NOTE: The registrations 188 assume that this document is updated to no longer have "video" as 189 part of the name, but have "video" as a field-of-use in the 190 registration. 192 The definitions of width, height and aspect ratio are taken from 193 [RFC6236]. 195 o MinWidth - valid for video. Corresponds to the "x" value (pixel 196 count) from RFC 6236. Only integer values are valid. 198 o MaxWidth - valid for video. Definition as for MinWidth. 200 o MinHeight - valid for video. Corresponds to the "y" value (pixel 201 count) from RFC 6236. Only integer values are valid. 203 o MaxHeight - valid for video. Definition as for MinHeight. 205 o MinAspectRatio - valid for video. Corresponds to the "par" 206 (picture aspect ratio), with "sar" set to 1.0. A 4:3 format 207 display corresponds to an AspectRatio of 1.3333. Floating point 208 values are valid. 210 o MaxAspectRatio - valid for video. Definition as for 211 MinAspectRatio. 213 o MinFramerate - valid for video. Corresponds to the framerate 214 defined in [RFC4566], the "a=framerate" attribute. 216 o MaxFramerate - valid for video. Definition as for MinFramerate. 218 The contact person is Harald Alvestrand . 220 Change control for the registration is with the IETF, as designated 221 by the IESG. 223 Note that MinFramerate defines a lower bound for the a=framerate 224 attribute, which is itself defined as an upper limit; this means that 225 even if a high framerate is negotiated, the actual framerate used may 226 be lower due to temporary considerations (for instance CPU or 227 bandwidth, or simply lack of movement in the picture). 229 5. Security Considerations 231 No security considerations particular to these specific constraints 232 have so far been identified. 234 6. Acknowledgements 236 Special thanks are given to Dan Burnett, Cullen Jennings, the IETF 237 RTCWEB WG and the W3C WEBRTC WG for strongly influencing this memo. 239 7. References 241 7.1. Normative References 243 [I-D.burnett-rtcweb-constraints-registry] 244 Burnett, D., "IANA Registry for RTCWeb Media Constraints", 245 draft-burnett-rtcweb-constraints-registry-01 (work in 246 progress), April 2012. 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 252 Description Protocol", RFC 4566, July 2006. 254 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 255 Attributes in the Session Description Protocol (SDP)", 256 RFC 6236, May 2011. 258 7.2. Informative References 260 [I-D.alvestrand-rtcweb-resolution] 261 Alvestrand, H., "RTCWEB Resolution Negotiation", 262 draft-alvestrand-rtcweb-resolution-00 (work in progress), 263 April 2012. 265 [I-D.lennox-mmusic-sdp-source-selection] 266 Lennox, J. and H. Schulzrinne, "Mechanisms for Media 267 Source Selection in the Session Description Protocol 268 (SDP)", draft-lennox-mmusic-sdp-source-selection-04 (work 269 in progress), March 2012. 271 [W3C.WD-mediacapture-streams-20120628] 272 Burnett, D. and A. Narayanan, "Media Capture and Streams", 273 World Wide Web Consortium WD WD-mediacapture-streams- 274 20120628, June 2012, . 277 [W3C.WD-webrtc-20120821] 278 Bergkvist, A., Burnett, D., Jennings, C., and A. 279 Narayanan, "WebRTC 1.0: Real-time Communication Between 280 Browsers", World Wide Web Consortium WD WD-webrtc- 281 20120821, August 2012, 282 . 284 Author's Address 286 Harald Alvestrand 287 Google 289 Email: harald@alvestrand.no