User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Say I have an mp4 like this:
10 seconds of audio.
8 seconds of video, offset +2 seconds.
Both streams start at the same time.

This didn't happen before version 115 and doesn't seem to happen with other codecs like VP9 for example.

Actual results:

Video and audio both start at the same time, regardless of when they actually start in the file.

Expected results:

The video stream should be delayed until it begins.

Same demo but as a webm, no problem here.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I can reproduce the issue on Nightly 117.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9fa4a7ae19238256fcd261c727ad2b08c6f1a4fd&tochange=a708c20c4e36970e5a9bb9b244a6865ad6bdcc92

:padenot, since you are the author of the regressor, bug 1830206, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a708c20c4e36970e5a9bb9b244a6865ad6bdcc92&tochange=928afb6ad2a5dc2f68d9d0b29181162aaac56866, likely regressor is bug 1817997.

(In reply to Paul Adenot (:padenot) from comment #5)

Range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a708c20c4e36970e5a9bb9b244a6865ad6bdcc92&tochange=928afb6ad2a5dc2f68d9d0b29181162aaac56866, likely regressor is bug 1817997.

Confirmed. (Sorry, I made a copy/paste mistake.)

Fix in https://github.com/mozilla/mp4parse-rust/pull/407, thanks for reporting!

Depends on D184213

Depends on D184225

https://hg.mozilla.org/mozilla-central/rev/1a7c4231566f
https://hg.mozilla.org/mozilla-central/rev/5a58ca98f84d

The patch landed in nightly and beta is affected.
:padenot, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox116 to wontfix.

For more information, please visit BugBot documentation.

We'll let this ride the trains normally because we're releasing in 7 days, but we might want it in ESR, because it's a real regression.

Comment on attachment 9345055 [details]
Bug 1842375 - Update mp4parse-rust to 12142fda2ba0870. r?#media-playback-reviewers

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Content breakage, severe audio/video desynchronization with otherwise valid media files
• User impact if declined: Completely incorrect rendering, it's not possible to work around it, since the video files are already online.
• Fix Landed on Version: 117
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is reverting the code to its previous behavior.

This needs more work.

https://pernos.co/debug/dMCdlYgSTbxji8hRKCAQkA/index.html#f{m[AXvA,pl8_,t[5Q,OhdZ_,f{e[AXvA,pl8_,s{afzAFYAAA,bAZY,uEbRuvQ,oEc0SJQ___/ shows that we don't have a moof parser (this file isn't fragmented), so we end up using a timescale of 15360 from the mdhd box instead of picking the correct timescale of 1000 from the mvhd box.

Matthew, do you have any pointer in the spec on what scale we should use here, so I can write a proper fix? The old code seemed to have the correct behaviour, so I guess I can just look at it.