RE: Revised Constraints modification API proposal

> From: Dan Burnett [mailto:dburnett@voxeo.com]
> On Aug 21, 2012, at 4:56 PM, Travis Leithead wrote:
> > As a reminder, the goal of this proposal is to facilitate "informed
> > constraints" (i.e., allow constraints to be applied after existing
> > client capabilities are known) in order to avoid potential pitfalls of
> > blindly over-constrained use of getUserMedia across a range of different
> devices.
> 
> I always wanted to have capabilities along with constraints, and I'm pleased
> to see (finally) a realistic capabilities proposal.  Given that we will not always
> have capabilities available for privacy reasons, I'd like to understand better
> these "potential pitfalls of blindly over-constrained use".  I have heard that
> mentioned but have not yet seen enough evidence to convince me that this
> is a real problem.  Could you point me to some examples?

[TODO]


> > A secondary goal is to provide the right set of APIs for uniformly
> > working with the devices that supply the local media stream tracks,
> > for future APIs and scenarios we may wish to add.
> >
> > If this proposal is adopted, I would expect that the existing
> > constraint usage in getUserMedia could be significantly scaled back,
> > if not removed altogether.
> 
> With the device-level only focus below, I don't think that would quite work.
> One of the goals of the constraints approach was to free a developer who
> just wants "a camera" from having to worry about which one.  They just
> specify their constraints, mandatory or optional based on their needs, and if
> they get something it is something they can use.

I don't fully understand why the "device-level focus" prevents what you said 
from working. Even with the spec-as-is, this only gives a developer one-shot to
get the right settings. For example, if they specify a constraint for some camera 
setting (perhaps white balance or flash?) and when they get a chance to look at
the result stream and don't like it... well then you would probably expect that 
there would be another setting for white balance or flash on the track. So, we're 
in a situation where we have a set of constraints, and a set of settings which are 
basically duplicates. With the proposal below, it consolidates these concepts. Using
the proposal below, I would expect:

1. User requests "video" from getUserMedia (because they want "a camera")
2. If there's some device that provides video, it is provided as a track on a local
    media stream.
3. Now, the developer applies the same constraints to that track, and if the 
    contraints were applied, then we're good to go.

Not too much more complicated than the current draft. If the developer doesn't
like the result, they can just re-apply a different set of constraints to the same
track, and see if that works for them. This IMO is much simpler.


> > If targeted toward a specific track, the new constraints are evaluated
> > against the current track settings, and if the current settings fall
> > within the new constraints then no change is made. If the constraints
> > affect the current settings of the track, then that track is stopped
> > (and consequently removed from the LocalMediaStreamTrackList as a
> > result) and if the device associated with that track can support the
> > new constraints, then a new track is created and added to the
> > LocalMediaStreamTrackList. (All these actions trigger the appropriate
> > add/remove
> > events.)
> 
> This isn't necessary.  Since getUserMedia() still exists, a developer can can
> always call that to get completely new tracks.
> If I tweak the constraints of an existing track I would expect that track to be
> modified (if it satisfies the constraints).

Yes, I suppose you are correct. However, calling getUserMedia *again* is also
the suggested practice for obtaining a second camera. So, how do we rationalize
those two use cases?

Regarding tweaking the constraints, you echo Rich's feedback, that he also
expects the track behavior to change, rather than getting a new track. To me
it seemed like a good design to make MediaStreamTracks un-changeable, but
perhaps that ship already sailed with the work going on for PeerConnection
and remote-sourced tracks. So, I'm not married to this design :-)

Received on Wednesday, 22 August 2012 18:36:33 UTC