recut retains black startup frames that compose shows beneath its overlays

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 22d ago ·closed by John Lauer

AI Flow 0.1.15 recut leaves approximately 0.233 seconds of pure black recorder startup at the head of nonblank action cuts. Compose preserves those frames underneath its clocks and step overlay. In Astra's 116.033 s composition, the required ten-second contact sheet happened to hit them at 5 s and 45 s; closer inspection shows brief blank transitions, not long blank clips.

Reproducible source: /home/adom/aiflow-esc-astra/window-16521934-20260914-034714-action.mp4. Before the workaround, ffmpeg blackdetect reports black_start:0 black_end:0.233333 black_duration:0.233333. The nine-frame whole-clip check accepts the otherwise valid clip.

Run: https://wiki.adom.inc/adom/adom-aiflow/files/docs/runs/source-unplaced-codex-astra-20260914-0314/README.md

Workaround source attached: inspect each eligible action cut with blackdetect, preserve its original copy, remove only measured leading pure-black frames, reset PTS, then run compose again. Raw clips and 10x cuts are unchanged; no captions enter per-step clips. The full ledger records the rejection and workaround, and the original delivery clocks are unchanged. The final clip inventory reports the new action durations. Fix recut by dropping unpainted startup frames before motion selection, and consider checking the final composed canvas below its overlay. Also, take capture=ai is refused as an unknown stage although capture/compose can need an AI workaround; the capture mark records this one instead.

final-at-5

trim_action_startup.py.txt

action-black-trim.json

3 Replies

John Lauer · 22d ago

Correction after re-composition: compose reads raw recordings again rather than consuming the action copies, so trimming action copies alone is insufficient. The raw startup is one frame (for routing-4, 0.0365667 s), which motion selection stretches into about 0.23 s. The attached run-local ffmpeg adapter seeks past each measured pure-black startup only on raw input to compose; no raw file is changed. raw-startup-skip.json records the exact seek for each input, and effective command logging makes the workaround reviewable.

compose-ffmpeg-adapter.py.txt

raw-startup-skip.json

John Lauer · 22d ago

The captured ffmpeg command establishes the precise source: compose consumes each -10x.mp4, applies setpts=PTS*10 and mpdecimate, then draws clocks and repaces the retained frames. It does not consume the action file or the original raw file. The final adapter therefore applies the measured startup seek to the 10x input (typically 0.033333 s), leaving every source file unchanged. This attachment and compose-input-startup-skip.json supersede the earlier raw-input adapter. Earlier attempts are preserved in the ledger; the final video will be reviewed after this correction.

compose-ffmpeg-adapter.py.txt

compose-input-startup-skip.json

John Lauer · 21d ago

Fixed in adom-aiflow 0.1.16 (insiders): every clip stop (and recut) runs blackdetect on the head of the raw clip and cuts the recorder's black startup, up to five seconds, off the head of both the 10x cut and the action cut; a marker in the ledger says how much was cut. Longer black at the head is left in, since that is a clip problem worth seeing. Raw clips are untouched.