Encode Video Components

VRAM is the constraint that defines local video generation, and a chunk of it gets eaten before you've even started sampling - just by holding the raw frame tensor in memory. Encode Video Components sidesteps that: it extracts frames from a video, resizes them, and VAE-encodes them straight to latent, without ever materializing the full-resolution image batch in RAM or VRAM.

Why the normal path costs you

The obvious way to get a video into a LATENT is: load the video into an IMAGE batch, resize that batch, then run it through a VAE Encode node. That's three separate tensors of the full frame stack alive at once at some point in the chain, and for anything more than a few seconds of footage at real resolution, that image batch alone can be the thing that pushes you into an out-of-memory error - before sampling even starts, before the part of the pipeline everyone budgets VRAM for. This node collapses extract → resize → encode into one pass so the full image tensor never has to exist as a standalone object in memory.

The inputs and outputs that matter

• video (VIDEO) and vae (VAE) in - your source clip and the matching VAE for whatever model you're feeding.
• width (default 768) / height (default 512) - target resolution frames get resized to before encoding. Match these to what your model actually wants; feeding it something wildly off from the model's trained resolution is a familiar way to get soft or broken output regardless of which encode node you use.
• max_frames (default 0, meaning no limit) - cap how many frames get pulled from the source. Useful for testing a workflow on a short clip before committing to encoding the whole thing.
• upscale_method (default lanczos) - the resize algorithm for getting frames to your target resolution.
• keep_proportion - controls how frames fit into your target width/height (crop to fill, pad to fit, stretch, etc., depending on what's available in the dropdown for your ComfyUI version).

Four outputs come out the other side: latent (ready for your sampler), audio (passed straight through, so you don't lose the source clip's soundtrack while doing the video-only encode), fps, and frame_count. The last two matter more than they look - feed them into your video-combine/export node at the end so your output plays back at the right speed and you don't have to hardcode a frame count that drifts out of sync with max_frames.

Installing it

Part of KJNodes, no extra install:

• ComfyUI Manager - search KJNodes for ComfyUI, install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt, restart.

You'll of course still need whatever video model and VAE you're targeting (Wan, LTX-2, etc.) - this node doesn't reduce that requirement, it just keeps the intermediate frame-extraction step from being its own VRAM spike on top.

Common issues & troubleshooting

Still running out of memory. This node avoids the extra copy of holding a full-resolution image batch separately from the encode step - it doesn't shrink the fundamental cost of encoding a long, high-resolution clip. If you're still hitting OOM, drop width/height, use max_frames to cap the clip, or process in shorter segments; video generation's VRAM appetite scales with resolution and frame count regardless of which encode node does the work.

Audio is missing downstream. Make sure you're actually wiring the audio output somewhere - it passes through automatically, but only if something downstream consumes it. If your source video has no audio track to begin with, this output will be empty, which is expected, not a bug.

Output video looks squished or oddly cropped. That's keep_proportion and your target width/height not matching your source aspect ratio. If your model needs a specific aspect and your source doesn't match it, decide upfront whether you want cropping or padding and set keep_proportion accordingly rather than fighting the resize after the fact.