Hi,
I'm planing to use the TexasInstruments TFP401A as DVI/HDMI input into the IMX6Q CSI. It should convert to parallel RGB565 data with CLOCK,HSYNC,VSYNC so in my opinion the gated-mode must be used. In section 37.4.3.9 it is mentioned that "16bit RGB565" does only work together with non-gated mode. So can i use "16bit as generic data"? Whats the exact difference between these two?
Looking into the patch from How to Support RGB565 Gated Mode Input to i.MX6 CSI it seems it has something to do with Bayer format? (cfg_param.data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER).
Finally i want to capture the rgb data, compress using the VPU and stream it over Ethernet.
Thanks in advance!
Udo Schmelmer
已解决! 转到解答。
Hi Udo
"no on the fly processing" means that data is put in DDR memory,
after that it can be processed.
Yes, "RGB as generic data" means that the input data is fed into a buffer in RAM.
Yes, one can pipe from this buffer into the VPU, encode to h.264 and from here into a network stream
Best regards
chip
Hi Udo
section 37.4.3.9 describes two methods for "16bit RGB565":
1. without "on the fly processing", no restriction on gated/non-gated mode
bayer format is used (RGB treated as generic data)
2. with "on the fly processing", CSI#_SENS_DATA_FORMAT=RGB565
and only non-gate mode may be used
patch uses first method.
Best regards
chip
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
hI, Udo .
We have the similar application to connect pararel RGB input with MX6Q CSI.
Have you finish your application?
I try the patch - https://community.freescale.com/docs/DOC-97981.
and change setting as folloing:
drivers/media/video/mxc/capture/mxc_v4l2_capture.c
csi_param.clk_mode = IPU_CSI_CLK_MODE_GATED_CLK;
csi_param.data_width = IPU_CSI_DATA_WIDTH_16;
I use the mxc_v4l2_overlal.c to preview the image,
but the overlay preview image is not normal. Its really greenish preview image and there are 4 frames not 1 frame. (and rolling)
Any help woud be appreciated.
Share my experience to who have the same problem, as below:
1. Change mfw_v4lsrc element default color format from V4L2_PIX_FMT_YUV420, to V4L2_PIX_FMT_SGRBG8
2. Change mfw_v4lsrc element default caps from video/x-raw-yuv to video/x-raw-rgb, default fourcc code from 'I' '4' '2' '0' to 'R' 'G' 'B' 'P'
3. After these changes, run pipeline to show on the screen, like this:
gst-launch mfw_v4lsrc device=/dev/video0 capture-mode=4 ! mfw_v4lsink device=/dev/video16 sync=false
thanks!
Hi huang:
I have a similar problem like yours, i run gstreamer pipeline to get generic 16 bits data(original is RGB565) from csi port, but i got four divided frames and rolling and greenish, have you fix your problems? if yes, can you give me some suggestions? thanks
Hi tsaikenny,
The following are the files that i have modified to support RGB565 with Gated mode. It's based on Linux-3.0.35.
Board-mx6q_sabresd.c (arch\arm\mach-mx6)
Ipu_bg_overlay_sdc.c (drivers\media\video\mxc\capture)
Ipu_csi_enc.c (drivers\media\video\mxc\capture)
Ipu_device.c (drivers\mxc\ipu3)
Ipu_fg_overlay_sdc.c (drivers\media\video\mxc\capture)
Mxc_v4l2_capture.c (drivers\media\video\mxc\capture)
Rgb565_16bit.c (drivers\media\video\mxc\capture)
Hi,
thanks for your answer! So in detail for my solution:
1. What does "no on the fly processing" exactly mean? From my understanding it means that i only can't use VDIC, IC, and IRT of the IPU? Or are there more restrictions?
2. Does "RGB as generic data" mean that the parallel input data is fed into a buffer in RAM as it ?
3. If so, can i pipe from this buffer into the VPU, encode to h.264 and from here into a network stream?
Thank you,
Udo
Hi Udo
"no on the fly processing" means that data is put in DDR memory,
after that it can be processed.
Yes, "RGB as generic data" means that the input data is fed into a buffer in RAM.
Yes, one can pipe from this buffer into the VPU, encode to h.264 and from here into a network stream
Best regards
chip