When a 3D camera runs fine in the vendor's viewer but kills your driver at launch, the log ends with Failed to get depth profile: Invalid input, No matched video stream profile found!, the stream it asked for, and exit code 255. The message then suggests a USB 2.0 connection. Put that aside: in most of these start-ups the driver requested an exact depth width, height, frame rate and format combination the camera does not offer, and profile matching is all-or-nothing. Here is where the real profile list sits in the same log, which tuple to set instead, and the one case where the USB 2.0 hint is genuine.
What the error actually reports
Every stream a driver enables is one tuple: width, height, frame rate, format. At start-up the driver asks the device for that tuple out of the profile list the camera enumerated over USB, and the answer is either the matching profile or this failure. There is no nearest fit and no fallback: request a resolution the device never advertises and the lookup returns No matched video stream profile found.
The same log tells you what worked. In this start-up the color stream enabled first at 1280 × 720, 30 fps, MJPG, so the device was open, the link carried data and permissions were in order. The depth request that followed was 640 × 576 at 30 fps in Y16, and the process exited at that line.
The pattern is not special to depth hardware. Any USB camera whose driver asks for a format the device does not advertise fails the same way — USB camera format negotiation: diagnose rejected modes walks the 2D case, and a camera stream stuck in Y16 grayscale shows the negotiation failing on format alone.
The offered profiles are printed in the log
Right after the failure the driver prints every depth profile the device offers, under Available profiles:. Configure against that list — not against a datasheet, a forum post or last year's defaults. For this camera it reads:
| Depth resolution | Frame rates | Formats |
|---|---|---|
| 320 × 200 | 30, 15, 10, 5 fps | Y14, Y16, REL |
| 640 × 400 | 30, 15, 10, 5 fps | Y14, Y16, REL |
| 1280 × 800 | 30, 15, 10, 5 fps | Y14, Y16, REL |
Three resolutions, four frame rates and three formats give 36 valid combinations, and the requested resolution is not one of them. Y16 stores one 16-bit depth sample per pixel and Y14 one 14-bit sample; request Y16 unless you have a specific reason not to.
Decide from the list, not from the failed request. The field of view is set by the optics and stays the same across these modes; what changes is sampling density. Choose 640 × 400 at 30 fps in Y16 as the closest replacement, or 1280 × 800 at 30 fps in Y16 for four times the samples per frame — 1,024,000 pixels against 256,000.
Set the depth stream to a listed tuple
- Copy one
Available profiles:line exactly — for instance 640 × 400, 30 fps, Y16. - Open the launch file or parameters file that feeds the driver and find the depth block; depth width, height, fps and format are set there as launch arguments or YAML entries.
- Replace those four values with the copied tuple. Leave the color settings alone — that tuple already matched.
- Relaunch and read the stream-enable line: it should print your depth width, height, fps and format, then keep running.
- Pull one depth frame in your processing node and check its dimensions before enabling further streams such as IR.
If a format field refuses to change, a preceding setting usually gates it; 3D camera pixel format locked read-only: set the scan type first shows that ordering trap on a related camera.
When the USB 2.0 warning is real
The USB 2.0 line in the error is a canned guess printed by the profile lookup, not a measurement of your link. The same start-up had enumerated the camera with Connection: USB3.1, found two further 3D cameras on USB 3.0, and enabled an MJPG color stream over that link. Trust the enumeration lines over the boilerplate.
The failure the hint points at does exist. A replug can bring the same camera up as new high-speed USB device once and new SuperSpeed USB device the next — a SuperSpeed handshake failing silently because of a marginal cable, a hub port that drops the handshake or a connector not fully seated, leaving the link at 480 Mbit/s. When the kernel log for your serial number says high-speed, fix the physical link first: reseat the connector, shorten the run, or move the camera to a controller port. The bandwidth arithmetic for that case is in depth and color stream timeouts: the USB bandwidth check.
Worked example: 640 × 576 Y16 against the listed 640 × 400 at 30 fps
Inputs, all taken from the failing start-up log: the requested depth stream 640 × 576 at 30 fps in Y16; the nearest listed tuple 640 × 400 at 30 fps in Y16; the largest listed tuple 1280 × 800 at 30 fps in Y16; and Y16 meaning 2 bytes per sample.
Requested stream: 640 × 576 × 2 = 737,280 bytes ≈ 0.70 MiB per frame; × 30 × 8 = 176,947,200 bit/s ≈ 0.18 Gbit/s.
640 × 400 Y16: 640 × 400 × 2 = 512,000 bytes; × 30 × 8 = 122,880,000 bit/s ≈ 0.12 Gbit/s.
1280 × 800 Y16: 1280 × 800 × 2 = 2,048,000 bytes ≈ 2.0 MiB; × 30 × 8 = 491,520,000 bit/s ≈ 0.49 Gbit/s.
A 5 Gbit/s USB 3 link carries roughly 3-4 Gbit/s of payload after 8b/10b encoding and protocol overhead, so the largest profile the camera offers uses about one seventh of the link — and the refused 640 × 576 stream would have needed less bandwidth than the 1280 × 800 profile the camera does offer. Bandwidth was never the reason for the refusal. Decision: change the tuple and keep the cable. The threshold where link speed starts to matter: on a genuine 480 Mbit/s link, with practical payload near 300 Mbit/s, the 1280 × 800 Y16 stream at 30 fps (≈ 0.49 Gbit/s) cannot run, and even at 15 fps (≈ 0.25 Gbit/s) leaves little room for a color stream. Below roughly 0.2 Gbit/s per depth stream, the link speed is not your constraint.
When the offered list itself is the problem
Three situations make the printed list unreliable, and all three sit on the host side:
- Driver older than the camera. The SDK carries the format tables and the defaults, so a camera newer than the SDK enumerates profiles the driver cannot name, and defaults drift toward another model's resolutions. Pin one SDK version across the driver, containers and tools — pinning one library version everywhere shows the build fix — and check SDK version support first before debugging streams.
- Firmware updated ahead of the stack. A firmware change can shift the profile table; rebuild the driver stack before trusting an old list. Depth stream missing after a firmware update covers the sequence.
- A second process holding the camera. A viewer left open claims the USB interfaces, and the next connection sees a shortened list or none at all. Close every viewer and replug before judging the list.
Several depth cameras on one controller also share the link and host stack. If profiles match but frames stall, test one camera and one stream at a time — three depth cameras dropping to low FPS has the method.
Checks before you re-cable or reorder
- The enumeration line for your serial number says SuperSpeed or USB 3.x, not high-speed.
- Your depth width, height, fps and format match one printed
Available profiles:line, frame rate included. - No viewer, second launch or stale container holds the camera.
- The SDK version fits the camera's generation, and the stack was rebuilt after the last firmware change.
- Depth runs and one frame checks out before color and IR come on, one at a time.
Only the first check points at hardware. If the link does fall back to high-speed, replace the run with a short, shielded USB 3 data cable such as the LS-CBL-0219, a 3 m USB3.0 camera cable built for drag-chain use.
If the fix is a different sensor
When the profile table keeps blocking the application — the one resolution your algorithm needs is missing on every unit — re-specify the sensor instead of fighting defaults. Time-of-flight suits close-range presence, volume and robot feedback; projected structured light suits static scans of fine surfaces; laser galvanometer stereo covers larger working volumes. 3D vs 2D machine vision system: when to choose 3D compares the approaches, and the depth camera SDK support check lists what to confirm about driver support before you buy. Three sensors covering those cases:
- Type
- Depth / ToF camera
- Type
- Stereo / structured light
- Type
- Stereo / structured light
The MV-DT01WMU is a ToF sensing camera, the MV-DLS300P-04 a laser galvanometer stereo camera, and the MV-DPS200P-02 a projected structured-light 3D camera. Browse the 3D sensors category or the camera finder for the full range.
Checklist before the next launch
- Depth tuple copied from a printed
Available profiles:line, frame rate included - Enumeration shows SuperSpeed or USB 3.x for your serial number
- One process per camera; every viewer closed
- SDK version pinned and matched to the camera generation
- Depth confirmed first, then color, then IR
- Cable run short and shielded where the link has renegotiated before
Laser profilers and stereo 3D cameras
170 models · from $699.00Set the tuple first — it costs minutes and no hardware. If you are also re-specifying the camera, start from the category card above, or ask the applications team about a model's supported depth modes before ordering.
Questions
Why does the driver request a depth resolution the camera never lists?
Launch defaults are written for whichever model the package was tested on first. Here the same defaults start two other 3D cameras on the same controller, but this camera enumerates only 320 × 200, 640 × 400 and 1280 × 800, so the 640 × 576 default can never match. The vendor's viewer works because it reads the device's profile list and picks from it instead of assuming.
When is the USB 2.0 warning in the error genuine?
When the kernel log for your serial number shows `new high-speed USB device` after a replug. A failed SuperSpeed handshake — a marginal cable, a hub port that drops it, a connector not fully seated — silently leaves the link at USB 2.0 speed. Fix that physically: reseat, shorten or reroute the cable, or move the camera to a controller port. If the log says SuperSpeed, the warning is boilerplate and the depth tuple is the problem.
Which depth format should I request: Y14, Y16 or REL?
Y16 is the safe default: 16 bits cover any range these sensors output, and each word maps to a distance your processing reads directly. Y14 carries 14-bit samples and suits pipelines that specifically call for it. The REL family the log also lists is device-specific; request it only where your integration already knows what those frames contain.
Can I get 640 × 576 by cropping or scaling another profile?
No. The profile list is fixed in the camera firmware, and the driver can only request tuples the device advertises. You can crop a 1280 × 800 frame to 640 × 576 downstream — that keeps your coordinate frame but cannot add depth detail the sensor never sampled. Request 1280 × 800 at 30 fps in Y16 and crop in your processing node.
Why did the color stream start while depth failed?
Each stream negotiates on its own. The color tuple, 1280 × 720 at 30 fps in MJPG, existed in the device's list, so it enabled normally; the depth tuple did not, and the driver aborted at the first failing stream with exit code 255. Fix depth, relaunch, then bring further streams such as IR online one at a time.