Hi, Gary Gary Thomas wrote: > Sorry for cross-posting, but I'm not sure where best to get help :-( > > I'm working on an OMAP/3530 board (similar to the BeagleBoard, > but of local design). I'm using the 2.6.32+ kernel from Angstrom > which has the DVSDK support, including ISP camera support using > V4L2. My camera is NTSC or PAL composite input through a TVP5150m1 > decoder into the ISP, using 8 bit BT-656 data. This mostly works, > but I'm suffering some strange problems. My queries to the TI forums > have not yielded any [useful] feedback, so I'm hoping someone on these > lists can help. > > I'm wondering if the BT-656 data from the TVP5150m1 device is compatible > with the ISP, based on the comments in TRM 12.1.1 which implies that > interlaced data is not supported via BT-656 and I'm pretty sure the > data from the TVP _is_ interlaced since it came from an interlaced > TV/video camera. Of course, I could be reading this incorrectly... > > My problem is the raw data from the ISP (UYVY422, grabbed using > gstreamer v4l2src (*)) does not seem to be quite right. If I just > look at it, e.g. > gst-launch v4l2src ! > 'video/x-raw-yuv,width=720,height=576,format=(fourcc)UYVY' ! \ > ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! > xvimagesink > the images will "tear" and streak if there is any motion. Sometimes, > there are ghosts (faded after-images) left behind that last for many > seconds. Eventually, they will clear up, especially if the image > becomes more static. If I try to do much more processing of these images, > e.g. encode them into some compressed format like H264, the results > are horrible. > I'm pretty sure that the ISP driver that you using haven't proper support for interlaced data. I guess the image data should passed through CCDC-> resizer, in that case the odd and even lines should be resized separately. One every frame odd or even data should be resized. This comes from the interlaced nature of the input data. The resizer in the ISP expects progressive data, IMO. So this is a driver issue. I would suggest you to look into Davinci isp driver, vpfe_capture.c in vpfe_isr, vdint1_isr. There is solution for interlaced data in CCDC part of the ISP. > (*) I also wrote a very simple program to grab the data from the camera > instead of using gstreamer v4l2src. This produces the same poorly > constructed > UYVY stream, so I don't think the problem is in the v4l2src component (but > it _could_ be in the v4l2 kernel code, but it doesn't really do anything > with the camera data except for managing the DMA+buffers) > > I created a known data source (not from the camera interface), using > ffmpeg to produce a UYVY422 data file from an MP4 that I know looks good. > I used this to test the back-end of the pipeline. It does not suffer these > problems, even when the image has lots of motion. > > What leads me to think this is all about the camera/ISP path > is that if I introduce a scaling component, I get even stranger > results. For example, this pipeline > gst-launch v4l2src always-copy=FALSE ! > video/x-raw-yuv,width=720,height=576 ! \ > TIVidResize name=qos-scaler contiguousInputFrame=TRUE ! \ > 'video/x-raw-yuv,format=(fourcc)UYVY,width=320,height=240' ! > ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! > xvimagesink > often has a Venetian-blind look - alternating good data with dark grey > bars (that seem to have the desired data underneath). The image tearing > and ghosting is much exaggerated. > > Running that same pipeline with the known good UYVY data file does > not exhibit these behaviours. > > Does anyone have any ideas what might be causing these problems? > Ever seen such before? > Any ideas what I can look at or, if necessary, a better place to ask? > I'm pretty sure I'm up against hardware problems (could be the design, > could be the driver or configuration). > > If anyone has ideas or can help and need to see any of these data, I'll > gladly provide them. > Could send a file with tearing effect for sure, please send only to me without cc-ing the mailing lists, I suppose that the file will be big. > Thanks for any help/ideas > Regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
