Add Blank Frames

Sooner or later every video workflow hits the same wall: the thing you built produces a clip of length X, and the thing downstream wants length Y. Wan wants frame counts in the 4n+1 family, LTX wants divisible by 8 plus 1, your edit wants every shot to be exactly 96 frames, and you just want a beat of black at the top so the fade-in doesn't start mid-motion. Add Blank Frames does exactly one job here - it sticks N black frames on the front or the back of an IMAGE batch - and it does it without resampling, resizing, or re-encoding a single pixel.

That's the whole node. It's a plumbing node in a pack full of them, and it's the kind of thing you install once and then reach for constantly.

What it actually does

The shipped code is short enough to read in one sitting: it allocates torch.zeros with the same height, width and channel count as your input, the same dtype, the same device, and torch.cats it onto the batch dimension. End frames, or start frames, depending on which way you point it.

Practical consequences, all of which are good:

• Nothing is touched. No CPU round-trip, no Pillow, no colour conversion. Just an allocation and a concat.
• Black means black. These are literal zeros, not a fade. If you want a fade, that's a different problem.
• blank_frames_count of 0 is a pass-through. It returns your input tensor unchanged, which makes it safe to leave in a graph you've temporarily zeroed out.

The inputs, honestly there are only three

images is your IMAGE batch - same socket type every video node in ComfyUI speaks. blank_frames_count is an INT from 0 to 1000, default 1. insert_position is a two-option dropdown, end (default) or start. That last default catches people: if you wanted black at the head and just dragged the node in, you got black at the tail. Flip it.

The single output is new_batch, an IMAGE batch - so it wires straight into whatever you'd have wired the original into: your video combine/save node, another padding node, a concatenator, or the input of the next stage of processing.

Where it earns its place

The frame-count arithmetic is the big one. Wan's VAE compresses time roughly 4x, so 111 frames in can come back as 109 out; LTX 2.3 will simply refuse a count that isn't divisible by 8 plus 1. When you're one or two frames off, padding black frames is far cheaper than re-generating a shot, and - unlike mirrored/ping-pong padding, which the community uses to hit those same lengths - it doesn't invent motion that wasn't there. You get a couple of black frames. You can trim them in the editor.

Second use: assembly. If you're cutting several shots together and want them all padded to a common length, this is a one-node fix. Same story for looping clips - a single black frame at the tail turns a hard jump cut back to the head into something that at least reads as intentional.

One opinion: keep this at the end of your pipeline, after generation. If black frames go into a video model as conditioning context, the model treats them as real input and will cheerfully try to generate motion out of a black frame - smearing, contrast drift, or a weird slow fade you didn't ask for. Padding is for assembly and for downstream arithmetic, not for papering over a latent that's the wrong size.

Install

One install covers this node and everything else in the pack (about 37 node modules at v1.5.9, including the Consistent Character Creator and the iterative-video machinery - you get all of it whether you want it or not).

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git

Then restart ComfyUI. Via Manager it's easier: search "Mickmumpitz", hit Install, restart. The pack is published under publisher id mickmumpitz as "Mickmumpitz-Nodes", MIT licensed, and it's actively maintained - releases still landing in late 2026.

No models to download, no checkpoints to place anywhere. requirements.txt does pull numpy, Pillow, opencv-python and ultralytics>=8.0.0, but the README is explicit that ultralytics is only needed if you let the Consistent Character Creator's face-area nodes load their own detector. You don't need it for this node. It gets installed anyway because it's in the dependency file, and it drags a sizeable stack behind it - worth knowing if your environment is held together with tape.

Where people get burned

• Nothing happened. blank_frames_count is 0, so you got your batch back identical. Or a downstream node was cached and never re-ran.
• Black at the wrong end. insert_position defaults to end.
• You padded, then interpolated. Run a frame-interpolation pass over the padded clip and the frames between your last real frame and the first black one get blended - a fade, not a cut. If you want a hard boundary, interpolate first and pad afterwards.
• The video model still complained. Padding adds frames to the assembled clip; it doesn't change the arithmetic the VAE applies at sampling time. If the model wants 4n+1 latents, that's a sampler-side problem, not a padding-side one.