W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-constraints-resolution-03.txt

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 30 Aug 2013 07:55:14 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
CC: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C382A0D@ESESSMB209.ericsson.se>
On 2013-08-26 14:26, Harald Alvestrand wrote:
> I have updated my description of how to do resolution negotiation with
> input from -unified-plan and from the newly updated constraints update API.
> Comments welcome, but preferably on one mailing list; since this has
> turned into mainly API usage, I think the discussion should go on
> public-webrtc if it's not specifically about the SDP components.

Looking at the different settings (width, height, CPU load, frame-rate,
bit-rate, ...) in question width and height of the video stands out
since the correct setting can be automatically determined by the
receiving (or rather rendering) browser in a way that is obvious (by 
looking at the video element the MediaStream is attached to).

The others are either content related (e.g the appropriate frame rate
would depend on the content) or would require a lot of specification
work if browsers should behave the same (e.g. if CPU load is high,
should the receiving browser ask for reduced resolution, reduced frame
rate, both, or something else?). In addition we would have to specify 
signaling (if we wanted this to happen automatically). For resolution we 
have the image attribute, for bitrate b=AS I guess, but what about CPU-load?

On top of all this it seems like doing a SDP O/A to convey this kind of 
information is an overkill (and gives a certain risk for glare).

To me it is very tempting to for v1 say let's have API surface on the
sending side only, and let the receiving app signal to the sending app
in a non standardized way whatever it wants to influence. We can then
gain experience on the need for receiver side APIs (or automatic
signaling) for a later update.

And perhaps we will with time see RTP/RTCP development where these
things could be signaled there rather than requiring SDP updates.

>            Harald
> -------- Original Message --------
> Subject: 	New Version Notification for
> draft-alvestrand-constraints-resolution-03.txt
> Date: 	Mon, 26 Aug 2013 05:23:13 -0700
> From: 	internet-drafts@ietf.org
> To: 	Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand
> <harald@alvestrand.no>
> A new version of I-D, draft-alvestrand-constraints-resolution-03.txt
> has been successfully submitted by Harald Alvestrand and posted to the
> IETF repository.
> Filename:	 draft-alvestrand-constraints-resolution
> Revision:	 03
> Title:		 Resolution Constraints in Web Real Time Communications
> Creation date:	 2013-08-26
> Group:		 Individual Submission
> Number of pages: 10
> URL:http://www.ietf.org/internet-drafts/draft-alvestrand-constraints-resolution-03.txt
> Status:http://datatracker.ietf.org/doc/draft-alvestrand-constraints-resolution
> Htmlized:http://tools.ietf.org/html/draft-alvestrand-constraints-resolution-03
> Diff:http://www.ietf.org/rfcdiff?url2=draft-alvestrand-constraints-resolution-03
> 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.
>     It also discusses the possible use of SDP to carry that information
>     between browsers.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat
Received on Friday, 30 August 2013 07:55:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC