πΉ kmlbdh Video Combine (Smart + Tiled)
A VideoCombine that survives 4K on 8 GB VRAM
- images
- audio
- VHS_FILENAMES
Every video workflow you download leans on VideoHelperSuite's VHS_VideoCombine to write the final file. It's the default for a reason, but it has a failure mode you'll meet the moment your clip gets ambitious: long sequences, frame interpolation, an upscale in the chain - and suddenly the whole export dies in an out-of-memory error at the end of a run that took twenty minutes. kmlbdh Video Combine (Smart + Tiled) is a small-pack alternative that attacks exactly that problem: it streams the encode in chunks and suggests safe settings from your actual hardware.
What it actually does
It's an ffmpeg-powered video exporter, the flagship node of the kmlbdh/ComfyUI-kmlbdh-VideoCombine pack. Feed it an IMAGE batch - the frames coming out of your Sampler, RIFE, or upscale chain - and it writes an .mp4 to your output folder. Nothing exotic on the surface.
Two things separate it from VHS_VideoCombine:
- Chunked encoding. Instead of loading every frame into memory and running one giant ffmpeg encode, it slices the batch into
chunk_size-frame pieces, encodes each to a temp file, then concatenates them with a stream copy. RAM usage stays flat no matter how long the clip. - Auto-detected defaults. When the node instantiates, it reads your system RAM and VRAM and picks
chunk_size,tile_size, andsave_images_in_memoryto match. Sub-16 GB RAM or sub-10 GB VRAM gets conservative settings; a high-end box gets bigger chunks and no tiling.
The output type is VHS_FILENAMES, deliberately. That's VideoHelperSuite's filename format, so this node can drop into a workflow where something downstream expects VHS output. Smart move for a node that's pitching itself as a drop-in replacement.
The inputs that matter
You'll touch maybe four of these as a beginner:
images- your frame batch. The only required wiring.frame_rate- 16 by default, matching most image-to-video pipelines. Set it to whatever your model actually outputs (Wan 2.2 and friends often want 16β24).codec/crf-h264with acrfof 15 is a great starting point. Lower CRF = better quality and bigger files; 15 is already quite clean.save_images_in_memory- the big lever. Off (the default on lower-end machines) means chunked streaming to disk. Turn it on only if you've got RAM to spare and want the simpler full-batch path.
Everything else - preset, pix_fmt (yuv420p stays default for maximum player compatibility), tile_size, tile_overlap, chunk_size, filename_prefix - has sane defaults. There's an optional audio input (AUDIO) if you want to mux a soundtrack in.
A word about tiling, straight from the source
The README sells tiling hard ("split frames into tiles to avoid VRAM crashes"). Reading the code, the tile path streams each tile crop to ffmpeg as its own output frame - there's no step that stitches the tiles back into full frames. So a 4K frame split four ways becomes four separate output frames, which is not the video you wanted. My take: leave tile_size at 0 (off) unless you've tested and verified your output on a small clip first. The chunked streaming is the feature that actually earns its keep, and high-end machines default to tiling off anyway.
Installing it
Same as any custom node. ComfyUI Manager β search "kmlbdh Video Combine (Smart + Tiled)", or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/kmlbdh/ComfyUI-kmlbdh-VideoCombine.git
Then restart ComfyUI. No model downloads, no requirements.txt - the pack ships nothing to pip-install, which is refreshing but means you need a system ffmpeg binary on your PATH. The node shells out to ffmpeg directly. On Linux that's usually fine; on the Windows portable build ffmpeg often isn't on PATH, so if you see an ffmpeg-not-found error, install it and add it to PATH.
When it's worth it
This is a tiny hobby pack - one author, essentially no community footprint, a README heavy on marketing. Set expectations accordingly. But the core idea is sound and it costs nothing to try: if VHS_VideoCombine is eating your RAM on long or high-res exports, clone this, set save_images_in_memory to off, bump chunk_size to taste, and see if your exports stop dying. For everyone else, the bundled VHS_FILENAMES output means your workflow doesn't even know the difference.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | β | |
| frame_rate | INT | 161β120 | β |
| codec | COMBO | h264 | 2 options: h264, hevc |
| crf | INT | 150β50 | β |
| preset | COMBO | fast | 7 options: ultrafast, superfast, veryfast, faster, fast, medium, +1 |
| pix_fmt | COMBO | yuv420p | 2 options: yuv420p, yuv444p |
| chunk_size | INT | 61β64 | β |
| save_images_in_memory | BOOLEAN | false | β |
| tile_size | INT | 10240β8192 | β |
| tile_overlap | INT | 80β64 | β |
| filename_prefix | STRING | kmlbdh | β |
| audioopt | AUDIO | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| VHS_FILENAMES | VHS_FILENAMES | β |