Nodes/ComfyUI_VideoChunkTools/Concat Video Chunks
ComfyUI Node

Concat Video Chunks

Concat Video Chunks — the simplest seam you'll ever fix

By gregtee2·Created 6 months ago·Updated 6 months ago· 4
Concat Video Chunks
  • chunk_a
  • chunk_b
  • video
  • total_frames
trim_b_start1

Here's the thing about rolling-reference video generation: when it works, chunk B's first frame is nearly identical to chunk A's last frame, because B was generated from that frame. Which means you don't need a crossfade, a slerp, or any fancy dissolve. You need to drop the duplicated frame and glue the two clips together. That's exactly what this node does.

It's the most boring node in the VideoChunkTools pack, and that's the compliment. ConcatVideoChunks takes two decoded video chunks, trims the start of the second one, and concatenates. No blending, no overlap math, no curve choices. If your chunks already agree at the boundary - and with proper rolling reference they should - this is the right tool, and BlendVideoChunks is overkill.

Inputs and the one knob that matters

  • chunk_a - first chunk (decoded pixels).
  • chunk_b - second chunk. Its first frame should match chunk_a's last frame if you did the rolling-reference dance correctly.
  • trim_b_start - the whole node in a single parameter. Default 1: drop B's first frame, which is the frame duplicating A's last. Set it to 0 if you generated B independently and want every frame, or higher if B starts with a few redundant frames.

Outputs are video (the concatenated batch) and total_frames (INT). Nothing else to configure. If you trim too much and B is empty, it safely returns just A, which is a nice touch for edge cases where B fails to produce frames.

Why this works with Wan

Wan's native context is 81 frames, and everything longer is chunking. The community's standard approach - long before this pack existed - was last-frame-to-first-frame chaining: generate clip 1, take its last frame as clip 2's start image, repeat. Because I2V conditions so hard on the reference image, the first generated frame snaps to it almost exactly. So chunk B opens with a frame that is effectively chunk A's last frame. Drop it, concatenate, and the boundary is basically invisible without any blending at all.

That's why the all-in-one WanChunkedI2VSampler in this pack uses the same "concat approach" internally: it trims the overlapping first frame of each subsequent chunk and concatenates, trusting the reference conditioning to make the join seamless. This node is that logic exposed for hand-rolled pipelines with any I2V model - FantasyPortrait, Wan, whatever - where you're doing the chain manually.

When to use it vs. BlendVideoChunks

If your chunks match at the boundary, concat. If there's any drift - say the model wandered off between chunks - you want the 16-frame crossfade from BlendVideoChunks to paper over it. A reasonable workflow is: try ConcatVideoChunks first, eyeball the result, and only reach for blending when you see a seam. Saves you a node and a decision for the common case.

Installing

Same as the rest of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/gregtee2/ComfyUI_VideoChunkTools.git

Or search "VideoChunkTools" in ComfyUI Manager, install, restart. No pip dependencies - it's pure PyTorch tensor slicing, no model files, no wrapper needed. It'll work in a graph that has never touched Wan.

The whole pack exists because the 81-frame ceiling is real and isn't going away. This node is the least glamorous answer to it, and honestly the one you'll use most.

CategoryVideoChunkTools

Inputs (3)

NameTypeDefaultDescription
chunk_aIMAGEFirst video chunk (decoded pixels)
chunk_bIMAGESecond video chunk (decoded pixels). Its first frame should match chunk_a's last frame if using rolling reference.
trim_b_startINT10–100Number of frames to trim from the START of chunk_b before concatenating. Default 1 = drop B's first frame (which duplicates A's last frame in rolling-reference workflows).

Outputs (2)

NameTypeDescription
videoIMAGE
total_framesINT