BBAI-64 CSI camera video0 is not a capture device: pick the right node

You wire the CSI-2 camera to the BBAI-64, run the gst-launch pipeline every quick-start prints, and GStreamer stalls at PAUSED with Device '/dev/video0' is not a capture device. The camera is fine and the ribbon cable is seated. On this board the SoC's own video blocks — display, encoder, ISP, capture — each claim the next free /dev/video number as their drivers probe at boot, and the display block gets there first. video0 belongs to hardware that can never deliver a frame from your sensor. This guide gives you the three-command workflow to enumerate every video node, find the one wired to your sensor through the media controller, verify its capture capability, and point v4l2src at it. It is written for engineers bringing up board-level cameras on embedded Linux, and the same workflow applies on any media-controller SoC.

The fix in one pass

The failure is a wrong device path, and you can correct it in about a minute on the bench:

1. Run v4l2-ctl --list-devices. It groups every /dev/video*, /dev/v4l-subdev* and /dev/media* node under the driver that registered it.
2. For each candidate video node, run v4l2-ctl -d /dev/videoN --all. A usable capture node prints Video Capture in its device caps; an output or metadata node does not.
3. Run media-ctl -d /dev/media0 -p and find the entity named after your sensor. The link chain out of that entity ends at the video node you open.

Then substitute that node in the pipeline — v4l2src device=/dev/video2 in the worked example below — and set caps inside the format list the node prints. On the BBAI-64 the CSI capture node commonly sits at video2 or later, because the SoC's display and encoder drivers register before the camera path. If --list-devices shows no group for your sensor's driver at all, the camera never probed and no node choice can fix it: the sensor-probe checklist in media0 with no video0 device node: the sensor driver never probed is the next stop.

Why /dev/video0 is not your camera

V4L2 hands out device numbers in registration order, across the whole SoC, as each driver probes. Nothing reserves numbers per function: the display subsystem, the video encoders, the ISP, the CSI receiver and any USB webcam all take the next free minor in the order they come up. On the BBAI-64 that puts the low numbers on SoC-internal blocks and the camera path higher, commonly at video2 or beyond, and the exact split moves with the kernel build — which is why you enumerate instead of hardcoding a number.

Two more node families sit beside the video nodes. Each sensor registers as a V4L2 subdevice at /dev/v4l-subdevN, and each capture pipeline registers a media controller device at /dev/mediaN describing the graph: which entity feeds which pad, and ultimately which video node carries the frames.

The error text is exact. On the way to PAUSED, v4l2src queries the node's capabilities, and a node without capture capability — an output feeding the display, or a metadata collector — fails with Device '...' is not a capture device. The MESA-LOADER complaint about tidss_dri.so printed above it is the video sink failing to load a display driver; it is not the capture failure, and fixing the node usually leaves it untouched.

Likely causes, in order

Work down the table in this order. Causes 1 and 3 together account for nearly every no-video-from-the-CSI-camera report on media-controller boards, and cause 1 is the one the worked example fixes end to end.

Find the capture node step by step

1. v4l2-ctl --list-devices prints each node grouped by owning driver. Note the group whose name matches the CSI capture driver; ignore the display group.
2. For each node in the capture group, v4l2-ctl -d /dev/videoN --all prints the caps. The node you want lists Video Capture, with or without Multiplaned; nodes listing only Video Output or Metadata Capture are excluded, whatever their number.
3. v4l2-ctl -d /dev/videoN --list-formats-ext prints the pixel formats and frame sizes. The sensor's RAW formats appear here if this is the CSI node; NV12 appears only after the ISP stage.
4. media-ctl -d /dev/media0 -p prints the graph. Find the entity whose name carries the sensor part number and follow the links to the video node; media-ctl -d /dev/media0 -e '<entity name>' prints that entity's own device node.
5. A sysfs shortcut does the same survey faster: grep -H . /sys/class/video4linux/video*/name prints each node with the driver that owns it, and the line matching the capture driver marks your node.
6. Prove the node streams before touching GStreamer: v4l2-ctl -d /dev/video2 --stream-mmap --stream-count=1 --stream-to=/tmp/frame.raw writes one frame, and the file size should equal width × height × bytes per pixel for the selected format. The raw Bayer capture walkthrough runs the same one-frame test on a multi-camera rig.

None of this is board-specific. The same media-ctl then v4l2-ctl sequence — list drivers, check caps, print the graph, follow the sensor entity's links — is the standard bring-up flow for any CSI pipeline on a media-controller SoC, so the commands you learn here carry over to other boards unchanged.

Worked example: the failing gst-launch pipeline on a BBAI-64

Inputs. The pipeline, as run on the board: gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! videoconvert ! autovideosink. The failure, from the same run: Device '/dev/video0' is not a capture device. at PAUSED, plus a MESA-LOADER warning about tidss_dri.so. Tools: v4l-utils, so v4l2-ctl and media-ctl are installed. The node outputs below are illustrative shapes; the driver names and exact numbers on your build decide the mapping.

Rule. A node is your capture node only if it passes both checks: its caps include Video Capture, and the media graph links your sensor entity to it. Any node printing only Video Output or Metadata Capture is excluded regardless of its number.

Steps.

1. --list-devices reports six video nodes, video0 through video5, plus /dev/media0 and several subdevs. The display driver's group owns video0 and video1; the CSI capture driver's group owns video2.
2. --all on video0 prints Video Output — excluded. --all on video2 prints Video Capture Multiplaned, and --list-formats-ext lists the sensor's RAW format at 1920×1080, 30 fps.
3. media-ctl -p shows the sensor entity linked through the CSI receiver to video2. Both checks pass: video2 is the capture node.

Arithmetic. The NV12 caps promise 1920×1080 at 30 fps, and NV12 stores 12 bits per pixel, so 1.5 bytes per pixel:

That 746 Mbit/s is what NV12 at these caps consumes; a 1 Gbit/s link would run at three quarters of line rate before any protocol overhead, which is worth knowing if you pipe frames off-board later.

Result. Use v4l2src device=/dev/video2, request the RAW format the node lists instead of NV12, and route the SDK's ISP elements ahead of videoconvert and the sink. The pipeline then reaches PLAYING with caps matched to the format list.

Decision. On the BBAI-64, never open video0 blind: open the first node that passes both checks, commonly video2 or later on this board. If a node fails either check, move to the next candidate. The number is never the evidence; the capability line and the graph link are.

Point the pipeline at the right node

Two things change in the command: the device path, and the caps. The CSI node hands you sensor data, not ISP output, so a plain videoconvert cannot turn a packed RAW10 stream into NV12 — the supported route runs through the ISP elements that ship with the SoC vendor's GStreamer plugin set. The MIPI CSI-2 pipeline walkthrough follows the whole path from sensor pad to host memory, stage by stage.

The sensor's own controls do not live on the capture node. Exposure and gain sit on the sensor's subdev node, which is why a control list queried on the video node comes back empty — the v4l2-ctl list-ctrls guide shows how to find the node that carries them.

Two environment checks finish the bring-up. If the open fails with EACCES rather than a capability error, it is device permissions, not node choice: the Linux camera device permissions checklist covers the group membership checks. If acquisition runs inside a container, pass the video node, the media node and the subdev nodes together — media-ctl sees an empty graph when only the video node crosses the boundary, and the Docker V4L2 node guide lists the full set to hand through.

Prevent it on the next bring-up

The second recurring trap is at the pin level: when a boot-time peripheral claims pins, later opens fail with errno 16, EBUSY, which looks like a camera problem and is not. The BBAI-64 walkthrough for the errno 16 device-busy error traces one such case end to end.

When a USB3 board camera is the better choice

CSI bring-up buys the SoC's ISP and a small ribbon cable, but it costs a driver, a device tree and a media graph that must match the image. When the deliverable is a working camera this week, a USB3 board camera moves the driver burden to the module: it registers its own video node in its own --list-devices group, so there is no SoC graph to trace, and the same three checks — capability, formats, one test frame — close the job. Match the sensor to the inspection task rather than to the connector: global shutter for moving parts, a C-mount or M12 mount to fit your optics, a board outline that fits the housing.

The LS-BCM-0003 is a 3.1 MP USB3 board camera with a 1/1.8" IMX252 global-shutter sensor running 120 fps; the MV-CB060-10UM-B is a 6 MP mono bare-board USB3 camera with the same 1/1.8" sensor format.

Each registers on the host as its own V4L2 device, so the verification commands above work unchanged. Choosing between them starts with the sensor and the lens, not the bus: the board camera selection guide walks that match, and the camera finder filters the board-level range by mount, shutter and interface. If the module pairs the sensor with a USB3 bridge chip, check the pairing before you stream — the USB3 bridge matching guide covers what the link needs.

Checks before you order

• Sensor driver first. Confirm the sensor part number is in your SoC's supported-camera list before ordering a module; on a media-controller board the driver is the whole integration.
• Output format. A sensor that outputs RAW10 or RAW12 means the frame path runs through the SoC ISP; check the SDK lists ISP support for that format.
• Connector and lanes. Match the module's connector family and data-lane count to the board's CSI header, and confirm the module's power and enable wiring against the board's camera documentation.
• Image release. Have the SDK-matched image written and boot-tested before the module arrives, so a missing driver is never mistaken for a dead camera.
• Tools and test. Install v4l-utils and save the one-frame capture command as a script; it settles node questions in seconds.
• Fallback bus. If the schedule is tight, a USB3 board camera drops the media-graph work entirely, as covered above.

When the graph still shows no sensor after all of this, send your --list-devices and media-ctl -p output through the contact page and we will read it with you. To pick the camera side first, start at the camera configurator; the systems topic page collects the rest of the embedded capture guides.