RE: MediaStreams and state changes

> 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.

Received on Monday, 6 August 2012 17:30:25 UTC