SaveMP4 batch

Easy to misread this one from the name alone: it's not "SaveMP4, but for a bigger batch of frames." It's specifically the save step for Cutting_video, another node in this same pack that splits a longer sequence into multiple separate clips. If you've already got a plain frame batch and just want one MP4 out, that's SaveMP4's job, not this one - this node expects a Video_Batch object, which is a specific WJNodes type representing several distinct video segments, not a single stack of frames.

It's part of ComfyUI-WJNodes, a personal utility pack from an author who publishes only as 807502278 on GitHub. Per the pack's own description, this node exists to save the output of Cutting_video - a mask-based video splitter elsewhere in the pack - as individual MP4 files in one step, rather than requiring a separate save node per clip.

What it does

Cutting_video (not covered in this article, but the node this one is built to pair with) takes a video sequence and a mask-driven split point and produces multiple segments bundled together as a Video_Batch. This node takes that bundle and writes each segment out as its own H.264 MP4 file, using the same encoding controls as the single-clip SaveMP4 node: a frame rate and a CRF value governing quality versus file size.

Inputs and outputs that matter

• Video_Batch - required, and it has to come from a compatible upstream node (Cutting_video, specifically) rather than a plain image batch. This is the field that trips people up if they're expecting this node to accept the same input as SaveMP4.
• filename_prefix - default MP4Video, same convention as the single-clip node.
• fps - default 25, adjustable 1–400 in steps of 0.1. Note the name difference from the single-clip node's frame_rate - same purpose, different label, which is worth knowing if you're used to the sibling node and wiring things from muscle memory.
• crf - default 23, same H.264 Constant Rate Factor as SaveMP4: lower means higher quality and bigger files, higher means more compression.

The single output, Video_filenames, is a string - the saved paths for the resulting clips, bundled together rather than as a separate output per file. This node is also marked as a terminal output node, so it runs and writes files even without anything consuming Video_filenames downstream.

Installing it

ComfyUI Manager: search "ComfyUI-WJNodes." Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/807502278/ComfyUI-WJNodes.git

Restart ComfyUI. Like SaveMP4, this depends on ffmpeg being available for the actual H.264 encoding - if it fails at the encode step specifically rather than on load, check that first.

Where people get stuck

The most common mistake is exactly the one this article opened with: wiring a plain image batch into Video_Batch and getting a type mismatch, because this node isn't a general-purpose "save many frames as one video" tool - it's specifically for Cutting_video's output format. If you just have a stack of frames and want one MP4, use SaveMP4 instead; this node only makes sense once you're already using Cutting_video to split a sequence into segments.

Beyond that, the same CRF-direction confusion applies here as with SaveMP4 - lower is higher quality, higher is more compressed, which reads backwards to a lot of people coming from other tools. And because Video_filenames bundles multiple saved paths into one string output rather than a list you can index cleanly, check exactly how that string is formatted (whether it's newline-separated, comma-separated, or something else) before building downstream logic that parses it - there's no public documentation beyond the README to confirm the format ahead of time, so the fastest way to know is to preview it directly the first time you run this node.