Re: Help with omap3isp resizing from CCDC

2013-08-21 Thread Laurent Pinchart
Hi Samuel,

On Friday 02 August 2013 13:12:24 samuel.rasmus...@gdc4s.com wrote:
 Hi,
 
 I've been having problems getting the resizer to take its input from the
 CCDC. From the linux-media mail-archive, it looks like Paul Chiha ran into a
 similar problem in Oct 2011 with his message Help with omap3isp resizing. 
 Paul had a patch at the end of the discussion, but even his patch hasn't
 fixed my problem yet. I might have made a mistake porting the patch since
 I'm on a newer kernel, or perhaps it doesn't work with my TVP5151 decoder.
 
 My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder.
 
 The video looks great with a 640x480 resolution, and the CCDC is de-
 interlacing the video. However, for my needs the video must be resized to
 320x240 or 160x120. The video, coming from the resizer, is split into a top
 and bottom half. Both halves are identical where everything in the video is
 too wide and too short. The CCDC must not be de-interlacing the video going
 to the resizer. I tried setting up the pipeline to send the CCDC to the
 resizer, but something must have gone wrong.

Unfortunately the CCDC can't deinterlace frames sent to the resizer. The 
deinterlacing process takes place at the CCDC output DMA engine when writing 
the frames to memory.

There's two solutions to resize interlaced video. The first one would be to 
capture the deinterlaced frames at the CCDC output to memory and then use the 
resizer in memory-to-memory mode. The second one would be to modify the driver 
to support deinterlacing at the resizer output, by doubling the line offset 
and computing the correct start address for each odd/even frame.

As you only need to downscale by two or four, another much simpler solution 
would be to drop every other interlaced frame. You would then get 640x240 
frames that you could resize to 320x240 or 160x120 with the resizer.

 Up until this point, I was using the UYVY2X8 format.  Then I saw the
 
 discussion Paul Chiha created.  In that discussion Laurent said:
  But the original poster wants to use the sensor - ccdc - resizer -
  resizeroutput pipeline.
 
  Also several sensor drivers that i have checked, usually define its
  output as 2X8 output. I think is more natural to add 2X8 support to
  CCDC and Resizer engines instead to modifying exiting drivers.
 
  Sure, sensor drivers should not be modified. What I was talking about
  was to configure the pipeline as
 
  sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
  resizer:0 [YUYV8_1X16]
 
 I wasn't sure if Laurent's advice would also apply to the TVP5151, but I
 wanted to test it out.  I implemented Paul's patch so I could use the
 YUYV8_2X8 and YUYV8_1X16 formats.  The 640x480 resolution looked good in
 the YUYV8_2X8 format.  However, once again the video from the resizer
 was not de-interlaced so it had a top and bottom half (using YUYV8_2X8
 and YUYV8_1X16).  This time it was even worse because the video from the
 resizer was very green.
 
 Does anyone have suggestions for resizing video from the TVP5151?
 
 Thanks for taking the time to read this,
 Samuel
 
 I'm adding some media-ctl details below.
 media-ctl commands I'm using:
 
 media-ctl -v -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1]'
 media-ctl -v -l 'OMAP3 ISP CCDC:1-OMAP3 ISP resizer:0[1]'
 media-ctl -v -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
 media-ctl -v -f 'tvp5150 3-005c:0 [YUYV2X8 640x480]'
 media-ctl -v -f 'OMAP3 ISP CCDC:0 [YUYV2X8 640x480]'
 media-ctl -v -f 'OMAP3 ISP CCDC:1 [YUYV 640x480]'
 media-ctl -v -f 'OMAP3 ISP resizer:1 [YUYV 320x240]'
 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv
 driver=v4l2:device=/dev/video6
 
 Output of medi-ctl -p:
 
 Opening media device /dev/media0
 Enumerating entities
 Found 16 entities
 Enumerating pads and links
 Media controller API version 0.0.0
 
 Media device information
 
 driver  omap3isp
 model   TI OMAP3 ISP
 serial
 bus info
 hw revision 0xf0
 driver version  0.0.0
 
 Device topology
 - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev0
   pad0: Sink
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CCP2 input:0 []
   pad1: Source
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CCDC:0 []
 
 - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video0
   pad0: Source
   - OMAP3 ISP CCP2:0 []
 
 - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev1
   pad0: Sink
   [fmt:SGRBG10/4096x4096]
   pad1: Source
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CSI2a output:0 []
   - OMAP3 ISP CCDC:0 []
 
 - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
 type Node subtype 

Help with omap3isp resizing from CCDC

2013-08-02 Thread Samuel.Rasmussen
Hi,

I've been having problems getting the resizer to take its input from the
CCDC.  From the linux-media mail-archive, it looks like Paul Chiha ran
into a similar problem in Oct 2011 with his message Help with omap3isp
resizing.  Paul had a patch at the end of the discussion, but even his
patch hasn't fixed my problem yet.  I might have made a mistake porting
the patch since I'm on a newer kernel, or perhaps it doesn't work with
my TVP5151 decoder.

My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder.

The video looks great with a 640x480 resolution, and the CCDC is
de-interlacing the video.  However, for my needs the video must be
resized to 320x240 or 160x120.  The video, coming from the resizer, is
split into a top and bottom half.  Both halves are identical where
everything in the video is too wide and too short.  The CCDC must not be
de-interlacing the video going to the resizer.  I tried setting up the
pipeline to send the CCDC to the resizer, but something must have gone
wrong.

Up until this point, I was using the UYVY2X8 format.  Then I saw the
discussion Paul Chiha created.  In that discussion Laurent said:

But the original poster wants to use the sensor - ccdc - resizer -
resizer 
output pipeline.

 Also several sensor drivers that i have checked, usually define its
 output as 2X8 output. I think is more natural to add 2X8 support to
 CCDC and Resizer engines instead to modifying exiting drivers.

Sure, sensor drivers should not be modified. What I was talking about
was to 
configure the pipeline as

sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
resizer:0 [YUYV8_1X16]

I wasn't sure if Laurent's advice would also apply to the TVP5151, but I
wanted to test it out.  I implemented Paul's patch so I could use the
YUYV8_2X8 and YUYV8_1X16 formats.  The 640x480 resolution looked good in
the YUYV8_2X8 format.  However, once again the video from the resizer
was not de-interlaced so it had a top and bottom half (using YUYV8_2X8
and YUYV8_1X16).  This time it was even worse because the video from the
resizer was very green.

Does anyone have suggestions for resizing video from the TVP5151?

Thanks for taking the time to read this,
Samuel

I'm adding some media-ctl details below.
media-ctl commands I'm using:

media-ctl -v -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1]'
media-ctl -v -l 'OMAP3 ISP CCDC:1-OMAP3 ISP resizer:0[1]'
media-ctl -v -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
media-ctl -v -f 'tvp5150 3-005c:0 [YUYV2X8 640x480]'
media-ctl -v -f 'OMAP3 ISP CCDC:0 [YUYV2X8 640x480]'
media-ctl -v -f 'OMAP3 ISP CCDC:1 [YUYV 640x480]'
media-ctl -v -f 'OMAP3 ISP resizer:1 [YUYV 320x240]'
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv
driver=v4l2:device=/dev/video6

Output of medi-ctl -p:

Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Media controller API version 0.0.0

Media device information

driver  omap3isp
model   TI OMAP3 ISP
serial  
bus info
hw revision 0xf0
driver version  0.0.0

Device topology
- entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CCP2 input:0 []
pad1: Source
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CCDC:0 []

- entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
- OMAP3 ISP CCP2:0 []

- entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
[fmt:SGRBG10/4096x4096]
pad1: Source
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CSI2a output:0 []
- OMAP3 ISP CCDC:0 []

- entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
- OMAP3 ISP CSI2a:1 []

- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
[fmt:YUYV2X8/640x480]
- OMAP3 ISP CCP2:1 []
- OMAP3 ISP CSI2a:1 []
- tvp5150 3-005c:0 [ENABLED]
pad1: Source
[fmt:YUYV/640x480
 crop.bounds:(0,0)/640x480
 crop:(0,0)/640x480]
- OMAP3 ISP CCDC output:0 []
- OMAP3 ISP resizer:0 [ENABLED]
pad2: Source
[fmt:unknown/640x479]
- OMAP3 ISP preview:0 []
- OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP AF:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP histogram:0