feat(videogen): LastImage — pin the trailing keyframe (first-last-frame-to-video) #26

Merged

steve merged 4 commits from feat/videogen-last-frame into main 2026-08-08 07:10:27 +00:00

Conversation 4 Commits 4 Files Changed 6

+216 -22

4 Commits

Author	SHA1	Message	Date
steveandClaude Opus 5	5994d96921	refactor(llamaswap): drop initImageFilename — one caller left, and it was a rename of imageFilename ... The 2/4 finding is right: after writeImagePart started passing an explicit filename stem, initImageFilename had no caller in video.go, and its "conditioning frame" doc no longer described its one remaining user (lipsync.go's avatar image). A one-line wrapper that survives only to be misdescribed is not indirection worth keeping. lipsync now calls imageFilename(mime, "frame") directly, and imageFilename's doc lists the real bases — including WHY the video keyframes need distinct ones: a backend that stages uploads by filename would otherwise have the second overwrite the first. Not taken: consolidating the first/last-frame rationale to a single canonical site. The copies address different readers — the wire encoding (provider), the contract's undetectable-support caveat (videogen), and the mode table (README) — and last round's finding was a doc pointing at a note that did not exist. Trading duplication for cross-references is what produced that. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01PLjgrxvHjm1sJgUu9zBPH9	2026-08-08 03:06:21 -04:00
steveandClaude Opus 5	588e092465	docs(videogen): gadfly — README FL2V section, and stop pointing at a note that does not exist ... - README documented only t2v/i2v. Now a table of the four keyframe combinations, plus the undetectable-support caveat, which is the one thing a caller cannot work out for itself. - The LastImage doc comment said "see the note on LastImage support in provider/llamaswap" — there was no such note. A pointer to something that does not exist is worse than no pointer; the comment is now self-contained. - Generate's doc described only input_reference; it now names input_reference_last and explains why an unsupporting backend returns a clip rather than an error. The 2/4 finding (writeImagePart reusing the "frame" base for both parts) was already fixed in dbc9689 — from the receiving end, where the consequence is concrete rather than stylistic: ComfyUI stages uploads by FILENAME with overwrite=true, so a shared name means the second clobbers the first and both keyframes resolve to one image. Not taken: initImageFilename's name is no longer misleading (writeImagePart stopped calling it), and it is still used by lipsync.go so it is not dead. The empty-LastImage test stays standalone — it mirrors the existing standalone empty-InitImage coverage rather than a table this file does not have. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01PLjgrxvHjm1sJgUu9zBPH9	2026-08-08 02:59:12 -04:00
steveandClaude Opus 5	dbc96898ab	fix(videogen): distinct FILENAMES for the two keyframes, not just distinct field names ... Caught while writing the receiving end. Distinct multipart field names are not sufficient: backends stage an uploaded frame under a name derived from the FILENAME, and our own ComfyUI shim posts to /upload/image with overwrite=true. Both parts were sending initImageFilename(mime) — literally "frame.png" for each — so the second upload would have clobbered the first and BOTH keyframe inputs would have resolved to the same stored image. The failure mode is the worst kind: a clip pinned at both ends to the same frame renders cleanly, returns 200, and looks like the feature not working rather than like a bug. Nothing upstream or downstream would report a fault. writeImagePart now takes the filename stem (frame / frame_last), and the test asserts the two arrive under different filenames. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01PLjgrxvHjm1sJgUu9zBPH9	2026-08-08 02:50:43 -04:00
steveandClaude Opus 5	44fcfbb273	feat(videogen): LastImage — pin the trailing keyframe (first-last-frame-to-video) ... videogen.Request gains LastImage alongside InitImage, so one Request covers t2v, i2v and FL2V without a mode flag. With InitImage it pins both ends of the clip; alone it pins the destination and lets the backend invent the approach. The llamaswap provider sends it as a SEPARATE `input_reference_last` part rather than a second `input_reference`. Multipart permits repeated names, but then which frame is first and which is last depends on part ORDER — an ordering contract invisible in the payload, that nothing notices breaking. A backend that does not know the new name ignores the part, the same degradation as any other unknown field. Both parts go through one writeImagePart helper so their encoding cannot drift, and an empty LastImage is rejected up front exactly as InitImage already is. Support is per-model and deliberately NOT advertised in this contract: a backend that ignores a trailing keyframe returns an ordinary clip, which is indistinguishable from success. The doc comment says so, because a caller that needs to know whether the pin took effect has to establish that out of band — and the mort side gates on a convar for exactly this reason. Motivated by mort's #1567 (long-form video): with both ends pinned, drift becomes structurally bounded inside each shot instead of compounding across an autoregressive chain. Tests break-checked: sending the last frame under the shared name fails both the distinct-name assertion and the last-alone case. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01PLjgrxvHjm1sJgUu9zBPH9	2026-08-08 02:47:39 -04:00