Network Working Group H. Alvestrand Internet-Draft Google Intended status: Informational October 21, 2012 Expires: April 24, 2013 Resolution Constraints in Web Real Time Communications draft-alvestrand-constraints-resolution-01 Abstract This document specifies the constraints necessary for a Javascript application to successfully indicate to a browser that supports WebRTC what resolutions it desires on a video stream. 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 24, 2013. Copyright Notice Copyright (c) 2012 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 Alvestrand Expires April 24, 2013 [Page 1] Internet-Draft Resolution Constraints October 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Disposition of this text . . . . . . . . . . . . . . . . . 3 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Scenario: Resolution change . . . . . . . . . . . . . . . . 4 2.2. Scenario: Constrained bandwidth . . . . . . . . . . . . . . 5 3. Syntax and Mapping Examples . . . . . . . . . . . . . . . . . . 6 3.1. Examples with GetUserMedia . . . . . . . . . . . . . . . . 6 3.2. SDP mappings . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Changes from -00 to -01 . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Alvestrand Expires April 24, 2013 [Page 2] Internet-Draft Resolution Constraints October 2012 1. Introduction There are a number of scenarios where it's useful for a WebRTC application to indicate to the WebRTC implementation in the supported browser what the desired characteristics of a video stream are. These include, but are not limited to: o Specifying a minimum desired resolution for a given application, in order to control the user experience or resource tradeoffs made by the browser to favour a particular stream o Specifying a maximum desired resolution for a given stream, in order to save some resource (bandwidth, CPU....), possibly outside of the browser where the browser can't tell that it's exceeding a constraint o Specifying resolutions that are a reasonable fit for the current usage of the video stream, for instance fitting with the number of pixels available on the part of a device's display surface that is devoted to displaying this video stream o Specifying the shape of a video stream, in order to fit the video onto a display surface without the need for black bars or image distortion Similar considerations apply for framerate. 1.1. Disposition of this text This draft is written in order to get something specific out to refer to during spec-writing and implementation. The text may eventually get merged into the JSEP specification, [I-D.ietf-rtcweb-jsep]. 2. Usage Scenarios These constraints are usable in several places: o As constraints to the getUserMedia call [W3C.WD-mediacapture-streams-20120628], where they serve to guide the configuration of the camera obtained, and may influence the choice of camera. o As constraints to the addStream call on a PeerConnection [W3C.WD-webrtc-20120821], where they serve to guide the configuration of the codec that encodes the video content for transmission. Alvestrand Expires April 24, 2013 [Page 3] Internet-Draft Resolution Constraints October 2012 o As constraints applied to an existing local video stream using the "change constraints" API, where it may cause the video engine to reconfigure the device or codec for that particular stream. o As constraints applied to an incoming video stream using the "change constrains" API on a MediaStreamTrack, where it serves to inform the video engine about the desirable properties of the video track, which may lead to the video engine choosing to reencode the video and/or signal a remote video source that it wishes certain constraints to be put in place. All of the constraints may be meaningful in both "mandatory" and "optional" forms. Consider the following (simplified) model of a video stream through a WebRTC application: |<-------------- Browser A -------------------->| Camera ---> Mediastream A ---> Peerconnection A ------+ |<------- Application A ---------->| | v ^ v Signalling channel Internet (media) v ^ | |<------- Application B ---------->| |