Open Bug 2056945 Opened 2 days ago Updated 1 day ago

Firefox applies a leading empty-edit (elst media_time=-1) presentation offset via MSE but not via progressive <video src> (internally inconsistent)

Categories

(Core :: Audio/Video: Playback, defect)

Firefox 152
ARM64
macOS
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mormegil, Unassigned)

References

()

Details

Attachments

(1 file)

Attached video plain.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

Tested on Firefox 152. Both pages below play the SAME bytes; only the delivery path differs. The fMP4 video track carries one leading empty edit (elst entry: media_time = -1, media_rate = 1, non-zero duration), which offsets video start.

  1. MSE path - https://mormegil6.github.io/mse-edit-list-repro/ (video fed via MSE: SourceBuffer.appendBuffer of a DASH init + media segments)
  2. Progressive path - https://mormegil6.github.io/mse-edit-list-repro/progressive.html (the identical media as a single file via <video src>)

Actual results:

Firefox handles the same edit two different ways depending on the path:

  • MSE: APPLIES the offset. SourceBuffer.buffered.start = 3.0 s, HTMLMediaElement.duration = 8.0 s; picture delayed onto the audio (in sync).
  • Progressive <video src>: DROPS it. duration = 5.0 s (media length only), first frame at ~1.0 s (undelayed).

So Firefox disagrees with itself: its MSE path applies a leading empty edit that its progressive path ignores.

Cross-engine context (identical bytes): Chromium and Safari are the reverse - their <video src> applies the offset while their MSE drops it. The Chromium case is reproduced and triaged by Google: https://issues.chromium.org/issues/537235698

Origin: ffmpeg -f dash writes this leading empty edit when the muxed tracks don't start at the same timestamp; the same media served progressively carries the equivalent edit in its moov.

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:152.0) Gecko/20100101 Firefox/152.0

Expected results:

The two Firefox paths agree on the same edit - ideally both apply the offset, as the MSE path already does (and as Chromium/Safari progressive playback do).

Has STR: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: