Re: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 06:32, Enrico wrote: Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Is there any way to prove this by doing the de-interlacing in software? I just tested software deinterlacing (with gstreamer) and i can confirm it works very well, it removes ghosting completely. It will cause other problems that have a big performance impact (colorspace conversions, doubled framerates...) but that's another story, and i don't know if this is the appropriate place to talk about them. So i don't think it's the tvp51xx to blame or the isp, you will have to deinterlace with any analog decoder (unless it has integrated deinterlacing). Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas g...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-13 06:32, Enrico wrote: On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.comwrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Is there any way to prove this by doing the de-interlacing in software? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 06:32, Enrico wrote: On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Hello, Yes, I noticed that the images arrive correctly but disabling the interlaced mode fldmode == 0 and not setting an offset to copy the odd/even fields ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); If you do so, you will see a image that is composed of both odd and even frames each of them half the size of the deinterlaced image. So the TVP is producing the correct YUV data and also the ISP is decoding correctly using the BT.656 embedded sync info. My guess is that has to do with the buffers. I guess there are two ways to probe this. 1- Hack yavta to memset to 0 every buffer before passing to V4L2 layer. Is there any way to prove this by doing the de-interlacing in software? 2- Deinterlace by software. As I said before deactivate the interlaced mode and get the two frames, then you can copy 1440 bytes (one line) from the first sub-frame (lines[0]) and then copy one line of the second sub-frame (lines[height/2-1]), and so on. Since YUV data is RAW you can manipulate this way. Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP ghosting
On 2011-10-13 07:47, Javier Martinez Canillas wrote: On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-13 06:32, Enrico wrote: On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomasg...@mlbassoc.comwrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Hello, Yes, I noticed that the images arrive correctly but disabling the interlaced mode fldmode == 0 and not setting an offset to copy the odd/even fields ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); If you do so, you will see a image that is composed of both odd and even frames each of them half the size of the deinterlaced image. So the TVP is producing the correct YUV data and also the ISP is decoding correctly using the BT.656 embedded sync info. I tried these changes and what I get is the top of each frame looks quite good, but the bottom is always blank. Have a look at http://www.mlbassoc.com/misc/test-static.mp4 http://www.mlbassoc.com/misc/test-movement.mp4 Any ideas about how to get the other 1/2 of the frames? The one thing I see is that in the 'test-movement' file, there doesn't seem to be any ghosting (or tearing) even though this is from a pretty low quality camera. I'm hopeful that I can get the remainder of the data and attempt the software interlace and come up with really good image. My guess is that has to do with the buffers. I guess there are two ways to probe this. 1- Hack yavta to memset to 0 every buffer before passing to V4L2 layer. Is there any way to prove this by doing the de-interlacing in software? 2- Deinterlace by software. As I said before deactivate the interlaced mode and get the two frames, then you can copy 1440 bytes (one line) from the first sub-frame (lines[0]) and then copy one line of the second sub-frame (lines[height/2-1]), and so on. Since YUV data is
Re: OMAP3 ISP ghosting
On 2011-10-11 07:20, Gary Thomas wrote:
As a number of us have seen, when using the OMAP3 ISP with a BT-656
sensor, e.g. TVP5150, the results are not 100% correct. Some number
of frames (typically 2) will be correct, followed by another set (3)
which are incorrect and show only partially correct data. Note: I
think the numbers (2 correct, 3 wrong) are not cast in stone and may
be related to some other factors like number of buffers in use, etc.
Anyway, I've observed that in the incorrect frames, 1/2 the data is
correct (even lines?) and the other 1/2 is wrong. One of my customers
pointed out that it looks like the incorrect data is just what was
left in memory during some previous frame. I'd like to prove this
by zeroing the entire frame data memory before the frame is captured.
That way, there won't be stale data from a previous frame, but null
data which should show up strongly when examined. Does anyone in this
group have a suggestion the best way/place to do this?
Final question: given a properly connected TVP5150-CCDC, including
all SYNC signals, could this setup be made to work in RAW, non BT-656
mode? My board at least has all of these signals routed, so it should
just be a matter of configuring the software...
Any ideas on this? My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
diff --git a/arch/arm/mach-omap2/board-cobra3530p60.c
b/arch/arm/mach-omap2/board-cobra3530p60.c
index a8e8f21..5e97838 100644
--- a/arch/arm/mach-omap2/board-cobra3530p60.c
+++ b/arch/arm/mach-omap2/board-cobra3530p60.c
@@ -480,6 +480,6 @@ static struct isp_v4l2_subdevs_group
cobra3530p60_camera_subdevs[] = {
.data_lane_shift = 0,
.clk_pol = 1,
-.bt656 = 1,
+.bt656 = 0,
.fldmode = 1,
}
},
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index f4a66c7..26360ae 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -499,7 +499,7 @@ static const struct i2c_reg_value tvp5150_init_enable[] = {
},{ /* Activates video std autodetection for all standards */
TVP5150_AUTOSW_MSK, 0x0
},{ /* Default format: 0x47. For 4:2:2: 0x40 */
- TVP5150_DATA_RATE_SEL, 0x47
+ TVP5150_DATA_RATE_SEL, 0x40 /*0x47*/
},{
TVP5150_CHROMA_PROC_CTL_1, 0x0c
},{
@@ -993,7 +993,7 @@ static int tvp515x_s_stream(struct v4l2_subdev *subdev, int
enable)
/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
if (enable)
- tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09);
+ tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09+0x04);
else
tvp5150_write(subdev, TVP5150_MISC_CTL, 0x00);
