LTX Chunk Writer (TJ 2.5)

Long video in a local model is a memory problem dressed up as a creativity problem. LTX is the fast option - that's the whole reason people tolerate its weaker prompt adherence - but 1080p for thirty seconds still isn't fitting in one pass on consumer hardware. So you render it as chunks and stitch. LTX Chunk Writer (TJ 2.5) is the half that makes the seam work.

What it does besides saving frames

Saving PNGs is the boring part. The useful part is the handoff: it copies the last N frames of the chunk it just wrote into ComfyUI's input/ folder, so the next chunk can pick them up as a guide image sequence and continue from exactly where the last one stopped. That's the trick that keeps subject and camera coherent across a cut - and it's why the overlap is a real overlap rather than two shots butted together.

handoff_frames is snapped to a multiple of 8 for a reason worth internalising: the LTX VAE packs 8 pixel frames into one latent frame. Hand it 12 and the guide lands mid-latent, and you get a hitch at the seam that no amount of re-rendering fixes.

The node also passes images straight through, so it sits in front of your Video Combine rather than replacing it. You get the frames on a wire and the files on disk from one stage.

The fields that matter

• images - your decoded chunk. Everything else is bookkeeping.
• run_name - the folder for the whole video. Same string on every chunk, or you'll silently build four separate one-chunk runs.
• chunk_index - 1, 2, 3… per chunk. total_chunks plus auto_assemble means the last chunk joins everything into <run>/final/ with a seam-blend you don't have to think about.
• handoff_frames - 8 by default, 0 disables the handoff entirely (useful when you'd rather cut hard between unrelated shots).
• frame_format / jpeg_quality - JPEG q95 by default, and the reasoning is honest: the h264 encode that follows loses far more than the JPEG does, and JPEG is ~30× faster to write and several times smaller. Handoff frames are always PNG regardless, because those go back into LTX as guides and need to stay clean. Chroma isn't subsampled, so text doesn't smear.
• audio (optional) - wire the chunk's audio in, normally off the audio VAE decode of the first pass. It gets saved beside the frames and crossfaded into one continuous track at assembly.

Outputs: images (pass-through), handoff_folder (where the guide frames landed), info.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/designloves2/ComfyUI-TJ_NODE_STUDIO_ONE.git

Restart, then bash install_requirements.sh (install_requirements.bat on Windows) once - the pack depends on other node packs that Manager won't pull in. If you're driving this from the LTX 2.5 studio UI rather than hand-wiring, Render All fills chunk_index, total_chunks and video_fps for you; set them by hand only when you're queueing chunks yourself.

Traps, in order of how often they catch people

match_to_previous sounds great and the author's own tooltip calls it unreliable - it level-matches per frame, comparing this chunk's first frame against the previous chunk's last handoff. Prefer assemble_match_levels, which measures the shared frame with early_cut and carries the correction forward chunk by chunk. Leave the per-frame one off unless you're specifically fixing one bad chunk.

Re-running a chunk with clear_chunk_first on wipes that chunk's folder before writing (only that one) - good hygiene, since stale frames from a 20-frame render sitting under a 40-frame render will absolutely poison your assembly.

And the disk fills faster than you think. A 16-second 1080p sequence is around 10 GB as float32 in memory; even at JPEG q95 you're storing hundreds of stills per run. save_all_frames off writes only the handoff frames, which is the right move while you're testing whether a seam works at all.