mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-11 19:09:20 +00:00
miga-heygenandMiguel Ángel
29378b6c7f
* fix(engine): classify a single-keyframe video as problematic, not healthy analyzeKeyframeIntervals short-circuited to isProblematic:false whenever it found fewer than 2 keyframes, but exactly one keyframe is the worst case for seek performance, not a healthy result: every seek past frame 0 must decode the entire file. The single-keyframe branch treats the rest of the video stream's own duration (not a container duration, which a longer audio track can inflate) as one uninterrupted GOP. ffprobe's frame timestamps are absolute presentation timestamps rather than relative to stream start, so a re-muxed or trimmed clip with a nonzero start time is normalized the same way extractFinalVideoFrameTimestamp already does for the same quirk. The cache key now includes both values, matching that sibling function's convention, since a stale cache entry from a different duration/start pair would otherwise win silently. Co-Authored-By: Miguel Ángel <miguel.sierra@heygen.com> * refactor(engine): share stream-window normalization between keyframe check and final-frame lookup extractFinalVideoFrameTimestamp and analyzeKeyframeIntervals each independently computed the same stream-start fallback, finite guard, and cache-key format from the same metadata shape. Extracted resolveStreamWindow so the two can't drift out of sync with each other. Also: match ffprobe's real trailing-comma csv output in one keyframe mock, add a test at the exact 2s threshold boundary, and comment the noUncheckedIndexedAccess-only fallback at the single-keyframe branch. Co-Authored-By: Miguel Ángel <miguel.sierra@heygen.com> * style(engine): trim long comments to one-to-three lines --------- Co-authored-by: Miguel Ángel <miguel.sierra@heygen.com>