|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
+++ This bug was initially created as a clone of Bug #1323847 +++ +++ This bug was initially created as a clone of Bug #1305284 +++ The problem persists. Reproducible: always Steps To Reproduce(e.g. I can be reliably reproduced): 1. Open https://www.youtube.com/watch?v=vmotO-7Bzt4 2. Change resolution to 144p from gear icon 3. Right-click the HTML5 Player, click "Stats for nerds" and ensure 'Mime Type: video/webm; codecs="vp9"' 4. Pause 5. Seek to 0:00 6. Change resolution to 480p from gear icon 7. Play Actual Results: At around 0:16, sound breaks off. I'm feeling it was stopping about hundreds mili-second. It's a large gap. The progress bar of the HTML5 Player looks like buffer was dropped, or adjusted.(?) Expected Results: Finished normally
[Tracking Requested - why for this release]: The problem is reproducible since Firefox51beta, but not on Firefox50.1.0
status-firefox50: --- → unaffected
status-firefox51: --- → affected
status-firefox52: --- → affected
tracking-firefox51: --- → ?
tracking-firefox52: --- → ?
tracking-firefox53: --- → ?
Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b535fb46742b36ecc87a8d1fba4a7fad27714588&tochange=d441ac0b35aedaf1df5ffe995cd4ffaaa697ee49 Regressed by: Bug 1280023
Is this still happening with bug 1323847 in?
(In reply to Jean-Yves Avenard [:jya] from comment #3) > Is this still happening with bug 1323847 in? Tested with : https://hg.mozilla.org/mozilla-central/rev/a3ce1fce4f15616f66ac328e4a562d0117c93a0d Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 ID:20161218030213 Bug 1323847 did not fix this.
This is not a bug in our implementation per say. We're doing what the specs say we should do. When the new buffer is appended the source buffer is full (size exceed 12MB). As part of the prepare append algorithm. https://w3c.github.io/media-source/index.html#sourcebuffer-prepare-append we reject the new append. The issue here is that the data that's going to be added will overwrite existing data and as such, will not cause the size to increase. But the Prepare Append Algorithm has no way to tell that this will be the case. It can't distinguish new data with about to be overwritten data. Issue is on YouTube's end really, they add way too much audio in advance (over 5 minutes worth) and flush the entire buffer when a quota exceeded error occur. :k17e could we raise the issue with YouTube? Or we can bump again the audio threshold to 30MB like we used to.... there would still be ways to reproduce the problem, were you adding tape to hide the problem. Just less likely to happen.
( FWIW, in this case, workaround is as follows user_pref("media.mediasource.eviction_threshold.audio", 15728640); )
(In reply to Alice0775 White from comment #6) > ( > FWIW, in this case, workaround is as follows > user_pref("media.mediasource.eviction_threshold.audio", 15728640); > ) yeah, this is what I was thinking.. but that doesn't guarantee the issue won't occur again with different steps...
Richard - why does YouTube flush the entire buffer when the quota is exceeded? Shouldn't it simply stop appending data for a while?
Track 51+/52+/53+ as some youtube musics are broken.
tracking-firefox51: ? → +
tracking-firefox52: ? → +
tracking-firefox53: ? → +
Comment on attachment 8819847 [details] Bug 1324306: [MSE] Bump audio memory threshold to 20MB. https://reviewboard.mozilla.org/r/99462/#review99974
Attachment #8819847 - Flags: review?(gsquelart) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/3e76f6a459f9 [MSE] Bump audio memory threshold to 20MB. r=gerald
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Hi :jya, Do you think this is worth uplifting to Beta51 & Aurora52?
yes... though we also need bug 1323847. Will apply for uplift
Comment on attachment 8819847 [details] Bug 1324306: [MSE] Bump audio memory threshold to 20MB. Approval Request Comment [Feature/Bug causing the regression]: 1280023 [User impact if declined]: Discontinuous audio playback in YouTube [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: OP has reported that the issue was fixed by setting a threshold of 15MB, for greater safety, we set it to 20MB [Needs manual test from QE? If yes, steps to reproduce]: Descriptions provided in bug [List of other uplifts needed for the feature/fix]: 1323847 [Is the change risky?]: No [Why is the change risky/not risky?]: bumping the threshold makes us closer to what was there prior 1280023 [String changes made/needed]:
Comment on attachment 8819847 [details] Bug 1324306: [MSE] Bump audio memory threshold to 20MB. Fix a regression related to webm/vp9 audio. Beta51+ & Aurora52+. Should be in 51 beta 10.
status-firefox52: affected → fixed
status-firefox51: affected → fixed
I could not reproduce this issue following the steps from the description. I also used the nightly from 2016-12-18 and Fx51.0b1 - Fx 51.0b4 on Windows 10 x32 and Windows 10 x64. Is there a possibility that the issue is from the site or am I missing something?
(In reply to Cristian Comorasu from comment #20) > I could not reproduce this issue following the steps from the description. I > also used the nightly from 2016-12-18 and Fx51.0b1 - Fx 51.0b4 on Windows 10 > x32 and Windows 10 x64. Is there a possibility that the issue is from the > site or am I missing something? I do not know. But I can reproduce on the Nightly53.0a1(2016-12-18).
I'm hearing a gap 1 second after changing the resolution, 53.0a1 (2016-12-16) Win 7. No longer reproduce it on 51b11, 52.0a2 (2017-01-05), 53.0a1 (2017-01-04).
Status: RESOLVED → VERIFIED
status-firefox51: fixed → verified
status-firefox52: fixed → verified
status-firefox53: fixed → verified
You need to log in before you can comment on or make changes to this bug.