Pinning both keyframes aborts the render on every recipe whose frame-0 item APPENDS, which is keyframe_interpolation — the one pipeline that exists to interpolate between two pinned ends. docs/USAGE.md's worked example for that kind passes --first-frame open.ppm --last-frame close.ppm, and ltx2-gen --help says to use the two together, so the documented headline command is the one that fails. Reachable from the shipped CLI and from vllm_video_engine_load / Generate.
The failure is a derived index that was correct only by APPEND ORDER.
src/vllm/multimodal/ltx2_video.cpp's last-frame arm locates its own appended tokens at video.positions[target_tokens * 2] and asserts their temporal position is (frames - 1) / fps. target_tokens is Ltx2VideoTokenCount(vshape, 1), fixed for the phase and never moved by an append, so that index names the first token PAST THE TARGET GRID — the first appended token in the sequence, whichever item appended it. That was the last-frame arm's own token only while the last-frame item owned the first append.
Row LTX25-KEYFRAME-INTERP (#1096) put a second appending item in front of it: on image_conditionings_by_adding_guiding_latent recipes the frame-0 image takes VideoConditionByKeyframeIndex and APPENDS (keyframe_cond.py:79-82) rather than replacing (latent_cond.py:40-41), and conditioning items are applied in list order. With both ends pinned the index then named the FIRST frame's keyframe at temporal 0 and the assertion threw:
ltx2 video: the last-frame keyframe's appended tokens must carry the temporal position of
pixel frame `frames - 1` (0.333333), but the first appended token starts at 0.000000
... ltx2_video.cpp:3397
The ti2vid_two_stage control — replace at frame 0, one append — is unaffected and stayed green throughout, which is what says "ordering" rather than "keyframes".
The generated-keyframe-slot arm carries the same shape: its growth check reads video.tokens == target_tokens + slots * tokens_per_keyframe, which is equally false once anything appended in front of it.
The assertions are right and neither is weakened. Fixed in flow by capturing the sequence length at the moment of each append and locating each item's tokens from that, so no arm depends on being first. The slot arm additionally asserts that the recorded generated_keyframe_layout.first_token equals that pre-append count, so a layout that named some other token is refused rather than counted. Gated by a permanent case in test_ltx2_video that pins both ends on both builders, with the bare grid and each single end as controls, captured RED at the pre-fix source with this exact message.
Found by the fresh review of #1096.
Pinning both keyframes aborts the render on every recipe whose frame-0 item APPENDS, which is
keyframe_interpolation— the one pipeline that exists to interpolate between two pinned ends.docs/USAGE.md's worked example for that kind passes--first-frame open.ppm --last-frame close.ppm, andltx2-gen --helpsays to use the two together, so the documented headline command is the one that fails. Reachable from the shipped CLI and fromvllm_video_engine_load/Generate.The failure is a derived index that was correct only by APPEND ORDER.
src/vllm/multimodal/ltx2_video.cpp's last-frame arm locates its own appended tokens atvideo.positions[target_tokens * 2]and asserts their temporal position is(frames - 1) / fps.target_tokensisLtx2VideoTokenCount(vshape, 1), fixed for the phase and never moved by an append, so that index names the first token PAST THE TARGET GRID — the first appended token in the sequence, whichever item appended it. That was the last-frame arm's own token only while the last-frame item owned the first append.Row
LTX25-KEYFRAME-INTERP(#1096) put a second appending item in front of it: onimage_conditionings_by_adding_guiding_latentrecipes the frame-0 image takesVideoConditionByKeyframeIndexand APPENDS (keyframe_cond.py:79-82) rather than replacing (latent_cond.py:40-41), and conditioning items are applied in list order. With both ends pinned the index then named the FIRST frame's keyframe at temporal 0 and the assertion threw:The
ti2vid_two_stagecontrol — replace at frame 0, one append — is unaffected and stayed green throughout, which is what says "ordering" rather than "keyframes".The generated-keyframe-slot arm carries the same shape: its growth check reads
video.tokens == target_tokens + slots * tokens_per_keyframe, which is equally false once anything appended in front of it.The assertions are right and neither is weakened. Fixed in flow by capturing the sequence length at the moment of each append and locating each item's tokens from that, so no arm depends on being first. The slot arm additionally asserts that the recorded
generated_keyframe_layout.first_tokenequals that pre-append count, so a layout that named some other token is refused rather than counted. Gated by a permanent case intest_ltx2_videothat pins both ends on both builders, with the bare grid and each single end as controls, captured RED at the pre-fix source with this exact message.Found by the fresh review of #1096.