- From: David Sanders via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Jul 2019 10:11:41 +0000
- To: public-webrtc-logs@w3.org
Another example of how an `onframe` event moves flexibility into userland and lets developers deal with issues that they can't currently deal with due to the implementation. Currently if a next frame never comes, the Chromium implementation will leave the promise from `grabFrame` unresolved forever. The implementation *should* reject the promise when the stream ends or is muted, otherwise it leads to the never resolving (or rejecting) promise. With the above `ThrottledImageCapture` class, covering this case in pure JS, independent of bugs in implementations is easy, simply add: ```javascript class ThrottledImageCapture { constructor (capturer) { // See above for full constructor, keeping abbreviated this.streamEnded_ = false; capturer.track.addEventListener('ended', () => { this.streamEnded_ = true; pendingGrabFramePromise_.reject('Stream ended'); } } grabFrame () { if (this.streamEnded_) { return Promise.reject('Stream ended'); } // Rest of implementation } ``` It really seems like an `onframe` event provides the ability to entirely implement `grabFrame` in userland, which lets users make the decisions on issues like this, instead of them being left to the spec or implementation. -- GitHub Notification of comment by dsanders11 Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/210#issuecomment-512754591 using your GitHub account
Received on Thursday, 18 July 2019 10:11:43 UTC