Re: OMAP3 ISP - interlaced data incorrect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomas <gary@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux