Intent to Implement: Media Capture from HTMLMediaElement

138 views
Skip to first unread message

Miguel Casas-Sanchez

unread,
Jan 12, 2016, 11:30:51 PM1/12/16
to blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin

Contact emails

mca...@chromium.org, nik...@chromium.org


Spec

Media Capture from DOM Elements: HTML Media Element Media Capture Extensions


Summary

“Media Capture from DOM Elements” document by W3C defines captureStream() method that allows the capture of a <video> and/or <audio> elements in the form of a MediaStream. We want to implement the necessary Blink and Chromium sections that would create this stream by accessing the canvas output according to the given frame rate constraints. 


The implementation is rather straightforward once the security constraints are cleared, so not much need for a DD per se. It adds a captureStream() and a captureStreamUntilEnded() static methods. EME-labeled content cannot be captureStream()ed, obviously.


Motivation

This feature lets users stream <video> contents through RTC easily. Also, it already has an implementation by Mozilla Firefox.


Compatibility Risk

This feature is well defined by the W3C spec and already supported by Mozilla Firefox.


Ongoing technical constraints

Currently, there is no transparency support in MediaStream as well as encoders, which would mean that alpha channel output would be lost.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


OWP launch tracking bug

https://crbug.com/569976


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5522768674160640


Requesting approval to ship?

No. We are planning to implement it behind a runtime flag.

Harald Alvestrand

unread,
Jan 14, 2016, 5:42:18 AM1/14/16
to Miguel Casas-Sanchez, blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin
Non-owner LGTM.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Joel Weinberger

unread,
Jan 14, 2016, 12:29:22 PM1/14/16
to Harald Alvestrand, Miguel Casas-Sanchez, blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin
Hi there! Taking a brief look at the spec, I'm a bit confused about the implications of using this API on HTTP. Should it be disallowed over insecure origins, similar to what we've done with getUserMedia(), or is there a reason there isn't a similar security concern which I'm missing? Thanks!
--Joel 

Harald Alvestrand

unread,
Jan 14, 2016, 12:42:01 PM1/14/16
to Joel Weinberger, Miguel Casas-Sanchez, blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin
The reason why getUserMedia() is deemed a "powerful feature" is that it gives access to camera and microphone - something that the page doesn't have access to before this functionality is available.

The content of a <video> tag is available to the page already, so we're not adding access to anything it doesn't already have (security-wise).

Joel Weinberger

unread,
Jan 14, 2016, 2:15:42 PM1/14/16
to Harald Alvestrand, Miguel Casas-Sanchez, blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin
Ah, I was thrown off by the "capture" portion of the API name :-) Thanks!
--Joel

Philip Jägenstedt

unread,
Jan 18, 2016, 6:03:29 AM1/18/16
to Joel Weinberger, Harald Alvestrand, Miguel Casas-Sanchez, blink-dev, Niklas Enbom, emi...@chromium.org, David Dorwin
An Intent to Implement needs no LGTM, but a few comments anyway. I've filed these spec bugs:
Overall, mapping an HTMLMediaElement to a MediaStream is complicated by the fact that a HTMLMediaElement can represent multiple media resources over its lifetime, and each media resource can have tracks added and removed.

Would it solve the same uses cases to instead map a AudioTrack or VideoTrack to a MediaStreamTrack, leaving the rest of the decisions up to the application?

outdre...@gmail.com

unread,
Nov 8, 2016, 11:24:06 AM11/8/16
to blink-dev, nik...@chromium.org, emi...@chromium.org, ddo...@chromium.org
This does not seem to work with <video> captureStream on chrome 54.

PhistucK

unread,
Nov 8, 2016, 11:49:16 AM11/8/16
to outdre...@gmail.com, blink-dev, Niklas Enbom, Emircan, David Dorwin
It is still behind a flag. Did you enable the experimental web platform features flag?
If so, you can use crbug.com to report it.


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Bubble Goos

unread,
Nov 8, 2016, 1:51:53 PM11/8/16
to PhistucK, blink-dev, Niklas Enbom, Emircan, David Dorwin
When will it be in the release? I know the workaround, using audiostream + canvas.StreamCaputre combo. but it's messy.

Miguel Casas-Sanchez

unread,
Nov 8, 2016, 2:04:58 PM11/8/16
to Bubble Goos, blink-dev
The Intent-To-Ship discussion is in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/SKLhE1LhjOg ; it has been stalled for a while now.
Reply all
Reply to author
Forward
0 new messages