Device.startPipeline not exposed to Python in v3, C++ method still exists

[bherbruck]

What I'm seeing

In v2, Python users could build one Pipeline and call device.startPipeline(pipeline) to run the same graph on multiple devices from one process. That's gone in v3 Python bindings, even though the C++ method is still there and still shipping. The result is that every device in a multi-camera manager now needs its own fresh Pipeline object, which costs real host RAM per camera.

Repro

import depthai as dai
print("Device.startPipeline exists:    ", hasattr(dai.Device, "startPipeline"))
print("DeviceBase.startPipeline exists:", hasattr(dai.DeviceBase, "startPipeline"))
print("depthai version:                ", dai.__version__)

Output (depthai 3.5.0):

Device.startPipeline exists:     False
DeviceBase.startPipeline exists: False
depthai version:                 3.5.0

The C++ method is still there

include/depthai/device/DeviceBase.hpp:286:

bool startPipeline(const Pipeline& pipeline);

src/device/DeviceBase.cpp:1717:

bool DeviceBase::startPipeline(const Pipeline& pipeline) {
    return startPipelineImpl(pipeline);
}

Used internally by Pipeline::start() at src/pipeline/Pipeline.cpp:894:

defaultDevice->startPipeline(Pipeline(shared_from_this()));

And bindings/python/src/DeviceBindings.cpp has no .def("startPipeline", ...) anywhere. grep -r "startPipeline" bindings/ returns zero hits.

Bonus: utilities/stress_test.py:169 still calls device.startPipeline(pipeline). That script cannot run against the shipped v3 Python bindings. Probably worth fixing or removing depending on how this issue resolves.

Why it matters

Most multi-camera managers run the same graph on every camera. In v2 the clean pattern was:

self.pipeline = create_pipeline()   # build the graph once
...
for device_info in device_infos:
    device = dai.Device(device_info)
    device.startPipeline(self.pipeline)

I'm porting a production eggseer manager forward that uses exactly this pattern across 24 cameras. In v3 the only option is dai.Pipeline(device) per device, which means 24 separate Pipeline objects, each paying their own per-Pipeline allocation cost. I measured this at roughly 17 MiB steady-state and 60 MiB transient per device during construction. At 24 devices that's 400 to 700 MiB of duplicated Pipeline state for 24 identical graphs.

Worse, Device is no longer the hot-swappable unit. When a camera disconnects in v2 you dropped its Device and reused the same Pipeline on reconnect. In v3 you tear down the whole Pipeline and rebuild it, which means paying the 60 MiB transient again and running through all the node wiring code on every reconnect.

Suggested fix

Add one line to bindings/python/src/DeviceBindings.cpp:

deviceBase.def("startPipeline",
               &DeviceBase::startPipeline,
               py::arg("pipeline"),
               DOC(dai, DeviceBase, startPipeline));

The C++ method is already public, already tested (it's called internally by Pipeline::start()), and already shipping. Re-exposing it to Python is a pure bindings change with no C++ risk.

Questions

1. Was startPipeline removed from Python bindings intentionally in the v2-to-v3 migration? If so, what's the v3-blessed way to share one graph definition across multiple devices in one process?
2. If it was an oversight, can the binding be added back? Happy to open a PR with the one-line change if that'd help.
3. If there's a deeper architectural reason it can't come back, it'd be great to have that documented so multi-camera users know to plan around it.

Environment

• depthai 3.5.0
• Python 3.14
• Linux (WSL2, Debian)
• OAK-D x 3 (RVC2, Myriad X)

[bherbruck]

Went to look at the source to see if the removal was intentional or an oversight. Pretty sure it was intentional, and I want to update the ask because just re-exposing startPipeline verbatim would actually be unsafe now.

The 1-Pipeline-per-Device model is baked in at construction

include/depthai/pipeline/Pipeline.hpp:43-48:

PipelineImpl(bool createImplicitDevice = true) : assetManager("/pipeline/") {
    ...
}
PipelineImpl(std::shared_ptr<Device> device) : assetManager("/pipeline/"), defaultDevice{std::move(device)} {}

defaultDevice is set at construction and never reassigned. Pipeline::start() is a no-arg method that eventually calls defaultDevice->startPipeline(Pipeline(shared_from_this())) at src/pipeline/Pipeline.cpp:894. So at the C++ level, calling someOtherDevice->startPipeline(thisPipeline) would upload the graph to the wrong device, but the Pipeline's own host-side plumbing (queues, XLink bridges, scheduler wiring) would still point at defaultDevice. The host-side state is what makes the old v2 pattern unsafe to expose as-is.

That means the version I asked for in the original post (just add the binding line) would probably be fine for simple cases but would silently corrupt host-side state if anyone passed a Pipeline whose defaultDevice differs from the target device. Not a great API.

Better ask: a graph-clone method on Pipeline

What I actually want is the shape that v2 supported: build the expensive graph definition once, use it on N devices. In v3 the "graph definition" and "runtime state" are fused into one Pipeline class. If they can be cleanly separated, the ask becomes something like:

template_pipeline = dai.Pipeline(createImplicitDevice=False)
# build graph into template_pipeline, no device work
cam = template_pipeline.create(dai.node.Camera).build()
# etc.

for device_info in device_infos:
    device = dai.Device(device_info)
    pipeline = template_pipeline.cloneFor(device)   # new Pipeline, shared graph, bound to device
    pipeline.start()

Or equivalently a Pipeline.copyGraph() that returns a detached graph-only object you can bind to a device later. The expensive thing in my measurements was the per-device Pipeline construction cost (17 MiB steady, 60 MiB transient per device), and most of that is graph-definition state that's identical across every device running the same graph.

Why this matters for multi-camera managers

Our production manager runs 24 cameras with the same graph on every camera. With the current v3 API we pay for 24 independent Pipeline instances that differ only in which Device they're bound to. At roughly 17 MiB per instance that's 400+ MiB of redundant state for 24 identical graphs, and peak goes higher during the staggered startup.

The old v2 pattern avoided this by building the graph once:

self.pipeline = create_pipeline()
for device_info in device_infos:
    device = dai.Device(device_info)
    device.startPipeline(self.pipeline)

With a cloneFor or similar we could get the same benefit in v3 without exposing the unsafe raw startPipeline.

Questions

1. Is separating graph state from runtime state feasible in the current Pipeline design, or is it tangled enough that this would be a significant refactor?
2. If this is on the v4 wishlist instead of something for v3, that's a fine answer. We can work around it by accepting the per-device cost, but a "planned, not rejected" label would help downstream users make architectural decisions.
3. Short-term workaround question: is there a way to pre-build a .dap application package once and then flash it to many devices via DeviceBootloader.flash(package)? That would at least amortize the NN and graph serialization cost, even if each target device still needs its own runtime Pipeline.

Thanks for the earlier API, by the way. The v3 node API is much cleaner than v2 for single-device work, and the NNArchive format is a huge improvement. This is the one spot where the multi-device story regressed.