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

[mediacapture-image] grabFrame and muted streams (#213)

From: David Sanders via GitHub <sysbot+gh@w3.org>
Date: Thu, 18 Jul 2019 09:58:10 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-469678614-1563443888-sysbot+gh@w3.org>
dsanders11 has just created a new issue for https://github.com/w3c/mediacapture-image:

== grabFrame and muted streams ==
The current Chromium implementation will reject `grabFrame` for a muted stream, [here's the relevant line](https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/imagecapture/image_capture.cc?l=43). The spec currently says nothing about rejecting on a muted stream.

This behavior is problematic as a stream created from a canvas will constantly toggle `mute` and `unmute` as new content is drawn. This means to use `grabFrame` effectively on a stream from a canvas, you'd need to call it inside the `onunmute` handler for the track, which overly complicates the code. There's ongoing discussion in #212 regarding whether `grabFrame` should be for the 'current frame' or the 'next frame', and I think this is another example of a sharp edge created by that behavior being 'next frame'. If `grabFrame` was clarified in the spec to grab the current frame, then the spec could enforce that a muted track should not cause a rejection of `grabFrame`.

Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/213 using your GitHub account
Received on Thursday, 18 July 2019 09:58:11 UTC

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