Re: UserMediaSettings

Thanks first of all.

A year ago our API used dictionaries, not objects, and there was no 
Constrainable interface.

I would argue my proposal is actually much closer to what we had then 
than where the spec has moved since (moves I find exiguous support for 
in the list archives).

Where my proposal is dissimilar from a year ago, it addresses problems 
discovered over the last year.

Where my proposal is dissimilar from today's spec, it addresses problems 
introduced in the last year.

.: Jan-Ivar :.

On 2/21/14 4:39 AM, Cullen Jennings wrote:
> I probably would have supported this API had it been proposed a year ago but at  this point I don’t see any advantage of it and I’m not seeing much consensus to change to it.
>
>
> On Feb 21, 2014, at 5:13 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>
>> (Hopefully fixes messed-up indentation)
>>
>> Constraints went general at every turn. What if we went the other way?
>>
>> Roc's MediaRecorder proposal http://lists.w3.org/Archives/Public/public-media-capture/2014Feb/0001.html was dismissed for not being compatible with constraints in gUM, so it seems there's no way around addressing gUM.
>>
>> Here's how to solve gUM with dictionaries, while keeping functional parity.
>>
>> The goal is to learn from constraints yet rid the spec of them entirely, as nothing less will simplify.
>>
>> dictionary UserMediaSettings {
>>     boolean video;
>>     boolean audio;
>>     DOMString peerIdentity;
>>     long width;
>>     long height;
>>     double aspectRatio;
>>     double frameRate;
>>     VideoFacingModeEnum facingMode;
>>     double volume;
>>     unsigned long sampleRate;
>>     unsigned long sampleSize;
>>     boolean echoCancelation;
>>
>>     // Dictionary may be extended through gUM-specific IANA registry.
>> };
>>
>> dictionary Request {
>> {
>>     DOMString require; // explained below
>>     DOMString prefer;  // explained below
>> };
>>
>> dictionary UserMediaSettingsRequest : Request {
>> {
>>     boolean video;
>>     boolean audio;
>>     DOMString peerIdentity;
>>     (unsigned long or UnsignedLongRequest) width;
>>     (unsigned long or UnsignedLongRequest) height;
>>     (double or DoubleRequest) aspectRatio;
>>     (double or DoubleRequest) frameRate;
>>     (VideoFacingModeEnum or sequence<VideoFacingModeEnum>) facingMode;
>>     (double or DoubleRequest) volume;
>>     (unsigned long or UnsignedLongRequest) sampleRate;
>>     (unsigned long or UnsignedLongRequest) sampleSize;
>>     boolean echoCancelation;
>>
>>     // Dictionary may be extended through gUM-specific IANA registry.
>> };
>>
>> dictionary UnsignedLongRequest {
>>     unsigned long min;
>>     unsigned long max;
>>     unsigned long ideal;
>> };
>>
>> Clients may list the names of keys they require. Example:
>>
>>   var request =
>>   {
>>     require: "width, height",
>>     width: { min: 640, ideal: 1280 },
>>     height: { min: 480, ideal: 768 },
>>     aspectRatio: 16/9,
>>     frameRate: 60,
>>     facingMode: "user",
>>   };
>>   navigator.getUserMedia(request, success, failure);
>>
>> If they do, getUserMedia will fail if required keys are either missing, unknown or unsatisfied.
>>
>> There is no order by default, instead sources are ranked by how many settings they satisfy, with the UA breaking a tie for the default choice (which end-users may ultimately override).
>>
>> Clients who prefer an order may do this:
>>
>>   var request =
>>   {
>>     require: "width, height",
>>     prefer: "aspectRatio",
>>     width: { min: 640, ideal: 1280 },
>>     height: { min: 480, ideal: 768 },
>>     aspectRatio: 16/9,
>>     frameRate: 60,
>>     facingMode: "user",
>>   };
>>   navigator.getUserMedia(request, success, failure);
>>
>> which will pick a 16:9 environment-facing 75Hz camera over a user-facing 60hz 4:3 camera, without requiring 16:9.
>>
>> getUserMedia will not fail if preferred keys are missing, unknown or unsatisfied.
>>
>> MediaStreamTrack re-absorbs the affected functionality:
>>
>> interface MediaStreamTrack : EventTarget {
>>
>>     UserMediaSettingsRequest getInherentCapabilities ();
>>     UserMediaSettings        snapshotCurrentSettings ();
>>     void                     applySettings (UserMediaSettingsRequest settings,
>>                                             VoidFunction successCallback,
>> ConstraintErrorCallback errorCallback);
>>                 attribute EventHandler onconflict;
>>
>>     readonly    attribute DOMString             kind;
>>     readonly    attribute DOMString             id;
>>     readonly    attribute DOMString             label;
>>                 attribute boolean enabled;
>>     readonly    attribute boolean               muted;
>>                 attribute EventHandler onmute;
>>                 attribute EventHandler onunmute;
>>     readonly    attribute boolean _readonly;
>>     readonly    attribute boolean remote;
>>     readonly    attribute MediaStreamTrackState readyState;
>>                 attribute EventHandler onstarted;
>>                 attribute EventHandler onended;
>>     MediaStreamTrack clone ();
>>     void             stop ();
>> };
>>
>> More than just renaming, there is no universal constraint concept, no Constrainable interface, no object-based constraint object, and no co-mingled domain-spanning data definitions outside of WebIDL.
>>
>> Things are well defined in context using standard WebIDL.
>>
>> MediaRecorder may borrow what little it needs or invent its own API.
>>
>> .: Jan-Ivar :.