Epiphany, Eolie, etc. with WebkitGTK 2.34.1 cannot load video or get sound played well with a green-colored glitch graph. command : "gsettings set org.gnome.Epiphany.web:/ hardware-acceleration-policy 'never'" make Epiphany play video correctly. OS is latest Arch linux, laptop with Intel integrated graphs and NVIDIA standalone, both xorg and wayland session, flatpak version also tested, the issue is same. firefox performs normally with hardware acceleration.
Can you take a debug log following the instructions at https://trac.webkit.org/wiki/WebKitGTK/Debugging#Debuggingmultimediastuff please? Also make sure to uninstall gstreamer1-vaapi if you have it.
Created attachment 443809 [details] screenshot
Created attachment 443810 [details] logs with gstreamer-vaapi
Created attachment 443811 [details] logs without gstreamer-vaapi
Epiphany on Arch Linux
(In reply to Vicente from comment #2) > Created attachment 443809 [details] > screenshot So it's broken both with and without gstreamer-vaapi, and it really is caused by whether the page uses accelerated compositing rather than hardware video decoding. Interesting.
Moving this back to GTK component since it smells more like a graphics problem than a multimedia problem....
(In reply to Michael Catanzaro from comment #6) > So it's broken both with and without gstreamer-vaapi, and it really is > caused by whether the page uses accelerated compositing rather than hardware > video decoding. Interesting. No: without gstreamer-vaapi works well
(In reply to Michael Catanzaro from comment #1) > Can you take a debug log following the instructions at > https://trac.webkit.org/wiki/WebKitGTK/Debugging#Debuggingmultimediastuff > please? > > Also make sure to uninstall gstreamer1-vaapi if you have it. well uninstall gstreamer-vaapi fix it
(In reply to Tic2929014466 from comment #9) > well > uninstall gstreamer-vaapi fix it That is no solution... hardware video decoding is *necessary*
(In reply to Vicente from comment #10) > (In reply to Tic2929014466 from comment #9) > > well > > uninstall gstreamer-vaapi fix it > > That is no solution... hardware video decoding is *necessary* i understand otherwise switch to firefox fix all xd
Ah, OK. Can you please report this at https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/ then? Getting your issue to the correct issue tracker is essential if you want it fixed. :) Please include the two debug logs you attached above with your gstreamer-vaapi bug report, since they could be useful, and be sure to mention this only occurs when used in combination with WebKit's accelerated compositing mode. We've seen plenty of similar bugs in the past, but since they're inevitably hardware-specific there's not much we can do about it here. This is the first time someone has identified that it depends on WebKit's accelerated compositing mode, though.
Hi, I found running epiphany with environment variable "WEBKIT_FORCE_SANDBOX=0 WEBKIT_DISABLE_COMPOSITING_MODE=1", video plays well without any glitch and in intel_gpu_top, both Video and VideoEnhance channel has value changed, shows hardware acceleration in use. Therefore I think the issue may not relate to GStreamer. I've seen glitch graph always relate to page content, perhaps there's something wrong in WebKit's GPU Render. Here's discussion from GStreamer https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/877
It looks like the GStreamer devs have reproduced the issue without WebKit involved at all [1]. We already established that the bug requires accelerated compositing mode. As to why WEBKIT_FORCE_SANDBOX makes a difference, I don't know, but maybe the sandbox is blocking access to something that vaapi needs, "fixing" the issue? Hi Victor, any thoughts on that? [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/877#note_1154667
(In reply to Michael Catanzaro from comment #14) > It looks like the GStreamer devs have reproduced the issue without WebKit > involved at all [1]. > > We already established that the bug requires accelerated compositing mode. > As to why WEBKIT_FORCE_SANDBOX makes a difference, I don't know, but maybe > the sandbox is blocking access to something that vaapi needs, "fixing" the > issue? Hi Victor, any thoughts on that? > > [1] > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/877#note_1154667 I didn't expect WEBKIT_FORCE_SANDBOX fix the problem, that was because I wanted to make Epiphany perform more like WebKit MiniBrowser. Now I think hardware compositing and hardware video acceleration are two different modules, and they have a mystic conflict when both enabled. Sandbox plays a role, though.
(In reply to Michael Catanzaro from comment #14) > It looks like the GStreamer devs have reproduced the issue without WebKit > involved at all [1]. > > We already established that the bug requires accelerated compositing mode. > As to why WEBKIT_FORCE_SANDBOX makes a difference, I don't know, but maybe > the sandbox is blocking access to something that vaapi needs, "fixing" the > issue? Hi Victor, any thoughts on that? > > [1] > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/877#note_1154667 I added some notes in the gstreamer issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/877#note_1160747 Yet, it's pending to verify if the sandbox affects the output. A preliminary conclusion is, when WebKitGLVideoSink is used (when composite is enabled) with gstreamer-vaapi garbage is rendered. While with the new gstva ements are used (with vapostproc), only the color space is not handled correctly (if no vapostproc is added, only the va decoder, the rendering is correct). I wonder if WebKitGLVideoSink requests the correct number of retained frames to upstream in pool negotiation, and if gstreamer-vaapi frames lifetimes are handled right.