- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 30 Aug 2013 11:51:34 +0200
- To: public-webrtc@w3.org
On 08/30/2013 09:55 AM, Stefan Håkansson LK wrote: > 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). Actually it's not quite that obvious.... we have limitations like the need for width & height being a whole number of macroblocks, we have applications that want to preserve aspect ratio and use letterboxing / pillaring, we have applications that prefer consistent image quality to rescaling, we have applications that so want to have rapid up-scaling when a stream is maximized that they're OK with "wasting" the bits while it's in a smaller window..... > > 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). Depends on your signalling channel's speed, of course. But it's a lot of work. > > 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. Given all the interaction with application opinions mentioned above, my tendency goes into the same direction. > > And perhaps we will with time see RTP/RTCP development where these > things could be signaled there rather than requiring SDP updates. ...if Ericsson's patent application on COP is either not granted or licensed in an acceptable fashion... > >> 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 09:51:02 UTC