- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 20 Nov 2013 17:59:25 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 20/11/13 18:45, Martin Thomson wrote: > On 20 November 2013 09:41, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com> wrote: >> I'm going to throw in one more thing here (relevant only to >> width/height/aspect): how do we relate this to the width and height of >> the consumer? > > When I was talking of multivariate optimization problems, I neglected > to mention that set of dimensions. Yes, that also might influence the > choice. > >> Say a video MediaStreamTrack with mandatory setting of width min 1024 is >> only attached to a video element with a width of 200. Should the camera >> really produce a stream with width 1024, only to have it scaled at >> display time? > > You know what, if the browser wants to lie about having a 1024 wide > video stream, but actually only produce what it needs, I'm perfectly > cool with that. As long as the 1024 wide stream is there when I > resize the video element or start recording, etc... I agree, but should it lie also when I check the settings of the Constrainable it implements? And in general: if I use constraints with gUM, would those also be applied to the tracks, or just used to select devices? I.e., if I read out the Constraints, would I get an empty set, or the one used with gUM? I sort of prefer to get the unconstrained track (but knowing what it can do) back - but can't really motivate well why. I'm not sure the set of constraints that can be used at gUM time is exactly the same as later. E.g., facingMode could be crucial when selecting device, but not later (because you can't change it). >
Received on Wednesday, 20 November 2013 17:59:50 UTC