Repository navigation
fix(core): a clip that has fully downloaded stays loaded and plays on time - #6787
Closed
miguel-heygen wants to merge 2 commits into
Closed
miguel-heygen wants to merge 2 commits into
miguel-heygen wants to merge 2 commits into
Conversation
Contributor
Edit accuracy: accurate 271 (base branch 271), smooth 137 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (2)
|
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head 93d52593
Scope
releaseMediahas one caller (init.tslook-ahead). A kept clip that comes near again goes throughstartPrefetch.preloadMediaskipsload()at readyState ≥ 3, and the slot isn't taken, so the buffered data is reused. A clip at readyState < 3 still gets the old reload.- The edge test needs one range covering [≤0.1 s, ≥duration−0.1 s]. A partly buffered long file, or one with a gap, is still released, so the connection-freeing path is unchanged.
- fails without the fix: confirmed locally. Restoring main's
preloadMedia.tsfails onlykeeps a clip whose whole file is buffered. 93d52593vs2f3e7fbfonly removes a comment. CI, Windows, regression, Comments and edit accuracy are green.
5 of 6 tasks
Collaborator
Author
|
Folded into #6785 with its tests and numbers, so the three preview fixes for long cut-list edits review and land as one. |
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
A short clip that has already downloaded in full stays loaded when the playhead moves away from it, so it plays on time when its turn comes. Before, a b-roll clip in a long edit could show its first frame over a second late.
Why
Studio's preview releases a clip that leaves the look-ahead window (drops its
srcand reloads it) so it stops holding one of the browser's six connections to the server. A clip armed by the clip before it on its track loads early. When that earlier clip ends, the arm lapses and the clip is released, even when its whole file had already arrived and it held no connection. It then had to fetch again just before its start, queued behind long video downloads on the same host. On a long edit with b-roll over two camera files, that request waited 1.2-3.2 s, and one b-roll per run showed its first frame about 1.2 s late.Related work
#6033 bounds open-ended media ranges in the file servers, which shortens how long the camera downloads hold connections. This PR is independent: a clip that is already in memory should not be fetched again at all.
How
releaseMediareturns early when the element's buffered range covers the whole file. Its only caller is the look-ahead window ininit.ts.Test plan
preloadMedia.test.ts: a clip with its whole file buffered is not reloaded; a clip with only part of a long file buffered still is.keeps a clip whose whole file is buffered; treating any range that reaches the end as whole failsreleases a clip with only 430-2642 s of a long file buffered; treating any range from the start as whole failsreleases a clip with only 0-15 s of a long file buffered. Each mutation fails only that test.vitest run src/runtimeinpackages/core: 108 files, 2647 tests passed. oxfmt, oxlint, coretscand the comment ratchet clean.main→ this branchSome b-roll requests still wait 1.2-1.9 s for a connection, but none of them now delays a clip's first frame.