MarigoldDepthEstimation_v2_video

This is the video variant of the newer, diffusers-based Marigold node, and it solves the same frame-flicker problem as the older MarigoldDepthEstimationVideo node with a different, simpler trick: instead of computing optical flow between frames, it uses the previous frame's own depth latent as the starting point for the current frame's diffusion process. Consecutive frames start from somewhere similar, so they tend to land somewhere similar - cheaper to compute than flow warping, and it fits naturally into the pipeline-based v2 architecture.

Where it fits

If you've read the article on MarigoldModelLoader or MarigoldDepthEstimation_v2, this node is exactly what you'd expect: take that same diffusers-pipeline approach, apply it across a batch of frames instead of one image, and add one new setting to control how much continuity carries from frame to frame. It needs the same MARIGOLDMODEL from MarigoldModelLoader as its single-image sibling - there's no separate video-specific model, just a different node that runs the pipeline frame-aware.

How it works

For the first frame, there's nothing to carry forward, so it diffuses normally from pure noise. For every frame after that, the node initializes the latent partway toward the previous frame's result, controlled by blend_factor, rather than starting from scratch each time. That's a cheaper and more direct way to buy consistency than optical flow: no motion estimation step, just letting each frame's diffusion process start from a point already close to a plausible answer.

The inputs and outputs that matter

• marigold_model (MARIGOLDMODEL) - from MarigoldModelLoader, same as the single-image v2 node.
• images (IMAGE) - your frame batch.
• blend_factor (default 0.1) - the one setting that's genuinely new here, and the one you'll actually tune. It controls how strongly each frame's starting point leans on the previous frame's result. Push it up for smoother, more stable video at the cost of responsiveness to real motion; pull it down toward 0 and you're closer to independent per-frame estimation with all the flicker that implies.
• denoise_steps (default 4) and scheduler (default LCMScheduler) - same pairing logic as the single-image node: LCM checkpoints want few steps and the LCM scheduler, the base model wants more steps and DDIMScheduler.
• processing_resolution (default 768) - same Marigold sweet spot as everywhere else in the pack.
• use_taesd_vae (default true here, unlike the single-image node where it defaults off) - worth noting the default flip; for video you're decoding many frames, so the speed win from the lighter VAE compounds more, which is presumably why the author defaulted it on here.
• keep_model_loaded (optional, default false) - turn this on; for any video batch you're running the same pipeline across many frames in a row, and reloading between them would be wasteful.

One output: image (IMAGE) - the depth frame batch.

How to install it

Same pack, no separate steps. ComfyUI Manager: search "marigold", install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-Marigold
pip install -r ComfyUI-Marigold/requirements.txt

You need MarigoldModelLoader upstream, same as MarigoldDepthEstimation_v2 - this node has no model-loading of its own.

Common issues & troubleshooting

Video runs are slow, and it adds up fast across many frames. This is the same diffusion-based cost as the single-image node, multiplied by however many frames you're processing. Turn on keep_model_loaded at minimum so you're not paying a reload cost on top of the diffusion cost, and consider whether ensemble_size-style quality (not exposed here - the single-image node has it, this one doesn't) is something you actually need for video where a viewer won't scrutinize any single frame as closely as a still.

Depth looks smeared or laggy compared to actual motion in the source. blend_factor is set too high for how much motion your clip actually has - it's carrying over too much of the previous frame's answer. Pull it down toward 0 to let each frame respond more to what's actually in it.

Still seeing visible flicker. blend_factor may be too low to meaningfully smooth things, or your clip has fast motion/scene changes where "start near the last frame's answer" isn't a good prior to begin with - in that case this frame-blending approach and the flow-based MarigoldDepthEstimationVideo will both struggle, since neither is a purpose-built video depth model.

Output is oddly soft compared to the single-image node. Check use_taesd_vae - it defaults to true here (unlike the single-image v2 node's false default), trading a little decode quality for speed across the batch. Turn it off if you're chasing maximum per-frame quality and can afford the slower decode.