| Summary: | [GStreamer] Playing video causes very high CPU usage | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Kdwk <kdwkleung> | ||||||||||||
| Component: | Media | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
| Status: | RESOLVED DUPLICATE | ||||||||||||||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, philn | ||||||||||||
| Priority: | P2 | ||||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Kdwk
2023-02-03 04:47:56 PST
Created attachment 464820 [details]
Screencast showing CPU usage of Epiphany when playing video (high) VS Clapper when playing video (low)
That's a packaging issue. The GStreamer backend is capable of handling HW decoders but in the flatpak runtime the only GStreamer HW decoder shipped there is disabled. If your GPU is AMD or Intel you can try to set this env var in the flatpak runtime: GST_PLUGIN_FEATURE_RANK=vah264dec:MAX,vah265dec:MAX,vavp8dec:MAX,vavp9dec:MAX I'm afraid the problem persists after setting the environmental variable (using Flatseal). Can you try the env var mentioned in https://bugs.webkit.org/show_bug.cgi?id=251017#c19 ? (In reply to Philippe Normand from comment #4) > Can you try the env var mentioned in > https://bugs.webkit.org/show_bug.cgi?id=251017#c19 ? The original env var works, thanks (I made a mistake). Though I must say I don't really understand why the HW decoder is disabled in the runtime... Just tried the videos on https://wpewebkit.org/blog/05-new-svg-engine.html again. This time the problem persists even with the GST plugin rank environmental variable set. Please make sure to install org.freedesktop.Platform.GL.default//22.08-extra And then provide the output of flatpak run --command=gst-inspect-1.0 org.gnome.Epiphany.Devel va org.freedesktop.Platform.GL.default//22.08-extra is installed. Plugin Details: Name va Description VA-API codecs plugin Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so Version 1.20.5 License LGPL Source module gst-plugins-bad Source release date 2022-12-19 Binary package GStreamer Bad Plug-ins source release Origin URL freedesktop-sdk vaav1dec: VA-API AV1 Decoder vadeinterlace: VA-API Deinterlacer vah264dec: VA-API H.264 Decoder vah265dec: VA-API H.265 Decoder vampeg2dec: VA-API Mpeg2 Decoder vapostproc: VA-API Video Postprocessor vavp8dec: VA-API VP8 Decoder vavp9dec: VA-API VP9 Decoder 8 features: +-- 8 elements (In reply to Philippe Normand from comment #4) > Can you try the env var mentioned in > https://bugs.webkit.org/show_bug.cgi?id=251017#c19 ? Did you try this? WEBKIT_GST_DMABUF_SINK_ENABLED=1 Just tried, same result. VA decoders work fine in Clapper the video player (Flatpak). (In reply to kdwkleung from comment #10) > VA decoders work fine in Clapper the video player > (Flatpak). Yeah we know, it's already mentioned in earlier comments, no need to repeat :) I'll need a GST_DEBUG="*CAPS*:5" log please... How do I obtain this log? Thanks $ flatpak run --filesystem=home --command=/bin/bash org.gnome.Epiphany.Devel [📦 org.gnome.Epiphany.Devel ~]$ GST_DEBUG="3,webkit*:6" GST_DEBUG_FILE="$HOME/gst.log" GST_DEBUG_NO_COLOR=1 WEBKIT_FORCE_SANDBOX=0 epiphany The log file doesn't show up in my home directory after doing these. Try WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead of WEBKIT_FORCE_SANDBOX? Created attachment 465048 [details]
gst.log
The requested log.
Now with GST_DEBUG="3,webkit*:6,*CAPS*:5" Created attachment 465051 [details]
gst.log
Requested log file(1)
openh264dec0 is still used instead of the va decoder... Are you sure you set the rank as explained in comment 2 ? flatpak run --command=gst-inspect-1.0 org.gnome.Epiphany.Devel vah264dec If the rank shown is still NONE, rm $HOME/.var/app/org.gnome.Epiphany.Devel/cache/gstreamer-1.0/registry.x86_64.bin and: flatpak --env="GST_PLUGIN_FEATURE_RANK=vah264dec:MAX,vah265dec:MAX,vavp8dec:MAX,vavp9dec:MAX" run --command=gst-inspect-1.0 org.gnome.Epiphany.Devel vah264dec (In reply to Philippe Normand from comment #19) > openh264dec0 is still used instead of the va decoder... Are you sure you set > the rank as explained in comment 2 ? I set it in the org.gnome.Platform//master runtime by running `flatpak run --command=/bin/bash org.gnome.Platform` and then running `GST_PLUGIN_FEATURE_RANK=vah264dec:MAX,vah265dec:MAX,vavp8dec:MAX,vavp9dec:MAX`. > > flatpak run --command=gst-inspect-1.0 org.gnome.Epiphany.Devel vah264dec Factory Details: Rank none (0) Long-name VA-API H.264 Decoder Klass Codec/Decoder/Video/Hardware Description VA-API based H.264 video decoder Author VÃctor Jáquez <vjaquez@igalia.com> Plugin Details: Name va Description VA-API codecs plugin Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so Version 1.20.5 License LGPL Source module gst-plugins-bad Source release date 2022-12-19 Binary package GStreamer Bad Plug-ins source release > > If the rank shown is still NONE, rm > $HOME/.var/app/org.gnome.Epiphany.Devel/cache/gstreamer-1.0/registry.x86_64. > bin > > and: > > flatpak > --env="GST_PLUGIN_FEATURE_RANK=vah264dec:MAX,vah265dec:MAX,vavp8dec:MAX, > vavp9dec:MAX" run --command=gst-inspect-1.0 org.gnome.Epiphany.Devel > vah264dec Factory Details: Rank primary + 2147483391 (2147483647) Long-name VA-API H.264 Decoder Klass Codec/Decoder/Video/Hardware Description VA-API based H.264 video decoder Author VÃctor Jáquez <vjaquez@igalia.com> Plugin Details: Name va Description VA-API codecs plugin Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so Version 1.20.5 License LGPL Source module gst-plugins-bad Source release date 2022-12-19 Binary package GStreamer Bad Plug-ins source release As of now, the problem persists. (In reply to kdwkleung from comment #21) > As of now, the problem persists. New log please :) I look forward seeing openh264dec not mentioned in that one. Created attachment 465053 [details]
gst.log
Requested log file(2)
(In reply to Philippe Normand from comment #22) > (In reply to kdwkleung from comment #21) > > As of now, the problem persists. > > New log please :) I look forward seeing openh264dec not mentioned in that > one. grep disagrees. Look, I don't know what you're doing exactly, but you're experiencing the bug because this decoder is used, it's not a hardware decoder. vah264dec is working fine for me in that page loaded from Ephy TP. Closing. Unfortunately it appears the env var got reset before Epiphany is opened when set with your method. I got it to persist by setting it in Flatseal. The gst-inspect-1.0 now consistently reports vah264dec getting max rank. However, the problem persists. This time I'm able to get a new log file. I promise, I checked with both the Text Editor find tool and grep that the file does not contain a single instance of "openh264dec". Created attachment 465054 [details]
gst.log
Requested log file(3)
Setting WEBKIT_GST_DMABUF_SINK_ENABLED=1 does make CPU usage go down, but the video is basically visually corrupt. (In reply to kdwkleung from comment #28) > Setting WEBKIT_GST_DMABUF_SINK_ENABLED=1 does make CPU usage go down, but > the video is basically visually corrupt. Thanks, so same behaviour as in bug 251017 :( Let's close this as duplicate because I have no further ideas beyond the issue tracked in bug 251017. *** This bug has been marked as a duplicate of bug 251017 *** |