Repository navigation
fix(runtime): prepare trimmed video frames before preview cuts - #5633
Merged
Merged
Conversation
miguel-heygen
enabled auto-merge
October 15, 2026 03:13
jrusso1020
reviewed
Oct 15, 2026
jrusso1020
left a comment
jrusso1020
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed at 6a054640. I found no blocker in the code. This is a COMMENT and not an approval for two reasons: the approval needs a go from a maintainer, and CI is still running on this head.
Checked
- Target matches activation.
prepareUpcomingVideocomputesmediaStart + sourceTimeAt(rate, start - origin). That is the samerelTimethe active branch ofsyncRuntimeMediacomputes att = start. The loop wrap and the non-loopsourceDurationclamp mirror the active path's loop wrap and held-tail clamp. At the cut, drift is about one tick, well underMEDIA_HARD_SYNC_SECONDS, andevictMediaSyncStatemakes it a first tick. So the activation takes the play path, not a second seek. The PR's claim holds. - Units.
dueInis in timeline seconds, andVIDEO_PRESEEK_SECONDS * playbackRateconverts the 1.5 s wall-clock lead into timeline seconds. The index lookahead ininit.tsuses the same bound, so the two cannot disagree about which clips are in range. - Index. The extra pass runs only while playing and not during export, and it only adds
VIDEOelements. Audio and paused seeks visit exactly what they did before. Visiting an upcoming clip early runs only the inactive branch (evict, pause, prepare), which is a no-op for an already-paused hidden element. - Export and render. The pass is skipped under
__HF_EXPORT_RENDER_SEEK_CONFIG(in both places) and when an injected render frame exists.playingis false during capture anyway.holdSeekBarrierUntilVideoLandsis not called, so a hidden seek cannot hold up a visible frame.
Non-blocking
- The activation path clamps with
Math.max(0, min(t, end) - origin); the pre-seek path usesstart - originwithout the clamp. The two differ only iforigin > start. In that case thetarget < 0guard or the existing hard sync at activation covers it, so this falls back to today's behavior rather than regressing it. - The
<= 0.001"already prepared" check assumes the engine reads backcurrentTimeas written. If an engine snaps it to a frame boundary, the clip would be seeked again on every tick inside the lead window, once the previous seek settles. Chrome is measured; Safari and Firefox are not, as the PR says.
I read the source and the two new test files. I did not run the suite locally or do a live player run.
— Rames
Contributor
Edit accuracy: accurate 271 (base branch 271), smooth 190 of thoseThe gate passes. Quarantined, measured but not gated (0) |
jrusso1020
approved these changes
Oct 15, 2026
jrusso1020
left a comment
jrusso1020
left a comment
Collaborator
There was a problem hiding this comment.
Approving at 6a054640, on Miguel's explicit go. CI on this head is fully green: 69 pass, 8 skipped, and all required checks pass. My earlier review found no blocker. Its two non-blocking edges still stand (the pre-seek is not clamped when origin > start, and the <= 0.001 re-seek check can loop if an engine quantizes currentTime).
— Rames
5 tasks done
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
Prepare incoming trimmed video frames while they are still hidden, so continuous preview playback can show the in-point immediately at a cut.
Why
An incoming clip currently becomes visible before its activation seek has decoded a frame. This causes the cut flash reported in #5631. Preloading bytes alone does not put the video at its trimmed in-point.
Related work
Fixes #5631. No overlapping open PR found when starting this fix.
How
Test plan
The monorepo pre-commit typecheck proceeds past core but cannot complete Studio with the borrowed dependency environment (missing dockview-react/html2canvas/@mcp-b/global and older Tailwind). That local hook alone was excluded after recording the failures; hosted clean-environment Typecheck remains a mandatory merge gate. No dependency manifests or lockfiles changed.
No real-user footage, native Desktop launch, Safari/mobile run, or production release is claimed. Hosted required checks and exact-head approval must pass before normal queue merge.