Mpi Bernini Length

Ask Bernini for 48 frames and you get 45. No error, no warning, no log line. The clip is just three frames shorter than the plate you asked it to edit, and you find out two nodes downstream when a stitch or a splice refuses two different frame counts and points at some masking node that has nothing to do with it.

That's not a bug in this pack. It's arithmetic. Core builds ((length - 1) // 4) + 1 latent frames and the VAE decodes 4 pixel frames out of each one, so the only counts Bernini can actually return are 4n+1 - 1, 5, 9, … 81, 85 … Ask for anything else and it silently rounds down. The community hit the same wall from the other direction with the "Bernini Infinity" chunked-conditioning node, which documents the same latent-arithmetic trap and pads to fix it.

What it does

MpiBerniniLength is pure arithmetic: frames in, the count Bernini will really return out. Nothing is sampled, nothing is loaded, it costs nothing.

48 in  → length = 45, on_grid = false
81 in  → length = 81, on_grid = true

That's the whole node. It's boring on purpose.

Inputs and outputs

frames is the count you have - wire a video loader's frame_count straight in. Typing it is fine too, but wiring it is the point: whatever is upstream of your plate is the thing that has to be cut, and a wire can't go stale the way a typed number does.

fps is optional and used for exactly one thing: turning the count into seconds. Wire the loader's own fps rather than guessing, or your seconds readout is a different kind of wrong. (Division by zero is guarded, so a 0 fps gives you seconds = 0 instead of a crash.)

Three outputs:

• length - the snapped count. Feed this to MpiBerniniConditioning.length and to whatever trims your source plate: MpiListRange, an image-batch trim, the frame-count input on your stitcher. One number, two consumers.
• seconds - length / fps, i.e. the duration you're going to get, not the one you asked for.
• on_grid - false when your input had to be snapped. Wire it into a logger or an if/else if losing frames matters to you. This is the honest part of the node: 48 was never going to be 48, so it tells you instead of quietly shaving.

Why it isn't just an output on the conditioning node

This is the design decision worth understanding, because it looks like an obvious oversight until you try it the other way.

MpiBerniniConditioning can't report the effective length, because the thing that needs trimming - the source plate - is upstream of that node's source_video, usually through a crop and a packer. Read the count off the conditioning node and you've closed a dependency cycle, and ComfyUI simply refuses to execute the graph. So it's a separate node feeding both ends: the plate gets trimmed to n, the conditioning is asked for n, and the two cannot disagree. MpiH3Length is its own node for exactly the same reason.

Install

Ships in MadPonyInteractive/ComfyUi-MpiNodes - search ComfyUi-MpiNodes in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

Restart ComfyUI and search "Mpi Bernini Length". No dependencies to install (the pack has no requirements.txt), no model files, no GPU work. You will still need a ComfyUI new enough to have the core Bernini nodes for the companion conditioning node - this one itself is happy anywhere. The pack is AGPL-3.0 from v1.2.7 onward.

Where people get burned

Feeding it back into itself. length is already on the grid, so a second pass through this node is a no-op - harmless, just pointless. The one-count-two-places rule is the whole trick.

Assuming snapping rounds up. It rounds down: you lose up to 3 frames, you don't gain them. If you need a specific duration, start from a frame count you actually want and accept the snap, or plan around a grid point like 81 (5.06 s at 16 fps).

Trimming the plate with the number you typed instead of the number it returned. That's the failure the node exists to prevent, and it presents as a stitch error about mismatched batches, nowhere near the conditioning where the frames went missing.

Expecting the seconds output to save your audio sync. It's a readout, not a fix - if you're windowing the picture you still have to window the soundtrack to match.