Re: Cloning and sharing of MediaStreamTracks - worth it?

Jim,

I think (if these things are not clear in the Editor's draft) should 
either initiate a discussion on them (one mail thread per topic), or 
file bugs.

The risk is otherwise (as seem to have happened in at least one of the 
cases) that there is a discussion/explanation, but it is never documented.

Br,
Stefan

On 5/10/13 7:41 PM, Jim Barnett wrote:
> Stefan, I agree completely.  I think that there are a few other areas
> where we will want to do this as well (asking someone to write
> something up, that is.  We can give Dan a break every now and
> then...)
>
> 1.  Permissions: How long do permissions granted by gUM persist?  If
> the user wants to grant permanent permissions to a site, is that done
> through our API or independently through the UA (in either case, the
> spec needs to say something about it.) 2.  Origin of the media
> stream:   For the purposes of enforcing cross-origin constraints,
> what is the origin of a media stream created by gUM?  Ekr gave a
> clear explanation of this once, but I haven't seen it written down.
> 3.  Branching off into WebRTC, what is the origin of a remote stream
> received over a PeerConnection?  (It may seem obvious that it's the
> remote site, but we need to make sure that all use cases work
> correctly if that's the case.)
>
> - Jim
>
> -----Original Message----- From: Stefan Håkansson LK
> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Friday, May 10, 2013
> 1:30 PM To: Jim Barnett Cc: Martin Thomson;
> public-media-capture@w3.org; Harald Tveit Alvestrand; Robert
> O'Callahan Subject: Re: Cloning and sharing of MediaStreamTracks -
> worth it?
>
> Jim,
>
> I think we need to clarify all of this. But perhaps the best way is
> that Dan - who has been spending a lot of time on this lately -
> writes up a proposal (taking into account what was said during the
> telco the other day), and that we take it from there.
>
> Br, Stefan
>
> On 5/10/13 2:01 PM, Jim Barnett 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.  Martin is saying that they are never applied to
>> the source object (but instead realized in software in the Track.)
>> 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.  In Martin's model, a
>> setting applied to one Track will not affect the output of other
>> Tracks.
>>
>> 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.
>>
>> 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.  If it is allowed, I think that
>> it would have to affect the output of all Tracks that share the
>> source. Which is it?
>>
>> - Jim
>>
>> -----Original Message----- From: Stefan Håkansson LK
>> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Friday, May 10,
>> 2013 2:17 AM To: Jim Barnett Cc: Martin Thomson;
>> public-media-capture@w3.org; Harald Tveit Alvestrand; Robert
>> O'Callahan Subject: Re: Cloning and sharing of MediaStreamTracks -
>> worth it?
>>
>> On 5/10/13 12:09 AM, Jim Barnett wrote:
>>> Well, we'd better agree on this  soon or we'll be chasing our
>>> tails forever.  People have radically different understandings of
>>> what a Track actually does. I think that's one reason that the
>>> discussions of cloning and constraints/settings never seems to
>>> progress.
>>
>> Jim, I agree fully. But I don't think Martin and I really differ.
>> I think we're both saying that
>>
>> * enabled and the set of constraints are track properties * mute
>> and the media are source properties. The app can get info about the
>> media currently generated by probing the state of the source
>> serving the track:
>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#source-states
>>
>>
>>
>>
Stefan
>>>
>>> -Jim
>>>
>>> *From:*Martin Thomson [mailto:martin.thomson@gmail.com] *Sent:*
>>> Thursday, May 09, 2013 4:09 PM *To:* Jim Barnett *Cc:*
>>> public-media-capture@w3.org; Harald Tveit Alvestrand; Stefan
>>> Håkansson LK; Robert O'Callahan *Subject:* RE: Cloning and
>>> sharing of MediaStreamTracks - worth it?
>>>
>>> "Jim Barnett" <Jim.Barnett@genesyslab.com
>>> <mailto:Jim.Barnett@genesyslab.com>> wrote:
>>>>
>>>> But see Stefan's email; _everything_ is a source attribute
>>>> except
>>> for 'enabled'.  I don't think that Track is doing much work.
>>>
>>> That isn't the model that I described. A large part of the state
>>> of the source is actually transparent. The set of constraints,
>>> enabled, and, consequently, the precise form of the track output
>>> are track properties.
>>>
>>> As far as I can tell, the only concrete properties the source has
>>> are invariant: mute, the media itself. The rest are derived from
>>> the set of constraints provided by the enabled tracks that the
>>> source serves. Those are the properties I'm interested in
>>> cloning.
>>>
>>
>>
>>
>
>
>

Received on Friday, 10 May 2013 19:57:14 UTC