DepthAnythingV3_Streaming

This is the node for running Depth Anything 3 over a whole video - a real one, hundreds of frames - without blowing up your VRAM or getting flicker between chunks. It takes a VIDEO in and gives you a depth VIDEO out. Where the multi-view node processes one batch of frames with cross-attention, DepthAnythingV3_Streaming chunks the clip, processes each chunk, and aligns the chunks so the depth stays consistent across the seams. It's the "I have actual footage, not eight photos" tool.

Why chunking matters

Cross-view attention over an entire video at once is memory-suicide past a couple dozen frames. So the streaming approach slices the video into overlapping windows, runs depth on each, and stitches them together by aligning the overlap regions so the depth scale matches across the boundary. You get the temporal stability benefit of multi-view without holding the whole clip in memory. This is how you get the smooth video depth the pack's demo videos show off.

The inputs worth touching

• da3_model (required) - a main-series or Nested model, since streaming leans on the same cross-view mechanism.
• video (required) - your input clip.
• normalization_mode (default V2-Style) - V2-Style for a depth video you'll feed to ControlNet; Raw if you're after the point cloud path.
• chunk_size (default 30) - how many frames per window. Bigger chunks = more temporal context but more VRAM. If you're OOM-ing, lower this first.
• overlap (default 8) - how many frames adjacent chunks share for alignment. More overlap means smoother seams and slower processing. If you can see a "pop" in depth at chunk boundaries, raise it.
• align_lib / align_method (defaults auto / sim3) - how chunks get aligned to each other. Leave on auto/sim3 unless you have a specific reason; sim3 (scale + rotation + translation) is the sensible default for matching depth scale across windows.
• salad_model (optional) - a SALAD_MODEL from LoadSALADModel, which improves alignment robustness. Optional, but it's the reason LoadSALADModel exists.

The 3D-specific knobs - save_pointcloud, sample_ratio, conf_threshold_coef - only come into play if you flip save_pointcloud on to also emit a cloud from the video.

Outputs

Three: depth_video (the depth pass as a video - the main output, straight into a video ControlNet or a depth-aware video model), npz_folder (a folder path holding the raw per-frame depth arrays, for anyone who wants the numbers rather than a rendered video), and pointcloud_path (populated when save_pointcloud is on).

Where this sits vs. the alternatives

The KB's depth notes are clear that frame-by-frame depth flickers and video needs a temporally-aware approach - that's historically been DepthCrafter's job. DA3 streaming is the in-pack answer: it keeps everything in one model and one workflow, and it also gives you the camera/geometry data DepthCrafter doesn't. For short clips or a handful of stills, DepthAnythingV3_MultiView is simpler. For genuine long-form video, this is the node.

Common issues

Out of memory is the big one - drop chunk_size before anything else, it's the dominant VRAM lever here. Seeing a depth "jump" where two chunks meet? Raise overlap, and consider loading a SALAD model to firm up the alignment. Flicker within a chunk usually means you loaded a Mono/Metric model that doesn't get cross-view attention - switch to Large or Nested. And if the whole thing is just slow, that's the nature of running a transformer over every frame of a video with overlap on top; a smaller model variant (Base instead of Giant) buys back a lot of time for a modest quality hit.