244727 2022-09-02 14:07:01 -0700 [GStreamer] DMABuf sink mis-renders frames in XvFB 2024-01-20 04:33:08 -0800 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED WORKSFORME P2 Normal --- 1 aboya webkit-unassigned bugs-noreply philn oldest_to_newest 1895862 0 aboya 2022-09-02 14:07:01 -0700 While debugging https://github.com/WebKit/WebKit/pull/3802#issuecomment-1232898953 I found out that video elements don't render any image inside LayoutTests. This is particularly problematic for any tests relying on visual output, such as reftests. This is easily reproduced with compositing/video/video-border-radius-clipping.html, which should output a single big green frame -- and does so in the minibrowser -- but appears white when ran in the test runner, for instance, in this EWS results: https://ews-build.s3-us-west-2.amazonaws.com/GTK-WK2-Tests-EWS/dbb1766c-24083/results.html Passing --wrapper='env GST_DEBUG=webkit*:DEBUG' to run-webkit-tests shows the likely culprit of this, a failure to get a GL context: 0:00:03.530073170 56 0x7f6ac0 WARN webkitmediaplayer PlatformDisplayGStreamer.cpp:115:tryEnsureGstGLContext: Failed to fill in GStreamer context: could not retrieve fbconfig from its ID 0x42. Wrong Display or Screen? 1901027 1 philn 2022-09-25 09:35:08 -0700 compositing/video/video-border-radius-clipping.html is passing though? At least here in the default XvFB setup and also when I pass --display-server=wayland 1943336 2 philn 2023-03-23 04:55:32 -0700 The GL sink is now replaced by another sink, re-titling the bug. I can now reproduce this issue here, the actual rendered frame is white instead of green. Zan mentioned this could be a TextureMapper bug. To be confirmed. 1950399 3 philn 2023-04-21 09:13:00 -0700 Seems like this was fixed... compositing/video/video-border-radius-clipping.html is passing in XvFB and host wayland compositor.