[mediacapture-main] Track changes on cloned streams

martinthomson has just created a new issue for 
https://github.com/w3c/mediacapture-main:

== Track changes on cloned streams ==
@pehrsons notes 
[here](https://bugzilla.mozilla.org/show_bug.cgi?id=1208371#c210) an 
issue with stream cloning.

The fundamental question raised is whether changes to the set of 
tracks on the original stream should be propagated to clones of that 
stream.  The [current 
algorithm](https://w3c.github.io/mediacapture-main/#widl-MediaStream-clone-MediaStream)
 does not propagate changes.

It's very tempting to suggest that the current algorithm is sufficient
 and that changes can be managed by the application ([I 
did](https://bugzilla.mozilla.org/show_bug.cgi?id=1208371#c209)), but 
@pehrsons raises a few points that I think need more consideration.  
These concerns arise from the fact that the set of tracks on a stream 
can change automatically, whether as a result of track additions by 
`RTCPeerConnection` or maybe `HTMLMediaElement::captureStream()`.

The simplest polyfill looks like this:

```js
var cloneStream = originalStream.clone();
originalStream.onaddtrack = e => 
cloneStream.addTrack(e.track.clone());
originalStream.onremovetrack = e => cloneStream.removeTrack(/* 
something more complex */);
```

In cases where the browser modifies the set of tracks, use of the 
clone and use of the original will differ in ways that cannot be 
easily repaired by an application.  If a new track is added, the time 
required to propagate the `onaddtrack` event means that an 
application-managed clone could miss the lead-in for a track on the 
clone.  A similar concern applies to `onremovetrack`.

See https://github.com/w3c/mediacapture-main/issues/271

Received on Tuesday, 10 November 2015 19:08:26 UTC