On 2011-10-14 17:43, Enrico wrote:
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).

That works great, thanks.  Maybe we need another user flag, like fldmode,
for this?



    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!

I'll play with this a bit more tomorrow.

--
------------------------------------------------------------
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

Reply via email to