LTX Chunk Assembler (TJ 2.5)

You rendered your long video as chunks because a 20-second 1080p LTX clip doesn't fit in anyone's VRAM in one pass. Now you have four folders of frames and a seam problem. LTX Chunk Assembler (TJ 2.5) is the node that turns those folders into one file - and its defaults are set up around a specific insight about where two chunks can be joined cleanly.

The mechanism, which explains the defaults

Each chunk was started from a handoff guide: the previous chunk's last N frames dropped in as the guide for the new one. That means the next chunk's first frame is a reproduction of a frame the previous chunk already contains. The two chunks agree perfectly at that moment and then drift apart; by the end of the overlap they've usually diverged.

Old-school cross-dissolving averaged the whole overlap, which blended across frames that no longer match and produced the soft doubling everyone calls ghosting. The seam_mode default, early_cut, cuts exactly at the frame the two chunks share. Identical content, nothing mixed. If the camera is moving and you can see a velocity step more than a content jump, early_scurve ramps across a few frames with an S-curve - soft at both ends, quick through the middle, which is where a velocity change reads as a jerk. early_blend is the same length with a straight fade. dissolve and hard_cut are the old behaviour and you probably don't want them.

Audio gets the same treatment via audio_crossfade, defaulting to auto: it measures each seam and picks between passing identical material through with a linear fade, equal-power for independent generated sound, or a short 15 ms splice for music the model rendered slightly differently in each chunk - a long blend of near-but-not-identical audio flanges, which is a real and ugly sound. Every option consumes the same overlap, so audio never drifts out of sync with picture.

What you actually set

• run_name / runs_folder - must match what the Chunk Writer used. Default folder is ltx25_one_runs under ComfyUI's output/.
• overlap_frames - must equal the handoff_frames you rendered with, and you must have started each window that many frames before the previous chunk ended. This is the number people get wrong.
• seam_mode / seam_blend_frames - as above. Keep blends short.
• match_levels - off by default, and deliberately so: it only shifts each chunk's average brightness to match the one before, never contrast. Turn it on if one chunk came back noticeably darker; leave it off and grade in your editor if the seams look fine.
• write_video / video_fps / video_crf - produces <run>_final.mp4 next to the stills. CRF 18 is visually near-lossless.

Outputs are final_folder and info, both strings - the folder it wrote and a summary of what it did.

Why it doesn't hand you an IMAGE batch

Because a 16-second 1920×1088 sequence is roughly 10 GB as float32. Handing that to a video encoder through a wire would chew your RAM for no reason, so this node writes to <run>/final/ and tells you where. If what you need is frames on a wire, wire the last chunk's images into Video Combine instead - the writer passes them through.

Install

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

restart, then run install_requirements.sh (install_requirements.bat on Windows) once, since the pack's other node packs don't come with a Manager install. The mp4 encode goes through PyAV, which ComfyUI already ships; if av is genuinely missing the node degrades to writing stills only rather than failing outright.

Where this bites

If overlap_frames doesn't match the render, you get a visible hiccup at every join and there's no error to tell you why. If you assemble before the last chunk is on disk, the run assembles short. And the writer can call this whole thing for you: with auto_assemble on and total_chunks set, the final chunk triggers assembly automatically, which is the sane path unless you're queueing chunks by hand.