Closed Bug 1159366 Opened 5 years ago Closed 5 years ago
youtube live stream: switching resolution causes high cpu & memory use
16.45 KB, text/plain
memory report taken when FF was consuming about 2.x gb (lightly edited to remove my username & email)
175.85 KB, application/x-gzip
1.30 KB, patch
|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.
5 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 188.8.131.52, Privacy mode ON.
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
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.
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
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.
Anthony Jones, I spoke to Lawrence Mandel about this on IRC and suggested I flag your team to look into this.
5 years ago
Too late for 38 but we could take a patch for 39.
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.
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.
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)
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+
Flagging this for QE verification to make sure this is fixed and did not introduce any new regressions.
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
Comment on attachment 8607314 [details] [diff] [review] sidx-check User facing bug, should be safe, early in the 39 cycle, taking it.
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.
(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.
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).
Also verified using Firefox 41 beta 5 on same OS`s from comment 23.
You need to log in before you can comment on or make changes to this bug.