[rtcweb] Resolution negotiation - a contribution
Harald Alvestrand <harald@alvestrand.no> Thu, 12 April 2012 08:46 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6021F8644 for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 01:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level:
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGNJvRbNE6W3 for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 01:46:02 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0321F8636 for <rtcweb@ietf.org>; Thu, 12 Apr 2012 01:46:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A62B839E178 for <rtcweb@ietf.org>; Thu, 12 Apr 2012 10:46:01 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcleHKqSvqBB for <rtcweb@ietf.org>; Thu, 12 Apr 2012 10:46:00 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BD34039E082 for <rtcweb@ietf.org>; Thu, 12 Apr 2012 10:46:00 +0200 (CEST)
Message-ID: <4F869648.2020605@alvestrand.no>
Date: Thu, 12 Apr 2012 10:46:00 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Resolution negotiation - a contribution
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 08:46:03 -0000
Hello folks, after the IETF, I've attempted to gather together information about resolution negotiation and what we might need to do there. I pulled together the paragraphs below - this may want to be incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go somewhere else. Chairs' guidance is appreciated. At the moment, I have it in xml2rfc format, so it should be easy to do cut-and-paste on it, but don't want to push it as a separate I-D unless that's what the chairs desire. Note - there are some QUERY sections in there - I'm unsure what those should be resolved to. Comments? Harald 2. Requirements The relevant requirement for video resolution negotiation from the RTCWEB use cases document [I-D.ietf-rtcweb-use-cases-and-requirements] is: o F25 The browser SHOULD use encoding of streams suitable for the current rendering (e.g. video display size) and SHOULD change parameters if the rendering changes during the session. The resulting need is: o To negotiate a maximum spatial resolution for all videos at call setup time o To negotiate a maximum temporal resolution ("frame rate") across all videos at call setup time o To indicate the desire of the recipient for a particular spatial or temporal resolution on a particular video source o To indicate the intent of the sender to send a video source in a particular spatial or temporal resolution This document does not mention other requirements. 3. SDP negotiation of video resolution An RTCWEB client MUST support negotiation of resolution using the "imageattr" attribute, as documented in [RFC6236]. An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and MAY choose to support only the 1.0 value of the "sar" attribute. The interpretation of the negotiation is that any video stream in the m= line containing the a=imageattr attribute will have a resolution within the bounds established by the negotiation. An RTCWEB client MUST support negotiation of the "a=framerate" attribute, as specified in [RFC4566] section 6. Note that this is an upper bound on framerate; there is no lower bound negotiated. These requirements are necessary and sufficient for establishing the maximum spatial and temporal resolution for all videos at call setup time. These bounds MAY be renegotiated over the course of the call, but MUST NOT be renegotiated to render any currently transmitted video stream out of bounds; the sending video stream MUST first be changed to be of a resolution that fits within both the old and the new bounds, or halted. <<QUERY: Is this necessary or sufficient restriction???>> An RTCWEB client MUST support per-SSRC requests for video resolutions, as described in [I-D.lennox-mmusic-sdp-source-selection]. This satisfies the requirement to indicate the desire of the recipient for a particular spatial or temporal resolution. We assume that the media sent from a sender to a receiver contains enough information inside the media format to tell what the resolution and framerate is. <<QUERY: Do we need to extend RFC 5576 with an "imageattr" or "framerate" attribute in the forward direction instead?>> 4. Non-SDP negotiation of video resolution An RTCWEB client MAY support the COP mechanism [I-D.westerlund-avtext-codec-operation-point] to negotiate the resolution of video within the limits established by the SDP negotiation without the need for additional SDP exchanges. 5. Relation to WebRTC API constraint It is intended that the resolution negotiation be influenced by the constraints set by the application of either mandatory or optional constraints at the WebRTC API, as registered in the registry established by [I-D.burnett-rtcweb-constraints-registry]. The following relationships hold for all attributes that the implementation intends to satisfy (note that the constraints listed here have NOT been registered yet): video-min-height >= value of imageattr y= xyrange lower bound video-max-height <= value of imageattr y= xyrange upper bound video-min-framerate is not represented in SDP video-max-framerate <= value of a=framerate attribute video-min-aspect-ratio <= value of imageattr "par=" prange lower bound video-max-aspect-ratio >= value of imageattr "par=" prange upper bound The implementation is free to increase "min" values or decrease "max" values (make requirements more restrictive) and add "step" in order to fit with its implementation restrictions. <<NOTE - check the value of the direction of those assumptions>>. Constraints specified at PeerConnection creation time are reflected as SDP-wide values. Constraints specified when creating a MediaStream or attaching a MediaStream to a PeerConnection are reflected as ssrc-specific values.
- [rtcweb] Resolution negotiation - a contribution Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Timothy B. Terriberry
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Marshall Eubanks
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- [rtcweb] VP8 payload, decoder processing capabili… Stephan Wenger
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Yuepeiyu (Roy)
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- [rtcweb] Alternative Proposal for Dynamic Codec P… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Timothy B. Terriberry
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Bernard Aboba
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Cullen Jennings (fluffy)
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Harald Alvestrand