W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

Re: [mediacapture-image] onframe Event (#210)

From: David Sanders via GitHub <sysbot+gh@w3.org>
Date: Thu, 18 Jul 2019 10:11:41 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-512754591-1563444700-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:25 UTC