- From: Martin Thomson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Nov 2015 17:39:14 +0000
- To: public-media-capture-logs@w3.org
> 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. 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. > Secondly, we have ways to set up an empty track from the start, and make that part of both streams on the remote side (and once content starts flowing in that track it would do so in both streams of course). That's part of the solution, yes. > HTMLMediaElement::captureStream()could be a case, but why can't the original stream be used for all consumers (instead of being cloned)? Or why can't the second consumer capture from the same element rather than cloning the first stream being captured? Well, that's questioning the need for `MediaStream::clone()`. I'm starting to be convinced by your arguments here. If we can be satisfied that `onaddtrack` propagation is not needed, then I think we could say the same for `clone()`. -- GitHub Notif of comment by martinthomson See https://github.com/w3c/mediacapture-main/issues/271#issuecomment-156497224
Received on Friday, 13 November 2015 17:39:17 UTC