DEV Community

Cover image for I fixed a clip-split bug in Hyperframes with 89 lines (and it was about where time starts)
Migbolivar
Migbolivar

Posted on

I fixed a clip-split bug in Hyperframes with 89 lines (and it was about where time starts)

I fixed a clip-split bug in Hyperframes with 89 lines (and it was about where time starts)

A bug report about a two-second edit that lost its position. My fix: make the split point honest about time. Merged as heygen-com/hyperframes#3272 (+89/−2).

The bug

Hyperframes (HeyGen's open-source video rendering framework) has a browser-based Studio where you can split a clip in two. The bug: when you split an untrimmed clip, the source-media position of the right segment was wrong — the second half started playing from the wrong in-point, and audio drifted out of sync with video.

The root cause was subtle: when a clip had never been trimmed, the left segment carried no explicit in-point — and the split logic treated "no in-point" as "start at 0" for the left, but the right segment's source position was computed from a baseline that didn't include the original clip's own trim state.

The fix

Two changes, 89 additions, 2 deletions:

  1. Left segment: when the original clip was untrimmed, it now carries an explicit zero in-point — so "no in-point" can never be misinterpreted downstream.
  2. Right segment: its in-point now starts at the split-adjusted source position — the exact point in the source media where the split happened, instead of an offset from the wrong baseline.

Small principle, wide blast radius: be explicit about where time starts. A missing attribute read as zero by luck; now it's zero by contract.

Why it mattered

  • Audio/video sync: the split could desync a talking-head clip — the exact failure mode that makes rendered videos unusable.
  • Deterministic rendering: Hyperframes renders seek-by-frame, so any in-point ambiguity becomes a permanent, reproducible artifact — the worst kind.

Verification

  • Merged and green (CI + lint + format gates: oxlint/oxfmt).
  • I also rendered the fixed behavior through the pr-to-video workflow to watch the split behave correctly end-to-end.

What I learned

  1. "No value" and "zero" are different states — normalize the first into the second before any arithmetic touches it.
  2. A two-line conceptual fix can be 89 lines of test coverage — and that's the right ratio.
  3. Split logic is a time-travel machine — every segment must be able to answer "where am I in the source?" on its own, without depending on siblings.

The takeaway

The bug was invisible in preview and permanent in render — the classic "works in the editor, broken in the output" trap. Being explicit about in-points fixed both segments, the audio drift, and the class of bugs around it.

🔗 PR: https://github.com/heygen-com/hyperframes/pull/3272

bugsmash

javascript

opencode

Top comments (0)