MakeBatchFromIntList

This is one of those nodes that looks like a waste of space until you understand why it exists. In the ComfyUI-InfiniteTalk-MultiImage workflow, the core InfiniteTalkMultiImage node returns its results as lists - a frame_count_list of however many integers your images produced. But ComfyUI's graph doesn't loop over a list by magic. The workflow runs a for-loop (the Easy-Use nodes) that processes one segment per iteration, and for that it needs a batch of values it can pull individual items out of with an index. MakeBatchFromIntList is the bridge.

It's about as simple as a node gets: an int_list input that accepts multiple connected INT values, and one int_batch output. Internally it's INPUT_IS_LIST, so ComfyUI hands it a Python list of all the connected values. If there's only one value, it passes it through untouched. If there are several, it packs them into a torch tensor so downstream nodes can treat them as a single batch.

The flow in practice: InfiniteTalkMultiImage → frame_count_list (a list) → MakeBatchFromIntList → int_batch → then, inside the loop, GetIntByIndex pulls out batch[index] for the current iteration. The two nodes are a pair; this one builds, the other one reads.

Inputs: int_list (INT, multiple allowed). Output: int_batch (INT). Nothing to configure, nothing to tune. The category is InfiniteTalk because that's the workflow it exists to serve, but it's genuinely generic - if you have any batch of integers in a graph and need a single batch object, it works the same way there.

It ships with the ComfyUI-InfiniteTalk-MultiImage pack, install identical to everything else:

cd ComfyUI/custom_nodes
git clone https://github.com/xuhongming251/ComfyUI-InfiniteTalk-MultiImage

or ComfyUI Manager → search ComfyUI-InfiniteTalk-MultiImage → Install → restart. No Python dependencies, no model files.

Nothing to troubleshoot here, which is the point. The only gotcha is a workflow-design one: make sure you connect all the values you care about before it hits the batch step, because a batch is a fixed-size snapshot. And if your downstream index asks for a position beyond the batch's length, the matching GetIntByIndex node clamps rather than errors - which is polite, but also means a wrong index silently gives you the last value. That's a "your loop is off by one" signal, not a bug in the node.