11495 WARNING: Must have an opaque ImageHost if we reported CONTENT_OPAQUE: file gfx/layers/composite/ImageLayerComposite.cpp, line 145

This warning [1] shows up in the following test suites:

  2079 - test-linux64/debug-mochitest-e10s-3 3
  2070 - test-linux64/debug-mochitest-fis-e10s-3 3
  2061 - test-linux64/debug-mochitest-sw-e10s-3 3
  1114 - test-linux64/debug-mochitest-media-fis-e10s-2 mda2
  1072 - test-linux64/debug-mochitest-media-e10s-2 mda2
  1054 - test-linux64/debug-mochitest-media-sw-e10s-2 mda2
   986 - test-linux64/debug-mochitest-media-spi-e10s-2 mda2
   285 - test-linux64/debug-mochitest-webgl1-core-fis-e10s gl1c
   282 - test-linux64/debug-mochitest-webgl1-core-sw-e10s gl1c
   273 - test-linux64/debug-mochitest-webgl1-core-e10s gl1c
    94 - test-linux64/debug-web-platform-tests-e10s-16 wpt16
    88 - test-linux64/debug-web-platform-tests-sw-e10s-16 wpt16
    10 - test-linux64/debug-reftest-no-accel-sw-e10s-7 Ru7
    10 - test-linux64/debug-reftest-sw-e10s-7 R7
     9 - test-linux64/debug-reftest-e10s-7 R7
     8 - test-linux64/debug-reftest-no-accel-e10s-7 Ru7

It shows up in 15 tests. A few of the most prevalent:

  6210 - [e10s] dom/canvas/test/test_capture.html
  3003 - [e10s] dom/media/tests/mochitest/test_peerConnection_simulcastOddResolution.html
   877 - [e10s] dom/media/tests/mochitest/test_peerConnection_simulcastAnswer.html
   840 - [e10s] dom/canvas/test/webgl-mochitest/test_capture.html
   104 - [e10s] dom/media/tests/mochitest/test_peerConnection_multiple_captureStream_canvas_2d.html
    98 - [e10s] /webrtc/simplecall.https.html
    84 - [e10s] /webrtc/simplecall-no-ssrcs.https.html
    78 - [e10s] dom/media/tests/mochitest/test_getUserMedia_bug1223696.html
    75 - [e10s] dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html
    40 - [e10s] dom/media/tests/mochitest/test_peerConnection_captureStream_canvas_2d_noSSRC.html

[1] https://hg.mozilla.org/mozilla-central/annotate/a3a081ae714f1123bdc23c9d9ef53dfaa783a8de/gfx/layers/composite/ImageLayerComposite.cpp#l145

The warning was added in bug 1538969. Any ideas Matt?

FWIW, just looking at the tests, this seems related to canvas captureStream. This captures frames from a canvas into a video track and typically plays that video track in a media element.

It looks like the video element is reporting that we'll only ever get opaque frames, but the captureStream is providing ones with an alpha channel (or isn't tagging them as always being opaque).

It seems possible that this could cause invalid rendering (if the stream is indeed partially transparent), since we'll think content behind it is occluded.

I can't find where the frames come from with a quick code browse, would need someone to debug this properly.

If the frames are from canvas captureStream and the canvas is partially transparent, the frames will be as well. Canvas-capture frames originate here.

I know the MediaStream and canvas-capture bits, but not how the media element reports that we'll only ever get opaque frames. If you point me to where it does this and lay down how it should behave I can patch this.

We support webm with an alpha channel too I believe. Sounds like it might be impacted by the same warning?

The HTMLVideoElement reports that it only expects opaque frames using the provided MediaInfo here - https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLVideoElement.h#111

./mach mochitest \
dom/canvas/test/test_capture.html \
dom/media/webrtc/tests/mochitests/test_peerConnection_simulcastOddResolution.html \
dom/media/webrtc/tests/mochitests/test_peerConnection_simulcastAnswer.html \
dom/canvas/test/webgl-mochitest/test_capture.html \
dom/media/webrtc/tests/mochitest/test_peerConnection_multiple_captureStream_canvas_2d.html \
dom/media/webrtc/tests/mochitest/test_getUserMedia_bug1223696.html \
dom/media/webrtc/tests/mochitest/test_peerConnection_simulcastOffer.html \
dom/media/webrtc/tests/mochitest/test_peerConnection_captureStream_canvas_2d_noSSRC.html | grep CONTENT_OPAQUE | wc -l

On m-c: 3656
With the patches: 0

One could imagine an alpha failure mode where alpha 0 blends with black (also 0,
in rgb). If that happened the webm-alpha reftest becomes a false positive.

Feeding a video track with alpha frames into a peer connection results in black
on the remote side.

Grey should handle this case. The other channels in the test video show four
quadrants of different colors, so a failure mode where alpha is ignored would
render those quadrants instead, keeping testing of that mode unchanged.

https://hg.mozilla.org/mozilla-central/rev/ec2ec774de6f
https://hg.mozilla.org/mozilla-central/rev/d718b5fdf955
https://hg.mozilla.org/mozilla-central/rev/d416f835b0a5
https://hg.mozilla.org/mozilla-central/rev/e7a73de0451d
https://hg.mozilla.org/mozilla-central/rev/911db7f96ac8