Closed
Bug 1159366
Opened 9 years ago
Closed 9 years ago
youtube live stream: switching resolution causes high cpu & memory use
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
People
(Reporter: gabriel.branchaud, Assigned: mattwoodrow)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files)
16.45 KB,
text/plain
|
Details | |
175.85 KB,
application/x-gzip
|
Details | |
1.30 KB,
patch
|
jya
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150420134330 Steps to reproduce: 1. start firefox in "safe-mode" 2. open https://www.youtube.com/watch?v=dH496B9QsRk (live until april 30th 2015) 3. using the "gear" icon in the youtube player, switch resolution (to, say, 720p) Actual results: 4. The youtube player shows the "spinner" 5. Firefox starts to consume about 30% of the cpu and its memory use grows to about 2.7gb (according to the "memory" column of the Windows Task Manager) 6. memory & cpu falls down to original levels after peaking (down to about 350mb of memory; >1% of cpu use). 7. the stream never switches resolution (the "spinner" is still spinning in the youtube player) Expected results: 4. The youtube player shows the "spinner" 5. The stream switches resolution and the video goes on.
Reporter | ||
Comment 1•9 years ago
|
||
Updated•9 years ago
|
Component: Untriaged → Video/Audio
Product: Firefox → Core
I can confirm the bug, it happened even with HTML5 live stream, and maybe just on youtube (I tried twitch and ustream website, and there the live stream is OK) you can go to https://www.youtube.com/live to reproduce it. Just click on an active live stream and change resolution (no matter if higher or lower): memory go up (leak?) until FF is frozen (with my pc). Tested on PC with Windows 7 64bit, Firefox 38.0, flash 17.0.0.188, Privacy mode ON.
Comment 3•9 years ago
|
||
I have this bug too. The bug happens when changing resolution or when seeking to a different time. For more details see my bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1164659
Comment 4•9 years ago
|
||
Per comment 2, it should be pretty easy for QA to verify this bug. Just go to https://www.youtube.com/live and then open a live stream. To experience the bug, either change resolution or seek to a different time. I hope someone from QA has the time to do this verification. So that the bug can be worked on by the right people as soon as possible. I think this bug is important. Because YouTube is one of the most popular websites worldwide, and it should function properly in Firefox. Every day YouTube doesn't work properly Firefox will probably lose market share.
Flags: needinfo?(anthony.s.hughes)
Marking this bug as NEW as I can reproduce this with Firefox but not with Chrome. I suspect this might be a tech evangelism issue but I'll need a developer to confirm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(anthony.s.hughes)
OS: Unspecified → All
Hardware: Unspecified → All
Version: 38 Branch → Trunk
[Tracking Requested - why for this release]: nominating to track mainly to raise awareness of this issue.
status-firefox38:
--- → affected
status-firefox38.0.5:
--- → affected
status-firefox39:
--- → affected
status-firefox40:
--- → affected
status-firefox41:
--- → affected
status-firefox-esr38:
--- → affected
tracking-firefox38:
--- → ?
tracking-firefox38.0.5:
--- → ?
Anthony Jones, I spoke to Lawrence Mandel about this on IRC and suggested I flag your team to look into this.
Flags: needinfo?(ajones)
Comment 9•9 years ago
|
||
Too late for 38 but we could take a patch for 39.
Assignee | ||
Comment 10•9 years ago
|
||
I think there's at least a few bugs here. The first is that we keep getting MDSM::OnAudioDecodeFailed, which sets a WaitForData promise request on the reader, and when that finishes calls DispatchDecodeTasksIfNeeded. We're still in DECODER_STATE_SEEKING and mDecodeToSeekTarget is true (this is only cleared once we've finished seeking both video and audio), so NeedToDecodeVideo/Audio both return true. This keeps repeating, with us decoding a new video frame and failing to decode audio every time. The endless video decoding is using all the CPU time it can, and we keep collecting all the video frame in VideoQueue() so memory usage climbs quickly. I think we might want to split mDecodeToSeekTarget into separate audio/video variables so we can stop decoding one when we're only really waiting on the other. I'm still looking into why the audio track isn't decoding.
Assignee | ||
Comment 11•9 years ago
|
||
During MediaSourceReader::OnAudioNotDecoded, mLastAudioTime is 14395590082, but the end of the buffered range is 14614739333. We update mLastAudioTime to the end value, but then set it back again because the difference is bigger than EOS_FUZZ_US. WaitForData always resolves the promise immediately, because mLastAudioTime is before the end of the buffered range.
Assignee | ||
Comment 12•9 years ago
|
||
Do we really need to check IsMediaSegmentPresent as well as gotMedia? The problem was that ParseStartAndEndTimestamp was returning true and a valid set of times (that overlapped with mLastEndTimestamp considerably), but IsMediaSegmentPresent returned false (since the data started with sidx, not moof or styp) and we appended into the existing decoder.
Attachment #8607314 -
Flags: review?(jyavenard)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → matt.woodrow
Comment 13•9 years ago
|
||
Comment on attachment 8607314 [details] [diff] [review] sidx-check Review of attachment 8607314 [details] [diff] [review]: ----------------------------------------------------------------- Would much prefer that we test for the presence of a moof. Or if sidx that it's immediately following the moof
Attachment #8607314 -
Flags: review?(jyavenard) → review+
Comment 15•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/df6daac07473
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment 16•9 years ago
|
||
Flagging this for QE verification to make sure this is fixed and did not introduce any new regressions.
Flags: qe-verify+
Assignee | ||
Comment 17•9 years ago
|
||
Comment on attachment 8607314 [details] [diff] [review] sidx-check Approval Request Comment [Feature/regressing bug #]: MSE [User impact if declined]: Infinite loading spinner when changing resolutions on youtube live streams [Describe test coverage new/current, TreeHerder]: Manually tested [Risks and why]: Very low risk, simple change to how we detect media segments [String/UUID change made/needed]: None
Attachment #8607314 -
Flags: approval-mozilla-beta?
Attachment #8607314 -
Flags: approval-mozilla-aurora?
Comment 18•9 years ago
|
||
Comment on attachment 8607314 [details] [diff] [review] sidx-check User facing bug, should be safe, early in the 39 cycle, taking it.
Attachment #8607314 -
Flags: approval-mozilla-beta?
Attachment #8607314 -
Flags: approval-mozilla-beta+
Attachment #8607314 -
Flags: approval-mozilla-aurora?
Attachment #8607314 -
Flags: approval-mozilla-aurora+
Comment 19•9 years ago
|
||
Just a small comment, the bug did not only happen when changing resolutions, but also when seeking to an earlier time (using the seek bar at the bottom of the video). Seeking to an earlier time in a live broadcast also led to an infinite loading spinner. Is this bug also fixed? This is something that really should be checked. Both changing resolutions and seeking to a different time should work properly.
Comment 22•9 years ago
|
||
(In reply to dusty-2011 from comment #19) > Just a small comment, the bug did not only happen when changing resolutions, > but also when seeking to an earlier time (using the seek bar at the bottom > of the video). Seeking to an earlier time in a live broadcast also led to an > infinite loading spinner. Is this bug also fixed? You should be able to check this yourself by grabbing the latest Nightly build from https://nightly.mozilla.org.
Comment 23•9 years ago
|
||
Reproduced the initial issue on Firefox 38 beta 5, verified that using Firefox 39 beta 1 on Windows 10 64-bit and Windows 7 64-bit Firefox does not eat more then 300MB of memory and different live stream video actions are quick and smooth (seek, change quality, next, pause, play, volume, reload etc).
Comment 24•9 years ago
|
||
Also verified using Firefox 40 beta 4 on same OS`s.
Comment 25•9 years ago
|
||
Also verified using Firefox 41 beta 5 on same OS`s from comment 23.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•