OV3640 camera on i.MX53

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OV3640 camera on i.MX53

3,004 Views
ripple
Contributor I

We develop one i.MX53 board which integrated OV3640 CMOS image sensor connected with CSI0 port. And get the driver from the L2.6.35_11.09.01_ER_source_bundle.tar.gz package. OV3640 works but the image is bad in color.

I inputed the gstreamer command line as followings:

gst-launch -v mfw_v4lsrc capture-width=640 capture-height=480 ! mfw_v4lsink

I recorded the video on the screen using my mobile phone and attached. The image's shape was clear but the color was bad. The colorful bar was flickering and shinning. Whether I have some mistake on the color format?

Can anybody help me for this problem? Thank you!

Tags (1)
0 Kudos
15 Replies

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

dmesg is normal. the ipu error is not a problem

I could not see your movie.

I think it´s a good idea take a scope and double check if your hardware is OK

and unfortunately, i have no idea how to use a scope and debug hardware =P

0 Kudos

2,135 Views
ripple
Contributor I

Dear Daiane,

Here is the movie I made.

I am wondering if there is some hardware problems in my board?

The dmesg log shows little information:

"

NV12

mxc_ipu mxc_ipu: IDMAC20's EBA0 is not 8-byte aligned

mxc_ipu mxc_ipu: IDMAC20's EBA1 is not 8-byte aligned

mxc_v4l_close: release resource

"

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

I don´t see anything on your log......

is LVDS´s pixclock  right?

If you make a movie, can the movie be played on your PC?

Anything else from dmesg?

0 Kudos

2,135 Views
ripple
Contributor I

I believe it means the plugins feel difficult to scale the 640x480 images to the 1024x768 screen.

I changed the command line to be :

gst-launch -v --gst-debug=2 mfw_v4lsrc capture-width=640 capture-height=480 ! queue ! mfw_isink disp-width=640 disp-height=480

the warning disappeared. Please see the attached log.

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

what does it mean?

mfw_v4lsink mfw_gst_v4l.c:1357:mfw_gst_v4l2_display_init: Wrong display width information

 

 

0 Kudos

2,135 Views
ripple
Contributor I

Thank you!

Following is the gst-launch log:

root@freescale ~$ gst-launch -v --gst-debug=2 mfw_v4lsrc capture-width=640 ca>
MFW_GST_V4LSRC_PLUGIN 2.0.3 build on Mar 1 2012 13:44:16.
MFW_GST_V4LSINK_PLUGIN 2.0.3 build on Mar 1 2012 13:44:21.
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/MFWGstV4LSrc:mfwgstv4lsrc0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)NV12, width=(int)640, height=(int)480, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
0:00:00.244215417 2192 0x16050 WARN bin gstbin.c:2312:gst_bin_do_latency_func:<pipeline0> failed to query latency
New clock: GstSystemClock
0:00:00.456938145 2192 0xe87b0 WARN mfw_v4lsink mfw_gst_v4lsink.c:1217:mfw_gst_v4lsink_set_format: set to nv12 mode
/GstPipeline:pipeline0/MFW_GST_V4LSINK_INFO_T:mfw_gst_v4lsink_info_t0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)NV12, width=(int)640, height=(int)480, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1
full screen size:1024x768
0:00:00.460228732 2192 0xe8ae0 WARN mfw_v4lsink mfw_gst_v4l.c:1357:mfw_gst_v4l2_display_init: Wrong display width information
0:00:00.460397355 2192 0xe8ae0 WARN mfw_v4lsink mfw_gst_v4l.c:1361:mfw_gst_v4l2_display_init: Wrong display height information
[V4L Update Display]: left=0, top=0, width=1024, height=768
0:00:00.460764975 2192 0xe87b0 WARN mfw_v4lsink mfw_gst_v4lsink.c:1217:mfw_gst_v4lsink_set_format: set to nv12 mode
>>V4L_SINK: Actually buffer status:
hardware buffer : 12
software buffer : 0

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

Ok

So you think the error is not caused by any mismatch of configuration, right?

Please, let me see your debug log

gst-launch -v --gst-debug=2 (...)

0 Kudos

2,135 Views
ripple
Contributor I

yes, problem same but image smaller.

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

you can resize the output as well

0 Kudos

2,135 Views
ripple
Contributor I

yes, I tried! The capture size was 176x144, and the small image was scaled to whole screen 1024x768. So it looked worse than the command line(640x480) above.

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

In fact, I´m not sure about sensor-width property. I don´t use it. 

You can set capture-mode=0 to get 640x480 from your camera

But, have you tried only:

gst-launch mfw_v4lsrc ! mfw_v4lsink

????

0 Kudos

2,135 Views
ripple
Contributor I

Thank you!

 

Is the mode which listed in ov3640.c as following:

       enum ov3640_mode {
          ov3640_mode_MIN = 0,
          ov3640_mode_VGA_640_480 = 0,
          ov3640_mode_QVGA_320_240 = 1,
          ov3640_mode_XGA_1024_768 = 2,
          ov3640_mode_QXGA_2048_1536 = 3,
          ov3640_mode_NTSC_720_480 = 4,
          ov3640_mode_PAL_720_576 = 5,
          ov3640_mode_MAX = 5
       };

  By the way, what is the difference between the property "sensor-width" and "capture-width" of the plugin mfw_v4lsrc? Should I set the property “sensor-width" and "sensor-height"? (When I tried, no apparently difference on the screen)

OK, I will start a new topic for the VPU problem. Yes, it is very complex. Thank you!

 

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

Please, open a new topic for the VPU stuff. Network streaming is a very complex topic. Take a look on others conversations and try as much as you can.

Let´s keep this one for camera. 

In your first command line (gst-launch -v mfw_v4lsrc capture-width=640 capture-height=480 ! mfw_v4lsink) there is no VPU reference. It´s a lookback camera -> display

 

Take a look on camera´s driver (on kernel, it should be something like ov3640.c) you will find any "supported capture mode".

 

For example, if you configure the camera with capture mode = 1, you will configure camera for 360X480@25FPS. If you configure all other parameters on gstreamer command line another way, you will get a bad picture on screen.

 

So, take a look on the "real supported" parameters, and make sure your camera configuration and command like match.

 

 

0 Kudos

2,135 Views
ripple
Contributor I

Daiane,

Thank you!

In your reply
" Do you know if your "standard" camera capture mode is for 640X480? "
Do you mean I should check the default resolution of OV3640, then use the mfw_v4lsrc in that resolution and convert it to any size using mfw_ipucsc plugin?
"The clock on the camera is right?"
I think so, 24MHz. And the OV3640 should have a very wide clock tolerance range according to its document.
I met another question when using OV3640 camera for video phone application, seems some troubles come from VPU.
I had two i.mx53 board with OV3640 camera, one's ip is 192.168.0.202, the other's is 192.168.0.210.
Used following command line as video streaming receiver:

gst-launch-0.10 -v udpsrc port=5002 ! queue ! capsfilter caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)420014, payload=(int)96" ! rtph264depay ! mfw_vpudecoder codec-type=std_avc ! queue ! mfw_isink sync=false

Used following command line as video streaming transmitter:

gst-launch-0.10 -v mfw_v4lsrc capture-width=352 capture-height=288 ! queue ! mfw_vpuencoder codec-type=std_avc ! rtph264pay ! queue ! udpsink host=192.168.0.202 port=5002 sync=false
192.168.0.202 (run receiver command line) <----- 192.168.0.210 (run transmitter command line)         worked well
192.168.0.202 (run transmitter command line) -----> 192.168.0.210 (run receiver command line)         worked well
192.168.0.202 (run transmitter command line) -----> 192.168.0.210 (run receiver command line)         worked well
                      (run receiver command line) 
192.168.0.202 (run transmitter command line) <----- 192.168.0.210 (run transmitter command line)         worked well
                      (run receiver command line) 
192.168.0.202 (run transmitter command line) -----> 192.168.0.210 (run receiver command line)         worked well
                                                                                                (run transmitter command line) 
192.168.0.202 (run receiver command line) <----- 192.168.0.210 (run transmitter command line)         worked well
                                                                                                (run receiver command line) 
192.168.0.202 (run receiver command line) <----- 192.168.0.210 (run transmitter command line)         has problem
                     (run transmitter command line)     ---->               (run receiver command line) 
each mx53 came out such log line text each 1s:
"[WARN]  VPU mutex couldn't be locked before timeout expired"
the screen freezed and no any video playing.
Can you give me some suggestion? Thank you!
 

Daiane Angolini said:

Do you know if your "standard" camera capture mode  is for 640X480?

The clock on the camera is right?

0 Kudos

2,135 Views
daiane_angolini
NXP Employee
NXP Employee

Do you know if your "standard" camera capture mode  is for 640X480?

The clock on the camera is right?

0 Kudos