On 2011-10-06 10:11, Javier Martinez Canillas wrote:
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.
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.
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
--
------------------------------------------------------------
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
