On Thu, Oct 6, 2011 at 5:47 PM, Gary Thomas <gary@xxxxxxxxxxxx> wrote: > On 2011-10-06 08:50, Javier Martinez Canillas wrote: >> >> On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas >> <martinez.javier@xxxxxxxxx> wrote: >>> >>> On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomas<gary@xxxxxxxxxxxx> wrote: >>>> >>>> On 2011-10-06 01:51, Javier Martinez Canillas wrote: >>>>> >>>>> On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas >>>>> <martinez.javier@xxxxxxxxx> wrote: >>>>>> >>>>>> On Wed, Oct 5, 2011 at 6:28 PM, Enrico<ebutera@xxxxxxxxxxxxxxxx> >>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> since we are all interested in this driver (and tvp5150) i'll try to >>>>>>> make a summary of the current situation and understand what is needed >>>>>>> to finally get it into the main tree instead of having to apply a >>>>>>> dozen patches manually. >>>>>>> >>>>>>> The current status of git repositories/branches is: >>>>>>> >>>>>>> - main tree: working (i suppose) but no support for bt656 input >>>>>>> >>>>>>> - pinchartl/media: >>>>>>> * omap3isp-omap3isp-next: i think it's in sync with linuxtv master >>>>>>> (for the omap3-isp parts) >>>>>>> * omap3isp-omap3isp-yuv: like ..next but with some additional format >>>>>>> patches >>>>>>> >>>>>>> "Floating" patches: >>>>>>> >>>>>>> - Deepthy: sent patches (against mainline) to add bt656 support >>>>>>> >>>>>>> Laurent made some comments, i haven't seen a v2 to be applied >>>>>>> >>>>>>> - Javier: sent patches for tvp5150, currently discussed on >>>>>>> linux-media; possible patches/fixes for omap3-isp >>>>>>> >>>>> >>>>> Hello, >>>>> >>>>> Since the patches are not against mainline I can't post for reviewing >>>>> but can be found in one of our development trees [1]. Comments are >>>>> highly appreciated. >>>>> >>>>> The tree is a 2.6.37 that already contain Deepthy patch. I rebased my >>>>> changes on top of that to correctly support both BT656 an non-BT656 >>>>> video data processing. >>>>> >>>>> [1]: >>>>> >>>>> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.37.y-next >>>> >>>> Any chance of rebasing these against a more up to date kernel, e.g. >>>> 3.2-working >>>> with the patches Laurent sent today? >>>> >>> >>> Sure, but I won't have time to do it neither today nor tomorrow. But >>> will do it during the weekend. >>> >>>>>> >>>>>> I will find some free time slots to resolve the issues called out by >>>>>> Sakari, Hans and Mauro and resend the patch-set for the tvp5151. >>>>>> >>>>>> Also I can send the patches of the modifications I made to the ISP >>>>>> driver. Right now I'm working on top of Deepthy patches. >>>>>> >>>>>> I can either send on top of that patch or rebase to mainline, whatever >>>>>> you think is better for reviewing. >>>>>> >>>>>>> Now what can we all do to converge to a final solution? I think this >>>>>>> is also blocking the possible development/test of missing features, >>>>>>> like the recently-discussed resizer and cropping ones. >>>>>>> >>>>>>> Enrico >>>>>>> >>>>>> >>>>>> Right now I have a working the tvp5151 with the ISP. I can capture >>>>>> ITU-R BT656 video both in PAL-M and NTSC standard. Also, the whole >>>>>> pipeline is configured automatically with the video standard detected >>>>>> by the tvp5151. Also, I'm using the CCDC to crop the frames and only >>>>>> capture the active lines for each standard (576 for PAL and 480 for >>>>>> NTSC) using the CCDC to crop the image. >>>>>> >>>>> >>>>> As I told you before video capturing is working for both PAL and NTSC >>>>> using standard V4L2 application (i.e: gstreamer) but the video still >>>>> shows some motion artifacts. Capturing YUV frames and looking at them >>>>> I realized that there does exist a pattern, the sequence 2 frames >>>>> correct and 3 frames with interlacing effects always repeats. >>>> >>>> I think I've seen this as well. Could you provide a short video >>>> which shows the artefacts? >>>> >>> >>> Yes, I've attached a 16-frame video file. It is a PAL-M video >>> (720x576) in YUV 4:22 data format. Please let me know if it is OK for >>> you. >>> >> >> Sorry, I didn't notice the size of the image (13 MB) and got a lot of >> rejects from your MTAs. I uploaded the file to my personal github >> account [1]. >> >> [1]: >> https://github.com/martinezjavier/omap3isp_tvp5151/blob/master/pal.yuv > > Very interesting. What was your source (camera type, etc)? A samsung HD video camera connected to the TVP with its RCA video connector. But the artifact its independent of the analog input data, I've tried with an Sony Cybershot camera and other input sources. > How are you looking (or extracting) individual frames for analysis? > I'm using gstreamer to capture RAW YUV data and MPEG encoded video using the DSP. This are my pipelines: YUV: gst-launch-0.10 -v v4l2src device=/dev/video2 queue-size=16 num-buffers=16 ! video/x-raw-yuv,format=\(fourcc\)UYVY ! filesink location=capture.out MPEG: gst-launch-0.10 -v v4l2src device=/dev/video2 queue-size=8 ! video/x-raw-yuv,format=\(fourcc\)UYVY ! TIVidenc1 codecName=mpeg4enc engineName=codecServer ! qtmux ! filesink location=capture.m4v > I see much the same sort of artefacts as you are. An example is at > http://www.mlbassoc.com/misc/untitled.m2t > This is a little example I put together using kdenlive. The first segment > is the raw video from my camera, imported via USB. The second is roughly > the same video captured using my OMAP board and converted to MP4 on the fly > by this command: > ffmpeg -r 30/1 -pix_fmt uyvy422 -s 720x524 -f video4linux2 -i /dev/video2 > -qscale 1 -f mp4 test1.mp4 > I think there are some aspect ratio issues with these but what bothers me > the most is how much the captured data tears whenever there is a lot of > motion in the video. > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > Best regards, -- 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
