A depth camera node exits at launch with Invalid input, No matched video stream profile found! and, two lines later, prints the requested stream parameters followed by every profile the device does support. Nothing is broken. The camera is reporting which resolution, frame rate and format combinations exist on the link it enumerated on, and the configuration asked for one outside that set. The sections below decode the log, compute the bandwidth that decides the list, and end with the working profile for each link type.
What does no matched video stream profile mean?
It means the exact width, height, frame rate and format triple your configuration requested is not one of the profiles the camera advertised on this link — a lookup miss, not a hardware fault. The error line names the stream, the resolution, the frame rate and the format that found no match.
Every depth camera enumerates a fixed set of stream profiles at power-up: one list per stream (color, depth, IR), each entry a width by height, a frame rate and a pixel format. The driver's lookup is an exact match on all fields at once, so a single wrong field fails it. Twenty fps requested where the device lists ten returns nothing, and the driver exits rather than silently substituting a nearby profile.
The failing log names the request: OB_STREAM_COLOR at 640x400, 20 fps, OB_FORMAT_MJPG. It then hints that the device might be connected via USB 2.0 and prints an Available profiles block in which the 640x400 color rows show only 10 fps and 5 fps. The same lookup runs for depth; if your failure is there instead, the fix has the same shape — 3D camera no matched video stream profile: set a listed depth mode.
Why does the profile list change from one PC to another?
The advertised list is filtered by the link the camera enumerated on: on a USB 2.0 link, which carries about 40 MB/s of usable payload, the device drops every profile the link cannot carry, so the 20 and 30 fps rows disappear and 10 and 5 fps remain. Same camera, same launch file, different list.
The list is not fixed firmware text; the device filters it against the negotiated link at every power-up. Move the camera through a monitor dock, a hub without SuperSpeed, a passive extension or a single-board computer port wired for high speed only, and the link settles at 480 Mbps. The connector shape tells you nothing: USB 3-style plugs sit on ports whose wiring never reaches the SuperSpeed pins.
When a camera offers both USB and Ethernet, read the log line that names the transport that actually opened — the failing session logged its connection over Ethernet — and budget against that transport: about 115 MB/s usable on Gigabit Ethernet, about 40 MB/s on USB 2.0. The profile list is sized to match. The same filter produces the depth stream with no data on a USB 2.0 port, and USB cable length limits for 3D cameras decide how far a SuperSpeed link reaches.
How much bandwidth does a stream profile need?
Multiply width by height by bytes per pixel by frame rate, then compare with the link: an RGB888 color stream at 1280x800 and 30 fps needs 92.2 MB/s, more than double the roughly 40 MB/s a USB 2.0 link carries, so that profile is never advertised there.
The usable figures are the line rate minus protocol framing; the USB 2.0 ceiling works out near 42 MB/s, and 40 is the conservative planning number. Three cases decide the failure:
- Failed request — 640x400, 20 fps, MJPG. Raw equivalent: 640 × 400 × 3 B × 20 fps = 15.36 MB/s, about 1.5 MB/s at MJPG's typical 10:1 compression. One stream this small cannot overrun a 40 MB/s link, so the absence is not single-stream arithmetic: the device sizes the advertised set so everything opened together (color, depth, IR) fits with margin, and it withdrew the whole 20 fps row on the 480 Mbps link.
- Replacement — 640x400, 10 fps, three streams. Color 7.68 MB/s raw, about 0.8 as MJPG; depth 640 × 400 × 2 B × 10 fps = 5.12 MB/s; IR 640 × 400 × 1 B × 10 fps = 2.56 MB/s. Total 15.4 MB/s, about 40% of the link, and every triple appears in the enumerated list.
- Ceiling — 1280x800, 30 fps, RGB888. 1280 × 800 × 3 B × 30 fps = 92.2 MB/s, which no USB 2.0 link carries, so the row is absent by design.
Treat 10:1 as a planning figure for MJPG: default-quality compression lands between roughly 6:1 and 12:1 with scene content, and a stream that plans close to the link limit should be measured, not assumed.
How do you find the profiles your device actually supports?
Let the node fail once: the driver prints the complete enumerated list immediately after the error, one line per profile in the form width x height, fps, format, and any line on that list can be requested as it stands.
- Run the failing launch and capture the log to a file.
- From the error line, note the stream (color, depth or IR) and the requested width, height, frame rate and format.
- Find that stream's block under
Available profilesand filter it to your width and height. - Take the highest frame rate listed at that resolution in your preferred format; only 10 and 5 fps present is the signature of a USB 2.0 enumeration.
- Enter that exact triple into the launch configuration's resolution, frame rate and format parameters.
- Relaunch and confirm frames arrive; if the error returns, compare each field one by one, because a format typo fails the match even at the right resolution.
On the logged device, the 640x400 color rows offered 10 fps and 5 fps in MJPG, RGB888, BGR, BGRA and I420, which makes 640x400 at 10 fps MJPG the drop-in replacement for the failed request.
Which profile should you request on a USB 2.0 link?
Take the smallest resolution that still resolves your smallest feature, at the highest frame rate listed for it: on USB 2.0 that means 10 fps, and a full color, depth and IR set at 640x400 totals 15.4 MB/s against roughly 40 MB/s usable.
| Requested triple | Raw payload (MB/s) | On the 2.0 list? | Verdict |
|---|---|---|---|
| 640x400, 20 fps, MJPG (the failed request) | 15.4 (about 1.5 as MJPG) | No, 20 fps row withdrawn | Not requestable on this link |
| 640x400, 10 fps, MJPG | 7.7 (about 0.8) | Yes | Drop-in fix |
| 800x600, 10 fps, MJPG | 14.4 | Yes | More detail, still light |
| 1280x800, 10 fps, MJPG | 30.7 (about 3.1) | Yes | Full frame; budget depth beside it |
| 1280x800, 30 fps, RGB888 | 92.2 | No, physically over the link | Needs USB 3 or Gigabit Ethernet |
The decision per case: preview, presence detection or parcel-volume logging — take 640x400 at 10 fps MJPG and ship. Full-frame color with depth — 1280x800 MJPG color at about 3.1 MB/s, depth at 20.5 MB/s and IR at 10.2 MB/s total 33.8 MB/s, the heaviest set USB 2.0 carries with margin, so hold everything at 10 fps. A hard 20 or 30 fps requirement — do not fight the list; fix the link in the next section. And a 10 fps profile that delivers 7 is a different fault, because exposure length caps the frame rate before bandwidth does — see depth camera frame rate drops: exposure settings cap the FPS.
How do you get the full profile list back?
Enumerate on a link the host rates as SuperSpeed: a controller port that reports 5000 Mbps, a USB 3-rated cable within its length limit and no high-speed-only hub between camera and host. At roughly 400 MB/s usable, ten times USB 2.0, the withdrawn 20 and 30 fps rows return.
- Plug the camera directly into a host-controller port; front-panel ports and monitor docks are the usual 2.0 culprits.
- Replace the cable with a certified USB 3 cable; passive copper holds a few metres and longer runs need active or optical cable.
- On single-board computers, check the port wiring: boards commonly expose SuperSpeed on one port and high speed on the others despite identical connectors.
- Confirm the negotiated speed in the operating system before relaunching, so you change one variable at a time.
- Share bandwidth deliberately; a hub that repeats at high speed caps every camera behind it, as USB hub drops camera frame rate: budget the bandwidth first shows.
If the camera is a Gigabit Ethernet model, wire the Ethernet path and the arithmetic moves in your favour. About 115 MB/s usable carries the 92.2 MB/s full-resolution 30 fps color stream, but not alongside 30 fps depth at 61.4 MB/s and IR at 30.7 MB/s, which totals 184 MB/s. Take color as MJPG, about 9.2 MB/s, and the three-stream set lands near 101 MB/s inside the link; or run all three raw at 15 fps for 92.2 MB/s combined.
When is the error not a bandwidth problem?
Three other causes fail the identical lookup: a configured triple that no firmware version ever offered, a pixel format gated behind another setting, and a firmware-SDK generation mismatch. Each has a two-minute test, and none is fixed by changing cables.
- Impossible values. A 1920x1080 request on a 1280x800-max sensor, or 15 fps where the hardware only ever offered 30. Enumerate once on a known-good USB 3 port: the list printed there is the hardware's full set, and a triple absent there is absent everywhere.
- A gated format. Some SDKs keep the pixel format read-only until the scan type is set, and the lookup then fails on format alone; see 3D camera pixel format locked read-only: set the scan type first.
- A generation mismatch. Firmware and SDK from different generations can drop or rename profile rows; align them before concluding the sensor lacks the mode — see 3D camera header version mismatch: fix firmware and SDK alignment.
- A shared controller. A second camera on the same USB 2.0 controller passes enumeration and then starves both streams at runtime; the budget is the same — see multiple USB cameras on one host: bandwidth and power budget and depth and color stream timeouts: the USB bandwidth check.
How do you keep the error from returning on the next machine?
Pin the exact enumerated triple in the launch configuration, qualify the node on the production PC, cable and hub before rollout, and budget every stream you open at no more than 70% of the link's usable payload, which is 28 MB/s on USB 2.0 and 80 MB/s on Gigabit Ethernet.
- Configuration — copy width, height, frame rate and format from the enumerated log, never from a remembered bench setup.
- Deployment — run the node once on the target machine's actual port, cable and hub; a bench result on SuperSpeed does not transfer to a 2.0-only port.
- Startup — log the enumerated profile list at boot and fail fast naming the closest listed profile, so the next engineer sees the valid set without digging.
- Budget — add color, depth and IR payloads before adding a camera, and keep the total under 28 MB/s per USB 2.0 controller.
- Versions — keep firmware and SDK on one generation, and re-enumerate after every firmware update.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
If you are specifying hardware rather than fixing a link, start from the sensor type and its profile set: laser profilers for swept profiles, structured-light stereo for close-range surfaces, ToF for range. The camera finder filters the range by type and resolution. Projected structured-light cameras like the MV-DPS200P-02 cover close-range stereo work, and ToF sensing cameras such as the MV-DT01WMU serve range-based tasks.
- Type
- Stereo / structured light
- Type
- Depth / ToF camera
Laser profilers and stereo 3D cameras
170 models · from $699.00Run the checklist above before ordering anything: most of these failures close with one edited parameter and a relaunch. If the enumerated list and your frame-rate requirement cannot meet on the link you have, the 3D topic page collects the surrounding integration notes, and the contact page is the way to reach us with your log attached.
Questions
Can I force a profile that is not in the advertised list?
No. The lookup is an exact match and there is no override; the enumerated list is the authoritative set for the current link. Change the request or change the link: move to a SuperSpeed port, replace the cable, remove the high-speed-only hub, and the missing rows reappear. Hand-editing a close-enough resolution into the configuration fails the same lookup.
Does MJPG compression hurt measurement quality?
MJPG is lossy, typically near 10:1 at default quality, and block artifacts can distort fine edges in color images. The depth and IR streams carry raw depth and intensity data rather than JPEG, so compression only ever affects the color image. If the inspection reads color texture, the raw RGB888 profile at 640x400 and 10 fps costs 7.7 MB/s and still fits USB 2.0.
How do I check which USB speed the camera enumerated at?
On Linux, lsusb -t prints each port's speed, where 5000 means SuperSpeed and 480 means high speed. Most camera drivers also log the enumerated speed, or hint at USB 2.0 right after the profile error as this one does. Two agreeing readings settle the question in under a minute, before you touch the launch file.
Can two depth cameras share one USB 2.0 controller?
Arithmetically, two 640x400 sets at 10 fps total about 31 MB/s against USB 2.0's roughly 40 MB/s usable, so it fits on paper with little margin. In practice, enumeration also reserves endpoint resources per camera, and controllers vary; prefer one streaming camera per controller, or move the second camera to its own USB 3 port or Ethernet path.
Why does the driver exit instead of falling back to a lower profile?
Silent substitution would change resolution, frame rate or latency without telling the downstream nodes that calibrated their geometry and timing against the request. Exiting with the enumerated list in the log keeps the mismatch visible and hands you the exact valid triples. Treat the exit as the data: copy a listed line into the configuration and relaunch.