Closed
Bug 1190530
Opened 9 years ago
Closed 9 years ago
2.5G+ memory usage after watching MSE streams
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox42 | --- | affected |
People
(Reporter: gcp, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink])
Attachments
(1 file)
253.68 KB,
application/x-gzip
|
Details |
STR (approximately) 1) Watch http://www.dota2.com/international/live/ 2) Close tab 3) Watch https://www.youtube.com/watch?v=VUW9emA4Kao 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(http://steamcommunity.com/broadcast/watch/76561198198486997?iframe=1&origin=http%3A%2F%2Fwww.dota2.com&enablevideo=1)
Comment 1•9 years ago
|
||
Jean-Yves, the dota2.com stream is using MSE. Does this look like an MSE eviction problem?
Reporter | ||
Comment 2•9 years ago
|
||
You may need to go to: http://www.dota2.com/watch/76561198198486997 (Which is the "watch live" button on the first page) It seems the stream on the frontpage is an embedded YouTube stream (also MSE).
Reporter | ||
Comment 3•9 years ago
|
||
(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.
Comment 4•9 years ago
|
||
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.
Comment 5•9 years ago
|
||
(This report looks to be on Windows and Jesse's was on OSX, so it may look a little different.)
Updated•9 years ago
|
Whiteboard: [MemShrink]
crash-stats shows an increase in OOMs on nightly starting in build 20150723030207. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e5c888d0d89&tochange=1f77b78797d6 jya, you're looking pretty suspicious!
Comment 7•9 years ago
|
||
Bug 1190258 is probably related to this one.
Comment 8•9 years ago
|
||
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.
Comment 9•9 years ago
|
||
(In reply to David Major [:dmajor] from comment #6) > crash-stats shows an increase in OOMs on nightly starting in build > 20150723030207. > > https://hg.mozilla.org/mozilla-central/ > 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)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 11•9 years ago
|
||
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.
Comment 12•9 years ago
|
||
If you disable e10s; do you still experience the issue? I'm playing this video https://www.youtube.com/watch?v=jEnd8JIMii4 ; 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.
Resolution: DUPLICATE → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•