Unknown pixel format: diagnose missing depth streams

A color preview can look healthy while depth and infrared acquisition remain unavailable. For an integration engineer, that partial success can send troubleshooting toward cables before the software stack has been checked. An unknown pixel format warning calls for a narrower first test: determine which stream and software layer cannot describe the format. You can then separate compatibility problems from transport limits without changing several variables together.

Start with the stage that fails

Color acquisition proves that one acquisition path works, not that every interface, format or processing component is supported. A sensor may expose several interfaces, while an SDK may generate depth from underlying image streams.

Prioritize the following checks when formats are missing before acquisition starts. This is a diagnostic order, not a universal ranking of failure rates.

A warning alone does not establish a fatal failure. Record whether the affected stream actually disappears, refuses to start or produces unusable data.

For devices that disappear entirely or fail unpredictably, use the broader intermittent camera acquisition troubleshooting guide. Here, keep attention on repeatable differences between working and missing streams.

Capture a reproducible compatibility record

Before updating anything, save the exact configuration. A distribution name alone is insufficient because kernel packages, architecture and SDK builds can differ.

Record:

• Sensor model and hardware revision, where available.
• Firmware revision reported by the manufacturer's supported utility.
• Operating-system release, running kernel release and processor architecture.
• SDK release, application build and libraries loaded at runtime.
• Driver or backend selected for each interface.
• Requested stream types, formats, dimensions and frame rates.
• Whether the error appears during connection, enumeration, configuration or acquisition.

On a Linux host, these read-only commands identify the running kernel and architecture:

uname -r
uname -m

For USB-connected equipment, the following provides a topology and negotiated-speed view:

lsusb -t

Do not treat this topology report as proof of sustainable throughput. It describes the connection, not the complete acquisition workload.

Architecture belongs in the record even when an application starts successfully. Optional processing libraries or plugins may have different requirements. The ARM64 acquisition compatibility checks explain how to separate processor support from successful device discovery.

Save the first relevant warning and the events immediately around it. Repeated warning lines are less useful than knowing which operation first triggered them.

Enumerate each stream through the correct interface

First establish the manufacturer's intended acquisition path. Some equipment uses operating-system video interfaces; other equipment requires a dedicated SDK backend. Not every depth stream should appear as an ordinary video device.

For an installation documented to use Video4Linux interfaces, these read-only queries can help:

v4l2-ctl --list-devices
v4l2-ctl --device=/dev/video0 --list-formats-ext

The device path is an example. Match each actual node to its interface before interpreting the output, and repeat the query for relevant capture nodes. Node numbering can change after reconnection.

Build a stream inventory with one row for color, depth and each infrared stream the manufacturer documents. Record the formats advertised by the SDK and, where applicable, by the operating system.

Then compare three states:

1. Advertised: Does the intended interface list the requested format and operating mode?
2. Configurable: Does selecting that exact mode succeed?
3. Delivering: Do frames arrive with the expected payload layout and timestamps?

These are different tests. Successful enumeration does not prove acquisition, and successful acquisition does not prove correct interpretation.

A four-character format identifier or hexadecimal code identifies a format convention. It does not, by itself, establish depth units, calibration, packing or invalid-value semantics. Obtain those definitions from the manufacturer's documentation.

Verify the active driver, not just the installed file

A successful installer or build does not prove that the intended driver is running. An older module may remain loaded, another package may supply the selected module, or the application may use a different backend entirely.

For a documented UVC acquisition path, these commands provide useful starting evidence:

modinfo -n uvcvideo
modinfo -F vermagic uvcvideo
lsmod

The first command reports the module file selected by the current module lookup configuration. It does not prove that this file supplied the module already loaded in memory. Likewise, a module appearing in lsmod does not establish which camera interface is bound to it.

Use the operating system's device-binding information and the manufacturer's diagnostics to connect the interface, active driver and installed package. Where available, compare loaded-module version information against the package records. A built-in driver requires different evidence from a loadable module.

Follow the documented reboot or reload procedure after installing a supported driver package. Stop acquisition first and schedule downtime when the change affects production equipment or other connected devices.

If the manufacturer's SDK uses a direct USB backend, changing the video driver may not address the failure. Confirm the backend before modifying the host.

Restore a supported software combination

Kernel, firmware, driver and SDK releases form a compatibility set. A newer release of one component is not automatically compatible with every older component.

Request a manufacturer-supported combination for the exact sensor revision. It should identify the operating-system release, kernel requirements, firmware range, SDK release and any required driver packages.

Obtain software, firmware and manuals only from the manufacturer or its authorized distributors. Use the documented firmware query and update procedure; do not infer a revision from purchase date or enclosure markings.

Test the supported combination on a controlled host image when practical. Preserve the original configuration and change one component at a time unless the documented installation requires a coordinated update. Some firmware changes cannot be reversed, so confirm recovery options beforehand.

Use the machine vision software upgrade validation checklist to organize rollback planning and acceptance evidence. For this fault, the key comparison is whether the required formats become visible and deliver valid frames.

Do not treat a generic video viewer as the final authority. It may support color while lacking the sensor-specific handling needed for depth. Conversely, a successful manufacturer viewer shifts attention toward your application's configuration, linked libraries and selected backend.

Investigate bandwidth after format support

Bandwidth becomes a stronger hypothesis when streams enumerate correctly and work independently, but fail together. It is a weaker explanation for a format that is rejected before payload transfer begins.

For uncompressed image data, estimate payload rate with:

Use stored bytes per pixel, not just nominal sensor bit depth. Packing, row padding, metadata and compression can change the actual payload.

Consider a hypothetical workload, unrelated to the catalog products below:

The sum is 119,808,000 bytes/s, or approximately 119.8 MB/s using decimal units. This is image payload only, excluding transport overhead and additional data.

Also distinguish application output from data transmitted by the sensor. An SDK might produce a color image after conversion, so its output buffer size may not equal the USB payload.

Test the documented connection arrangement, then add streams individually. Reduce frame rate while retaining a supported format. If failure depends on aggregate load, examine shared host-controller traffic, cabling, power, processing time and buffer handling. If enumeration fails identically at every supported rate, return to compatibility evidence.

Verify recovery with data, not just a preview

A practical acceptance test should exercise the full required stream set and the application's real processing path.

1. Enumerate the documented modes and save the results.
2. Start each required stream independently using the supported sample application.
3. Inspect payload dimensions, format identifiers, timestamps and frame counters where available.
4. Run the required simultaneous configuration and check for gaps or acquisition errors.
5. Repeat using your application with the same requested settings.
6. Close and reopen acquisition, then test a documented power-cycle sequence.

As an initial bench check, capture 300 frames from each required stream. At 30 frames/s, that represents 10 seconds of acquisition per stream. This can expose immediate faults but does not replace a production-length endurance test.

For depth, verify documented invalid-value handling and units against a stationary target at known positions. A nonzero buffer is not proof of correct distance measurement. A black preview can also result from display scaling rather than missing acquisition.

Acceptance should require usable data from every required stream, not simply the disappearance of a warning.

Request compatibility evidence before selecting a replacement

The 3D sensors category includes different sensing methods and acquisition architectures. Use the camera finder to shortlist the inspection technology, then request integration evidence for the exact candidate.

The MV-DPS200P-02 is listed as a projected structured-light camera.

The MV-DLS300P-04 is listed as a laser galvanometer stereo camera.

These catalog descriptions do not establish host-interface compatibility, raw infrared availability, pixel formats or operating-system support. Treat them as starting points for an application review, not confirmed replacements for another sensor.

Ask for a compatibility matrix and a representative acquisition demonstration. The evidence should show the required outputs operating together on the intended host software combination. If your algorithm needs raw infrared images, confirm that output explicitly; a device providing processed depth may not expose its internal images.

Keep a prevention checklist with the installation

Before releasing the system or ordering replacement hardware, check that:

• Required streams and simultaneous operating modes are documented.
• Enumeration results are saved for the accepted configuration.
• Active driver or backend evidence matches the supported installation.
• Firmware and SDK versions are recorded together.
• The application loads the intended runtime libraries.
• Aggregate payload and host processing have been tested under load.
• Restart and power-cycle tests reproduce the accepted behavior.
• Software changes have a documented recovery plan.

Retest the required stream set after operating-system, kernel, SDK or firmware changes. Color-only regression testing cannot protect a depth-dependent application.

For the next step, send the compatibility record, per-stream enumeration and first failing operation through application support. For a new selection, include the required outputs and target host environment so the review addresses acquisition compatibility as well as sensing performance.