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).
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.
(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/
(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.
*** Bug 197872 has been marked as a duplicate of this bug. ***
(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).
Do we have detailed and reproducible bug reports for the remaining issues?
Nope.
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.
(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.
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.
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.
(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?
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...
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.
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. :/
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.
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.
This actually did eventually land in bug #240664