Re: Cloning and sharing of MediaStreamTracks - worth it?

Yes, this is important, and the model is a little complicated.  But it
is my believe that Stefan, Harald and I are all just using different
ways to approach the description of the model.

On 10 May 2013 05:01, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> Stefan,
>   From pervious emails, I thought that you were saying that constraints/settings are always applied to the source _object_, i.e. that settings are implemented by changing the state of the underlying device.

This is correct.  But not entirely.  When you constrain a track, then
it might necessitate a change in the source operating mode (it might
cause a camera to turn on a fill light, for example).

> Martin is saying that they are never applied to the source object (but instead realized in software in the Track.)

Not "applied", but constraints/settings are never *owned* by the
source.  The source only reacts in response to the constraints that it
sees.  I think that is the key distinction.

> The difference is that in your model (as I understood it) a setting applied to one Track will affect the observed output of all other Tracks that share the same source.

Yes, a change in constraints/settings on one track can affect other
tracks attached to the same source, but only if that is permitted by
the constraints/settings on that track (e.g., if you don't constrain
the fill light, then you shouldn't be surprised when the light turns
on).

> In Martin's model, a setting applied to one Track will not affect the output of other Tracks.

See above, I think that's not the case.  Constraints/settings on one
track have independent ownership, but not independent observable
consequences.

The problem here is in this original discussion relating to cloning,
I've focused on ownership, not observable behavior.  That's the aspect
most relevant to that discussion.

> And Harald's  model seems to be: maybe it does, maybe it doesn't, who knows? Life is short, it's up to the UA.

This is also a perfectly valid perspective.  The UA is given some
constraints and settings.  As long as those are met (or appropriate
errors thrown) then the UA is free to operate as it chooses.  That's
just a messy reality.

> I think we need to be clear on which of these models we are using, or the discussion will keep going in circles.  As an example, in Tuesday's call when the 'zoom' setting came up, it was clear that many people wanted it to apply to the camera's native zoom ability, and not to be some post-processing sleight of hand.  In Martin's model that would not be allowed.

OK, here I need to make this very clear.  Constraints and settings
might influence the source, but ultimately, if the UA is able to
perform post-processing to comply, then that is what it will do.  The
alternative is outright rejection and I don't think that any UA
developer is willing to do that unless they have no other option.
Most will accept a significant degradation in quality before they
produce any sort of error.

The trick here is deciding whether this behavior can be controlled by
an app.  I'm not sure that we are there yet.

> If it is allowed, I think that  it would have to affect the output of all Tracks that share the source.  Which is it?

Mu.

--Martin

Received on Friday, 10 May 2013 17:13:53 UTC