Re: Explicit track cloning

On 04/09/2013 05:20 PM, Jim Barnett wrote:
> I vote for *1*.  We just have to make it clear to developers what it means to put the same track in multiple MediaStreams.  As I understand it, a Track represents a set of settings/operations applied to the output of a device.  (These settings may or may not affect the state of the device.)  If a Track is in multiple MediaStreams, then any modification applied in one Stream is reflected immediately in the other.  I can't think of a use case for this off the top of my head[1], but I don't see any reason to disallow it.
>
> - Jim
> 1.  Suppose I am talking to someone over a PeerConnection and want my screen to reflect exactly what I am sending to the other side.  Would this be a case where I would have two MediaStreams, one added to a PeerConnection and the other connected to a <video> element?  If so, this is a case where I would want any change applied to a Track to show up in both MediaStreams simultaneously.  (I would want the audio muted in my local copy, but would want the video to be exactly the same.  So I would clone the audio track, or omit it altogether, and use the same video Track.)

Most of the self-view code I've seen goes like this:

getUserMedia(..function(stream) {
    pc.AddStream(stream)
    videoElement.src = getObjectURL(stream)
    videoElement.volume = 0  // local mute
}
...)

or equivalents thereof.

> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Tuesday, April 09, 2013 8:57 AM
> To: public-media-capture@w3.org
> Subject: Explicit track cloning
>
> Hi
>
> I got the task from the editor's team to sum up the discussion around explicit track cloning from [1] and propose some changes.
>
> Summary:
> - we want explicit cloning.
> - we already have a one to many relationship between sources and track instances
> - we already have a one to many relationship between track instances and consumers (via MediaStream)
>
> What wasn't entirely resolved:
> - when addTrack() and the MediaStream() constructor doesn't auto-clone anymore, is it ok to add a track instance to more then one MediaStream?
>
> API impact:
> ----------------
> If we think it's ok to not put any limitations on adding the same track to several streams the API could behave as following (*1*):
>
> Adopts the track instance (i.e. no cloning):
> * MediaStream() constructor
> * MediaStream.addTrack()
>
> Clones the track instance:
> * MediaStreamTrack.clone()
>
> The current MediaStream() constructor is optimized for cloning an entire MediaStream since we identified that as a common use-case. Therefore, we could also have a MediaStream.clone() if we still want to have that operation as a one-liner.
> ----------------
>
> If we think it's not ok for two track instances to live in different MediaStreams then we need to patch the above API a bit.
>
> We've had two proposals to do this. One is to still have the addTrack() method clone the added track, but rename it to make this more clear (*2*). Unless that method would return the cloned track, we would still have the problem of finding a reference to the added track. It's however not that obvious how to patch the constructor in a similar way.
>
> The second proposal was to use the
> addTrack()/MediaStreamTrack.clone()-API mentioned above but, e.g., throw an exception when a track is added to a second stream (*3*). An readonly attribute on a track telling which MediaStream that it's currently belong to could help in this case.
> ----------------
>
> So what should we pursue?
>
> My preference would be (*1*) or (*3*).
>
> [1]
> http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0004.html
>
>
>
>
>

Received on Thursday, 11 April 2013 10:55:07 UTC