FFMPEG: MJPEG output buffer size mismatch

If you see repeated groups of messages like this:

FFMPEG: MJPEG output buffer size mismatch: 460800 (614400 expected)
2D processing operation fault
[ERROR] [1680887653.104109599]: Video4linux: frame grabber failed

it means that the color representation obtained from the MJPEG decoder does not match the representation configured in the configuration file. Try to change color_format parameter to another value. Then try to check if the configured frame size (image_width and image_height parameters) is actually supported by your camera querying /<node_name>/supported_formats service.

Determining correct pixel_format value for the device

If the output of the node is images of the correct size but the pixel format is literally mismatching the spec, like this:

try to use the following command:

v4l2-ctl --list-formats-ext --device=/dev/video0 | grep -e '^[[:space:]]*\[[0-9]*\]'

to have the list of available pixel formats and encodings, then select the proper format according to Pixel formats/encodings reference. The example output of this command for Logitech HD Pro Webcam C920 look like:

        [0]: 'YUYV' (YUYV 4:2:2)
        [1]: 'H264' (H.264, compressed)
        [2]: 'MJPG' (Motion-JPEG, compressed)

Distinguish between several identical USB devices

This case usually happens when several sensors (not always they are identical themselves) are connected to the same machine via identical USB-to-serial adaptors. Linux kernel does not have an ID persistence policy when the USB devices are enumerated during the boot, so the referral paths like /dev/ttyUSB0, and /dev/ttyUSB1 may easily change on the next boot when the identical device is connected to the same machine on the different USB port, despite the physical ports themselves are never changed.

To distinguish between such devices there are several ways to do. The most convenient way is to find a detailed description of the USB connection the device has through udevadm:

lsusb
udevadm info -a -n /dev/<DEVICE> | grep -e '{serial}'

The output will include a list of vendor IDs, product IDs and the serial numbers assigned to the device. Repeating this for all the devices connected to the machine, the different serial numbers would be revealed. Then the udev rules list could be created as something like this:

SUBSYSTEM=="tty", ATTRS{idVendor}=="<VendorID>", ATTRS{idProduct}=="<ProductID>", ATTRS{serial}=="<SerialNumber>", SYMLINK+="device_name"

This will create the dedicated virtual file with the name /dev/device_name persistent for the device with the mentioned SerialNumber. However, some cheap devices (especially, USB-RS232 adaptors) do not have identical serial numbers, so this approach is not always usable.

The second approach is to examine the USB bus ID assigned to the device:

lsusb -tvv

This will show the tree of USB bus connections with paths assigned in /dev/bus and /sys/bus namespaces. Then it is possible to access the device directly by the listed path.

The third approach is to examine the driver subsystem name to distinguish the devices by a unique name. To do that, examine the /dev directory for subdirectories created by the driver, like, for example, serial/ for TTY devices, or v4l/ for web cameras. Then enter the subdirectory to access the device by its persistent ID, like this:

/dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_919E375F-video-index0

Video4linux: frame mapping timeout (11)

This error is emitted when the camera does not respond on the USB port for 5 seconds or more being polled by the node. It may happen with some old camera chipsets incompatible with the given USB hub controller. In this case, it is needed to use a different controller or to check the motherboard for possible USB bridge malfunction. In the simplest case even reconnecting the camera to a different USB port may work.