Some 4320p60 (8K 60fps) videos on YouTube will always fill the video SourceBuffer and cause the player to reload once.
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
People
(Reporter: Zaggy1024, Assigned: alwu)
References
(Blocks 2 open bugs, )
Details
(Keywords: webcompat:needs-diagnosis)
User Story
platform:windows,mac,linux impact:annoyance configuration:general affects:all
Attachments
(1 file)
Steps to reproduce:
- Go to https://www.youtube.com/watch?v=zCLOJ9j1k2Y (AV1 codec) or https://www.youtube.com/watch?v=DXBdraW0IT4 (VP9 codec)
- Change the quality to 8k
- Allow the video to play.
- (Optional) If the connection is slow, playback speed can be lowered to let the buffer fill.
Result: The video player will reload within the first minute or so, after which the video will play back uninterrupted.
The issue seems to be caused by the fact that Chrome's buffer size limit is 150MiB, vs Firefox's default of 100MiB. This page will test and output the effective buffer size: https://beaufortfrancois.github.io/sandbox/media/source-buffer-limit.html
Raising the quota in Firefox by setting "media.mediasource.eviction_threshold.video" to 157,286,400 bytes (150MiB) solves the issue, and 8k60 videos will play uninterrupted.
Note that some 8k60 videos on do not buffer as far ahead as others, causing the issue to only be present for certain videos where the target buffer size used by YouTube is large enough to hit the limit.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Thanks for the report! It may make sense for us to increase the threshold in our MSE code. While there's various clever options, like computationally driving eviction off things like memory pressure, a simple increase is the numbers is the most straight forward. I think it's reasonable as
- The original numbers were set ~half a decade or more ago. Since then hardware has moved on, and we've also seen significant increases in the resolutions which are being streamed.
- Having parity with Chrome. This is icky, but if Chrome is using
X
bytes, and sites like YouTube then rely (at least in part) onX
sized buffers, then this helps with compatibility.
Comment 2•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 3•1 month ago
|
||
We're going to triage this as a P2 WebCompat issue for now. It's clearly not a P1 - but it's annoying to some users and we don't know how many users. If there is something we can fix, we should fix it.
Alastor, is this related to the investigations you're doing at the moment?
Assignee | ||
Comment 4•1 month ago
|
||
I will take a look on this one, I also noticed that reloading the resource seems causing a bug in Youtube player as well.
Assignee | ||
Updated•26 days ago
|
Assignee | ||
Comment 5•26 days ago
|
||
Nowaday 100MB size is not enough for 4K or 8K video, so we would like
to extend it to 150MB, which also matches Chromium's behavior in order
to reduce the possibility of causing web compabilitiy issues.
Assignee | ||
Updated•26 days ago
|
Pushed by alwu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fb2d95a15720 extend video source buffer eviction size to 150MB. r=media-playback-reviewers,padenot
Comment 7•26 days ago
|
||
bugherder |
Updated•20 days ago
|
Updated•19 days ago
|
Comment 8•4 days ago
|
||
I didn't manage to reproduce this issue while using multiple devices. Buffering instances occur regardless of whether using an older build such as Nightly 129.0a1 or the latest ones Nightly 130.0a1 and Firefox 129.0b7. However, I haven't observed the video reloading.
@Zaggy1024, could you please test this in the latest Firefox 129.0b7 version and let me know if this is still reproducible on your end? Thank you.
I get the same result here, so it looks like YouTube must have fixed their reliance on the 150MiB buffer size at some point. I think it may have been within the last year, but since I usually have the preference set on my end, I'm not sure when exactly.
Comment 10•3 days ago
|
||
Thank you for your feedback.
Based on the latest tests, I'm marking this as VERIFIED FIXED.
Description
•