On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomas <g...@mlbassoc.com> wrote: > For days, I've been chasing ghosts :-) I know they are still there, > but I think they are more a function of the source than the ISP setup. > So, I went looking for a better source, NTSC in my case. My choice is > is a DVD player with known good video (I'm convinced that my cheap NTSC > camera produces crap, especially when there is a lot of motion in the > frames). Looking at this on an analogue TV (yes, they still exist!), > the picture is not bad, so I think it's a good choice, at least when > trying to understand what's happening with the OMAP3 ISP. > > Look at these two pictures: > http://www.mlbassoc.com/misc/nemo-00001.png > http://www.mlbassoc.com/misc/nemo-swapped-00001.png > > These represent one frame of data captured via my OMAP3 ISP + TVP5150 > from a DVD (sorry, Disney). The first is a raw conversion of the > frame using ffmpeg. As you can see, there seem to be lines swapped, > so I wrote a little program to swap the lines even/odd. The second > (nemo-swapped) shows what this looks like. Obviously, the data is > not being stored in memory correctly. Does anyone know how to adjust > the ISP to make this work the right way around? Currently in ispccdc.c, we > have: > 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); > > I tried this: > ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, > 2); > ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, > 0); > ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, > 2); > ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); > but this lead to a kernel panic :-( > > Somehow, we need to be storing the data something like this: > EE EE EE EE ... > EO EO EO EO ... > OE OE OE OE ... > OO OO OO OO ... > but the current layout is 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); > > EO EO EO EO ... > EE EE EE EE ... > OO OO OO OO ... > OE OE OE OE ... > > First, I need to get the data into memory in the correct order :-) > > Note: these results are consistent, i.e. if I stop things and do another > grab, they are incorrect in the same [wrong] order.
Just set the FINV bit (search for it in ispccdc.c), i tested it before and i had the opposite result (from a good looking nemo-swapped-like picture to a bad one). > I've not done any recent tests with the gstreamer modules and the TI DSP > code, > but I will shortly. We'll see how well that does. I've tested it with the dsp and nothing changes, same problems. But i will be happy if proven wrong! 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
