Ensure Even Dimensions (encode-safe)

If you've ever batch-encoded video in ComfyUI and watched VHS_VideoCombine die with OSError: [Errno 22] Invalid argument on some files but not others, the culprit was probably sitting one wire upstream of where the error pointed. This tiny node is that fix. It ships as a bonus inside ComfyUI-BatchVideoLoader, and its whole job is to stop one of the most confusing mid-encode crashes you'll hit.

Here's the trap. H.264 in yuv420p - which is what VHS_VideoCombine and basically every video encoder you'll use in ComfyUI writes by default - requires both width and height to be even. Most generation pipelines land on even numbers by accident, so you never think about it. But the moment you run frames through an upscaler with a non-integer scale (1.5× on a source that isn't itself even), you can produce a 1536×855 batch. ffmpeg happily starts the encode and then dies mid-write when it gets handed the odd dimension. The traceback always points at VHS_VideoCombine, because decoding already succeeded and the pipe broke at the encode stage - which is why googling the error sends you down rabbit holes about VHS bugs when your actual problem is one odd pixel.

Ensure Even Dimensions exists to catch exactly that. You wire it between your upscaler's output and VHS_VideoCombine's images input. It reads the frame batch, and only if height or width is odd, crops a single pixel off the bottom or right edge. If both dimensions are already even - which is most of the time - it returns the tensor untouched.

The mechanism is dead simple, straight from the source:

new_h = h - (h % 2)
new_w = w - (w % 2)
if new_h == h and new_w == w:
    return (images,)            # already fine, pass through untouched
return (images[:, :new_h, :new_w, :],)

One input (images, an IMAGE tensor), one output (images). That's the entire surface area - no widgets, no settings, nothing to misconfigure. It never stretches or rescales; if your output is wildly off you need a resize node, not this. Cropping one row of pixels from the edge of an upscaled video frame is invisible in practice, and it beats the alternative of re-encoding your whole pipeline at odd dimensions.

Being a no-op when it's not needed is the real selling point. In a batch folder where each source video has a different resolution, some will land odd and some won't - a node that always resized would degrade every video in the folder. This one only touches the frames that would crash the encoder.

Installing it

It comes with the BatchVideoLoader pack, so there's nothing separate to install. Via ComfyUI Manager, search for "Batch Video Loader" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/artttaku/ComfyUI-BatchVideoLoader

The pack's only declared dependency is opencv-python - which you almost certainly already have, since VideoHelperSuite pulls it in. Restart ComfyUI and you'll find the node under video/batch → Ensure Even Dimensions (encode-safe).

Troubleshooting: when this isn't the fix

The README is honest that odd dimensions are only one cause of that Errno 22 crash. If this node doesn't cure it, the usual second suspect is a hardware NVENC session conflict - GeForce cards cap concurrent encoding sessions, and OBS, Discord, or a leftover ffmpeg.exe process can make a new session fail silently. To tell them apart, temporarily switch VHS_VideoCombine's format from video/nvenc_h264-mp4 to software video/h264-mp4 and rerun the failing file. Succeeds? It was NVENC - close the competing app and switch back. Still fails? Check the source file itself with ffprobe; you've got a corrupt or unusual stream.

Honestly, that diagnostic tip is worth more than the node in a lot of cases. But when the cause really is the odd pixel - and for batch work across mixed resolutions, it often is - this one-liner costs you nothing and removes an entire class of "why does video 3 of 12 always crash" frustration.