RE: New Editor's draft (v20140321)

I don't recall such definitive conclusions ever being reached in this group, but I'll take your word for it.  It is the right decision regardless. In that case, I agree with Jan-Ivar:  I have not seen a use case discussed in the context of this TF justifying the inclusion of getNativeSettings().  

It was in my opinion a mistake to only conduct discussion on inclusion of  this  feature  in the IETF.  There is not perfect overlap between participants in the W3C DAP/WebRTC WG's and the IETF RTCWeb WG.

-Giri

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, March 24, 2014 9:46 AM
To: Mandyam, Giridhar
Cc: Jan-Ivar Bruaroey; Harald Alvestrand; public-media-capture@w3.org
Subject: Re: New Editor's draft (v20140321)

Rolling back up the thread a little...

On 24 March 2014 07:31, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> For instance, say that getNativeSettings() returns {“frame rate”:  30.0, …}.
> However, a MediaStream was successfully created with 
> {“mandatory”:{“frame
> rate”: 60.0} …}.  Then the developer could have an indication as to 
> whether the UA is applying post-processing in trying to meet the 
> mandatory constraint, and may choose to adjust the constraint back to 
> 30 fps to avoid any UA-introduced processing delay.

I recall that on numerous occasions we have had discussions where everyone violently agrees that no information should be constructed to meet a constraint.  That means no interpolation to increase frame rate or resolution and probably a few other things I'm to fried to think of right now.

Received on Monday, 24 March 2014 17:06:25 UTC