Re: Constraints and MediaRecorder

On Feb 3, 2014, at 12:44 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/3/14 2:05 PM, Cullen Jennings wrote:
>> On Feb 3, 2014, at 10:32 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>>> These are all fine, but this offers little material support for the
>>> use of constraints in this specific use case.  Is there anything wrong
>>> with:
>>> 
>>> app: get me a 96kHz recorder
>>> browser: can't do that
>> le.
>> I’d be fine with that but that is not what the discussion is about. The discussion is if the app can control the setting or even discover what is being provided. What I sent to to roc was "The constraint API has moved to support more or less exactly what you propose below but calls it a setting. " I agree, often capabilities + settings can do what you need without constraints. To put it in context here, the conversation we are discussing
>> 
>> app: get me a 48KHz recorder
>> browsers: thinks to itself that it can’t do but decides that the browser know better than the app developer what the app app really needs and decides to say just take the app data from 22KHz recorder and pretend it it was from a 48KHz recorder
>> 
>> I agree that an application could solve this problem with settings, or with capabilities, or with constraints. I’m just saying that you need one of those three.
> 
> Great, I vote for settings then because settings are just dictionaries. Being able to read the settings from the resulting object as the same dictionary that was used as a constructor argument seems reasonable to me.

So are you fine with the Settings dictionary as defined in the Constrainable interface? And are you also Ok with find out what things are supported using the Capabilities dictionary as defined in Constrainable interface?

I think what roc was proposing was that the object passed to the API would be be a MediaRecorderOptions and looks like

{
	width = 640;
	height = 480;
}

Using the Constraints part of the Constrainable API you would need pass to get the above is

{ 
  mandatory:
  {
     width = 640;
     height = 480;
  }
}

Assuming that the stream 640x480, the setting API would return an object that looked like

{
	width = 640;
	height = 480;
}


Which seems very close to what roc had. 

I’ve pretty much lost track of what you are proposing we do. You are proposing we just ask the browser for a stream, it gives us whatever it wants, and then the app uses the setting API to figure out what the browser provided ? Mostly I just care that I have some way of doing this but I agree with Roc that not having to loop over a trial / test type interface makes more sense to me.

Received on Monday, 3 February 2014 22:34:02 UTC