W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2014

Re: Bare constraint values - KISS

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 10 Jul 2014 08:36:55 -0400
Message-ID: <53BE88E7.3020501@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 7/9/14 2:32 PM, Martin Thomson wrote:
> I think that screwing with constraints further (ekr: feel free to say
> "I told you so" now) isn't what we are looking for.  Rather than
> contorting to accommodate every new feature, we should take a step
> back and look at what the requirements are.

Since I'm effectively arguing to take one small step *back* because of 
semantic overcomplexity, I consider it unscrewing. The ideal/exact 
inversion I think better fits the description of a contortion, given 
that we purposely accepted a cost for some perceived gain.

> 1.
>
> I know that a call pattern like:
>
> ...getUserMedia({audio: false, video: false, application: true}, ...)
>
> ... might be uncomfortable or inconvenient for us to implement in
> Firefox, but I think that it's actually how people think of this.  And
> we already need to fix our code.  We can talk about having an
> allowance for failure when the sources are disparate if you like.

I agree with this.

> Another reason that I'm starting to like this is that the basic set of
> constraints we apply for camera sources are very different to those
> that apply elsewhere.

width? height? frameRate? Our constraints are effectively in one pool 
already, so I don't think this matters on way or the other.

> Since the depth (or range) input folks are already headed in this
> direction, I think that this makes even more sense.  This makes the
> "audio" and "video" labels a little less good, but I think that we can
> probably live with that.

I agree the labels would now stink. I don't know enough about the 
original reasons for picking the audio/video division. 
Screensharing-as-a-video is not a new form of "media" the way 
"smellovision" would be. Though cramming a screenshare into a video 
format is perhaps not the ideal screenshare format either (if I compare 
to, say, vnc or remote desktop formats).

> 2.
>
> Tim T pointed out a consideration that might be relevant: screen
> sharing can also include audio - and some applications actually
> support that - but I think that we probably want to be a little
> cautious about adding that.  Though that would favour a form that
> globally switches mode, rather than something local to a video
> constraints:
>
> ...getUserMedia({audio: false, video: true, source:
> "application|livecapture"}, ...)
>
>
> My preference tends slightly toward the second option.

Good point. If we stick to the audio/video division, then we'd logically 
have to add a new "soundsharing" audio type to accomplish this.

Sounds like we need a refresher on what the top division is supposed to 
serve.

.: Jan-Ivar :.
Received on Thursday, 10 July 2014 12:37:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:28 UTC