On Fri, Oct 7, 2011 at 1:39 PM, Gary Thomas <gary@xxxxxxxxxxxx> wrote: > On 2011-10-07 05:02, Javier Martinez Canillas wrote: >> >> On Fri, Oct 7, 2011 at 12:36 PM, Enrico<ebutera@xxxxxxxxxxxxxxxx> wrote: >>> >>> On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomas<gary@xxxxxxxxxxxx> wrote: >>>> >>>> Do we know for sure that these problems are happening in the ISP itself >>>> or could they possibly be in the TVP5150? Does anyone have experience >>>> with a different analogue encoder? >>> >>> Never tried another encoder, but at this point it's something to look >>> at. I don't think some TI people will say "yes the encoder has >>> ghosting artifacts". >>> >>> Enrico >>> >> >> I have never tried with an different decoder either. I don't think >> this is a HW thing. As far as I know the tvp5150 is used in some >> em28xx devices that is what Mauro said, and he would notice that >> behaviour. >> >> Also, if you try getting 625 lines (for PAL) but disable the >> line-output-formatter for deinterlacing, i.e: >> >> pdata->fldmode = 0; >> >> ispccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0); >> ispccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); >> ispccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0); >> ispccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); >> >> Then you get a frame with the 313 odd lines and 312 even lines >> correctly. That means that the TVP5151 is generating correctly the >> interlaced video. >> >> Also the ISP is doing correctly the deinterlacing for a some frames. >> But all the approaches used so far (wait for two VD0 interrupt to >> change the CCCDC output memory direction), looks more like a hack than >> a clean solution to me, but maybe is the only way to do it with the >> ISP. > > Looking at your sequence of pictures, you can see that image #10 and #11 > are pretty good, but #12..14 are all bad, then #15 & 16 are OK again. > In the bad ones, it looks like every other line has been shifted left by > some number of pixels. It's hard to tell, but I think the shift is constant > when it happens. > Yes the sequence is always the same 2 good, 3 bad. That is why I think that is something related to buffers management. >> >> My guess is that the problem is the ISP driver that before this >> configuration (TVP5150/1 + ISP) had never been tested with an video >> decoder that generates interlaced data. > > Of course, there's the comment in the manual that says it's not supported > :-) > According to 12.4.4.1, BT656 (ITU) data can only use progressive scan > sensors. > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
