Jump to content

OV5640 device tree overlay for OrangePi One H3

rreignier

By rreignier
in Orange Pi One

 Share

Recommended Posts

rreignier

rreignier

Posted
Posted

Hi!

 

Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One.

So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay.

 

But for now, it fails to compile with: 

$ sudo armbian-add-overlay sun8i-h3-csi.dts 
Compiling the overlay
Error: sun8i-h3-csi.dts:27.23-24 syntax error
FATAL ERROR: Unable to parse input tree
Error compiling the overlay

My current overlay looks like this: 

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target = <&pio>;
		__overlay__ {
			csi_mclk_pin: csi-mclk-pin {
				pins = "PE1";
				function = "csi";
			};
		};
	};

	fragment@1 {
		target = <&i2c2>;
		__overlay__ {
			status = "okay";

			ov5640: camera@3c {
				compatible = "ovti,ov5640";
				reg = <0x3c>;
				pinctrl-names = "default";
				pinctrl-0 = <&csi_mclk_pin>;
				clocks = <&ccu CLK_CSI_MCLK>;
				clock-names = "xclk";

				AVDD-supply = <&reg_aldo1>;
				DOVDD-supply = <&reg_dldo3>;
				DVDD-supply = <&reg_eldo3>;
				reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */
				powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */

				port {
					ov5640_ep: endpoint {
						remote-endpoint = <&csi_ep>;
						bus-width = <8>;
						data-shift = <2>; /* lines 9:2 are used */
						hsync-active = <1>; /* Active high */
						vsync-active = <0>; /* Active low */
						data-active = <1>;  /* Active high */
						pclk-sample = <1>;  /* Rising */
					};
				};
			};
		};
	};
	
	fragment@2 {
		target = <&csi>;
		__overlay__ {
			status = "okay";
			
			port {
				csi_ep: endpoint {
					remote-endpoint = <&ov5640_ep>;
					bus-width = <8>;
					hsync-active = <1>; /* Active high */
					vsync-active = <0>; /* Active low */
					data-active = <1>;  /* Active high */
					pclk-sample = <1>;  /* Rising */
				};
			};
		};
	};
};

So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;`

 

Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here.

 

But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line.

 

Could someone guide me to get my overlay right?

 

And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board?

 

Thank you.

1
Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted
14 hours ago, rreignier said:

So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;`

Right ! This is because CLK_CSI_MCLK is not define since it is not compiled from Main DT where there are kernel includes defining it.

In overlays, you need to use strictly numeric values, no defines are allowed ...

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted
5 minutes ago, martinayotte said:

Right ! This is because CLK_CSI_MCLK is not define since it is not compiled from Main DT where there are kernel includes defining it.

In overlays, you need to use strictly numeric values, no defines are allowed ...

 

Ok, I see. Thank you @martinayotte

 

From sun8i-h3-ccu.h I see: 

#define CLK_CSI_MCLK		107

So what syntax should I use to set it to 107? 

clocks = <&ccu 107>;
or
clocks = <107>;
or
clocks = "107";

Thank you

0
Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted
10 minutes ago, rreignier said:

So what syntax should I use to set it to 107?

Yes, like that : 

clocks = <&ccu 107>;

If it doesn't work, try to find the "phandle" of the "ccu" by decompiling the main DT, and write like (where N is the numeric value of the phandle found) : 

clocks = <N 107>;

 

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted

By replacing `CLK_CSI_MCLK`, `GPIO_ACTIVE_LOW` and `GPIO_ACTIVE_HIGH` constants by respectively `107`, `1` and `0` the device-tree overlay can be compiled.

 

But during the boot, I got: 

[   10.837084] i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   10.843681] ov5640 1-003c: ov5640_read_reg: error: reg=300a
[   10.849315] ov5640 1-003c: ov5640_check_chip_id: failed to read chip identifier

So I have disabled my overlay and load the sun8i-h3-i2c2 overlay instead.

With the command: 

i2cdetect -y 1

I got a lot of these errors in the serial console: 

[   40.470126] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   42.518174] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   44.566261] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   46.614294] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0

From this post I assumed that I could have a pull-up issue so I have created this overlay to enable the internal pull-up on the i2c-2 pins: 

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target = <&pio>;
		__overlay__ {
            i2c2_pins: i2c2-pins {
				pins = "PE12", "PE13";
				function = "i2c2";
				bias-pull-up;
			};
		};
	};

	fragment@1 {
		target = <&i2c2>;
		__overlay__ {
			pinctrl-0 = <&i2c2_pins>;
			status = "okay";
		};
	};
};

But now, I do not see the camera at the address 0x3c and if I let the i2cdetect continue, I get the "I2C bus locked" errors.

 

With the GC235 camera module, I detect something at the address 0x4c.

 

So, even if my OV5640 camera module is brand new, I am not sure if it is working.

 

Does anyone have an idea on how to test if my module is still functional?

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted

@olivluca Sorry, but I don't feel like writing a full kernel driver :unsure:

 

After some discussions with the vendor and some delivery delays because of the COVID-19, I have now received the OV5640 camera sensor board!

But with the overlay previously posted, there is not anything better :(

 

I have then crafted this simple overlay to enable the `i2c2` with pull-up: 

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
        target = <&pio>;
        __overlay__ {
            i2c2_pins: i2c2-pins {
                pins = "PE12", "PE13";
                function = "i2c2";
                bias-pull-up;
            };
        };
    };

    fragment@1 {
        target = <&i2c2>;
        __overlay__ {
            pinctrl-0 = <&i2c2_pins>;
            status = "okay";
        };
    };
};

I applied it with: 

$ sudo armbian-add-overlay i2c2-with-pullup.dts
$ sudo reboot

Once rebooted, I have checked the i2c device number. I am looking for address `1c2b400` according to the dtsi: 

$ ls -l /sys/class/i2c-adapter/
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 i2c-0 -> ../../devices/platform/soc/1ee0000.hdmi/i2c-0
lrwxrwxrwx 1 root root 0 Jan  1  1970 i2c-1 -> ../../devices/platform/soc/1c2b400.i2c/i2c-1

So let's check the detected devices on bus `1`: 

$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Nothing!

 

While with the GC2035 connected, I have: 

$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f
70: -- -- -- -- -- -- -- --

 

Does someone who owns an H3 based Orange Pi and the OV5640 camera module could try the above commands to see if the module is detected?

 

Thank you.

0
Link to comment
Share on other sites
mostly

mostly

Posted
Posted
On 5/29/2020 at 12:50 AM, rreignier said:

Does someone who owns an H3 based Orange Pi and the OV5640 camera module could try the above commands to see if the module is detected?

Was playing with it last October, exactly the same result. OV5640 now works only on kernel 3.x Somebody has to fix mainline driver(s). 

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted
10 hours ago, mostly said:

Somebody has to fix mainline driver(s). 

 

Actually. I cannot see the device on the i2c bus, so I don't think that the driver is to blame here. Or maybe i2c driver, but I don't think so.

Which kernel are you using to make use of the OV5640 so I could check that my camera works?

0
Link to comment
Share on other sites
mostly

mostly

Posted
Posted
On 6/3/2020 at 9:11 AM, rreignier said:

Which kernel are you using to make use of the OV5640 so I could check that my camera works?

3.4.113 (Armbian_5.46) 

fex:
[csi0]
vip_dev0_mname = "ov5640"



sunxi-pio -m "PG11<1><0><1><1>"

modprobe ov5640

modprobe vfe_v4l2

 

On 6/3/2020 at 9:11 AM, rreignier said:

I don't think that the driver is to blame here. Or maybe i2c driver, but I don't think so

Yup maybe it's just needed to set somewhere a bit enabling that i2c lane, or something else H3/board-specific. I was thinking about connecting oscilloscope to csi to see if there is any activity at all.

0
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted

I have ov5640 I am trying to get to work on 5.4.43 and then found this thread.  It seems like it doesn't work yet, but the reason is known?

I have a CSI breakout board on my pi and I can test pins for communication if needed.  But I can't even get a /dev/video device registered at this point.

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted
On 6/13/2020 at 3:46 PM, jgauthier said:

I have ov5640 I am trying to get to work on 5.4.43 and then found this thread.  It seems like it doesn't work yet, but the reason is known?

I have a CSI breakout board on my pi and I can test pins for communication if needed.  But I can't even get a /dev/video device registered at this point.

 

Before talking to /dev/video0, I would like to see some activity on the i2c side, so just with i2cdetect.

But it did not work for me. If you have another camera module, maybe you could try.

0
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted
13 hours ago, rreignier said:

 

Before talking to /dev/video0, I would like to see some activity on the i2c side, so just with i2cdetect.

But it did not work for me. If you have another camera module, maybe you could try.

 

Even with a working camera on 3.4.113 there's not any indication something is happening on i2c:

  

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@drone:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

 

 

 

 

1
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted

Gotcha.  The way I understand it, sun4i_csi should create /dev/video.  It doesn't.

Doing some kernel level debugging I discovered that the probe() function is never called when the module loads.

I learned that probe() is only called if there is hardware to match the name of the device.

https://stackoverflow.com/questions/16259580/probe-in-linux-devfreq-driver-not-being-called

 

Quote

In order for the probe function to be called, you must add a device from a machine file or via the device tree. This is typically done with platform_device_register() or platform_add_devices() in machine files. Alternatively, of_platform_populate() is used for the device tree model, but code does not use this directly.

 

Furthermore, I found a thread from past January from the author of the OV5640 code that discusses it not working in 5. kernels yet.

 

https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal/issues/17

 

I have no idea what it takes, but if he says it's not ready for the mainline, I am taking that as the authoritative source.

 

0
Link to comment
Share on other sites
@lex

@lex

Posted
Posted

OV5640 is ready and works in mainline kernel.

/dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking).

 

You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances.

1
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted
1 minute ago, @lex said:

OV5640 is ready and works in mainline kernel.

/dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking).

 

You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances.

 

Okay, thanks. I'm using a banana Pi M2-Zero.  the CSI port is actually inverted from normal.  I don't know if there is any correlation there.   So, are you saying that the NanoPi Neo Air works? If so, I will compare the schematics.

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted
36 minutes ago, jgauthier said:

Furthermore, I found a thread from past January from the author of the OV5640 code that discusses it not working in 5. kernels yet.

 

https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal/issues/17

 

I have no idea what it takes, but if he says it's not ready for the mainline, I am taking that as the authoritative source.

 

 

Interesting, indeed. But avafinger does not appear to be a contributor of the mainline driver : here.

I think he has worked the old one, for kernel 3.4.

 

Interestingly, the PineTab device tree uses an ov5640 here. On a A64 that uses the same sun6i_csi driver that the H3.

 

So I am sure there is still hope.

 

Quote

Doing some kernel level debugging I discovered that the probe() function is never called when the module loads.

 

What device tree are you using?

Are you using the device tree overlay I have posted above?

0
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted
19 minutes ago, rreignier said:

 

Interesting, indeed. But avafinger does not appear to be a contributor of the mainline driver : here.

I think he has worked the old one, for kernel 3.4.

 

Interestingly, the PineTab device tree uses an ov5640 here. On a A64 that uses the same sun6i_csi driver that the H3.

 

So I am sure there is still hope.

 

 

What device tree are you using?

Are you using the device tree overlay I have posted above?

 

Yes, i did try that.    You're on an OrangePi?  I'd have to compare that to the bove hardware and my banana as well.

0
Link to comment
Share on other sites
rreignier

rreignier

Posted
  • Author
Posted
3 minutes ago, jgauthier said:

You're on an OrangePi?

Yes, I have been trying on an Orange Pi One. I also have Orange Pi PC Plus and Orange Pi Lite2 (H6) on which I could also try.

But since I have received the ov5640 board, I did not try the driver, only the i2cdetect.

0
Link to comment
Share on other sites
jgauthier

jgauthier

Posted
Posted

Well, I tried the i2c overlay, along with implementing the dts posted above.  This is an H2+ but is pin-for-pin identical to the H3. I verified the schematics are the same between the two board.

 

I still have nothing when i load the ov5640 driver.   I'm not sure what else to try.

0
Link to comment
Share on other sites
gsumner

gsumner

Posted
Posted

@rreignier, I've just gotten an ov5640 going with my Orange Pi Zero Plus2 at 640x480 on mainline, Buster 5.4.43 - maybe the following applies to you too.

I had bus locked errors until I powered up the camera, on the Zero it was PA8 and PA7 for autofocus (which I turned on just in case). Looking at the One schematic (https://linux-sunxi.org/images/7/7e/ORANGE_PI-ONE-V1_1.pdf) it looks like it's PA17, PG11 and PG13 for autofocus.

After that I still wasn't getting an answer on i2c2, the ov5640 datasheet (https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf) says XVCLK (CLK_CSI_MCLK in the device tree) needs to be running before accessing registers. I couldn't see an a/c voltage on the csi-mclk pin so figured that was the issue. The fix for me was connecting the clock parent in the device tree. I'll post my dtb changes. I'm not sure this is all correct, but it lets me open the camera without having to mess with any gpios etc after boot.

Inside the "model = "OrangePi Zero Plus2";" braces: 

reg_vdd_1v5_csi: vdd-1v5-csi {
	compatible = "regulator-fixed";
	regulator-name = "vdd1v5-csi";
	regulator-min-microvolt = <1500000>;
	regulator-max-microvolt = <1500000>;
	gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
	enable-active-high;
	regulator-boot-on;
	regulator-always-on;
};

reg_vcc_csi: vcc-csi {
	compatible = "regulator-fixed";
	regulator-name = "vcc-csi";
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
	enable-active-high;
	regulator-boot-on;
	regulator-always-on;
};

reg_vcc_af_csi: vcc-af-csi {
	compatible = "regulator-fixed";
	regulator-name = "vcc-af-csi";
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	gpio = <&pio 0 7 GPIO_ACTIVE_HIGH>; /* PA7 */
	enable-active-high;
	regulator-boot-on;
	regulator-always-on;
};

At top level: 

&ccu {
	/* Use a stable clock source with known fixed rate for MCLK */
	assigned-clocks = <&ccu CLK_CSI_MCLK>;
	assigned-clock-parents = <&osc24M>;
	assigned-clock-rates = <24000000>;
};

&csi {
	status = "okay";

	port {
		#address-cells = <1>;
		#size-cells = <0>;
		
		/* Parallel bus endpoint */
		csi_ep: endpoint {
			remote-endpoint = <&ov5640_ep>;
			bus-width = <8>;
			hsync-active = <1>; /* Active high */
			vsync-active = <0>; /* Active low */
			data-active = <1>;  /* Active high */
			pclk-sample = <1>;  /* Rising */
		};
	};
};

&i2c2_pins {
	bias-pull-up;
};

&i2c2 {
	status = "okay";
	
	ov5640: camera@3c {
		compatible = "ovti,ov5640";
		reg = <0x3c>;
		pinctrl-names = "default";
		pinctrl-0 = <&csi_mclk_pin>;
		clocks = <&ccu CLK_CSI_MCLK>;
		clock-names = "xclk";

		AVDD-supply = <&reg_vcc_af_csi>;
		DOVDD-supply = <&reg_vdd_1v5_csi>;
		DVDD-supply = <&reg_vcc_csi>;
		reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */
		powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */

		port {
			ov5640_ep: endpoint {
				remote-endpoint = <&csi_ep>;
				bus-width = <8>;
				data-shift = <2>; /* lines 9:2 are used */
				hsync-active = <1>; /* Active high */
				vsync-active = <0>; /* Active low */
				data-active = <1>;  /* Active high */
				pclk-sample = <1>;  /* Rising */
			};
		};
	};
};

I also added csi_mclk_pin to sunxi-h3-h5.dtsi (after "csi_pins: csi-pins {") but I suspect you could reference the pin directly in the dtb and skip this: 

/omit-if-no-ref/
csi_mclk_pin: csi-mclk-pin {
	pins = "PE1";
	function = "csi";
};

I'm currently having issues with only being able to use 640x480, vlc reporting incorrect frame size and crashes when streaming from motion, but I don't want to derail your thread unless you have the same issues.

Hope that helps,

Greg

2
Link to comment
Share on other sites
@lex

@lex

Posted
Posted

Ahh, Good catch.

DOVDD first, then AVDD, followed by DVDD.

 

In the case of M2Z: 

gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */

 

sensor is at least recognized with i2c bit bang. 

ls /dev/video
video0  video1  
 v4l2-ctl --list-devices
sun6i-csi (platform:camera):
    /dev/video1

cedrus (platform:cedrus):
    /dev/video0


  

v4l2-ctl -d 1 --list-formats --list-ctrls

User Controls

                       contrast 0x00980901 (int)    : min=0 max=255 step=1 default=0 value=0 flags=slider
                     saturation 0x00980902 (int)    : min=0 max=255 step=1 default=64 value=64 flags=slider
                            hue 0x00980903 (int)    : min=0 max=359 step=1 default=0 value=0 flags=slider
        white_balance_automatic 0x0098090c (bool)   : default=1 value=1 flags=update
                    red_balance 0x0098090e (int)    : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider
                   blue_balance 0x0098090f (int)    : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider
                       exposure 0x00980911 (int)    : min=0 max=65535 step=1 default=0 value=885 flags=inactive, volatile
                 gain_automatic 0x00980912 (bool)   : default=1 value=1 flags=update
                           gain 0x00980913 (int)    : min=0 max=1023 step=1 default=0 value=176 flags=inactive, volatile
                horizontal_flip 0x00980914 (bool)   : default=0 value=0
                  vertical_flip 0x00980915 (bool)   : default=0 value=0
           power_line_frequency 0x00980918 (menu)   : min=0 max=3 default=1 value=1

Camera Controls

                  auto_exposure 0x009a0901 (menu)   : min=0 max=1 default=0 value=0 flags=update

Image Processing Controls

                     pixel_rate 0x009f0902 (int64)  : min=0 max=2147483647 step=1 default=61430400 value=61430400 flags=read-only
                   test_pattern 0x009f0903 (menu)   : min=0 max=4 default=0 value=0
ioctl: VIDIOC_ENUM_FMT
    Type: Video Capture

    [0]: 'BA81' (8-bit Bayer BGBG/GRGR)
    [1]: 'GBRG' (8-bit Bayer GBGB/RGRG)
    [2]: 'GRBG' (8-bit Bayer GRGR/BGBG)
    [3]: 'RGGB' (8-bit Bayer RGRG/GBGB)
    [4]: 'BG10' (10-bit Bayer BGBG/GRGR)
    [5]: 'GB10' (10-bit Bayer GBGB/RGRG)
    [6]: 'BA10' (10-bit Bayer GRGR/BGBG)
    [7]: 'RG10' (10-bit Bayer RGRG/GBGB)
    [8]: 'BG12' (12-bit Bayer BGBG/GRGR)
    [9]: 'GB12' (12-bit Bayer GBGB/RGRG)
    [10]: 'BA12' (12-bit Bayer GRGR/BGBG)
    [11]: 'RG12' (12-bit Bayer RGRG/GBGB)
    [12]: 'YUYV' (YUYV 4:2:2)
    [13]: 'YVYU' (YVYU 4:2:2)
    [14]: 'UYVY' (UYVY 4:2:2)
    [15]: 'VYUY' (VYUY 4:2:2)
    [16]: 'HM12' (YUV 4:2:0 (16x16 Macroblocks))
    [17]: 'NV12' (Y/CbCr 4:2:0)
    [18]: 'NV21' (Y/CrCb 4:2:0)
    [19]: 'YU12' (Planar YUV 4:2:0)
    [20]: 'YV12' (Planar YVU 4:2:0)
    [21]: 'NV16' (Y/CbCr 4:2:2)
    [22]: 'NV61' (Y/CrCb 4:2:2)
    [23]: '422P' (Planar YUV 4:2:2)
    [24]: 'RGBP' (16-bit RGB 5-6-5)
    [25]: 'RGBR' (16-bit RGB 5-6-5 BE)
    [26]: 'JPEG' (JFIF JPEG, compressed)

 

0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept