963922 - Dispose unneeded decoders more aggressively

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect, P2)

Description

[Emanuel Hoogeveen [:ehoogeveen]]

Attachment: Testcase that creates 1000 audio elements, starts playing and then pauses them. Depends on content/media/test/sound.ogg

I made this testcase for bug 958796 to see if the changes there would reduce (virtual) memory usage. I found that it produces large amounts of heap-unclassified (67% after one run on a fresh profile), and reloading the page a bunch of times quickly crashes the browser on OOM. The memory isn't leaked - waiting a while makes it go back down, as does closing the tab. However it takes a few seconds before this happens, so holding down F5 to reload the page over and over again (or just pressing it a few times a second) is enough to OOM the browser in a few seconds.

I don't really have any experience with html or JS, so this testcase might be pretty awful :) Still, I think it exposes some pretty bad behavior. Perhaps this is the same issue as bug 962986?

Comment 1

[Nicholas Nethercote [inactive]]

> Perhaps this is the same issue as bug 962986?

Bug 960873 (and hence bug 961441) might also be relevant.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Emanuel, can you try the patches from bug 960873?  It does sound very much like I saw in that bug.  The current proposed patches should fix the issue for ogg/vorbis.

Comment 3

[Emanuel Hoogeveen [:ehoogeveen]]

I applied the patches in a local build, but it didn't seem to make any difference:
- Memory usage after loading the testcase was roughly the same
- about:memory still showed 67% heap-unclassified
- Quickly refreshing the page with the testcase still OOMed the browser

Comment 4

[Emanuel Hoogeveen [:ehoogeveen]]

Attachment: DMD output after running testcase

Here's the output of running DMD after the testcase has been loaded.

Comment 5

[Nicholas Nethercote [inactive]]

Attachment: Most important part of the DMD output

Here's the important part of the DMD output. It's obviously all Ogg Vorbis stuff. I don't know enough about the media memory reporters to understand why this memory isn't being measured.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Looks like a known issue that the libvorbis internals need a memory reporter.  See bug 677653.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

I am working towards architectural changes that will make it easier to be more aggressive in disposing of decoders that we think we won't need. This will help here.

Comment 8

[Nicholas Nethercote [inactive]]

(In reply to Chris Pearce (:cpearce) from comment #7)
> I am working towards architectural changes that will make it easier to be
> more aggressive in disposing of decoders that we think we won't need. This
> will help here.

Let's make this bug about doing that.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

I am working on the dependencies of this now.

Comment 10

[ferongr]

Some 4chan boards have enabled posting .webm files instead of images and the page's script can display them inline. Opening many of them results in large amounts of memory used as follows.

├──1,038.35 MB (43.39%) -- media
│  ├──1,034.86 MB (43.25%) -- decoded
│  │  ├──1,034.83 MB (43.25%) ── video

I assume this bug covers this issue and I don't need to file a new one, right?

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to ferongr from comment #10)
> Some 4chan boards have enabled posting .webm files instead of images and the
> page's script can display them inline. Opening many of them results in large
> amounts of memory used as follows.

This bug is one of the things that needs to be fixed.

Memory use will probably already be a little better in Firefox 31 (current Firefox Nightly) thanks to bug 631058. Provided those videos aren't all trying to play at once.

Comment 12

[Sam]

Further to ferongr's question, using 4chan pages with large amounts of WebM videos can result in Firefox CPU use skyrocketing after some time browsing a single thread (page). Closing the tab and reopening it stops this. This happens when you use a feature of 4chan which makes the video pop up and play as you hover over the corresponding thumbnail on the page, and then disappear when the cursor leaves the thumbnail. Presumably the video is still playing in the background but I'm not sure. Is this the same bug or should I file it in detail separately?

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Sam from comment #12)
> Is this the same bug or
> should I file it in detail separately?

This is the same bug. Thanks for following up.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

We now dispose of decoders aggressively.