- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Mar 2017 23:46:41 +0000
- To: public-media-capture-logs@w3.org
@miguelao The ImageCapture API lets us operate a hardware camera, if only for a split second. That, to me, is not a sink. It's more like a track. Examples of sources with output-producing methods: [element.captureStream()](https://w3c.github.io/mediacapture-fromelement/#html-media-element-media-capture-extensions), [canvas.captureStream()](https://w3c.github.io/mediacapture-fromelement/#html-canvas-element-media-capture-extensions) and you mentioned [WebAudio.createMediaStreamSource()](https://webaudio.github.io/web-audio-api/#widl-AudioContext-createMediaStreamSource-MediaStreamAudioSourceNode-MediaStream-mediaStream). On scope, the ImageCapture [constructor](https://w3c.github.io/mediacapture-image/#dom-imagecapture-imagecapture) seems seriously under-specified by what you're saying. It appears to accept all `"video"` tracks indiscriminately. Naively, I suppose `grabFrame()` might be useful regardless of source, as [some](http://stackoverflow.com/q/43102043/918910) find the draw-to-canvas trick inconvenient. But yeah, it's not clear what should happen if `getPhotoCapabilities()` or `takePhoto()` are called on a non-photo camera track, but I have that same question even for a plain webcam without any photo-grade abilities. What happens then? One way to solve discovery might be to put these methods in a `PhotoStreamTrack` derived interface. Then people could use `instanceof` to discover whether these abilities are available on the track passed to them. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/142#issuecomment-290576432 using your GitHub account
Received on Thursday, 30 March 2017 23:46:47 UTC