1877617 - Twitter/X video fails to play in Firefox

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load https://twitter.com/i/status/1489727779411214339
   (No need to sign in. Dismiss any popups about notifications/etc. that get in the way.)

2. Click the play button in the center of the video (or the video might just attempt to start playing on its own)

ACTUAL RESULTS:
The video never loads/plays. There's just a spinning throbber overlay that spins forever.

EXPECTED RESULTS:
Video should load/play.

Chrome gives EXPECTED RESULTS.
Firefox 124.0a1 (2024-01-30) (64-bit) gives ACTUAL RESULTS.
So does Nightly 111.0a1 2023-02-01 and a few other nightlies in between that I tested -- so, this seems to not be a regression or a recent one.
(I also tried spoofing a Chrome UA string, but that didn't make a difference.)

Note, this is similar to old/fixed bug 1764293, but the embedded video from that bug does play correctly in Firefox for me. So there's something special about the video that I've linked here that makes it specially-broken.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Firefox Nightly vs. Chrome (alt-tabbing back and forth)

Comment 2

[Daniel Holbert [:dholbert]]

I'm on Ubuntu 22.04 Linux, FWIW, but I don't think this is platform-specific; it also repro's for me on Firefox 123beta on macOS Sonoma (tested via BrowserStack).

I haven't tested other platforms/versions beyond the brief mozregression investigation (confirming that old nightlies are affected) noted in comment 0.

Comment 3

[Daniel Holbert [:dholbert]]

:az or :padenot, maybe you'd be interested to take a look since you were involved on similar bug 1764293? (Not sure if this is a flavor of that same bug vs. something completely different under the hood.)

Comment 4

[Paul Adenot (:padenot)]

Good candidate for a pernosco recording, it's not hard to repro (at least it was immediate for me).

A suspicious thing I see in the log is https://searchfox.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp#5902-5908

Comment 5

[az [:az]]

This looks like a case of a video with an 1.0s offset presentation start time causing playback issues.

Before bug 1764293, we permitted a presentation start time "fuzz factor" of up to 0.25 seconds. The bugfix increased this value to 0.55 seconds, which isn't enough for the video in this bug report:

ffprobe -show_streams twitter.mp4 2>&1 | grep start_
start_pts=1000000
start_time=1.000000

According to the spec, further increasing this "fuzz factor" to a full second would be reasonable:

For the purposes of determining if HTMLMediaElement's buffered contains a TimeRanges that includes the current playback position, implementations MAY choose to allow a current playback position at or after presentation start time and before the first TimeRanges to play the first TimeRanges if that TimeRanges starts within a reasonably short time, like 1 second, after presentation start time.

The smaller value of 0.55 seconds was chosen previously to err on the conservative side, but being that we've gone this long without breakage I'm open to increasing this to 1.0 seconds.

Comment 6

[az [:az]]

Attachment: Bug 1877617 - Further increase fuzzing value used for stream start/seek to better support muxed streams with mismatched start times as seen on Twitter/DokiDoki/etc

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0fcb866e90f2
Further increase fuzzing value used for stream start/seek to better support muxed streams with mismatched start times as seen on Twitter/DokiDoki/etc r=padenot

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/0fcb866e90f2

Comment 9

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2024-01-30 Nightly build on macOS 12.
Verified as fixed on Firefox 124.0b2 and Firefox Nightly 125.0a1 on macOS 12, Windows 10, Ubuntu 22.