{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/mediacapture-main/issues/271","labels_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/271/labels{/name}","comments_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/271/comments","events_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/271/events","html_url":"https://github.com/w3c/mediacapture-main/issues/271","id":116179209,"number":271,"title":"Track changes on cloned streams","user":{"login":"martinthomson","id":67641,"avatar_url":"https://avatars.githubusercontent.com/u/67641?v=3","gravatar_id":"","url":"https://api.github.com/users/martinthomson","html_url":"https://github.com/martinthomson","followers_url":"https://api.github.com/users/martinthomson/followers","following_url":"https://api.github.com/users/martinthomson/following{/other_user}","gists_url":"https://api.github.com/users/martinthomson/gists{/gist_id}","starred_url":"https://api.github.com/users/martinthomson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/martinthomson/subscriptions","organizations_url":"https://api.github.com/users/martinthomson/orgs","repos_url":"https://api.github.com/users/martinthomson/repos","events_url":"https://api.github.com/users/martinthomson/events{/privacy}","received_events_url":"https://api.github.com/users/martinthomson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"stefhak","id":1180334,"avatar_url":"https://avatars.githubusercontent.com/u/1180334?v=3","gravatar_id":"","url":"https://api.github.com/users/stefhak","html_url":"https://github.com/stefhak","followers_url":"https://api.github.com/users/stefhak/followers","following_url":"https://api.github.com/users/stefhak/following{/other_user}","gists_url":"https://api.github.com/users/stefhak/gists{/gist_id}","starred_url":"https://api.github.com/users/stefhak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stefhak/subscriptions","organizations_url":"https://api.github.com/users/stefhak/orgs","repos_url":"https://api.github.com/users/stefhak/repos","events_url":"https://api.github.com/users/stefhak/events{/privacy}","received_events_url":"https://api.github.com/users/stefhak/received_events","type":"User","site_admin":false},"milestone":null,"comments":16,"created_at":"2015-11-10T19:08:22Z","updated_at":"2015-11-15T13:41:54Z","closed_at":null,"body":"@pehrsons notes [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1208371#c210) an issue with stream cloning.\r\n\r\nThe 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.\r\n\r\nIt'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()`.\r\n\r\nThe simplest polyfill looks like this:\r\n\r\n```js\r\nvar cloneStream = originalStream.clone();\r\noriginalStream.onaddtrack = e => cloneStream.addTrack(e.track.clone());\r\noriginalStream.onremovetrack = e => cloneStream.removeTrack(/* something more complex */);\r\n```\r\n\r\nIn 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`."},"comment":{"url":"https://api.github.com/repos/w3c/mediacapture-main/issues/comments/156812625","html_url":"https://github.com/w3c/mediacapture-main/issues/271#issuecomment-156812625","issue_url":"https://api.github.com/repos/w3c/mediacapture-main/issues/271","id":156812625,"user":{"login":"stefhak","id":1180334,"avatar_url":"https://avatars.githubusercontent.com/u/1180334?v=3","gravatar_id":"","url":"https://api.github.com/users/stefhak","html_url":"https://github.com/stefhak","followers_url":"https://api.github.com/users/stefhak/followers","following_url":"https://api.github.com/users/stefhak/following{/other_user}","gists_url":"https://api.github.com/users/stefhak/gists{/gist_id}","starred_url":"https://api.github.com/users/stefhak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stefhak/subscriptions","organizations_url":"https://api.github.com/users/stefhak/orgs","repos_url":"https://api.github.com/users/stefhak/repos","events_url":"https://api.github.com/users/stefhak/events{/privacy}","received_events_url":"https://api.github.com/users/stefhak/received_events","type":"User","site_admin":false},"created_at":"2015-11-15T13:41:54Z","updated_at":"2015-11-15T13:41:54Z","body":">>  I'm trying to find the use case where this is a practical problem. I don't think the RTCPeerConnection example is one. First of all, the time for the signaling to set up the additional audio track is probably much longer than the event propagation on the receiving side.\r\n\r\n> Aren't there cases where streams appear prior to receiving signaling?  I'm thinking about the case of a re-offer with bundle.  The answerer can start sending media long before passing back an answer.\r\n\r\nI've been thinking a bit about that. (If the answerer stars sending immediately, while it takes a while for the answer to make it back to the offerer) it is clear the the addTrack event in some cases could fire as soon as the offerer gets RTP packets with mid indicating to the m-line in question. However, the `RTCTrackEvent` would not be able to contain the `streams[]`data, nor would the track have an Id until the answer has been applied.\r\n\r\nIt seems to make most sense, in case there is an outstanding offer, to hold off firing `ontrack´ until the answer has arrived? I'm not sure exactly what the spec says though.\r\n\r\nBut regardless, in this situation there might be a gap in the cloned stream. The question is if the issue is big enough for us to redesign.\r\n"}}