MarigoldDepthEstimationVideo

The node's own description calls it out plainly: this is "experimental." Run any image-based depth model frame by frame across a video and you get flicker - each frame is an independent estimate, so even a static shot shows tiny, distracting shifts in the depth map from one frame to the next. This node's answer is optical flow: it warps the previous frame's depth estimate forward using motion data and blends it with the current frame's fresh estimate, so consecutive frames don't disagree with each other quite so much.

Why frame flicker matters and how this attacks it

A depth map that jitters is fine for a single ControlNet pass but ugly for anything that plays back as motion - parallax video, depth-guided video generation, VR conversion. The generic fix in the wider ecosystem is a video-native depth model built for temporal stability from the ground up (that's a real category, and Marigold isn't natively in it). This node is kijai's attempt to bolt temporal awareness onto Marigold specifically, using classical optical flow rather than a retrained model: warp what you already computed for the last frame toward where the pixels moved, then blend it against this frame's independent estimate instead of throwing the old one away.

The inputs and outputs that matter

Most of this overlaps with the standalone MarigoldDepthEstimation node - same model choice, invert, use_fp16-adjacent dtype, ensembling knobs. The video-specific additions are the ones worth understanding:

• first_frame_denoise_steps / first_frame_n_repeat - the first frame has no previous frame to warp from, so it gets its own settings, independent of the steady-state values used for every frame after it.
• flow_warping (default true) - the switch for the whole mechanism. Turn it off and you're back to independent per-frame estimation, same flicker problem as any other frame-by-frame depth model.
• flow_depth_mix (default 0.3) - how much of the warped previous-frame estimate gets blended into the current frame versus trusting the fresh estimate. Higher values lean more on continuity from the last frame; lower values trust each frame's own read more.
• noise_ratio (default 0.5) - how much fresh noise gets reintroduced into the warped estimate before diffusing again, balancing "stay consistent with last frame" against "don't just calcify whatever the first frame decided."
• dtype (default fp16, also bf16/fp32) - precision for the run. fp16 is the sensible default for VRAM; fp32 if you're chasing maximum stability and have room to spare.
• scheduler defaults to DEISMultistepScheduler here rather than DDIMScheduler - a different scheduler than the standalone node ships with by default, worth knowing if you're comparing results between the two.

One output: ensembled_image (IMAGE) - a batch of depth frames, one per input frame.

How to install it

Same pack, same 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

No extra dependencies beyond the rest of the pack - the optical flow work happens with what's already installed.

Common issues & troubleshooting

It's genuinely slow on any real video length. You're running the full Marigold diffusion process per frame, plus flow computation and blending on top. This isn't a node to reach for on a 200-frame clip without a plan for the runtime.

Flicker isn't actually gone, just reduced. That tracks with what the node claims - "experimental" and optical-flow-based consistency, not a purpose-built video depth model. If a shot has fast motion or big scene changes, flow-based warping has less to work with and the smoothing effect weakens. Treat flow_depth_mix as the tuning knob before concluding the approach doesn't work for your clip.

Depth looks over-smoothed or laggy relative to motion. Push flow_depth_mix down and noise_ratio up to let each frame's own estimate assert itself more; you're trading flicker suppression against responsiveness to actual change.

VRAM pressure on longer batches. Drop dtype to fp16 if you aren't already there, and treat this the same as the standalone node for memory: it's diffusion-based and it adds up fast.