- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 7 Aug 2012 09:59:53 +0200
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 08/06/2012 07:29 PM, Travis Leithead wrote: >> From: Stefan Hakansson LK >> [mailto:stefan.lk.hakansson@ericsson.com] If we isolate this down >> to resolution of video, I had this idea of that the consumer would >> hint to the producer the size, and the producer could adapt. Say >> you have a MediaStream connected to a video element, the >> width/height of the video element could be used to change the >> resolution produced by the camera - the browser knows has all facts >> about the consumer and controls the producer. Similarly a record >> function would have to provide width/size. If there are several >> consumers (e.g. two local video elements, or one video element >> along with a recording) the browser could determine the best >> compromise (which probably is to catch video with the highest >> resolution consumed). >> >> This idea could easily be extended over a PeerConnection. If the >> video is consumed on the other side of the PeerConnection the >> width/height could be signaled back to the sending browser, and >> used as input to how that browser handles the camera. >> >> The advantage would be that the naive author would just have to set >> up the size of the video element to fit the intended layout, and >> the rest would be automatic. >> >> However, one feedback has been that this should not 'just happen', >> the app should be in control. So perhaps it is not a good idea. > > Frankly, making things like this automatic seems like trouble--we > might get it right for some set of scenarios, and other scenarios > will consider this behavior a "bug". I'd strongly recommend leaving > the control (at least with questions like resolution) up to the > application. > > >> But if the application controls the resolution, is there really a >> benefit if the app receiving a MediaStream from a PeerConnection >> can ask (using some local API) for a specific resolution? Could >> this not just as well be signaled back to the sending app, that >> uses (a variant of) the API proposed by Travis to change the >> resolution produced by the camera. > > If I understood you correctly, are you saying that: since the > application can control the resolution, then having > PeerConnection-based resolution-change-request API is unnecessary? If > so, then I agree. Yes, that is what I meant. >
Received on Tuesday, 7 August 2012 08:00:20 UTC