Camera flipping in the new camera-streamer build

Camera model

Raspicam v2

What is the problem?

Vertical flip check box in camera-streamer plugin page has no effect.

What did you already try to solve it?

Tried flipping it several different ways, and restarting in between, all with no effect.

Have you tried running in safe mode?

No seems like wouldn't help this issue, the stream works fine, i just have my camera mounted upside down, so need the image to be flippable, likely both ways.

Did running in safe mode solve the problem?


Systeminfo Bundle

dont think it will help or needed at this point. I think i just need to uinderstand how to add the options to the libcamera config file.

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Running Pi 4B 8GB, latest octopi and octoprint, camera-streamer build. Have one Raspicam v2, and one Microsoft webcam. I have Charlie's camera-streamer plugin installed, and i have classic webcam enabled, to get the Microsoft cam to work. (Maybe i am doing this wrong, but it works.)

What does the output of the option endpoint show?


Among the items reported there should be the means to flip the image.

No options passed.

Set: /option?name=value

CAMERA Properties:

  • property: SensorSensitivity (00000009, type=5): 1.000000
  • property: ScalerCropMaximum (00000008, type=7): (0, 0)/3280x2464
  • property: ColorFilterArrangement (0000000a, type=3): 0
  • property: PixelArrayActiveAreas (00000007, type=7): [ (8, 8)/3280x2464 ]
  • property: PixelArraySize (00000005, type=8): 3280x2464
  • property: Rotation (00000002, type=3): 180
  • property: Location (00000001, type=3): 2
  • property: UnitCellSize (00000004, type=8): 1120x1120
  • property: Model (00000003, type=6): imx219

CAMERA Options:

  • available option: AeConstraintMode (00000004, type=3): [0..3]
  • available option: Saturation (00000011, type=5): [0.000000..32.000000]
  • available option: AeExposureMode (00000005, type=3): [0..3]
  • available option: ColourCorrectionMatrix (00000015, type=5): [-16.000000..16.000000]
  • available option: AwbEnable (0000000c, type=1): [false..true]
  • available option: AeEnable (00000001, type=1): [false..true]
  • available option: AnalogueGain (00000008, type=5): [1.000000..10.666667]
  • available option: ExposureTime (00000007, type=3): [75..11766829]
  • available option: ScalerCrop (00000016, type=7): [(0, 0)/64x64..(0, 0)/3280x2464]
  • available option: AeMeteringMode (00000003, type=3): [0..3]
  • available option: NoiseReductionMode (00000027, type=3): [0..4]
  • available option: ColourGains (0000000f, type=5): [0.000000..32.000000]
  • available option: ExposureValue (00000006, type=5): [-8.000000..8.000000]
  • available option: FrameDurationLimits (00000019, type=4): [47183..11767556]
  • available option: Brightness (00000009, type=5): [-1.000000..1.000000]
  • available option: Sharpness (00000013, type=5): [0.000000..16.000000]
  • available option: Contrast (0000000a, type=5): [0.000000..32.000000]
  • available option: AwbMode (0000000d, type=3): [0..7]


  • available option: horizontalflip (00980914, type=2): [0..1]
  • available option: verticalflip (00980915, type=2): [0..1]


  • available option: compressionquality (009d0903, type=1): [1..100]

STREAM Options:

  • available option: compressionquality (009d0903, type=1): [1..100]

VIDEO Options:

  • available option: videobframes (009909ca, type=1): [0..0]
  • available option: videogopsize (009909cb, type=1): [0..2147483647]
  • available option: videobitratemode (009909ce, type=3): [0..1]
    0: Variable Bitrate
    1: Constant Bitrate
  • available option: videobitrate (009909cf, type=1): [25000..25000000]
  • available option: sequenceheadermode (009909d8, type=3): [0..1]
    0: Separate Buffer
    1: Joined With 1st Frame
  • available option: repeatsequenceheader (009909e2, type=2): [0..1]
  • available option: forcekeyframe (009909e5, type=4): button
  • available option: h264minimumqpvalue (00990a61, type=1): [0..51]
  • available option: h264maximumqpvalue (00990a62, type=1): [0..51]
  • available option: h264iframeperiod (00990a66, type=1): [0..2147483647]
  • available option: h264level (00990a67, type=3): [0..15]
    0: 1
    1: 1b
    2: 1.1
    3: 1.2
    4: 1.3
    5: 2
    6: 2.1
    7: 2.2
    8: 3
    9: 3.1
    10: 3.2
    11: 4
    12: 4.1
    13: 4.2
    14: 5
    15: 5.1
  • available option: h264profile (00990a6b, type=3): [0..4]
    0: Baseline
    1: Constrained Baseline
    2: Main
    4: High

How do I change it?

Here is a pic of my libcamera.conf

What i dont know is how to format the "option" within to do the flips.

Don't have a similar camera chip with which to test this, but the return from your option endpoint suggests that flipping the image is controlled by the RESCALLER:STREAM Options. If this is true, using the guidelines for building libcamera.conf options from the camera-streamer configuration guide, I'd try the following two options:

OPTIONS='--camera-rescaller:stream.options="horizontalflip=1" --camera-rescaller:stream.options="verticalflip=1"'

The webcam endpoint itself ( http://octopi.local/webcam) is a nice one-stop-shop for testing all the various endpoints provided by the camera-streamer stack outside the confines of Octoprint.

Let us know how you fare.

Ha got a print running right now, i'll try once its done and post back.

No joy!

Tried all the variations shown here within my libcamera.conf, tried them all, and various combos of all. I separated your suggestions into 2 separate lines to try them independently, but none of these worked. When i try your suggestions, it breaks the stream all together, so the file definitely is affecting the stream, when i use the other options i built in there, the stream is live, but still upside down.

Frustrating, i was sure i was gonna be able to flip within 'software', so went ahead and built my mount and everything first, and here i am apparently not able to flip, gotta love it!!

I did try one other 'option' in the config;
OPTIONS='--camera-properties="Rotation=180"', no love here either.

After reading up on this a but, it seams that rotating 180 would be my idea situation here, but at this point i will take it just flipped vertical if possible, or both if possible, obviously both means the same thing as rotate 180, so either way works for me, but i guess i would prefer to get the rotate to work if possible. Thanks for your suggestions thusfar.

tried one more line, from foosel's original post regarding camera-streamer build:
Camera-streamer configuration on the new camera stack for OctoPi - Get Help / Guides - OctoPrint Community Forum
Under the section starting;

"Additionally, any of camera-streamer 's command line parameters can be provided as well:"

There is a suggestion for exactly this, i wrote it as;
OPTIONS='--camera-hflip=1 --camera-vflip=1"', this actually broke the stream as well.

Also should mention, i am only changing one thing at a time, and restarting with every change.

Does anyone even know if this camera can be flipped, in Foosel's post he mentions that some cannot. It's a standard raspicam V2. Kind of can be confirmed by the reported resolution on the options page.

Probably irrelevant, but i went to classic webcam settings, and checked flip there, and all the flip functions there work fine on my USB Microsoft webcam.

You don't need the 'Camera Streamer Control' plugin to use the new camera stack - and it should be noted the plugin is not finished yet.

Please test OctoPrint's flip feature just with the Classic Webcam plugin, the default as it is setup out of the box. If the flip works there, then it's probably just a bug with the new plugin that I haven't quite finished yet.

I will try this, however it's with more than just the plugin. Even when i change the settings in the libcamera.conf file, those changes don't take affect either.

That's why I suggested testing your changes from the /webcam endpoint links as a way of testing just the camera-streamer outside of Octoprint. Will help isolate the issue.

Still think you're going to be able to flip in software. I had one nagging thought about my recommendation to try RESCALLER:STREAM Options as a means to flip the image & that regards whether the ":" character requires any special handling when used in this way. The fact that those two options break the stream rather than have no effect makes me wonder more. None of the documentation I've read indicates that special handling is necessary & none of the cameras I have use any colon-seperated options so I'm unable to test it. I think it's time to summon the expertise of @ayufan, the camera-streamer author for clarification on that one.

Also surprised that the rotation property didn't work. Did you try any other values than 180 (which appears to be your default, making "0" the correct value)?

Yes, i tried several rotate values. And i noticed the default as well and set to 0.

Also when i tried your suggestions, i also noticed the period you placed, and noticed it used a dash in the default AF option, so i tried it with dashes in place of the periods, and that broke stream as well. I only had a couple minutes to answer here, I'll have to dable more later.

So it does indeed work through the classic webcam tab. Now basically i have both set to raspicam, and the Camera streamer tab show upside down;

And the classic webcam tab is flipped both ways;

Well seems to have boiled it down to the plugin. I will go ahead and mess with the options under the libcamera.conf under the classic webcam setup to see if those function actually do work.

Charlie anything you want me to do to report the bug, or do you already got it? I know its not complete, but mostly it works a treat, so thank you for it.

EDIT: I should have mention here that both flip checkboxes are checked on both settings tabs for both 'plugins'

If you browse to the /webrtc endpoint (http://octopi.local/webcam/webrtc) is the image displayed correctly (i.e. NOT in need of flipping)? The /webrtc endpoint is what Charlie is using in his camera-streamer plugin & I would think they display the same image. If that's the case, it would seem to point to an issue in the camera-streamer config.

Its is still upside down, however as i have it at the moment, none of the settings in the libcamera.conf are set, all are commented out. I will try when i can..

I only mentioned it because if we're unable to flip the image through configuration of the camera-streamer itself, I wouldn't hold out much hope of the plugin being able to accomplish it at this point.

Yep, im with ya, just right in the middle of a 2 day print, so once its done i will play some more. (Need to restart)