Marked as flaky Pass/Fail in root expectations, it's timing out in GLib platforms, especially in Release/Wayland platforms (WPE-Release and GTK-Wayland-Release bots).
When current spell of flaky timeouts started:
Revisions r267138 through r267140 were related to the GStreamer 1.18 update in the new SDK version.
At least in WPE-Release, it seems to be getting stuck in the `canvas2.getContext("2d").drawImage(video, 0 ,0);` call.
Link to results history: https://results.webkit.org/?suite=layout-tests&test=fast%2Fmediastream%2FcaptureStream%2Fcanvas2d.html
Created attachment 413192 [details]
This is a sample html test case likely related to the root issue, with the canvas1 -> video -> canvas2 pipeline drawing the canvas.
Works on firefox, but does not draw canvas2 in GTK/WPE ToT (although it does not get stuck like in the test).
Looks like we emit the play event before the first video frame reached the sink, that's why the canvas sourcing from the video element is empty in that test-case.
Created attachment 421194 [details]
*** Bug 217829 has been marked as a duplicate of this bug. ***
Committed r273309: <https://commits.webkit.org/r273309>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 421194 [details].