W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

Re: Early Holiday Present: Settings API version 6

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 13 Dec 2012 10:48:40 -0800
Message-ID: <CABkgnnV9+hynLriv23SqJNrokoPzRRg3BHJ_4R0z+7O1SAktMA@mail.gmail.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 13 December 2012 04:32, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> Overall I think this looks good.

Likewise, and I also agree that we need to get this merged soon; the
overhead of having two parallel specifications isn't fair on anyone
(Travis most of all).

> 3.2.1: It is said that "stop()" stops the source. But what if other tracks
> depend on the same source? Should it no be that stop detaches this track
> from the source and ends this track; and that a source is stopped if no
> tracks are attached.

stop() on the source makes the most sense.  Detaching all associated
media streams from their sinks might cause the source to scale its
output down to nothing...

> Section 6.1
> -----------
> First example: I look first on the local part only. In the example the two
> local  sinks are served by two different MS's. What is not clear to me is:
> what happens if the app sets the resolution to 1920*1080 on the MS serving
> sink A followed by setting it to 320*200 on the MS serving B? Is it the
> latest setting that takes effect, or is it the most demanding or latest or
> what? And, what if the track to which the setting was applied is ended, or
> not consumed, what happens?

I have no real concern with this other than the effect it might have
on implementations that have to perform an intersect operation at the
source to determine what it should do.

It would be easier, overall, if the constraints did apply to the
source and that the constraints that were set on a track were only
held in situ until a source was found, after which the
constraints/settings APIs on the track would just write through to the
Received on Thursday, 13 December 2012 18:49:09 UTC

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