W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: [Bug 23820] New: Add special values for PropertyValueRange to enable preference specification in optional constraints

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Wed, 20 Nov 2013 11:17:48 -0500
Message-ID: <528CE0AC.5060803@mozilla.com>
To: public-media-capture@w3.org
On 11/13/13 11:19 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23820
>
>              Bug ID: 23820
>             Summary: Add special values for PropertyValueRange to enable
>                      preference specification in optional constraints
>             Product: WebRTC Working Group
>             Version: unspecified
>            Hardware: PC
>                  OS: Windows NT
>              Status: NEW
>            Severity: normal
>            Priority: P2
>           Component: Media Capture and Streams
>            Assignee: public-media-capture@w3.org
>            Reporter: travil@microsoft.com
>                  CC: public-media-capture@w3.org
>
> We realized that we need to be able to specify "preference" and that the
> current technique for doing it isn't very nice (and not necessarily portable).
>
> To summarize the existing technique: you simply provide an ordered list of
> optional constraints where the values are the constrainable property's max+ or
> min- e.g.,:
> optional: [
>      { width: 1600 }, /* Where 1600 is the max width according to a previous
> capability check or simply a guess */
>      { height: 1200 }, /* Where 1200 is the max height according to a previous
> capability check or simply a guess */
>      { frameRate: 5 } /* Where 5 is the min framerate according to a previous
> capability check or simply a guess */
>    ]
> The net effect is that you've now stated (specifically for this UA/device) that
> "I prefer" best width over best height and that the framerate is to be
> completely deprioritized (in that order).
>
> So, after looking at that example, the proposal is to codify the concept of
> "best" by introducing keywords to make specifying these preferences easier.
>
> Proposal: Add special values of "min" and "max" as tokens that represent the
> minimum and maximum values for the constrainable property (whatever they may
> be).
>
> Given the proposal, the example becomes:
> optional: [
>      { width: "maximum" },
>      { height: "maximum" },
>      { frameRate: "minimum" }
>    ]
>
> With this proposal it becomes somewhat trivial to implement quality-of-service
> preferences for scenarios with multiple video/audio devices.
>
> The specific token names are up for negotiation :-) E.g., prop: {min:
> "minimum", max: "maximum" } might be silly.

Shouldn't we first nail down what min and max mean? e.g.

- Does { mandatory: { width: { min: 1024 } } } conservatively give me 1024x768
   or the highest available because I didn't constrain upward?

- Does { mandatory: { width: { max: 2880 } } } aggressively give me 2880x1800
   or the lowest available because I didn't constrain downward?

- Given choices, what does { mandatory: { width: { min: 1024, max: 2880 } } } give me?

I think we need to establish default behavior of the algorithm here (please point me to it if this is already done).

---

Without skirting the default issue, perhaps a 'prefer' keyword would help?

- { mandatory: { width: { min: 1024, max: 2880, prefer: 2880 } } }

This could be reused by devices to specify their native resolution if they have one.

.: Jan-Ivar :.
Received on Wednesday, 20 November 2013 16:18:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC