BFS Shot Join

The other half of the trick

Splitting one long video into shots is the easy part. Joining the results back into something that plays like the original is where shot-based video generation usually goes wrong: the model-valid lengths don't match the shot lengths, so every shot has extra frames hanging off the end, and a naive concatenation gives you a video that drifts a few frames later than the source with every shot.

This node knows better because the planner told it. Each generated shot gets trimmed to its true length - the shot's own frames, not the grid-valid length that was rendered - so the total timing matches the source exactly. The frames it trims off are the overlap the planner deliberately generated from the following video, and crossfade uses them: boundaries that aren't camera cuts get blended across instead of butted together. Camera cuts stay hard, which is what you want; a 4-frame dissolve on a cut looks like a mistake.

The inputs

Required: images (the decoded frames of every shot - the list that came out of VAE Decode), shots (the list straight from the planner, so the join knows the true lengths and where the cuts are), and crossfade (0–24 frames, default 4; 0 for hard joins everywhere).

Optional, and all three matter:

• audio - feed the planner's audio output and the soundtrack comes back with the video, already trimmed. Without it you get no audio output at all, not silence.
• timeline - the planner's timeline output. This is the one people forget. With it, shots that were skipped (disabled by a filter, or by you) get filled with the original video, and the audio follows the same fill-and-drop rules. Without it, your skipped shots just vanish from the output and nothing warns you.
• comparison + label + comparison_height - a side-by-side review render: original shot | references | result, with the shot's info and your label text (model, LoRA, steps, seed - whatever you write) on the top bar and the prompt underneath. This is genuinely the nicest feature in the shot loop for evaluation, and comparison_height (default 360, 0 for full size) is what keeps it from eating your VRAM on a long video.

Outputs: images (the joined video), audio, fps (so you can hand it straight to Create Video), and comparison.

How it behaves in queue loop

It's an INPUT_IS_LIST node that blocks every node after it until the last shot is done. That's why queue loop can run one shot per queue run, store each on disk, and still have a single Save Video at the end fire exactly once. It also means a long join feels like nothing is happening for a while, then everything happens - don't kill the run.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/alisson-anjos/ComfyUI-BFSNodes
cd ComfyUI-BFSNodes && pip install -r requirements.txt

Restart. Reading audio from the source video uses ffmpeg, falling back to PyAV when the ffmpeg binary is missing - the pack's own docs are upfront about that, and it's the first thing to check if the planner reports no usable audio track.

Where it goes wrong

crossfade on a cameraman's hard cut reads as a smear; leave the blend for the soft joins and set 0 if your material is full of fast cuts. Feeding images from a sampler instead of the decode means the shot count won't line up with shots and the trim lengths will be applied to the wrong thing. And the classic: no timeline wire, three shots skipped by the "needs a person" filter, and a final video that's nine seconds shorter than you planned with no error anywhere.