VideoLaVITT2VLong
The multi-clip T2V node
- model
- IMAGE
Take everything VideoLaVITT2V does - LLM writes keyframe tokens, then motion tokens, then a diffusion detokenizer turns them into frames - and run it several times in a row, chaining the clips so the story continues. That's VideoLaVITT2VLong. It's the text-to-video answer to VideoLaVITI2VLong, and it has the same two tricks: clip_num to extend, and inverse_rate to keep the seams from being obvious.
How it works
generate_video runs a loop over clip_num clips. On the first pass it generates both keyframe tokens and motion tokens from your prompt. On later passes it re-conditions on the previous clip's final frame - re-noised to a level set by inverse_rate - and generates the next chunk. That re-noise level is where the continuity happens: noise_level = int(inverse_rate * num_inference_steps). At the default 0.9, the carried-over frame is heavily re-noised, which keeps things flexible but lets the scene drift; drop it lower and later clips stay more faithful to the last frame, at the cost of less new motion. Then the node stitches clips together the same way the I2V long node does - first 24 frames, then 23 per additional clip.
One structural quirk: this node generates a keyframe image at keyframe_width × keyframe_height (1024×576 default) and the actual video at video_width × video_height (576×320 default). You're running two generations per clip at two resolutions. It's slow. Budget for it.
The inputs that matter
clip_num(2) - number of 24-frame chunks.inverse_rate(0.9) - how much of the previous clip's last frame survives into the next. The single most interesting knob in this node, and the one beginners ignore. If your long videos look like a slideshow of unrelated scenes, that's this value being too high; if they look frozen, it's too low.prompt- same default as the short node ("FPV drone footage of an ancient city in autumn"), and same advice: motion verbs carry the video.keyframe_width/keyframe_heightandvideo_width/video_height- two resolutions, both must be multiples of 64.guidance_scale_for_llm(4),guidance_scale_for_decoder(7),num_inference_steps(50),top_k(50),seed(16) - the full sampling set from the T2V node.
Output is IMAGE, one big frame batch, meant for VHS_VideoCombine. The bundled wf_t2v_long.json wires exactly that.
Install
Same story as every node in this pack: ComfyUI Manager search "ComfyUI-LaVIT" or git clone https://github.com/chaojie/ComfyUI-LaVIT into custom_nodes; model in models/diffusers/Video-LaVIT-v1; and manually pip install -r VideoLaVIT/requirements.txt because the root requirements file is empty.
Where people get burned
Runtime. This is the most expensive node in the pack - every clip is two generation passes at different resolutions, and clip_num multiplies all of it. Set clip_num to 3 and you'll be waiting a long time on anything short of a serious GPU. Also expect the standard research-model defects to compound across clips: drift, warping, and watermarks. It's a technical demo of "long video via autoregressive token chaining," not a replacement for the modern long-video models. Treat it as a curiosity that teaches you something about how token-based video models hold together - and where they fall apart.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| model | VideoLaVIT | — | |
| prompt | STRING | FPV drone footage of an ancient city in autumn | — |
| clip_num | INT | 2 | — |
| keyframe_width | INT | 1024 | — |
| keyframe_height | INT | 576 | — |
| video_width | INT | 576 | — |
| video_height | INT | 320 | — |
| guidance_scale_for_llm | FLOAT | 4.00 | — |
| guidance_scale_for_decoder | FLOAT | 7.00 | — |
| num_inference_steps | INT | 50 | — |
| top_k | INT | 50 | — |
| inverse_rate | FLOAT | 0.90 | — |
| seed | INT | 16 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |