CPU usage when viewing pages that contains mjpeg videos

RESOLVED FIXED in Firefox 22

Status

()

RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: josep.sanz, Assigned: seth)

Tracking

({regression})

22 Branch
mozilla23
x86_64
All
regression
Points:
---

Firefox Tracking Flags

(firefox21 unaffected, firefox22+ fixed, firefox23 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20130401 Firefox/22.0
Build ID: 20130401030817

Steps to reproduce:

I try to see this page some times:
- http://www.oadm.cat/en/content/61/live-webcams.htm


Actual results:

And when go to another page, the CPU usage is 100%!!!


Expected results:

I can understand that while the mjpeg video is running, firefox can require more amount of CPU but when I close or I go to another page, the cpu usage must be normal.

Comment 1

6 years ago
I can reproduce
http://hg.mozilla.org/mozilla-central/rev/0b7c27024048
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130401 Firefox/22.0 ID:20130401030817
Blocks: 716140
Status: UNCONFIRMED → NEW
tracking-firefox22: --- → ?
Component: Untriaged → ImageLib
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core

Comment 2

6 years ago
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/bef19bca23f9
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130325 Firefox/22.0 ID:20130325015122
Bad:
http://hg.mozilla.org/mozilla-central/rev/4d3250f3afea
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130325 Firefox/22.0 ID:20130325093524
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bef19bca23f9&tochange=4d3250f3afea


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/71fe5b69c834
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130324 Firefox/22.0 ID:20130324205822
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/1541b7a03e17
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130324 Firefox/22.0 ID:20130324220925
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=71fe5b69c834&tochange=1541b7a03e17

Comment 3

6 years ago
I can also reproduce on http://www.shioda-dcom.co.jp/shiocame/
Keywords: regression

Comment 4

6 years ago
May need to discuss with other contributors to bug 716140 about ownership here.
Assignee: nobody → joe
status-firefox21: --- → unaffected
status-firefox22: --- → affected
tracking-firefox22: ? → +
I cannot reproduce this with my patches in Bug 854803, but can without.

I'm going to optimistically call this a dupe. Please reopen if there is reason to believe otherwise.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 854803

Comment 6

6 years ago
CPU usage is low during play the mjpeg on the try build.

However, I can still reproduce the High CPU usage after close the tab.

http://hg.mozilla.org/try/rev/8360f6cd74a9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130331 Firefox/22.0 ID:20130331231006
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 7

6 years ago
The try server build of Bug 856486 Comment#6 does not fix the high CPU usage after close the tab :(

http://hg.mozilla.org/try/rev/6a78b2e8ecb9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130402 Firefox/23.0 ID:20130402173333

Comment 8

6 years ago
Stack during the high CPU usage after close the tab.
bp-73703684-cd7c-439b-8ff1-0e8fd2130403
(Stack using http://benjamin.smedbergs.us/crashfirefox.exe)

Comment 9

6 years ago
The try server build of Bug 856486 Comment#8 does not fix the high CPU usage after close the tab :(

http://hg.mozilla.org/try/rev/9aa6bef16179
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130403 Firefox/23.0 ID:20130403135600
(Assignee)

Comment 10

6 years ago
I can confirm this issue occurs on OS X as well, even with all of the various mJPEG-related fixes that are currently posted applied. Investigating now.
(Assignee)

Comment 11

6 years ago
Created attachment 733153 [details] [diff] [review]
RasterImage::DecodeJob should not reschedule itself if it can't make progress.

The problem seems to be that the image decoder thread keeps spinning away even when you leave the page, although it cannot make any more progress (it's not getting more data delivered to it), because we don't have a termination condition for it that covers this case. IMO the original termination conditions should have been sufficient, and the real cause is bug 857876, but that seems _much_ harder to fix, and I have no confidence the fix will come quickly, so I think it's still worth adding a termination condition to resolve this problem right away.

This patch is essentially a one-liner that says "if the DecodeJob didn't make any progress this time, it shouldn't reschedule itself".
Attachment #733153 - Flags: review?(jmuizelaar)
(Assignee)

Updated

6 years ago
Assignee: joe → seth

Comment 13

6 years ago
(In reply to Seth Fowler [:seth] from comment #12)
> Try job here: https://tbpl.mozilla.org/?tree=Try&rev=0349128958e7

The try server build works very well and fixed the CPU problem.

http://hg.mozilla.org/try/rev/0349128958e7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130403 Firefox/23.0 ID:20130403190924
http://hg.mozilla.org/try/rev/0349128958e7
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130403 Firefox/23.0 ID:20130403191148
(Assignee)

Comment 14

6 years ago
Thanks for the verification, Alice. The try results look good too.
Comment on attachment 733153 [details] [diff] [review]
RasterImage::DecodeJob should not reschedule itself if it can't make progress.

This seems reasonable to me.
Attachment #733153 - Flags: review?(jmuizelaar) → review+
(Assignee)

Comment 16

6 years ago
Thanks for the review!

Pushed to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/8161280e740e
https://hg.mozilla.org/mozilla-central/rev/8161280e740e
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
We should get this into 22.
Flags: needinfo?(seth)
(Assignee)

Comment 19

6 years ago
Sure. There are a couple of other related bugs. I will request uplift for all of them.
Flags: needinfo?(seth)
(Assignee)

Comment 20

6 years ago
Comment on attachment 733153 [details] [diff] [review]
RasterImage::DecodeJob should not reschedule itself if it can't make progress.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 716140
User impact if declined: Massive CPU usage regression. Will persist for the entire session once the user views an mJPEG image, even if they leave the page.
Testing completed (on m-c, etc.): On m-c without problems since 2013-04-05.
Risk to taking this patch (and alternatives if risky): Low. This is a very small patch that prevents a DecodeJob from continuing if it isn't making progress. Even if this were to happen for reasons unrelated to this bug, a new DecodeJob would still be scheduled if more data eventually did arrive, so this should be a safe choice.
String or IDL/UUID changes made by this patch: None.
Attachment #733153 - Flags: approval-mozilla-aurora?
Attachment #733153 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox22: affected → fixed
status-firefox23: --- → fixed
I confirm the fix is verified on FF 23b6: Build ID: 20130715155216
status-firefox23: fixed → verified
You need to log in before you can comment on or make changes to this bug.