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:

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