bug(studio): hard-cut video boundaries stutter/replay ~0.xs in preview

[nanxingw]

Summary

Studio preview briefly stalls and appears to replay roughly the previous 0.x seconds at video clip boundaries. The symptom persists on a rebuilt section made only of contiguous hard-cut video clips, with no transition and no image/overlay clip in that section.

This is different from #37: playback does advance and render frames, but the clip-to-clip handoff is visibly non-monotonic/stuttery.

Environment

• AutoViral CLI: 0.1.11
• Studio UI: V4.0
• Work: w_20260715_0035_20d
• Composition: 1080×1920, 24 fps
• Video asset count: 24
• Video clip count: 22

Minimal reproducible section

The first 48 seconds were rebuilt as 12 back-to-back video clips:

• timeline offsets: 0, 4, 8, ... 44
• each timeline window: in: 0, out: 4
• no gaps or overlap
• no transition records for these boundaries
• no overlay/image clip between 0 and 48 seconds
• no video keyframes in this section

All 12 source files have the same probed media shape:

codec=h264
width=720
height=1280
r_frame_rate=24/1
avg_frame_rate=24/1
start_time=0.000000
duration=4.041667
nb_frames=97

Example clips:

- id: vc_5b4c66
  src: assets/seedance/seedance-48453a04d51e.mp4
  trackOffset: 0
  in: 0
  out: 4
- id: vc_793a83
  src: assets/seedance/seedance-9d57eec297ff.mp4
  trackOffset: 4
  in: 0
  out: 4
- id: vc_203328
  src: assets/seedance/seedance-05ccae25a76a.mp4
  trackOffset: 8
  in: 0
  out: 4

Steps to reproduce

1. Open the work in Studio.
2. Seek to about 3.2s.
3. Press Play and watch across the hard cut at 4.0s.
4. Repeat across 8.0s, 12.0s, 16.0s, etc.

Expected

The preview clock and visible frames advance monotonically across the cut. A ready next clip appears on the first frame of its timeline window without replaying earlier frames or pausing.

Actual

At clip joins, the Studio preview briefly stalls and visually appears to replay approximately the previous 0.x seconds before continuing. The reporter can observe this across clip boundaries even after transitions and still-image clips were removed from the test section.

Diagnostic narrowing

Ruled out for the first 48-second fixture:

• Transition implementation: the fixture uses hard cuts and has no transition records at those cut points.
• Image/overlay switching: every visual clip in the fixture is video.
• Variable-frame-rate or non-zero media start: every source is CFR 24 fps and starts at zero.
• Mixed source dimensions/codecs: all sources are 720×1280 H.264 with the same frame count and duration.

Previous export-side checks on the same work sampled five boundaries and found no exact repeated frame pairs in the rendered MP4. That makes a Studio-only preview handoff/buffering defect more likely than corrupted source media, though a fresh export of this exact 12-clip fixture would strengthen the differential.

Ranked root-cause hypotheses

1. Preview media handoff is not warm/monotonic. The outgoing media element is released before the incoming element is ready at its source time, causing Remotion/Player to buffer, re-seek, or briefly present stale frames.
2. Decoder/resource pressure. The work has 24 video assets and 22 video clips; timeline/library/preview video elements may compete for decode or range-request resources. This may be a lower-severity relative of bug(studio): 重资产视频 work 预览死锁 — 56 个并发 <video> 全卡 readyState 0，Play 后时间码冻结且无任何反馈 #37, which covered total preview deadlock under heavier media-element load.
3. Player frame clock and media currentTime diverge at Sequence boundaries. A remount or source-time calculation near the exact out: 4 cut may reset or quantize to an earlier decoded frame.

Suggested instrumentation

For each active/outgoing/incoming video element, record within ±500 ms of a cut:

• composition frame/time
• requested source time and actual video.currentTime
• readyState, networkState, seeking, waiting, stalled, canplay
• webkitDecodedFrameCount / webkitDroppedFrameCount where available
• media element mount/unmount and src changes

Correlate those events with the Remotion Player frame clock. This should distinguish a clock rewind from a decoder wait or stale-frame presentation.

Acceptance criteria

• The 12×4-second CFR fixture plays across 4, 8, 12, ... 44s without a visible pause or replay.
• Composition time and active media source time are monotonic through every hard cut.
• Add an automated browser regression fixture that loops the boundary at least 20 times and fails on time regression, unexpected remount/seek, or an excessive waiting gap.
• Re-test with a 20+ video-asset work to cover the possible bug(studio): 重资产视频 work 预览死锁 — 56 个并发 <video> 全卡 readyState 0，Play 后时间码冻结且无任何反馈 #37 resource-pressure relationship.