I've recorded a video of the issue to help show the problem. Please see attached.

Deleted: chrome bug.mp4 700 KB

	chrome bug.mp4 700 KB View Download

Thanks for the issue...

Tried to reproduce the issue on reported chrome 70.0.3538.77 using Mac 10.14.0. attaching screencast for reference.
Steps:
-----
1. Launched chrome 
2. Opened given html file 
As we have observed that the blank screen on the html file

@reporter: Could you please check the attached screen cast and let us know if anything missed from our end and It would be really helpful if any other sample URL/Test file is provided, so that we can investigate the issue further.

Thanks..!

Deleted: 905249.mp4 1.5 MB

	905249.mp4 1.5 MB View Download

Here is a url that you can test it with: https://launchinteractive.com.au/chrome/test.html

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I've done some more investigation into this. It appears that it may be specific to Chrome on mac. I've been using Chrome 70 and Canary (72)

I should also mention how the video was encoded: 

ffmpeg -i square.mov -vf unpremultiply=inplace=1 -c:v libvpx-vp9 whiteSquare.webm

Able to reproduce the issue on chrome version# 70.0.3538.77 also seen on 72.0.3615.0 and the issue is not seen on M-60 with the sample URL and steps provided in comment# 4 using Mac 10.14.0. We will provide bisect information and other OS behaviour soon. Hence adding Needs-Bisect label and marking it as Untriaged. 

Thanks.

Able to reproduce the issue on chrome version# 70.0.3538.77 also seen on 72.0.3615.0 using Mac 10.14.0. Hence, providing bisect information for the same. 

Note: Issue not seen on Windows and Ubuntu

Bisect Info:
================
Good build: 70.0.3524.0
Bad build: 70.0.3525.0

CHANGELOG URL:
You are probably looking for a change made after 583622 (known good), but no later than 583623 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/8d58277248cb981741eb4a48d2938719880bee4e..1e53b4ec05f2485450a177c372e38b6215341a1c

Suspect: https://chromium.googlesource.com/chromium/src/+/1e53b4ec05f2485450a177c372e38b6215341a1c

Reviewed-on: https://chromium-review.googlesource.com/1174949

Miguel Casas:Please confirm the issue and help in re-assigning if it is not related to your change.Adding RBS label for M-71 feel free to change it if not required.

Thanks..!

Updating the above comment #10.

This is regressed in M70, we won't block M71 for this. Pls target fix for M72. Pls let us know ASAP if there is any concern here, Thank you.

Removing "Target-71" and "M-71" labels per comment #12. Pls fix this for M72.

Friendly ping for an update on this.

Friendly ping for an update on this issue as it is marked as stable blocker & stable release is coming soon.
Thanks..!

<video>/<canvas>.captureStream() with transparency is not a tremendously
popular use case from UMAs; will fix it soon-ish but this should not be
a Release Blocker.

This was assigned as a duplicate, however its a seperate issue and the fix for 902205 has not resolved this. The transparency is still grey in canary 73.

My bad, this was supposed to be a dupe of  Issue 642012 

Actually, this is not supposed to be a duplicate of any
media-recorder-not-producing-seekable-webm-files bug :-)

I put the html describing the bug in https://codepen.io/miguelao/pen/dwJeab
(with the usual https://simpl.info/videoalpha/video/dancer1.webm video
instead of the white box, to simplify running it) and I believed this Issue
is a duplicate of  Issue 902205  which was fixed by crrev.com/c/1359513.

marc@ and devs in CC please take a look and mark as verified/ reopen.

I believe this is a seperate issue. The dancer video is a vp8 video and the dancer is opaque. The white square video I created is a vp9 video and is a 50% transparent white square.

The issue is when you use drawImage to copy the video to the canvas the white square turns grey in mac chrome 71 and mac canary 73. I believe it works fine in the windows builds.

marc@ could you host that video somewhere and make a 
codepen or jsbin or similar please? I noticed a different
shade of pink applied to the dancer so we might have a 
skia/colorspace problem here.

Here is an updated codepen: https://codepen.io/anon/pen/mapvyE

A very odd behaviour I've just noticed with Chrome Canary Mac Version 73.0.3659.0 is that the preview image for the video shows the square as grey instead of white unless the video is inline. I added a toggle button to show this. 

marc@ thanks for the codepen. I'm using 73.0.3652.0 on a MBP 2017 High 
Sierra 10.13.6, Intel, and I see both blocks as grey over pink background,
either when clicking "inline" and not, see attached screen rec.

(Note that crrev.com/c/1359513 landed on 73.0.3631.0 )

Deleted: test.webm 817 KB

	test.webm 817 KB View Download

Interesting. I'm using a 13" MBP Mojave 10.14.2, Intel Iris Plus Graphics 655 1536 MB and this is what I see...

Deleted: strangeChromeRendering.mov 2.0 MB

	strangeChromeRendering.mov 2.0 MB View Download

I updated to Mojave, 10.14 (18A391) 
MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)
Intel Iris Plus Graphics 640 1536 MB

and I still see the box in the <video> gray, both inlined
or not.  This is turning into a find-the-difference game :-)
FTR, what's your Chrome version?

Chrome Stable doesn't have the inline issue. (Version 71.0.3578.98 (Official Build) (64-bit)) but does show a white and grey square.

Chrome Canary has the inline issue for me..
Version 73.0.3660.0 (Official Build) canary (64-bit)

This is strange. IIUC the current issue affects the inline/not video
playback; we should just file a new issue with the findings. Would 
you mind filing in and linking to your latest video and codepen? I
can route it if you add me to the CC list.

Sure,

I've created a new issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=919015

It looks like starting chrome with this argument: --disable-gpu-memory-buffer-video-frames fixes this issue in both stable and canary