Concat Video Chunks
Concat Video Chunks — the simplest seam you'll ever fix
- chunk_a
- chunk_b
- video
- total_frames
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. Default1: drop B's first frame, which is the frame duplicating A's last. Set it to0if 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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| chunk_a | IMAGE | First video chunk (decoded pixels) | |
| chunk_b | IMAGE | Second video chunk (decoded pixels). Its first frame should match chunk_a's last frame if using rolling reference. | |
| trim_b_start | INT | 10–100 | Number 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)
| Name | Type | Description |
|---|---|---|
| video | IMAGE | — |
| total_frames | INT | — |