- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 4 Sep 2012 08:16:06 +0200
- To: public-media-capture@w3.org
On 09/04/2012 08:03 AM, Stefan Hakansson LK wrote:
> On 09/04/2012 07:13 AM, Randell Jesup wrote:
>> On 9/3/2012 2:48 AM, Stefan Hakansson LK wrote:
>>> Travis,
>>>
>>> overall I like this a lot. It is very clear which objects you can use to
>>> change properties of the generated media ("MediaDevices"), which I think
>>> is a good thing.
>>
>> This effectively causes a pointer to the source to follow along with
>> tracks, providing a reasonable approximation of my proposal, in a
>> simple-to-understand and use form.
>>
>> The one issue that this doesn't address directly is competing settings -
>> if you fork a track to two streams, and consumers use them to set
>> different values for a parameter, you have to take the
>> "last-setter-wins" approach. This is a viable answer, but one that may
>> cause pain for applications that don't want that answer.
>
> As I understand it, it is up to the application to decide. It could
> apply "last-setter-wins", but just as well "highest(-resolution,
> framerate)-wins" or any other approach.
That came out wrong. Of course it is the last setter that wins. What I
meant was that the app can be designed in a way that the setter applies
some intelligence (so that if you have two video elements displaying, it
sets after the with the larger display size and lets the UA scale for
the smaller one, even if the smaller one was added later in time).
Received on Tuesday, 4 September 2012 06:16:30 UTC