Capturing analog video with i.MX51 CSI Port and TVP5147 TV Encoder

[LautaroCarmona1]

Hi Everyone!

My name is Lautaro Carmona, I'm from Argentina and, together with Jose Alvite and Fernando Tolassi we're working in a project that consists (as the title says) in capturing analog video with i.MX51 CSI Port and TVP5147 TV Encoder.

Our main goal is to connect analog baseband video to our TVIN board (through CVBS, YPbPr or S-Video connectors), then capture it through the MX51 CSI Port, and then compress it in H.264 using the MX51 VPU.

So far, we have made our TVIN board using TVP5147M1 TV Encoder and SN74AVCA164245 bus transceiver (in order to level shift TVP 3.3V I/O outputs to 1.8V).

We also made our own TVP5147 driver that uses the MXC V4l2 API (we based on the ADV7180 driver).

But until now, we're not able to see any frames. :(

This is what we are doing:

modprobe tvp5147_tvin // <-- our TVP driver

modprobe mxc_v4l2_capture

And then:

/unit_tests/mxc_v4l2_overlay.out -iw 720 -ih 576 -ow 720 -ih 576 -fr 30 -fg

but my HDMI monitor becames all green, and no video appears!

Any ideas? I would really appreciate some help from this community!

I can give much more details of our implementation and the source code of our driver to anyone interested.

[LautaroCarmona1]

Anthony, we tried the deinterlace plugin with no success... can you show me a GStreamer line that uses it, as an example? Thanks!

[LautaroCarmona1]

Anthony,

Thank you so much for this information! We'll try that module as well and let you know!

Anthony Tong said:

Lautaro,

We also managed to capture video from TVP5147M1, and we also got the interlaced video problem as you described in the following thread:

http://imxcommunity.org/forum/topics/i-mx53-ipu-deinterlacer?commen...

After some investigation we found that the IPU deinterlace function is bundled in the v4l2 output driver. It seems you cannot program the driver such that it captures, performs deinterlace operations and finally returns progressive video frames to you. You can only program the driver and just pass the interlaced video frames (those you directly get from capture driver) and the output driver will perform IPU deinterlacing and shows the video to the screen. 

Since we cannot use the IPU deinterlacer the way we want, we used the deinterlace plugin provided by gstreamer to do the job. The video output quality is so far acceptable, but it takes quite a lot CPU cycles. Since I have just figured out this way to do deinterlacing I still need to test more to confirm this. 

[AnthonyTong]

Lautaro,

We also managed to capture video from TVP5147M1, and we also got the interlaced video problem as you described in the following thread:

http://imxcommunity.org/forum/topics/i-mx53-ipu-deinterlacer?commentId=4103961%3AComment%3A43788

After some investigation we found that the IPU deinterlace function is bundled in the v4l2 output driver. It seems you cannot program the driver such that it captures, performs deinterlace operations and finally returns progressive video frames to you. You can only program the driver and just pass the interlaced video frames (those you directly get from capture driver) and the output driver will perform IPU deinterlacing and shows the video to the screen. 

Since we cannot use the IPU deinterlacer the way we want, we used the deinterlace plugin provided by gstreamer to do the job. The video output quality is so far acceptable, but it takes quite a lot CPU cycles. Since I have just figured out this way to do deinterlacing I still need to test more to confirm this. 

[LautaroCarmona1]

Anthony,

Hi! We managed to capture video with TVP5147M1 and iMX51 + gstreamer.

First of all, we connected the TVP5147 pins to the IMX51 through the CSI0 Port pins.

Then, we made our own TVP5147 TVIN driver (drivers/media/video/mxc/capture/tvp5147.c) based on ADV7180 driver (drivers/media/video/mxc/capture/adv7180.c), and we added it to our Linux Source Tree. Driver available here.

After adding this tvp5147 loadable kernel module to our kernel,we dinamically load it with:

modprobe tvp5147_tvin

And the we dinamically load the MXC v4l2 capture module:

modprobe mxc_v4l2_capture

After doing this, you can try the Freescale Unit Tests (/unit_tests) to test if you can see what is being captured (e.g. with mxc_v4l2_overlay.o).

Then you may try to capture video using Freescale Gstreamer Modules (mfw_v4lsrc, mfw_ipucsc, mfw_vpuencoder...).

Hope it helps!

Lautaro

Anthony Tong said:

   I am also working on a project with TVP5147 + iMX53 + gstreamer, but in first try we encountered some issues. I will take further look to the issue tomorrow  and post in this forum. Anyone who has a working solution with this HW/SW combination?

[AnthonyTong]

   I am also working on a project with TVP5147 + iMX53 + gstreamer, but in first try we encountered some issues. I will take further look to the issue tomorrow  and post in this forum. Anyone who has a working solution with this HW/SW combination?

[RobetAyala]

hello Eric,

Can you provide me with how you interfaced the ADV7180 to the IMX515. Also what in the linux BSP did you have to modifiy if anything.  Also what commands you used to test this interface. 

Best Regards,

Robert

eric said:

Hi~~All:

i had done in imx51 + ADV7180 project.

i forget to replace adv7180.ko after my compiler.

Eric

[DualDisplayiss1]

Hi~~All:

i had done in imx51 + ADV7180 project.

i forget to replace adv7180.ko after my compiler.

Eric

[LautaroCarmona1]

Hi Eric,

No, I'm sorry but I really don't know why the mxc_v4l2_capture module isn't working for you...

I would ask to someone at Freescale or maybe in another new post or forum on this community.

Maybe you need to recompile your kernel? or the modules?

Regards,

Lautaro.

Campro eric@campro-cctv.com said:

Dear Lautaro:

when i do "modprobe mxc_v4l2_capture" the error message as below.do you know why?

root@freescale /unit_tests$ modprobe mxc_v4l2_capture
mxc_v4l2_capture: disagrees about version of symbol video_devdata
mxc_v4l2_capture: Unknown symbol video_devdata (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_unregister_device
mxc_v4l2_capture: Unknown symbol video_unregister_device (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_device_alloc
mxc_v4l2_capture: Unknown symbol video_device_alloc (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_register_device
mxc_v4l2_capture: Unknown symbol video_register_device (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_device_release
mxc_v4l2_capture: Unknown symbol video_device_release (err -22)
modprobe: failed to load module mxc_v4l2_capture (/lib/modules/2.6.35.3-433-g0fae922/kernel/drivers/media/video/mxc/capture/mxc_v4l2_capture.ko): Invalid argument

Eric


Lautaro Carmona said:

Dear Fabio, all,

Thanks for your suggestion.

I checked the mxc_v4l2_capture.out source code, and found that in the process_cmdline function, the available capture formats (specified with the '-f' parameter) are:

• V4L2_PIX_FMT_BGR24 = BGR3
• V4L2_PIX_FMT_BGR32 = BGR4
• V4L2_PIX_FMT_RGB565 = RGBP
• V4L2_PIX_FMT_NV12 = NV12
• V4L2_PIX_FMT_YUV422P = 422P
• V4L2_PIX_FMT_UYVY = UYVY
• V4L2_PIX_FMT_YUYV = YUYV
• V4L2_PIX_FMT_YUV420 = YU12

In the other hand, I typed 'mplayer -rawvideo format=help' in order to know the available display formats:

Available formats: 444p 422p 411p yuy2 uyvy yvu9 if09 yv12 i420 iyuv clpl hm12 y800 y8 nv12 nv21 bgr24 bgr32 bgr16 bgr15 bgr8 bgr4 bg4b bgr1 rgb24 rgb32 rgb16 rgb15 rgb8 rgb4 rg4b rgb1 rgba argb bgra abgr mjpeg mjpg

MPlayer SVN-r1.0~rc3+svn20090426-4.4.3 (C) 2000-2009 MPlayer Team

Then I used the mxc_v4l2_capture.out unit test to capture the same video eight times, trying each time with one of the eight available formats. This way I created the following eight files:

• test_422P.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f 422P test.yuv )
• test_BGR3.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR3 test.yuv )  
• test_BGR4.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR4 test.yuv )
• test_NV12.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f NV12 test.yuv ) 
• test_RGBP.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f RGBP test.yuv )
• test_UYVY.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f UYVY test.yuv )
• test_YU12.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YU12 test.yuv )
• test_YUYV.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YUYV test.yuv )

Finally, I played each of these 8 files with 7 different display color formats that mplayer offers:

• mplayer -rawvideo w=640:h=360:fps=30:format=uyvy -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yuy2 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=nv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=422p -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr24 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr32 -demuxer rawvideo ${1}

In most of the playings the color format selected to display and the color format of the file being played were not compatible or they displayed in a wrong way (rare colors, and sync's issues).

But in the one that the color formats matched, the results were the same I posted earlier: a stable image (in sync terms) but with the colour only well displayed at certain alternating vertical bars.

Any other ideas?

FYI: In the tvp5147 driver we are setting this:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_UYVY;

The ADV7180 driver does the same...

We also tried:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_YUYV;

with similar results

[LautaroCarmona1]

Hi everyone,

We found that the problem was being caused by a hardware issue of our tvp5147 tvin board.

We asked Texas Instrument people, and we found out that we had a wrong crystal on our board, here is the forum where we discussed it:

http://e2e.ti.com/support/data_converters/videoconverters/f/376/p/142207/513278.aspx#513278

Thanks all for your interest!

Regards,

Lautaro.

Lautaro Carmona said:

About our colour issues while capturing:

As Harald Krapfenbauer previously suggested as, we tried the following in order to capture raw video:

cd /unit_tests/

./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YUYV test.yuv

We were able to do it, and then we could play it with mplayer on our host machine with: "mplayer -rawvideo w=640:h=360:fps=30:f=YUY2 -demuxer rawvideo" 

While doing this we found the color issues that I previously mentioned.

With this post I'm uploading a picture where this can be appreciated (we use the plain colors Blue, Red and Green as inputs, and a TestSignal too).

As it can be seen, the colour is well displayed only at certain alternating vertical bars.

Any ideas of what may the problem is?

[DualDisplayiss1]

Dear Lautaro:

when i do "modprobe mxc_v4l2_capture" the error message as below.do you know why?

root@freescale /unit_tests$ modprobe mxc_v4l2_capture
mxc_v4l2_capture: disagrees about version of symbol video_devdata
mxc_v4l2_capture: Unknown symbol video_devdata (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_unregister_device
mxc_v4l2_capture: Unknown symbol video_unregister_device (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_device_alloc
mxc_v4l2_capture: Unknown symbol video_device_alloc (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_register_device
mxc_v4l2_capture: Unknown symbol video_register_device (err -22)
mxc_v4l2_capture: disagrees about version of symbol video_device_release
mxc_v4l2_capture: Unknown symbol video_device_release (err -22)
modprobe: failed to load module mxc_v4l2_capture (/lib/modules/2.6.35.3-433-g0fae922/kernel/drivers/media/video/mxc/capture/mxc_v4l2_capture.ko): Invalid argument

Eric


Lautaro Carmona said:

Dear Fabio, all,

Thanks for your suggestion.

I checked the mxc_v4l2_capture.out source code, and found that in the process_cmdline function, the available capture formats (specified with the '-f' parameter) are:

• V4L2_PIX_FMT_BGR24 = BGR3
• V4L2_PIX_FMT_BGR32 = BGR4
• V4L2_PIX_FMT_RGB565 = RGBP
• V4L2_PIX_FMT_NV12 = NV12
• V4L2_PIX_FMT_YUV422P = 422P
• V4L2_PIX_FMT_UYVY = UYVY
• V4L2_PIX_FMT_YUYV = YUYV
• V4L2_PIX_FMT_YUV420 = YU12

In the other hand, I typed 'mplayer -rawvideo format=help' in order to know the available display formats:

Available formats: 444p 422p 411p yuy2 uyvy yvu9 if09 yv12 i420 iyuv clpl hm12 y800 y8 nv12 nv21 bgr24 bgr32 bgr16 bgr15 bgr8 bgr4 bg4b bgr1 rgb24 rgb32 rgb16 rgb15 rgb8 rgb4 rg4b rgb1 rgba argb bgra abgr mjpeg mjpg

MPlayer SVN-r1.0~rc3+svn20090426-4.4.3 (C) 2000-2009 MPlayer Team

Then I used the mxc_v4l2_capture.out unit test to capture the same video eight times, trying each time with one of the eight available formats. This way I created the following eight files:

• test_422P.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f 422P test.yuv )
• test_BGR3.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR3 test.yuv )  
• test_BGR4.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR4 test.yuv )
• test_NV12.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f NV12 test.yuv ) 
• test_RGBP.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f RGBP test.yuv )
• test_UYVY.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f UYVY test.yuv )
• test_YU12.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YU12 test.yuv )
• test_YUYV.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YUYV test.yuv )

Finally, I played each of these 8 files with 7 different display color formats that mplayer offers:

• mplayer -rawvideo w=640:h=360:fps=30:format=uyvy -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yuy2 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=nv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=422p -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr24 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr32 -demuxer rawvideo ${1}

In most of the playings the color format selected to display and the color format of the file being played were not compatible or they displayed in a wrong way (rare colors, and sync's issues).

But in the one that the color formats matched, the results were the same I posted earlier: a stable image (in sync terms) but with the colour only well displayed at certain alternating vertical bars.

Any other ideas?

FYI: In the tvp5147 driver we are setting this:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_UYVY;

The ADV7180 driver does the same...

We also tried:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_YUYV;

with similar results

[LautaroCarmona1]

Hi eric, Have you checked if "mxc_v4l2_capture" and "adv7180_tvin" modules are loaded? You should check that with the "lsmod" command. If not loaded, what you have to do is: > modprobe adv7180_tvin > modprobe mxc_v4l2_capture (In that order, you first load adv7180 kernel module, then freescale's v4l2 capture module, and just thenyou can capture) > /unit_tests/mxc_v4l2_capture.out Hope it may help you, Best regards, Lautaro

[DualDisplayiss1]

Hi~Lautaro:

our tvin decode ic av7180 and i try to use mxc_v4l2_overlay.out or mxc_v4l2_output.out

but some error message happen in below:

root@freescale /unit_tests$ ./mxc_v4l2_capture.out                             
in_width = 176, in_height = 144                                                                                        
out_width = 176, out_height = ERROR: v4l2 capture: slave not found!            
144                                                                            
top = 0, left = 0                                                              
Unable to open /dev/video0                                                     
get format failed       

i remember you have work in tvp5147.do you have meet this issue before?

Eric

Lautaro Carmona said:

Dear Fabio, all,

Thanks for your suggestion.

I checked the mxc_v4l2_capture.out source code, and found that in the process_cmdline function, the available capture formats (specified with the '-f' parameter) are:

• V4L2_PIX_FMT_BGR24 = BGR3
• V4L2_PIX_FMT_BGR32 = BGR4
• V4L2_PIX_FMT_RGB565 = RGBP
• V4L2_PIX_FMT_NV12 = NV12
• V4L2_PIX_FMT_YUV422P = 422P
• V4L2_PIX_FMT_UYVY = UYVY
• V4L2_PIX_FMT_YUYV = YUYV
• V4L2_PIX_FMT_YUV420 = YU12

In the other hand, I typed 'mplayer -rawvideo format=help' in order to know the available display formats:

Available formats: 444p 422p 411p yuy2 uyvy yvu9 if09 yv12 i420 iyuv clpl hm12 y800 y8 nv12 nv21 bgr24 bgr32 bgr16 bgr15 bgr8 bgr4 bg4b bgr1 rgb24 rgb32 rgb16 rgb15 rgb8 rgb4 rg4b rgb1 rgba argb bgra abgr mjpeg mjpg

MPlayer SVN-r1.0~rc3+svn20090426-4.4.3 (C) 2000-2009 MPlayer Team

Then I used the mxc_v4l2_capture.out unit test to capture the same video eight times, trying each time with one of the eight available formats. This way I created the following eight files:

• test_422P.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f 422P test.yuv )
• test_BGR3.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR3 test.yuv )  
• test_BGR4.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR4 test.yuv )
• test_NV12.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f NV12 test.yuv ) 
• test_RGBP.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f RGBP test.yuv )
• test_UYVY.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f UYVY test.yuv )
• test_YU12.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YU12 test.yuv )
• test_YUYV.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YUYV test.yuv )

Finally, I played each of these 8 files with 7 different display color formats that mplayer offers:

• mplayer -rawvideo w=640:h=360:fps=30:format=uyvy -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yuy2 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=nv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=422p -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr24 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr32 -demuxer rawvideo ${1}

In most of the playings the color format selected to display and the color format of the file being played were not compatible or they displayed in a wrong way (rare colors, and sync's issues).

But in the one that the color formats matched, the results were the same I posted earlier: a stable image (in sync terms) but with the colour only well displayed at certain alternating vertical bars.

Any other ideas?

FYI: In the tvp5147 driver we are setting this:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_UYVY;

The ADV7180 driver does the same...

We also tried:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_YUYV;

with similar results

[LautaroCarmona1]

Hi Eric, We do not have a record software yet... we are using freescale's unit_tests for now... we are actually planning to use gstreamer framework (and freescale's plugins) in order to do our own record software but we are still figuring out how to cross compile our gstreamer source code... We also tried to make use of the TVP with Cheese but it hangs up and starts consuming CPU resources... :( Hope you find the gstreamer alternative useful, Lautaro

Campro eric@campro-cctv.com said:

Hi~~Lautaro:

one more question.

Do you have record software?

we're work in Ubuntu and Wince 6.0.But i'm not sure those have ready API function.

Eric

[LautaroCarmona1]

Hi Craig, Sorry for my late response. We did some test with black and white pictures and luma seems to be consistent... About the color depth you're right, is differnet from adv7180, but as Harald says, we do have the tvp most significan bit aligned to d19 pin... We recently found, through a TI forum, that our problem may reside in the frequency of the clock we are using in our board... it should be of 14.31 MHz and we believe that instead we made the mistake of putting a 14MHz clock... so we will check this and let you know! Thanks for the ideas! Lautaro PS: how would you recommend to perform the hex dump of a raw video stream? Any tool recommended?

Craig Petku said:

Just some ideas..

Looking at the ds, a difference between the 7180 and the tvp is the bus width/color depth.  While the CSI port may be able to handle the capture and the IPU may be able to do CSC, it's possible the fsl framework or mplayer has not been validated for this combination.  With a 7180 I typically don't specify the format in either capture or mplayer, just the frame sizes /input path and rawvideo options

Have you verified your bits per color (CSIX_DATA_WIDTH)  in the IPU_CSIX_SENS_CONFIG register?

Have you considered looking at a hexdump of an image or raw video stream to understand the pattern of the data being captured?

Have you tried an all white or black image and compared the output to a crbr plot to see if LUMA is consistent?

[harald_krapfenb]

Hello,

10-bit color depth is interesting. We once had to modify the framework a little bit for capturing a 10-bit raw data stream with CSI. However, if the TVP's most significant bit is aligned to CSI1_D19 pin, and you do capturing with 8-bit, the two least significant bits are simply discarded, and you should as well get a correct picture.

So my advice: Try 8-bit first; that what the framework supports for sure.

[DualDisplayiss1]

Hi~~Lautaro:

one more question.

Do you have record software?

we're work in Ubuntu and Wince 6.0.But i'm not sure those have ready API function.

Eric

Lautaro Carmona said:

Hi everyone!

Thank you for your interest in this project.

We have made our driver available to anyone at this site: http://code.google.com/p/tvp5147-mxc-v4l2/

And we added the following instructions on how we managed to make it work with SBC-i.MX51.

Hope you found this useful.

We still have some colour issues, so any suggestion is welcomed.

Here are the instructions:

In order to include TVP5147 support to our board we needed to:

• Create the driver: "drivers/media/video/mxc/capture/tvp5147.c"
• Include the driver's registers header file: "drivers/media/video/mxc/capture/tvp514x_regs.h"
• Modify the following files:
  • "arch/arm/mach-mx5/mx51_3stack.c"
  • "drivers/media/video/mxc/capture/Makefile"
  • "drivers/media/video/mxc/capture/KConfig"

All this files are uploaded in the SVN trunk of this project: http://code.google.com/p/tvp5147-mxc-v4l2/


About the changes in "arch/arm/mach-mx5/mx51_3stack.c":

The modified version of "mx51_3stack.c" is also uploaded in the SVN trunk.
You should check the differences with your own version of "mx51_3stack.c" and then replace it with our version or manually add our changes.
Basically, we:

• added our device to the "i2c_board_info" struct (with i2c address 0x5c), 
• defined the powerup, powerdown, reset functions to dinamically control the device power when the driver module is loaded/unloaded, and
• set the CSI master clock frequency (although we are not currently using it, as we use our own 14.31 MHz clock on board).

About the changes in "drivers/media/video/mxc/capture/Makefile":

To compile our driver and add it to the kernel we added this lines to the file: "drivers/media/video/mxc/capture/Makefile"

#Added to include TVP5147 support:
tvp5147_tvin-objs := tvp5147.o
obj-$(CONFIG_MXC_TVIN_TVP5147) += tvp5147_tvin.o


About the changes in "drivers/media/video/mxc/capture/KConfig":

To make it available at the kernel menuconfig we added this lines to the file: "drivers/media/video/mxc/capture/KConfig"

config MXC_TVIN_TVP5147
tristate "Texas Instrument tvp5147 TV Decoder Input support"
depends on (MACH_MX35_3DS || MACH_MX51_3DS)
---help---
If you plan to use the tvp5147 video decoder with your MXC system, say Y here.

[CraigPetku]

Just some ideas..

Looking at the ds, a difference between the 7180 and the tvp is the bus width/color depth.  While the CSI port may be able to handle the capture and the IPU may be able to do CSC, it's possible the fsl framework or mplayer has not been validated for this combination.  With a 7180 I typically don't specify the format in either capture or mplayer, just the frame sizes /input path and rawvideo options

Have you verified your bits per color (CSIX_DATA_WIDTH)  in the IPU_CSIX_SENS_CONFIG register?

Have you considered looking at a hexdump of an image or raw video stream to understand the pattern of the data being captured?

Have you tried an all white or black image and compared the output to a crbr plot to see if LUMA is consistent?

[LautaroCarmona1]

Hi Harald,

Thanks once again for your contribution.

I double checked the output data format of the TVP, and we're programming the output formatters registers in order to transmit the data with this video output format:

10-bit ITU-R BT.656 4:2:2 YCbCr with embedded syncs

What ITU Recommendation BT.656 specifies about the video data format is this:

The video data words are conveyed as a 27 Mword/s multiplex in the following order:

CB, Y, CR, Y, CB, Y, CR, etc.

where the word sequence CB, Y, CR, refers to co-sited luminance and colour-difference samples andthe following word, Y, corresponds to the next luminance sample.

So we also understand that the TVP is transmitting with UYVY format (as the ADV7180 does). I don't think that we would need to change the IPU capture driver, but we will try.

I also find this input-output correlation very strange. Maybe it isn't a color format problem; we are not using the CSI's master clock signal... instead, we are using our own on-board clock... Do you think this has anything to do with it?

[harald_krapfenb]

Hello,

I've recently found out that the IPU capture driver for i.MX51 (Linux) always assumes that the input of the chip is in format UYVY, see files

  drivers/media/video/mxc/capture/ipu_prp_vf_sdc_bg.c

  drivers/media/video/mxc/capture/ipu_prp_vf_sdc.c

  drivers/media/video/mxc/capture/ipu_prp_enc.c

following line:

  enc.csi_prp_enc_mem.in_pixel_fmt = IPU_PIX_FMT_UYVY;

You've to modify the driver if the TVP does not provide UYVY data. What you set for tvp5147_data.pix.pixelformat is the OUTPUT of the CSI, so if necessary I guess the CSI does format conversion. If possible, you should imho stick to UYVY. Note that when capturing with the unit test, the format is saved in YUV420 format, and that's what mplayer expects by default.

-Harald

<edit> Lautaro, having a look at the .PNG you attached, I would say your problem are not related to the color format. If the color format is wrong, there are wrong colors, but areas with one color would stay one color (a wrong one though). I've never seen such input-output correlation... </edit>

[LautaroCarmona1]

Dear Fabio, all,

Thanks for your suggestion.

I checked the mxc_v4l2_capture.out source code, and found that in the process_cmdline function, the available capture formats (specified with the '-f' parameter) are:

• V4L2_PIX_FMT_BGR24 = BGR3
• V4L2_PIX_FMT_BGR32 = BGR4
• V4L2_PIX_FMT_RGB565 = RGBP
• V4L2_PIX_FMT_NV12 = NV12
• V4L2_PIX_FMT_YUV422P = 422P
• V4L2_PIX_FMT_UYVY = UYVY
• V4L2_PIX_FMT_YUYV = YUYV
• V4L2_PIX_FMT_YUV420 = YU12

In the other hand, I typed 'mplayer -rawvideo format=help' in order to know the available display formats:

Available formats: 444p 422p 411p yuy2 uyvy yvu9 if09 yv12 i420 iyuv clpl hm12 y800 y8 nv12 nv21 bgr24 bgr32 bgr16 bgr15 bgr8 bgr4 bg4b bgr1 rgb24 rgb32 rgb16 rgb15 rgb8 rgb4 rg4b rgb1 rgba argb bgra abgr mjpeg mjpg

MPlayer SVN-r1.0~rc3+svn20090426-4.4.3 (C) 2000-2009 MPlayer Team

Then I used the mxc_v4l2_capture.out unit test to capture the same video eight times, trying each time with one of the eight available formats. This way I created the following eight files:

• test_422P.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f 422P test.yuv )
• test_BGR3.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR3 test.yuv )  
• test_BGR4.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f BGR4 test.yuv )
• test_NV12.yuv ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f NV12 test.yuv ) 
• test_RGBP.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f RGBP test.yuv )
• test_UYVY.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f UYVY test.yuv )
• test_YU12.yuv   ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YU12 test.yuv )
• test_YUYV.yuv  ( ./mxc_v4l2_capture.out -ih 680 -iw 240 -oh 640 -ow 360 -fr 30 -f YUYV test.yuv )

Finally, I played each of these 8 files with 7 different display color formats that mplayer offers:

• mplayer -rawvideo w=640:h=360:fps=30:format=uyvy -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yuy2 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=yv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=nv12 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=422p -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr24 -demuxer rawvideo ${1}
• mplayer -rawvideo w=640:h=360:fps=30:format=bgr32 -demuxer rawvideo ${1}

In most of the playings the color format selected to display and the color format of the file being played were not compatible or they displayed in a wrong way (rare colors, and sync's issues).

But in the one that the color formats matched, the results were the same I posted earlier: a stable image (in sync terms) but with the colour only well displayed at certain alternating vertical bars.

Any other ideas?

FYI: In the tvp5147 driver we are setting this:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_UYVY;

The ADV7180 driver does the same...

We also tried:

tvp5147_data.pix.pixelformat = V4L2_PIX_FMT_YUYV;

with similar results