Batch Manager

If you've ever had a video workflow work fine at a few seconds and then OOM the moment you push the clip longer, this is the node that fixes that class of problem. It doesn't process anything itself - it hands out a "process this many frames at a time" instruction that other tbox video nodes, like VideoSaver, read and obey.

How it works

This is the same idea as VideoHelperSuite's well-known Meta Batch Manager node, and people building long Wan/AnimateDiff-style video pipelines lean on this pattern specifically to dodge OOM on interpolation and encoding passes: instead of loading every frame of a long clip into memory at once, the batch manager tells consuming nodes to work through the clip frames_per_batch frames at a time. tbox's BatchManager is a one-setting version of that same contract - set the chunk size, wire the output into anything downstream that accepts a meta_batch, and that node processes in batches instead of all at once.

It has exactly one job and no image or video data passes through it at all - it just produces a handle that other nodes read.

The inputs and outputs that matter

• frames_per_batch (required INT, default 16, range 1–128) - the only setting on the whole node. Lower it if you're still hitting memory limits with the default; raise it if your card has headroom and you want fewer, larger chunks (which is generally faster, since there's overhead to starting each batch).

Output: meta_batch (type BatchManager) - plug this straight into the meta_batch input on VideoSaver (or any other tbox node that exposes one). There's no image or video output here, just the batching contract itself.

How to install it

Via ComfyUI Manager: search ComfyUI-tbox, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ai-shizuka/ComfyUI-tbox

then restart. No models, no heavy dependencies - this is pure graph-control logic, nothing to download.

Common issues & troubleshooting

Nothing changes when you wire this in. Check that the node on the other end actually has a meta_batch input to accept it - BatchManager only does something for nodes built to read it, like VideoSaver. Wiring it into a random node with no such input does nothing.

Still OOMing even with a small frames_per_batch. Batching controls how many frames are held at once, not the total memory footprint of your model. If you're already at a low chunk size and still hitting the ceiling, the next lever is usually a purge/VRAM-clear node between batches, or a lighter model quantization - batching alone won't rescue a model that barely fits at batch size 1.

Seams or jumps between batches on interpolation-heavy workflows. This is a known limitation of chunked processing in general, not specific to tbox: a batch boundary means the last frame of one chunk and the first frame of the next were never processed together, so anything that needs continuity across that boundary (frame interpolation especially) can show a visible seam. Larger frames_per_batch reduces how often you hit a seam, at the cost of the memory headroom you were trying to save.