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: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 30 Aug 2013 11:51:34 +0200
Message-ID: <52206B26.3010006@alvestrand.no>
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

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