Bug 205561

Summary: [GTK][GStreamer] Extremely high CPU usage due to video playback
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: bugs-noreply, mcrha, philn, pnormand
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
URL: https://www.nytimes.com/interactive/2019/12/20/opinion/location-tracking-smartphone-marketing.html
Attachments:
Description Flags
Backtraces none

Sergio Villar Senin
Reported 2019-12-23 09:49:22 PST
Steps to reproduce: 1- Open https://www.nytimes.com/interactive/2019/12/20/opinion/location-tracking-smartphone-marketing.html The CPU usage rockets to 600% on my laptop and it keeps that way as long as the page is opened. Even if I scroll to a point where only text is shown the CPU usage is super high. Attaching to the WebProcess with gdb shows tons of GStreamer threads (>60). I've built WebKit with --no-video and the CPU usage goes down to 6-7% as any other web page.
Attachments
Backtraces (157.98 KB, text/plain)
2019-12-27 07:43 PST, Sergio Villar Senin
no flags
Sergio Villar Senin
Comment 1 2019-12-23 09:51:42 PST
BTW I had also tried with --no-web-rtc --no-media-stream first before building with --no-video and in that case the CPU usage goes down to 150%. So there is WebRTC stuff going on there too hijacking the CPU.
Sergio Villar Senin
Comment 2 2019-12-27 07:43:00 PST
Created attachment 386444 [details] Backtraces Backtraces of all running threads (88!!!) just after loading the web page. My GStreamer knowledge is pretty limitted but some of the backtraces look really scary, see #74, #65, #63, #54, #47, #38 or #29.
Sergio Villar Senin
Comment 3 2019-12-27 09:16:32 PST
Hmm after some investigation I am not sure this is a bug on our side, but the natural consecuence of a bad designed bloated webpage. After checking the DOM I see no less than 14 videos with both autoplay and loop enabled. I'd wait for the multimedia experts but I guess we can close this.
Philippe Normand
Comment 4 2020-07-20 07:18:00 PDT
Could this have been due to AC being disabled in Ephy?
Milan Crha
Comment 5 2021-08-05 02:55:37 PDT
Similar report from Epiphany: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1572 Using epiphany-40.1-1.fc34.x86_64 with webkit2gtk3-2.32.3-1.fc34.x86_64. It does this even when the video playback is paused in the MiniBrowser (or set as Deny autoplay in Epiphany).
Philippe Normand
Comment 6 2022-12-24 02:32:29 PST
(In reply to Sergio Villar Senin from comment #3) > Hmm after some investigation I am not sure this is a bug on our side, but > the natural consecuence of a bad designed bloated webpage. After checking > the DOM I see no less than 14 videos with both autoplay and loop enabled. > I don't think we can do much about this... You can disable autoplay with the --media-playback-requires-user-gesture=1 websetting. (In reply to Milan Crha from comment #5) > Similar report from Epiphany: > https://gitlab.gnome.org/GNOME/epiphany/-/issues/1572 > > Using epiphany-40.1-1.fc34.x86_64 with webkit2gtk3-2.32.3-1.fc34.x86_64. It > does this even when the video playback is paused in the MiniBrowser (or set > as Deny autoplay in Epiphany). I can't reproduce this issue in MiniBrowser with --media-playback-requires-user-gesture=1 ...
Note You need to log in before you can comment on or make changes to this bug.