- 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>
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