Repository navigation
fix(core): Safari audio is ready at the cut, and a stuck one resyncs in 1 s - #7024
Merged
Merged
Conversation
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Approve at a3a403d0 (re-pinned from b7f34910; that commit only drops the comment above WEBKIT_STUCK_AUDIO_SECONDS).
- Fails without the fix: confirmed. With
media.tsandpreloadMedia.tsfrommain, the two new tests fail (2 failed, 204 passed). At head: 206 passed. - Both changes check
isWebKit(). The preload path now pre-seeks WebKit audio onloadedmetadata, the same way upcoming video already gets pre-seeked, and theisUpcoming/paused/seekingguards still apply. - Non-blocking: the tier-1 comment in
syncRuntimeMediastill says "catastrophic drift (>3s)". It's 1 s for WebKit audio now. Also, on a slow link, cold WebKit audio may now get re-seeked about every 1 s while it buffers instead of every 3 s. That's acceptable since Remotion re-seeks at 0.65 s, but it's worth watching in the device run that hasn't been done yet.
miguel-heygen
enabled auto-merge
November 2, 2026 16:14
Contributor
Edit accuracy: accurate 271 (base branch 271), smooth 108 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Nov 2, 2026
Merged
2 of 3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
In Safari, the sound at a clip change can start late. Two causes, both fixed in the one place media sync routes through:
Chromium and Firefox are unchanged (both changes are gated on WebKit).
Why
Late cuts of 600 ms or more happened at about 1 in 7 clip changes on an iPhone; the 3 s ones were the valve waiting on a frozen element.
Related work
Follows the iPhone connection work in #7012 (merged).
How
What goes wrong: a clip's audio element is only told to seek when the cut arrives, and WebKit takes long enough to land that seek that the sound starts late; a WebKit element stuck on its seek is then waited on for 3 s.
The runtime already pre-seeked upcoming video (
media.tsprepareUpcomingMedia); this extends that to WebKit audio (preloadMedia.ts:39) and shortens the frozen-audio valve to 1 s (media.ts:649).Test plan
Fails without the fix: with
media.tsandpreloadMedia.tsrestored to main, exactly the two new tests fail (2 failed, 204 passed); with the fix 206 passed (devbox, head b7f3491).preloadMedia.test.ts); a frozen WebKit audio element is pulled onto the playhead after 1 s, not 3 (media.test.ts)Size
A lone 46-line fix: two WebKit-gated conditions in the single media sync path plus their tests; nothing else open can carry it.