From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from hermes.mlbassoc.com ([64.234.241.98]:48287 "EHLO mail.chez-thomas.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752274Ab1JGKWL (ORCPT ); Fri, 7 Oct 2011 06:22:11 -0400 Message-ID: <4E8ED2CF.70302@mlbassoc.com> Date: Fri, 07 Oct 2011 04:22:07 -0600 From: Gary Thomas MIME-Version: 1.0 To: Javier Martinez Canillas CC: Enrico , Laurent Pinchart , Deepthy Ravi , Adam Pledger , linux-media@vger.kernel.org, Sakari Ailus Subject: Re: omap3-isp status References: <4E8DB490.7000403@mlbassoc.com> <4E8DCD79.3060507@mlbassoc.com> <4E8EC793.9010001@mlbassoc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 2011-10-07 04:08, Javier Martinez Canillas wrote: > On Fri, Oct 7, 2011 at 11:34 AM, Gary Thomas wrote: >> On 2011-10-06 10:11, Javier Martinez Canillas wrote: >>> >>> On Thu, Oct 6, 2011 at 5:47 PM, Gary Thomas wrote: >>>> >>>> On 2011-10-06 08:50, Javier Martinez Canillas wrote: >>>>> >>>>> On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas >>>>> wrote: >>>>>> >>>>>> On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomas >>>>>> wrote: >>>>>>> >>>>>>> On 2011-10-06 01:51, Javier Martinez Canillas wrote: >>>>>>>> >>>>>>>> On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Wed, Oct 5, 2011 at 6:28 PM, Enrico >>>>>>>>> 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. >> >> I figured out how to split your raw video into individual frames. The >> problems >> don't look like only interlace issues to me. Take a look at >> http://www.mlbassoc.com/misc/UYVY_examples/PAL_from_JavierMartinezCanillas/ >> especially image #9 which shows some very serious ghosting. >> > > Yes, I don't know if this is because I'm not copying the sub-frame in > the correct buffer or another. > >> I see the same behaviour here and it bothers me quite a lot. I do hope that >> we can figure out what's causing it - we have a number of customers that are >> wanting to do analogue video capture using the OMAP+TVP5150, so it's pretty >> important to us. >> >> Thanks for your time > > Yes, we are in the same situation. I did my best to fix this but I > couldn't. I minimized the effect with those changes but there still > exists. 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? > > I hope as Enrico says that Laurent, Sakari (who im cc'ing here) or > Deepthy that know better the ISP can enter the discussion. So we can > all work together to resolve this issue. > > Best regards, > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------