197752 2019-05-09 12:29:29 -0700 [GStreamer] Consider blacklisting gstreamer-vaapi 2023-03-23 11:22:53 -0700 1 1 1 Unclassified WebKit Media WebKit Nightly Build PC Linux RESOLVED WONTFIX https://bugs.webkit.org/show_bug.cgi?id=240664 P2 Normal --- 1 mcatanzaro webkit-unassigned bugs-noreply calvaris mcatanzaro pnormand vjaquez webkit-bugzilla oldest_to_newest 1534824 0 mcatanzaro 2019-05-09 12:29:29 -0700 After removing gstreamer-vaapi from the GNOME runtime, I noticed: (a) Video corruption issues reported at https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/100 are fixed (b) Dramatically improved scrolling performance and web process responsiveness on pages with certain videos (c) Dramatic reduction in web process hangs on pages with certain videos I'm pretty sure gstreamer-vaapi is responsible for souring a large number of users on WebKit. It makes our web engine perform really bad. The quality difference after disabling it is really huge. I suggest we disable use of gstreamer-vaapi at the WebKit level, to immediately ensure a quality user experience until we are able to investigate and resolve (b) and (c). 1534960 1 pnormand 2019-05-10 00:59:44 -0700 There are 2 independent options: - Blacklist AMDGPU in gst-vaapi, until its maintenance is increased and the issues are fixed - Víctor suggested to add a web-setting to disable hw-accelerated playback in WebKit, which also makes sense. 1534973 2 vjaquez 2019-05-10 03:51:42 -0700 (In reply to Philippe Normand from comment #1) > There are 2 independent options: > > - Blacklist AMDGPU in gst-vaapi, until its maintenance is increased and the > issues are fixed https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/72 > - Víctor suggested to add a web-setting to disable hw-accelerated playback > in WebKit, which also makes sense. o/ 1534991 3 mcatanzaro 2019-05-10 07:42:54 -0700 (In reply to Philippe Normand from comment #1) > - Blacklist AMDGPU in gst-vaapi, until its maintenance is increased and the > issues are fixed Are Intel users not experiencing these problems? If so, OK, of course. Presuming that patch in gstreamer-vaapi!72 is going to actually land soon. > - Víctor suggested to add a web-setting to disable hw-accelerated playback > in WebKit, which also makes sense. I mean, we could. But if it's off by default, nobody will ever turn it on. And if it's on by default, then it would become another setting that just needs to be disabled to make WebKit work, like accelerated compositing mode. For Epiphany, I would disable it unconditionally and then Intel users won't have -vaapi either. 1536210 4 pnormand 2019-05-14 13:05:26 -0700 *** Bug 197872 has been marked as a duplicate of this bug. *** 1536469 5 mcatanzaro 2019-05-15 10:10:00 -0700 (In reply to Michael Catanzaro from comment #0) > After removing gstreamer-vaapi from the GNOME runtime, I noticed: > > (a) Video corruption issues reported at > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/100 are fixed > (b) Dramatically improved scrolling performance and web process > responsiveness on pages with certain videos > (c) Dramatic reduction in web process hangs on pages with certain videos (a) should be fixed now (in mesa), but I don't know about (b) and (c). 1536472 6 pnormand 2019-05-15 10:14:12 -0700 Do we have detailed and reproducible bug reports for the remaining issues? 1536492 7 mcatanzaro 2019-05-15 10:40:55 -0700 Nope. 1536536 8 mcatanzaro 2019-05-15 12:18:49 -0700 What we could do is: once we get a freedesktop-sdk update containing the new mesa, do a test build with gst-vaapi restored. Then we can decide if we need to report more bugs and rollback (likely) or not. 1536555 9 webkit-bugzilla 2019-05-15 13:18:17 -0700 (In reply to Michael Catanzaro from comment #8) > What we could do is: once we get a freedesktop-sdk update containing the new > mesa, do a test build with gst-vaapi restored. Then we can decide if we need > to report more bugs and rollback (likely) or not. I'd love to help test this build. 1536646 10 mcatanzaro 2019-05-15 15:52:35 -0700 Great, then we'll have three data points (you, me, Philippe). More testing is better here. It's going to be some time before the new mesa reaches freedesktop-sdk though, and GNOME is often delayed in updating freedesktop-sdk if there are regressions. So now we wait. 1545124 11 mcatanzaro 2019-06-16 06:21:01 -0700 Status update: freedesktop-sdk has adopted Phil's patch from https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/72 and I've re-added gstreamer-vaapi to the GNOME runtime for testing. If it works for me, then we'll keep gstreamer-vaapi in the runtime for now. That !72 should really urgently be applied upstream. 1547444 12 mcatanzaro 2019-06-24 11:46:03 -0700 (In reply to Michael Catanzaro from comment #11) > If it works for me, then we'll keep gstreamer-vaapi in the runtime for now. Yeah, all good here. > That !72 should really urgently be applied upstream. Since this merge request still has not been accepted upstream, I really think it's time to proceed here. Leaving WebKit broken for tons of users isn't cool. I don't know how to blacklist GStreamer elements, but surely it's possible? I don't think this would be needed if !72 were merged, but it doesn't seem likely to happen? 1547487 13 pnormand 2019-06-24 12:36:53 -0700 No. We can't blacklist vaapi unconditionally. It seems to work fine on Intel GPUs so I would rather NOT penalise Intel users for the well-being of AMD users... 1547520 14 mcatanzaro 2019-06-24 13:31:44 -0700 Then could you push harder to land your !72 merge request, please? Because that really works based on my testing, and should eliminate all complaints. Otherwise, the choice is between performance and correctness. I'd much rather all users receive non-accelerated video that works rather than broken video. 1550365 15 mcatanzaro 2019-07-05 08:31:51 -0700 Update on this, trying to keep a bunch of parallel bugs in sync. freedesktop-sdk stopped using !72 and instead just disabled the gallium vaapi driver. This might have been a mistake, though: now we are getting complaints from non-gstreamer users of vaapi. Turns out everyone agrees that gallium driver is fine and gstreamer-vaapi is to blame for misusing it. That bug is https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/137. And !72 has still not yet been merged. This is just such a mess, and what's worse, it causes me to lose confidence in GStreamer itself as a dependency. It seems too easy to break WebKit by installing a bad GStreamer plugin. :/ 1648486 16 vjaquez 2020-05-04 02:02:35 -0700 In the last gstreamer hackfest I added a flag in playbin to block hardware-based decoders: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/485 With it we could add a setting to disable hardware accelerated decoders, if the user meet issues in their setup. 1648516 17 mcatanzaro 2020-05-04 07:23:27 -0700 That might be good to do. Regardless, you solved this issue last year when you merged gstreamer-vaapi!72. I haven't had a problem since then, and I haven't heard complaints from users since then either. So I don't think we need to keep this particular bug open anymore. 1943434 18 mcatanzaro 2023-03-23 11:22:53 -0700 This actually did eventually land in bug #240664