You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When capturing an entire tab, all pixels are completely opaque. But what when capturing an element? Some of its pixels could be partially or fully transparent.
If getDisplayMedia() outputs a transparency-capable format, there is no issue. This is the ideal case, and should be the long-term goal of any implementation. The rest of this issue deals with a fallback in the short- and medium-term.
The specification has several options for what it could mandate if gDM cannot return a transparency-capable format, including:
Remove the alpha-value of all pixels, making them opaque.
Blend transparent pixels with an arbitrary value (likely white, possibly black).
Blend transparent pixels with a value of the app's choosing.
Blend transparent pixels with the target element's own background-color, with the alpha channel cleared out.
Blend transparent pixels with the body's own color.
I think the best would be:
Long-term, all implementations should return a transparency-capable format (if the application requests it).
Medium-term, we could consider option 3, though arguably it'd become throw-away work once an implementation supports a transparency-capable format.
Short-term, it should be easy and mostly sufficient to specify option 1.
The text was updated successfully, but these errors were encountered:
If getDisplayMedia() outputs a transparency-capable format, there is no issue.
What are the cases where this won't happen. If the format in which the video is being encoded is in control of the site, can we force them to use a format which supports transparency if the stream is for element capture?
I am not aware of a way for the app to control the video format in the MediaStreamTrack. (Different story when it's written to a file or sent over the network.)
As of the time of writing, the getDisplayMedia spec does not mandate that a transparency-capable format be used in the MST returned. We might have to accommodate the possibility of a browser implementing getDisplayMedia and Element Capture, while using an alpha-incapable video format.
When capturing an entire tab, all pixels are completely opaque. But what when capturing an element? Some of its pixels could be partially or fully transparent.
If getDisplayMedia() outputs a transparency-capable format, there is no issue. This is the ideal case, and should be the long-term goal of any implementation. The rest of this issue deals with a fallback in the short- and medium-term.
The specification has several options for what it could mandate if gDM cannot return a transparency-capable format, including:
I think the best would be:
The text was updated successfully, but these errors were encountered: