Starting a second rpicam-vid process resets H/V flips of an already-streaming OV5647 #360

Summary

On a Raspberry Pi 5 running Raspberry Pi OS (Debian 13/Trixie), starting a second, independent rpicam-vid process for an IMX477 changes the orientation of an already-running OV5647 stream by 180 degrees. The issue is reproducible when the first process uses --rotation 180; without that option, the visible orientation change does not occur.

The OV5647 V4L2 controls horizontal_flip and vertical_flip change from 1/1 to 0/0 exactly when the second camera process starts. The running OV5647 process is not restarted.

Environment

• Raspberry Pi 5 Model B
• OS: Debian GNU/Linux 13 (Trixie)
• Kernel: 6.18.50+rpt-rpi-2712
• Raspberry Pi libcamera: v0.7.2+rpt20260817
• rpicam-apps: v1.13.0 (build 63b1cf3361af-dirty)
• Session: X11 over xrdp
• Camera 0: OV5647, firmware path /base/axi/pcie@1000120000/rp1/i2c@88000/ov5647@36
• Camera 1: IMX477, firmware path /base/axi/pcie@1000120000/rp1/i2c@80000/imx477@1a

Steps to reproduce

1. Before starting any camera, query the OV5647 controls:

   v4l2-ctl -d /dev/v4l-subdev2 --get-ctrl=horizontal_flip,vertical_flip

   Observed output:

   horizontal_flip: 1
   vertical_flip: 1
   

2. Start the OV5647 with a 180-degree rotation:

   rpicam-vid --camera 0 --width 1920 --height 1080 --framerate 32 \
     --preview-backend qt -t 0 --preview 872,90,376,214 \
     --codec yuv420 --rotation 180

3. Query the controls again. They remain 1/1.

4. In a second terminal, start the IMX477 in a separate process:

   rpicam-vid --camera 1 --width 2028 --height 1520 --framerate 66 \
     --preview-backend qt -t 0 --preview 872,90,376,286 \
     --codec yuv420 --info-text "(%fps fps) focus %focus"

5. Query the OV5647 controls once more:

   v4l2-ctl -d /dev/v4l-subdev2 --get-ctrl=horizontal_flip,vertical_flip

   Observed output after the second process starts:

   horizontal_flip: 0
   vertical_flip: 0
   

   At the same time, the already-running OV5647 preview changes orientation by 180 degrees.

Expected behavior

Starting a separate camera process for another physical sensor should not alter the controls or image orientation of a camera that is already streaming in a different process.

Source-level investigation

In the Raspberry Pi libcamera source corresponding to the installed version, src/libcamera/sensor/camera_sensor_legacy.cpp, CameraSensorLegacy::init() deliberately clears V4L2_CID_HFLIP and V4L2_CID_VFLIP before enumerating media-bus formats. Its comment states that this is intended to ensure the native Bayer order is obtained. The return value of subdev_->setControls(&ctrls) is not checked.

Source for the installed-version tag:

• CameraSensorLegacy::init() in Raspberry Pi libcamera v0.7.2+rpt20260817

Starting another rpicam-vid process creates a new libcamera manager and enumerates the available camera sensors, including sensors that the new process will not select. The observed flip-control change is consistent with this initialisation code resetting the OV5647 controls while the first process is streaming.

The OV5647 kernel driver applies flip changes to the sensor while it is powered. Its inspected s_stream path does not grab the layout-altering flip controls during streaming:

• OV5647 driver, drivers/media/i2c/ov5647.c

For comparison, the inspected IMX477 streaming path explicitly grabs both flip controls while streaming:

• IMX477 driver, imx477_set_stream()

Potential fix direction

The sensor-enumeration path should obtain the sensor's native Bayer order without unexpectedly changing controls on a sensor that may already be in use by another process. Any approach that temporarily clears and restores flips should be evaluated carefully, since it could still disturb frames in a live stream. The OV5647 driver may additionally need to reject or prevent layout-altering flip changes while streaming, as defensive hardening.

The direct control-value transition (1/1 to 0/0) is reproduced on the reported system. The exact fix has not yet been implemented or tested; this report intentionally describes the observed behavior and source-level lead rather than claiming an unverified patch is complete.

Additional note

The failure is tied to --rotation 180: without this option on the first rpicam-vid process, starting the second process does not cause the visible 180-degree orientation change.