Bug 218580 – [GStreamer] fast/mediastream/captureStream/canvas2d.html is flaky timing out since GStreamer 1.18 update

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Lauro Moura]

fast/mediastream/captureStream/canvas2d.html

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:

WPE-Release: r267140
GTK-Wayland: r267141
GTK-Debug: r267156
GTK-Release: r267241
WPE-Debug: r268715

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

[Lauro Moura]

Created attachment 413192 [details]
Tentative example

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).

[Philippe Normand]

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.

[Philippe Normand]

Created attachment 421194 [details]
Patch

[Philippe Normand]

*** Bug 217829 has been marked as a duplicate of this bug. ***

[EWS]

Committed r273309: <https://commits.webkit.org/r273309>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421194 [details].

[Radar WebKit Bug Importer]

<rdar://problem/74644074>