RE: Early Holiday Present: Settings API version 6

> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> On 12/13/2012 07:48 PM, Martin Thomson wrote:
> > On 13 December 2012 04:32, Stefan Hakansson LK
> > <stefan.lk.hakansson@ericsson.com> wrote:
> >> 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
> > source.
> Agree.

This doesn’t get around the problem of having to have some kind of intersect operation, since you'd potentially have two different sets of "privately held" constraints (on two different tracks) that would need to be resolved onto a single source when that source is attached.

With track-level ownership, the effect of the intersection algorithm doesn't have to be visible to the application. (It would be visible when read-back occurs on the track(s) later.)

Also, you'd likely want additional state to identify whether constraints are "stale" or "live" based on whether the track has a source or not.

Finally, having a source doesn't necessarily mean that the constraints would be applied anyway (as is the case for readonly sources).

All of these reasons contributed to the track-ownership model, which I believe is just more self-consistent for the application.

Stefan is correct, however, when he implies that the "constraints intersection resolution algorithm" _does_ need to be clearly defined now that constraints have moved from being MediaStream-centric and static in gUM to Track-centric and dynamic via this proposal.

-Travis

Received on Thursday, 13 December 2012 20:18:54 UTC