Bug 1735300 - Do not use MP4 edit-list preroll as the media start time

[dancrew32]

Summary

• Treat negative first demuxed samples on tracks with positive media time as decode pre-roll when computing MediaFormatReader metadata start time.
• Preserve the original negative sample timestamp for decode; only the metadata origin is clamped to zero.
• Add a MediaFormatReader gtest covering an MP4 edit-list style pre-roll first sample.

Why

This fixes Bug 1735300.

MP4 edit lists describe the presentation timeline. A decoder may still need samples before the presentation start in order to decode the first visible frame, but those dependency samples should not become the media element's visible currentTime == 0 frame.

That distinction matches the broader media stack's behavior:

• FFmpeg's mov/mp4/3gp demuxer documents edit lists as timeline data: by default it modifies the stream index to reflect the timeline described by the edit list, with ignore_editlist as the opt-out path. See the ignore_editlist and advanced_editlist options in the FFmpeg formats documentation.
• QuickTime has first-class edit-list semantics for presenting only selected media ranges without duplicating media data. See Apple's Playing with edit lists documentation.
• OpenCV exposes an FFmpeg video I/O backend (CAP_FFMPEG), so video-processing workflows using that backend follow FFmpeg's presentation timeline behavior rather than exposing decode pre-roll as frame zero. See OpenCV's VideoCapture API backend list.

The current Firefox behavior lets MP4 decode pre-roll pull the media timeline earlier. That makes the first visible frame differ from Chrome and from file-processing tools that honor the edit-list presentation start.

Visual evidence

These screenshots use the public sample from Bug 1735300. The file reports a 2.0s audio/video presentation, while its first video packets are negative decode pre-roll:

format start=0.000000 duration=2.000000
video  start=0.000000 duration=2.000000
audio  start=0.000000 duration=2.000000
first video packet pts=-6.375000 dts=-6.458333 duration=0.041667 flags=KD_

Current Firefox 152.0.1 at 0.000000s still shows pre-roll before the edit-list start:

Chrome 149.0.7827.156 at 0.000000s starts on the edit-list presentation frame:

Current Firefox near the presentation end still remains behind the edit-list timeline:

Chrome near the presentation end remains aligned with the presentation timeline:

Test plan

• git diff --check
• Added TestMediaFormatReader.PositiveMediaTimeIgnoresNegativePreroll
• Not run locally: ./mach gtest TestMediaFormatReader.PositiveMediaTimeIgnoresNegativePreroll

This local checkout is sparse because the full Firefox checkout exceeded available disk on this machine. A full checkout/build or try run is still needed before this is ready for non-draft review.

Notes

• GitHub draft only. Mozilla review/landing should still go through the normal Bugzilla/Phabricator path if that is preferred for this component.
• Patched-Firefox visual screenshots are still pending a full local build or try artifact.

[firefoxci-taskcluster]

No Taskcluster jobs started for this pull request

The allowPullRequests configuration for this repository (in .taskcluster.yml on the default branch) does not allow starting tasks for this pull request.

[github-actions]

(Automated Close) Please do not file pull requests here, see https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html