This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23820 - Add special values for PropertyValueRange to enable preference specification in optional constraints
Summary: Add special values for PropertyValueRange to enable preference specification ...
Status: RESOLVED DUPLICATE of bug 25884
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-14 04:19 UTC by Travis Leithead [MSFT]
Modified: 2014-05-26 10:01 UTC (History)
3 users (show)

See Also:


Attachments

Description Travis Leithead [MSFT] 2013-11-14 04:19:20 UTC
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.
Comment 1 Silvia Pfeiffer 2013-11-14 10:23:07 UTC
I would like to see a property value that codifies "give me your best effort", too. I'd call it "minPossible" and "maxPossible" or something similar that is no "min" and "max", because we have these already as property names, so should not duplicate them as property values.

For example:

{
  mandatory: {
    { width: "maxPossible" },
    { height: "maxPossible" }
  },
  optional: [
    { frameRate: {max: 5} }
  ]
}   

would give me a low framerate but high quality video.
Comment 2 Silvia Pfeiffer 2013-11-14 10:30:46 UTC
I should add this to be in contrast to:

{
  mandatory: {
    { frameRate: "maxPossible" }
  },
  optional: [
    { height:  {min: "minPossible"}}
  ]
}

Which asks for the highest possible framerate at a small resolution.
Comment 3 Travis Leithead [MSFT] 2013-11-19 19:32:01 UTC
(In reply to Silvia Pfeiffer from comment #2)

>   mandatory: {
>     { frameRate: "maxPossible" }

I'm actually not really sure what these values mean in the context of a mandatory constraint. Since (in theory) they can _always_ be satisfied, aren't they the same thing as an "optional" constraint? Perhaps we don't need them for mandatory constraints...?
Comment 4 Silvia Pfeiffer 2013-11-22 00:42:49 UTC
(In reply to Travis Leithead [MSFT] from comment #3)
> (In reply to Silvia Pfeiffer from comment #2)
> 
> >   mandatory: {
> >     { frameRate: "maxPossible" }
> 
> I'm actually not really sure what these values mean in the context of a
> mandatory constraint. Since (in theory) they can _always_ be satisfied,
> aren't they the same thing as an "optional" constraint? Perhaps we don't
> need them for mandatory constraints...?

Maybe.... but how do you guarantee to the Web Dev that you're providing the maximum frameRate that is possible with the given camera? If you put that into "optional", the browser is free to ignore it and return the smallest frameRate.
Comment 5 Travis Leithead [MSFT] 2013-11-22 01:52:07 UTC
(In reply to Silvia Pfeiffer from comment #4)
> Maybe.... but how do you guarantee to the Web Dev that you're providing the
> maximum frameRate that is possible with the given camera? If you put that
> into "optional", the browser is free to ignore it and return the smallest
> frameRate.

It seems to me that if you're comfortable being able to use the concept of maximum/minimum at all, then you've already allowed for the possibility of not guaranteeing a consistent experience across a variety of devices, right? (Otherwise, you would have specified an exact value as a mandatory constraint.) It follows that if you're OK with variability in the experience, then being able to politely ask for the best possible experience via "optional" or "preference" input is about the same guarantee. The only difference I can see is whether you think the Browser is out to get you by not granting your polite requests. Why would a browser _not_ try to satisfy your preferences, in order?

It seems counter-productive to assume that if you set some options/preferences, that the browser probably won't give you them...? I would assume that the browser will make a best-effort to grant them! (That's how I'd code up this feature anyway.) 

Without any options/preferences set _at all_ then the browser is free to fallback to defaults which may/may not be what you want.
Comment 6 Silvia Pfeiffer 2013-11-24 02:10:09 UTC
(In reply to Travis Leithead [MSFT] from comment #5)
> (In reply to Silvia Pfeiffer from comment #4)
> > Maybe.... but how do you guarantee to the Web Dev that you're providing the
> > maximum frameRate that is possible with the given camera? If you put that
> > into "optional", the browser is free to ignore it and return the smallest
> > frameRate.
> 
> It seems to me that if you're comfortable being able to use the concept of
> maximum/minimum at all, then you've already allowed for the possibility of
> not guaranteeing a consistent experience across a variety of devices, right?

No. I am trying to get the best possible experience to the user. If the user has a camera that is capable of 720p, then I want to make use of that capability. If the user has a camera that is only capable of 640x480, then I'll accept that. I can't require 720p ("mandatory"), because in the second case, it will fail and I won't get any video.


> It follows that if you're OK with variability in the
> experience, then being able to politely ask for the best possible experience
> via "optional" or "preference" input is about the same guarantee.

I don't want to have to specify all possible high camera resolutions in the optional constraints from top to bottom as optional constraints, just to be missing the odd one out of the particular camera model that a user has and then end up providing whatever default the browser has (Chrome defaults to 640x480). Instead, I want the browser to go, find out what the best possible resolution of the camera is, and give that to me. How do you want that to be specified?
Comment 7 Harald Alvestrand 2014-05-26 10:01:51 UTC
This use case has been subsumed under the "ideal" part of the constraints reworking described in bug 25884.

Closing as "duplicate" - really "overtaken by events".

*** This bug has been marked as a duplicate of bug 25884 ***