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

Re: Explicit track cloning

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 9 Apr 2013 16:43:08 +0200
Message-ID: <516428FC.1040900@ericsson.com>
To: public-media-capture@w3.org
On 4/9/13 2:56 PM, Adam Bergkvist wrote:
> 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*).

My preference would be *1*. I don't really see why we would do any 
changes if we do not allow the same track to be part of more than one 
MediaStream - the current text says that constructing a MediaStream, or 
doing addTrack, clones the tracks.

> [1]
> http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0004.html
Received on Tuesday, 9 April 2013 14:43:28 UTC

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