- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Sep 2019 17:15:36 +0000
- To: public-webrtc-logs@w3.org
> @Pehrsons If we can make those guarantees then I agree we shouldn't return a promise. Only if the asynchronous part can fail would a promise be needed. I don't think that's the case here. > > `replaceTrack` should probably throw if either track is `ended`. That would avoid the race you mention. @jan-ivar Personally I like that it solved the track-lifetime problem more than I'd be annoyed by having to solve the race. Consider recording a stream from HTMLMediaElement.captureStream(). You could pipe an audio track through webaudio to be in full control of its lifetime. Then even when a video track from the media element ended before you managed to replace it with another (which if you managed to do it in time, would chop off a bit of the track's end), you can still do that after-the-fact. Or with a gUM track in case a user killed it through the browser's chrome. -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/186#issuecomment-531871811 using your GitHub account
Received on Monday, 16 September 2019 17:15:42 UTC