Depth viewer stuck on opening live: fix the stereo depth pipeline

Your stereo camera enumerates, the RGB preview streams, and the camera’s diagnostic tool passes every test — but the depth viewer sits on “Opening Live…” and never renders a map. That combination clears the camera, the cable and the basic SDK install, and points at the depth pipeline on the host: the neural depth model, the GPU runtime it loads through, or a security filter between the viewer and the SDK service. This guide works the causes in probability order, gives the test and the fix for each, runs a memory-budget check for small GPUs, and ends with the short sequence that clears most of these hangs. The detail comes from a Windows 11 host, and the same order holds on any platform.

What the symptom already tells you

The RGB path proves the USB link, the power budget, sensor enumeration and the SDK’s camera service are alive. Depth is not another stream; it is a pipeline. The viewer must rectify two images, load a neural depth model onto the GPU, run it through an inference runtime, and carry the result back over a local connection. “Opening Live…” that never finishes means one of those steps never returns — and the RGB passthrough never touches any of them.

With diagnostics green, work this order: security software hooking the SDK, an SDK build that does not match the GPU generation, a depth model that is not optimized, VRAM exhaustion, and last a marginal USB link that only fails under depth’s extra load. One exception: a report that shows the mono sensors missing is the hardware twin of this symptom — the stereo camera that works for RGB but has no depth — and no software change fixes that.

When one tool works and another stalls on the same camera, the split is usually in the middleware, not the sensor; a GigE camera that works in the vendor viewer but not in the second tool shows the same pattern on a different interface.

Cause 1: security software hooking the SDK

Depth viewers in this class reach the camera service through local sockets and shared memory, and antivirus and host-firewall products install filter drivers that inspect exactly that traffic. A plain RGB passthrough survives the hook; the depth pipeline’s first model-load handshake stalls, and the viewer waits forever. Camera support teams ask about this first for good reason.

Exclude the SDK’s install folder, the viewer executable and the camera service, reboot, then reopen the viewer. The reboot matters because the filter reloads only then. If depth opens, keep the exclusions in the deployment image rather than running inspection machines with protection disabled. If the hang survives a real exclusion and reboot, move on — and leave the exclusion in place while you test the next causes, so two hooks cannot stack.

Cause 2: the SDK build does not match the GPU

These SDKs ship as one installer build per inference-runtime generation — the case behind this guide had the TensorRT 8 build installed, while a TensorRT 10 build serves newer GPUs. Depth loads its neural model through that runtime; RGB never touches it. On an entry-level laptop GPU with 2 GB of VRAM, the newest build’s runtime can refuse to initialize, and the failure surface is exactly this one: a depth-only hang with green diagnostics.

Two facts from the runtime itself decide the fix. An engine compiled under one TensorRT version will not load under another, so a GPU driver update can break a depth pipeline that worked yesterday. And the first depth start after a fresh build compiles the model for your GPU, which can take minutes — a slow first start is normal, an indefinite one is not.

Test: open the SDK’s release notes and find the build your GPU generation is listed under; older mobile GPUs sit on the older runtime. Fix: uninstall, install the matching build, let the first start run. On robot controllers the same mismatch surfaces as a depth node that never starts — verify the GPU runtime libraries first covers that variant.

Cause 3: the depth model is not optimized

The diagnostic report’s “AI Models” block lists every model with its state. Depth needs “NEURAL DEPTH is optimized”, with NEURAL PLUS DEPTH and NEURAL LIGHT DEPTH beside it. In the case behind this guide those three lines read optimized while a dozen detection entries read “is not optimized” — normal and harmless, because detection models are optional extras and the depth map does not use them.

The decision is short. Detection lines unoptimized: ignore them. A NEURAL depth line unoptimized: repair the SDK install so optimization reruns against the current GPU driver, and rerun that check after every driver update, since the compiled model is tied to the runtime it was built for. When the report alone does not name the fault, debug log errors when opening a 3D camera viewer takes you the next step.

Worked check: the VRAM budget on a 2 GB GPU

Inputs, all from the case: a nominal 2 GB — 2048 MB — of VRAM, Windows 11, and a typical depth mode of 1280 × 720 with standard formats: depth and color at 4 bytes per pixel, the rectified pair at 1 byte, disparity at 2 bytes, a point cloud at 12 bytes. Rule in words: a buffer’s bytes equal width times height times bytes per pixel; sum the buffers, triple them for triple buffering, compare with what the desktop leaves free. Decimal megabytes throughout.

• Pixels per frame: 1280 × 720 = 921,600 px
• Depth, 4 B/px: 921,600 × 4 = 3.7 MB
• Color, 4 B/px: 921,600 × 4 = 3.7 MB
• Rectified pair, 1 B/px: 921,600 × 2 = 1.8 MB
• Disparity, 2 B/px: 921,600 × 2 = 1.8 MB
• Point cloud, 12 B/px: 921,600 × 12 = 11.1 MB
• Frame set: 3.7 + 3.7 + 1.8 + 1.8 + 11.1 = 22.1 MB
• Triple-buffered: 22.1 × 3 = 66 MB

Result: 66 MB against 2048 MB is about 3 %. Decision: image buffers never starve a 2 GB card — the neural model and its workspace are what grow. Watch dedicated GPU memory in Task Manager while the viewer starts; with more than 1 GB free, memory does not own this hang and causes 1 and 2 do. If depth opens one resolution mode lower, run that mode or close GPU-heavy apps, and read depth video playback running out of GPU memory for the same fault in playback form.

When it is the port after all

Depth adds streams and power draw on top of RGB, and a front-panel port, an unpowered hub or a long replacement cable can re-enumerate the camera at the moment depth engages. The tell is the RGB preview flickering, or the camera reappearing in the device list, when depth starts. Test: rear port on the machine, the supplied cable, no hub. With a rock-solid preview and green diagnostics this is the least likely cause, so it comes last.

One bench habit while you iterate: point the camera away from faces. Stereo cameras with pattern projectors are active emitters, and the safe-viewing distance in the camera’s documentation applies even while the viewer is hung.

The fifteen-minute sequence

1. Save the diagnostic report with the tool’s save button, so later reports can be diffed against it.
2. Add antivirus and firewall exclusions for the SDK folder, the viewer and the camera service, then reboot.
3. Reopen the depth viewer. Depth renders: done, and the exclusions go into the image.
4. Read the “AI Models” block: the three NEURAL depth lines must say optimized.
5. Check the installed SDK build against the release notes for your GPU generation; swap builds and give the first start several minutes.
6. Drop one resolution mode and watch dedicated GPU memory while the viewer starts.
7. Move to a rear USB port, supplied cable, no hub.
8. Still hung: capture the viewer’s log, attach both reports, and contact us — free expert support comes with every order.

If the host stays the constraint

Some hosts never clear this class of hang because the GPU is too small for the neural depth pipeline being asked of it. The decision then is to move depth off that runtime: a sensor that computes its 3D output in the device hands you a profile or point cloud directly, with no host-side model to compile, hook or feed. The 3D sensors shelf covers that route, and an area scan camera beside it keeps the RGB detail you already have.

Three examples from that shelf:

Before you image the next machine

• Pin the SDK build per GPU model in the image, and hold GPU driver updates until you can rerun model optimization.
• Bake the security-software exclusions in, so a fleet update cannot reintroduce the hook.
• Keep one known-good diagnostic report per workstation; a diff against it names what changed.
• For every camera added to the fleet, run the depth camera SDK support check before the purchase order, not after.

To size a whole station in one pass, start at the camera finder or the configurator; more depth-camera faults are collected on the 3D topic page.