Video Depth Anything Process

This is the node that actually runs the model. Feed it a batch of frames and the loaded Video Depth Anything model, and it hands back consistent depth for the whole clip - not a depth map per frame computed in isolation, but a sequence where the geometry agrees with itself from one frame to the next. That agreement is the entire point: run an image depth model frame-by-frame on video and you get flicker, subtle shifts in the depth reading for things that clearly aren't moving. This node exists specifically to not do that.

Where it sits in the pipeline

Three nodes, one job each. LoadVideoDepthAnythingModel picks the checkpoint. This node - VideoDepthAnythingProcess - is the middle step that does the inference. What comes out isn't a normal image; it's a DEPTHS object, a pack-specific container for the raw depth data. You then hand that to either VideoDepthAnythingOutput (turn it into a viewable/saveable video) or VideoDepthAnythingSaveEXR (export it as full-precision EXR for a 3D or compositing pipeline). Keeping the raw depths separate from a rendered image is deliberate - that DEPTHS object still carries full float precision, which a colormapped 8-bit PNG has already thrown away.

The inputs that matter

Two required inputs feed the model itself, plus three settings:

• vda_model and images - the loaded model and your frame batch. This is a batch-processing node, so images is the whole clip, not one frame at a time.
• input_size (default 518) - the resolution the model actually processes internally. 518 isn't a random number; it lines up with the ViT backbone's native training resolution (37 patches of 14px), so it's the size the model was actually trained to reason about. Pushing it up doesn't reliably buy more real detail since that's not the resolution the model learned on - it mostly costs you more VRAM and time. Leave it at default unless you have a specific reason not to.
• max_res (default 1280) - caps the working resolution for the pass, and this is your practical lever. Depth Anything models generally are cheap; running one over an entire video, frame after frame, is not. If you're processing a long or high-res clip and you're hitting an out-of-memory error or the run is crawling, drop max_res before you drop the model size - it's the more direct fix for exactly that problem.
• precision (default fp16, alternative fp32) - half precision is faster and uses less VRAM, and it's the sane default on any reasonably modern GPU. Drop to fp32 if you're on an older card and the output comes back broken.

Output

One output, depths (type DEPTHS). It wires into VideoDepthAnythingOutput's depths input to get a normal image/video out, or VideoDepthAnythingSaveEXR's depths input to write an EXR sequence. Nothing else in a typical ComfyUI graph accepts this type - it's specific to this pack.

Installing it

ComfyUI Manager: search ComfyUI Video Depth Anything, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/yuvraj108c/ComfyUI-Video-Depth-Anything

then restart ComfyUI. You need LoadVideoDepthAnythingModel upstream of this node with a checkpoint actually downloaded before this node will do anything - see that node's page for the model-file details.

Common issues & troubleshooting

Runs out of memory on longer clips, or takes forever. This is the single most common complaint with any video-native depth model that processes a whole clip rather than one frame at a time - the community's own reports on this exact model describe an eight-minute clip taking multiple hours and eating through available memory before it's done. Drop max_res first. If that's not enough, cut the clip into shorter segments and process them separately, or step down to the vits (small) checkpoint on the loader node.

Output looks broken, blank, or full of garbage values on an older GPU. Classic NaN-from-fp16 territory - pre-Turing cards (GTX 1600 series and earlier) don't handle half-precision math reliably, and it silently corrupts the output rather than erroring cleanly. Switch precision to fp32. It costs you VRAM and speed, but it produces valid numbers.

Depth looks fine per-frame but still flickers slightly. Some residual jitter is normal at the edges of fast motion or fine detail (hair, foliage) - that's the model's honest uncertainty, not a bug. If it's bad throughout the whole clip rather than just in hard regions, double-check you're actually feeding the whole batch through this node in one call rather than looping it frame-by-frame elsewhere in your graph - chopping the batch up defeats the entire temporal-consistency mechanism this node exists for.