this post was submitted on 20 Jun 2024
13 points (100.0% liked)

Firefox

33 readers
75 users here now

The latest news and developments on Firefox and Mozilla, a global non-profit that strives to promote openness, innovation and opportunity on the web.

You can subscribe to this community from any Kbin or Lemmy instance:

Related

Rules

While we are not an official Mozilla community, we have adopted the Mozilla Community Participation Guidelines as far as it can be applied to a bin.

Rules

  1. Always be civil and respectful
    Don't be toxic, hostile, or a troll, especially towards Mozilla employees. This includes gratuitous use of profanity.

  2. Don't be a bigot
    No form of bigotry will be tolerated.

  3. Don't post security compromising suggestions
    If you do, include an obvious and clear warning.

  4. Don't post conspiracy theories
    Especially ones about nefarious intentions or funding. If you're concerned: Ask. Please don’t fuel conspiracy thinking here. Don’t try to spread FUD, especially against reliable privacy-enhancing software. Extraordinary claims require extraordinary evidence. Show credible sources.

  5. Don't accuse others of shilling
    Send honest concerns to the moderators and/or admins, and we will investigate.

  6. Do not remove your help posts after they receive replies
    Half the point of asking questions in a public sub is so that everyone can benefit from the answers—which is impossible if you go deleting everything behind yourself once you've gotten yours.

founded 1 year ago
MODERATORS
 

cross-posted from: https://lemdro.id/post/9940873

And this is 100% Youtube's fault, not Firefox's fault, they created this issue:

This problem is triggered by bad muxed VP9 bytestream served by Youtube, so it's not a regression on our side, this issue can also be reproduced on old versions Firefox. Usually when muxing a video bytestream, the video samples' timestamp should be monotonizally increasing and no overlap between samples. But there are some bad video samples in YT's bytesteam, they overlapped with the previous sample. Eg. [124416000, 125126000] and [125125000, 131382000]. The next one should start from 12516000 instead of starting from 125125000 causing an overlapping.

That overlapped sample triggers this and our WebM demuxer fails to calculate the next timestamp in that situation. The end time of video sample was set to the same as the sample's start time, and that causes a gap being detected for the next sample, resulting in resetting append state. When doing so, mNeedRandomAccessPoint would be set to true and that triggers the sample skipping mechanism per the spec.

Therefore, there would be many sample being incorrectly skipped and won't be added into the buffered range. When entering the buffering state, Firefox would be waiting those sample which has been skipped but Youtube thought that those samples were already appended. That makes the endless buffering happened.

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c113 (Alastor Wu [:alwu])

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here