Skip to content

fix(engine): treat 0-1 detected keyframes as maximally problematic - #3881

Open
miga-heygen wants to merge 1 commit into
mainfrom
fix/sparse-keyframe-blindspot
Open

fix(engine): treat 0-1 detected keyframes as maximally problematic#3881
miga-heygen wants to merge 1 commit into
mainfrom
fix/sparse-keyframe-blindspot

Conversation

@miga-heygen

Copy link
Copy Markdown
Contributor

Summary

PRINFRA-307: analyzeKeyframeIntervals (root-caused by cli-repro via direct instrumentation) short-circuited any video with fewer than 2 detected keyframes to isProblematic: false, maxIntervalSeconds: 0 — but 0 or 1 keyframes is the sparsest possible GOP (a single I-frame, or none, covering the entire video), strictly worse than any finite gap. This meant the compiler's sparse-keyframe warning ([Compiler] WARNING: ... has sparse keyframes ... causes seek failures and frame freezing, which already correctly fires for the >2s finite-gap case) silently never fired for the worst-case input it exists to catch — common with yt-dlp --download-sections output and screen recordings.

  • 0 or 1 detected keyframes now returns isProblematic: true with avgIntervalSeconds/maxIntervalSeconds set to +Infinity (no keyframe to seek back to at all — strictly worse than any finite interval, so reporting it as "no interval data" would read as healthier than it is).
  • 2+ keyframes are unaffected — same max-gap-based evaluation as before.

Test plan

  • Three new tests in ffprobe.test.ts (analyzeKeyframeIntervals sparse-keyframe blind spot): 0 keyframes → problematic, 1 keyframe → problematic, 3 keyframes with a 1s gap → still correctly not problematic (unaffected by the fix). Confirmed RED on the two new blind-spot cases without the fix (isolated via tagged git stash) / GREEN with it.
  • bunx vitest run packages/engine/src/utils/ffprobe.test.ts — 114/118 passed, 3/3 new tests pass. The 4 failing tests are pre-existing and unrelated: they depend on a git-lfs-tracked PNG fixture (hdr-photo-pq.png) that resolves to an LFS pointer file (no git-lfs in this sandbox) — confirmed failing identically on a clean origin/main checkout before any of my changes.
  • bunx tsc --noEmit -p packages/engine and -p packages/producer (the one consumer of maxIntervalSeconds) — both clean.
  • bunx oxlint / bunx oxfmt --write — clean, no unwanted reformatting.
  • bunx fallow audit --base origin/main --fail-on-issues — clean (0 issues in 2 changed files).
  • Pre-commit hooks (lefthook: lint/format/fallow/typecheck/commitlint) all passed.

🤖 Generated with Claude Code

analyzeKeyframeIntervals short-circuited any video with fewer than 2
detected keyframes to isProblematic:false, maxIntervalSeconds:0 -- the
sparsest possible GOP (a single I-frame, or none, covering the entire
video) read as healthier than a video with a merely-long-but-finite gap,
so the compiler's sparse-keyframe warning silently never fired for the
worst case it exists to catch (yt-dlp --download-sections output and
screen recordings are common sources of exactly this).

0 or 1 keyframes now reports isProblematic:true with avg/max interval set
to +Infinity, consistent with "no keyframe to seek back to at all" being
strictly worse than any finite gap. 2+ keyframes are unaffected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant