Closed Bug 1190530 Opened 4 years ago Closed 4 years ago

2.5G+ memory usage after watching MSE streams


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

Windows 7



Tracking Status
firefox42 --- affected


(Reporter: gcp, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [MemShrink])


(1 file)

Attached file memory-report.json.gz
STR (approximately)

1) Watch
2) Close tab
3) Watch

plugin-container uses 2.6G RAM, and has big pauses for example when entering text in this bugzilla box.

I don't like how this looks:  ghost?

2,628.39 MB (100.0%) -- explicit
├──2,101.14 MB (79.94%) ── heap-unclassified
├────369.15 MB (14.04%) -- window-objects
│    ├──246.38 MB (09.37%) -- top(none)
│    │  ├──246.22 MB (09.37%) -- ghost
│    │  │  ├──234.33 MB (08.92%) -- window(
Jean-Yves, the stream is using MSE. Does this look like an MSE eviction problem?
Flags: needinfo?(jyavenard)
Priority: -- → P1
You may need to go to:

(Which is the "watch live" button on the first page)

It seems the stream on the frontpage is an embedded YouTube stream (also MSE).
(In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> It seems the stream on the frontpage is an embedded YouTube stream (also
> MSE).

... as opposed to Steam Broadcast in "Watch Live" which is a different MSE implementation.
Bug 1189194 is one Jesse filed about another thing with video and very high heap-unclassified. There's a DMD report in there which shows where the memory is going.
(This report looks to be on Windows and Jesse's was on OSX, so it may look a little different.)
Whiteboard: [MemShrink]
crash-stats shows an increase in OOMs on nightly starting in build 20150723030207.

jya, you're looking pretty suspicious!
Bug 1190258 is probably related to this one.
FWIW, the tool-tip in about:memory explains what ghost windows are...

> The number of ghost windows present (the number of nodes underneath
> explicit/window-objects/top(none)/ghost, modulo race conditions).  A ghost
> window is not shown in any tab, does not share a domain with any non-detached
> windows, and has met these criteria for at least
> memory.ghost_window_timeout_seconds, or has survived a round of
> about:memory's minimize memory usage button.
> Ghost windows can happen legitimately, but they are often indicative of leaks
> in the browser or add-ons.
(In reply to David Major [:dmajor] from comment #6)
> crash-stats shows an increase in OOMs on nightly starting in build
> 20150723030207.
> pushloghtml?fromchange=8e5c888d0d89&tochange=1f77b78797d6
> jya, you're looking pretty suspicious!

I think it's just revealing an existing bug.

The MediaDecoder::Shutdown() function isn't called until you quit the application.

Those memory issue are all the same as bug 1190592
Flags: needinfo?(jyavenard)
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1190019
I'll note that the duped bugs claims "with e10s disabled" but this was with e10s enabled as you can see from the memory report.
If you disable e10s; do you still experience the issue?

I'm playing this video ; with the quality set at 720p.

Once 100MB is reached for the video, the memory usage stop growing. I've had it running for over 45 minutes in a profiler.

A youtube video is made of two sourcebuffer; each can take up to 100MB ; this is normally how much the window will grow by.

If you have multiple tabs open, with youtube playing, it doesn't take long to reach 2GB, but that's not what this bug is about obviously.

My testing were made on the mac ; so that removes any potential leak in the windows h264 decoder itself or the DXVA rendering.
You need to log in before you can comment on or make changes to this bug.