This was exposed by the tests I wrote in bug 1136399. OutOfDecodedAudio() is overly-simplistic, and doesn't consider the fact that we can have a bit more than 1s of audio in the hardware buffer. I've got a patch that seems to do the trick.
Created attachment 8570202 [details] [diff] [review] Account for audio frames already pushed to audio hardware but not yet played when computing OutOfDecodedAudio. v1
Attachment #8570202 - Flags: review?(kinetik)
Attachment #8570202 - Flags: review?(kinetik) → review+
(In reply to Bobby Holley (:bholley) from comment #2) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=098a64f8a733 The oranges in the try push were a test that I pushed alongside this patch and wasn't ready yet. Aside from that this is green. https://hg.mozilla.org/integration/mozilla-inbound/rev/3148c577bfd9
This could improve our MTBR stats on YouTube. Let's consider uplifting after it bakes a bit.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Comment on attachment 8570202 [details] [diff] [review] Account for audio frames already pushed to audio hardware but not yet played when computing OutOfDecodedAudio. v1 Requesting uplift approval for 38 and 37b3 since this is a low risk fix to a high priority issue. Approval Request Comment [Feature/regressing bug #]: MSE [User impact if declined]: Unnecessary rebuffering pauses during youtube playback. [Describe test coverage new/current, TreeHerder]: Landed on m-c. [Risks and why]: Risk looks low. This just adds another condition to deciding we're out of audio data and need to request more. [String/UUID change made/needed]: None.
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox38: affected → fixed
status-firefox37: affected → fixed
You need to log in before you can comment on or make changes to this bug.