W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Explicit track cloning

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 9 Apr 2013 14:56:50 +0200
Message-ID: <51641012.50703@ericsson.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>

I got the task from the editor's team to sum up the discussion around 
explicit track cloning from [1] and propose some changes.

- we want explicit cloning.
- we already have a one to many relationship between sources and track 
- 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*).

Received on Tuesday, 9 April 2013 12:57:18 UTC

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