- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Wed, 20 Nov 2013 11:17:48 -0500
- 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