date:20111007


Hi,

Hmm, nasty...

On 10/06/2011 01:13 PM, Hans Verkuil wrote:

Hi Hans!

I've been looking into a problem with libv4l2 that occurs when you change TV
standard or video preset using VIDIOC_S_STD or VIDIOC_S_DV_PRESET. These calls
will change the format implicitly (e.g. if the current format is set for PAL
at 720x576 and you select NTSC, then the format will be reset to 720x480).

However, libv4l2 isn't taking this into account and will keep using the cached
dest_fmt value. It is easy to reproduce this using qv4l2.

The same problem is likely to occur with S_CROP (haven't tested that yet,
though): calling S_CROP can also change the format.

To be precise: S_STD and S_DV_PRESET can change both the crop rectangle and
the format, and S_CROP can change the format.


First of all it would be good to actually document this behavior of
VIDIOC_S_STD or VIDIOC_S_DV_PRESET, the current docs don't mention this at all:
http://linuxtv.org/downloads/v4l-dvb-apis/standard.html

I've attached 2 patches which should make libv4l2 deal with this correctly.
I assume you've a reproducer for this and I would appreciate it if you could 
test
if these patches actually fix the issue you are seeing.

Regards,

Hans
From a5abaaa08602b540c88ae4776f557a3b0c34b24d Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Fri, 7 Oct 2011 09:18:39 +0200
Subject: [PATCH 1/2] libv4l2: Move s_fmt handling code into a helper function

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 lib/libv4l2/libv4l2.c |  195 +
 1 files changed, 98 insertions(+), 97 deletions(-)

diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 977179a..f7ec85d 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -881,6 +881,101 @@ static void v4l2_set_src_and_dest_format(int index,
devices[index].dest_fmt = *dest_fmt;
 }
 
+static int v4l2_s_fmt(int index, struct v4l2_format *dest_fmt)
+{
+   struct v4l2_format src_fmt;
+   struct v4l2_pix_format req_pix_fmt;
+   int result;
+
+   /* Don't be lazy on uvc cams, as this triggers a bug in the uvcvideo
+  driver in kernel = 2.6.28 (with certain cams) */
+   if (!(devices[index].flags  V4L2_IS_UVC) 
+   v4l2_pix_fmt_compat(devices[index].dest_fmt, dest_fmt)) {
+   *dest_fmt = devices[index].dest_fmt;
+   return 0;
+   }
+
+   if (v4l2_log_file) {
+   int pixfmt = dest_fmt-fmt.pix.pixelformat;
+
+   fprintf(v4l2_log_file, VIDIOC_S_FMT app requesting: 
%c%c%c%c\n,
+   pixfmt  0xff,
+   (pixfmt  8)  0xff,
+   (pixfmt  16)  0xff,
+   pixfmt  24);
+   }
+
+   result = v4lconvert_try_format(devices[index].convert,
+  dest_fmt, src_fmt);
+   if (result) {
+   int saved_err = errno;
+   V4L2_LOG(S_FMT error trying format: %s\n, strerror(errno));
+   errno = saved_err;
+   return result;
+   }
+
+   if (src_fmt.fmt.pix.pixelformat != dest_fmt-fmt.pix.pixelformat 
+   v4l2_log_file) {
+   int pixfmt = src_fmt.fmt.pix.pixelformat;
+
+   fprintf(v4l2_log_file,
+   VIDIOC_S_FMT converting from: %c%c%c%c\n,
+   pixfmt  0xff, (pixfmt  8)  0xff,
+   (pixfmt  16)  0xff, pixfmt  24);
+   }
+
+   /* Maybe after try format has adjusted width/height etc, to whats
+  available nothing has changed (on the cam side) ? */
+   if (!(devices[index].flags  V4L2_IS_UVC) 
+   v4l2_pix_fmt_compat(devices[index].src_fmt, src_fmt)) {
+   v4l2_set_src_and_dest_format(index, devices[index].src_fmt,
+   dest_fmt);
+   return 0;
+   }
+
+   result = v4l2_check_buffer_change_ok(index);
+   if (result)
+   return result;
+
+   req_pix_fmt = src_fmt.fmt.pix;
+   result = devices[index].dev_ops-ioctl(devices[index].dev_ops_priv,
+  devices[index].fd,
+  VIDIOC_S_FMT, src_fmt);
+   if (result) {
+   int saved_err = errno;
+   V4L2_LOG_ERR(setting pixformat: %s\n, strerror(errno));
+   /* Report to the app dest_fmt has not changed */
+   *dest_fmt = devices[index].dest_fmt;
+   errno = saved_err;
+   return result;
+   }
+
+   /* See if we've gotten what try_fmt promised us
+  (this check should never fail) */
+   if (src_fmt.fmt.pix.width != req_pix_fmt.width ||
+   src_fmt.fmt.pix.height != req_pix_fmt.height ||
+   src_fmt.fmt.pix.pixelformat != req_pix_fmt.pixelformat) {
+   V4L2_LOG_ERR(set_fmt gave us a different result then 
try_fmt!\n);

Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git


Hi,

On 10/06/2011 02:23 PM, Hans Verkuil wrote:

Currently we have three repositories containing libraries and utilities that
are relevant to the media drivers:

dvb-apps (http://linuxtv.org/hg/dvb-apps/)
v4l-utils (http://git.linuxtv.org/v4l-utils.git)
media-ctl (git://git.ideasonboard.org/media-ctl.git)

It makes no sense to me to have three separate repositories, one still using
mercurial and one that isn't even on linuxtv.org.

I propose to combine them all to one media-utils.git repository. I think it
makes a lot of sense to do this.


Didn't we've this same discussion back when v4l-utils was formed, and didn't
the dvb-apps people want to keep doing there own tree + release?

I'm fine with this if it gets buy in from the dvb-apps people, but if they
don't want this I'm strongly against it!

Which would leave just media-ctl, I'm fine with that going into v4l-utils,
and Laurent getting direct push access to v4l-utils (if he does not have
that already), but in that case I would like to keep the v4l-utils name as
renaming is a pain for distros and leads to confusion.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

2011-10-07 Thread Enrico

On Thu, Oct 6, 2011 at 6:05 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
 On Thu, Oct 6, 2011 at 5:25 PM, Enrico ebut...@users.berlios.de wrote:
 - i don't see Deepthy patches, it seems to be based on the
 pre-Deepthy-patches driver and fixed (not that this is a bad thing!);
 i say this because, like Gary, i'm interested in a possible forward
 porting to a more recent kernel so i was searching for a starting
 point


 I didn't know there was a more recent version of Deepthy patches,
 Since they are not yet in mainline we should decide if we work on top
 of that or on top of mainline. Deepthy patches are very good to
 separate bt656 and non-bt656 execution inside the ISP, also add a
 platform data variable to decide which mode has to be used.

 But reading the documentation and from my experimental validation I
 think that there are a few things that can be improved.

 First the assumption that we can use FLDSTAT to check if a frame is
 ODD or EVEN I find to not always be true. Also I don't know who sets
 this value since in the TRM always talks as it is only used with
 discrete syncs.


Yes about FLDSTAT i noticed the same thing. And that's why we need
someone that knows the ISP better to help us


 Also, I don't think that we should change the ISP CCDC configuration
 inside the VD0 interrupt handler. Since the shadowed registers only
 can be accessed during a frame processing, or more formally the new
 values are taken at the beginning of a frame execution.

 By the time we change for example the output address memory for the
 next buffer in the VD0 handler, the next frame is already being
 processed so that value won't be used for the CCDC until that frame
 finish. So It is not behaving as the code expect, since for 3 frames
 the CCDC output memory address will be the same.

 That is why I move most of the logic to the VD1 interrupt since there
 the current frame didn't finish yet and we can configure the CCDC for
 the next frame.

 But to do that the buffer for the next frame and the releasing of the
 last buffer can't happen simultaneously, that is why I decouple these
 two actions.

 Again, this is my own observations and what I understood from the TRM
 and I could be wrong.


I can't comment on that, i hope Laurent or Deepthy will join the discussion...


 - i don't think that adding the priv field in v4l2-mediabus.h will
 be accepted, and since it is related to the default cropping you added
 i think it can be dropped and just let the user choose the appropriate
 cropping


 Yes, probably is too much of a hack, but I didn't know of another way
 that the subdev could report to the ISP of the standard and since
 v4l2_pix_format has also a priv field, I think it could be at least a
 temporary solution (remember that we want this to work first and then
 we plan to do it right for upstream submission).


...and my hope continues here.


Enrico
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l2 misbehavior after calling S_STD or S_DV_PRESET

2011-10-07 Thread Hans Verkuil

On Friday 07 October 2011 09:57:42 Hans de Goede wrote:
 Hi,
 
 Hmm, nasty...
 
 On 10/06/2011 01:13 PM, Hans Verkuil wrote:
  Hi Hans!
  
  I've been looking into a problem with libv4l2 that occurs when you change
  TV standard or video preset using VIDIOC_S_STD or VIDIOC_S_DV_PRESET.
  These calls will change the format implicitly (e.g. if the current
  format is set for PAL at 720x576 and you select NTSC, then the format
  will be reset to 720x480).
  
  However, libv4l2 isn't taking this into account and will keep using the
  cached dest_fmt value. It is easy to reproduce this using qv4l2.
  
  The same problem is likely to occur with S_CROP (haven't tested that yet,
  though): calling S_CROP can also change the format.
  
  To be precise: S_STD and S_DV_PRESET can change both the crop rectangle
  and the format, and S_CROP can change the format.
 
 First of all it would be good to actually document this behavior of
 VIDIOC_S_STD or VIDIOC_S_DV_PRESET, the current docs don't mention this at
 all: http://linuxtv.org/downloads/v4l-dvb-apis/standard.html

Odd, I'd have sworn that it was in the docs.

The full list of ioctls that can change both the crop settings and the format 
is:

VIDIOC_S_STD
VIDIOC_S_DV_PRESET
VIDIOC_S_DV_TIMINGS
VIDIOC_S_INPUT (can implicitly change standard/preset)
VIDIOC_S_OUTPUT (ditto)
VIDIOC_S_CROP

Note that I suspect that there are quite a few drivers that do not handle this
correctly. After all, for normal SDTV capture cards you almost never change
the TV standard once it is set up at the start so I doubt if this has been
tested much. For DV_PRESET it is much more common to switch from e.g.
720p to 1080p. That is how I found this issue.

 I've attached 2 patches which should make libv4l2 deal with this correctly.
 I assume you've a reproducer for this and I would appreciate it if you
 could test if these patches actually fix the issue you are seeing.

Almost working. The second patch forgot to set src_fmt.type, so I got an error 
back. After initializing it to BUF_TYPE_VIDEO_CAPTURE it worked fine.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

On Fri, Oct 7, 2011 at 10:54 AM, Enrico ebut...@users.berlios.de wrote:
 On Thu, Oct 6, 2011 at 6:05 PM, Javier Martinez Canillas
 martinez.jav...@gmail.com wrote:
 On Thu, Oct 6, 2011 at 5:25 PM, Enrico ebut...@users.berlios.de wrote:
 - i don't see Deepthy patches, it seems to be based on the
 pre-Deepthy-patches driver and fixed (not that this is a bad thing!);
 i say this because, like Gary, i'm interested in a possible forward
 porting to a more recent kernel so i was searching for a starting
 point


 I didn't know there was a more recent version of Deepthy patches,
 Since they are not yet in mainline we should decide if we work on top
 of that or on top of mainline. Deepthy patches are very good to
 separate bt656 and non-bt656 execution inside the ISP, also add a
 platform data variable to decide which mode has to be used.

 But reading the documentation and from my experimental validation I
 think that there are a few things that can be improved.

 First the assumption that we can use FLDSTAT to check if a frame is
 ODD or EVEN I find to not always be true. Also I don't know who sets
 this value since in the TRM always talks as it is only used with
 discrete syncs.


 Yes about FLDSTAT i noticed the same thing. And that's why we need
 someone that knows the ISP better to help us


Great, good to know that I'm not the only one that noticed this behavior.


 Also, I don't think that we should change the ISP CCDC configuration
 inside the VD0 interrupt handler. Since the shadowed registers only
 can be accessed during a frame processing, or more formally the new
 values are taken at the beginning of a frame execution.

 By the time we change for example the output address memory for the
 next buffer in the VD0 handler, the next frame is already being
 processed so that value won't be used for the CCDC until that frame
 finish. So It is not behaving as the code expect, since for 3 frames
 the CCDC output memory address will be the same.

 That is why I move most of the logic to the VD1 interrupt since there
 the current frame didn't finish yet and we can configure the CCDC for
 the next frame.

 But to do that the buffer for the next frame and the releasing of the
 last buffer can't happen simultaneously, that is why I decouple these
 two actions.

 Again, this is my own observations and what I understood from the TRM
 and I could be wrong.


 I can't comment on that, i hope Laurent or Deepthy will join the discussion...



I second you on that, we need someone who knows the ISP better than we
do. I have to fix this anyway, so it is better if I can do it the
right way and the code gos upstream, so we don't have to internally
maintain a separate patch-set and forward port for each kernel release
we do.

 - i don't think that adding the priv field in v4l2-mediabus.h will
 be accepted, and since it is related to the default cropping you added
 i think it can be dropped and just let the user choose the appropriate
 cropping


 Yes, probably is too much of a hack, but I didn't know of another way
 that the subdev could report to the ISP of the standard and since
 v4l2_pix_format has also a priv field, I think it could be at least a
 temporary solution (remember that we want this to work first and then
 we plan to do it right for upstream submission).


 ...and my hope continues here.


 Enrico


-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

2011-10-07 Thread Gary Thomas

On 2011-10-06 10:11, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 5:47 PM, Gary Thomasg...@mlbassoc.com wrote:

On 2011-10-06 08:50, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas
martinez.jav...@gmail.comwrote:

On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomasg...@mlbassoc.comwrote:

On 2011-10-06 01:51, Javier Martinez Canillas wrote:

On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:

On Wed, Oct 5, 2011 at 6:28 PM, Enricoebut...@users.berlios.de
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

Re: omap3-isp status

On Fri, Oct 7, 2011 at 11:34 AM, Gary Thomas g...@mlbassoc.com wrote:
On 2011-10-06 10:11, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 5:47 PM, Gary Thomasg...@mlbassoc.com wrote:

On 2011-10-06 08:50, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:

On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomasg...@mlbassoc.com
wrote:

On 2011-10-06 01:51, Javier Martinez Canillas wrote:

On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:

On Wed, Oct 5, 2011 at 6:28 PM, Enricoebut...@users.berlios.de
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.

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)?

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

Re: omap3-isp status

2011-10-07 Thread Gary Thomas

On 2011-10-07 04:08, Javier Martinez Canillas wrote:

On Fri, Oct 7, 2011 at 11:34 AM, Gary Thomasg...@mlbassoc.com wrote:

On 2011-10-06 10:11, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 5:47 PM, Gary Thomasg...@mlbassoc.comwrote:

On 2011-10-06 08:50, Javier Martinez Canillas wrote:

On Thu, Oct 6, 2011 at 4:29 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:

On Thu, Oct 6, 2011 at 4:00 PM, Gary Thomasg...@mlbassoc.com
wrote:

On 2011-10-06 01:51, Javier Martinez Canillas wrote:

On Wed, Oct 5, 2011 at 7:43 PM, Javier Martinez Canillas
martinez.jav...@gmail.comwrote:

On Wed, Oct 5, 2011 at 6:28 PM, Enricoebut...@users.berlios.de
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.

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)?

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

Re: omap3-isp status

2011-10-07 Thread Enrico

On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomas g...@mlbassoc.com 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

On Fri, Oct 7, 2011 at 12:36 PM, Enrico ebut...@users.berlios.de wrote:
 On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomas g...@mlbassoc.com 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.

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.

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

2011-10-07 Thread Gary Thomas


On 2011-10-07 05:02, Javier Martinez Canillas wrote:

On Fri, Oct 7, 2011 at 12:36 PM, Enricoebut...@users.berlios.de  wrote:

On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomasg...@mlbassoc.com  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.



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

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp status

On Fri, Oct 7, 2011 at 1:39 PM, Gary Thomas g...@mlbassoc.com wrote:
 On 2011-10-07 05:02, Javier Martinez Canillas wrote:

 On Fri, Oct 7, 2011 at 12:36 PM, Enricoebut...@users.berlios.de  wrote:

 On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomasg...@mlbassoc.com  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git


Em 07-10-2011 03:05, Hans Verkuil escreveu:

On Friday, October 07, 2011 04:07:38 Mauro Carvalho Chehab wrote:

Em 06-10-2011 14:24, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 10:27, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 09:23, Hans Verkuil escreveu:

Currently we have three repositories containing libraries and utilities that
are relevant to the media drivers:

dvb-apps (http://linuxtv.org/hg/dvb-apps/)
v4l-utils (http://git.linuxtv.org/v4l-utils.git)
media-ctl (git://git.ideasonboard.org/media-ctl.git)

It makes no sense to me to have three separate repositories, one still using
mercurial and one that isn't even on linuxtv.org.

I propose to combine them all to one media-utils.git repository. I think it
makes a lot of sense to do this.

After the switch the other repositories are frozen (with perhaps a README
pointing to the new media-utils.git).

I'm not sure if there are plans to make new stable releases of either of these
repositories any time soon. If there are, then it might make sense to wait
until that new stable release before merging.

Comments?


I like that idea. It helps to have the basic tools into one single repository,
and to properly distribute it.


Ok, I found some time to do an experimental merge of the repositories. It is 
available
at:

http://git.linuxtv.org/mchehab/media-utils.git

For now, all dvb-apps stuff is on a separate directory. It makes sense to latter
re-organize the directories. Anyway, the configure script will allow disable
dvb-apps, v4l-utils and/or libv4l. The default is to have all enabled.

One problem I noticed is that the dvb-apps are at version 1.1. So, if we're
releasing a new version, we'll need to jump from 0.9 to dvb-apps version + 1.
So, IMO, the first version with the merge should be version 1.2.

Comments?


Strange:

$ git clone git://git.linuxtv.org/mchehab/media-utils.git
Cloning into media-utils...
fatal: The remote end hung up unexpectedly

I've no problem with other git trees.


Re-cloned and ran update-server-info. Please test again.

Thanks,
Mauro.


Regards,

Hans


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l2 misbehavior after calling S_STD or S_DV_PRESET


Hi,

On 10/07/2011 11:06 AM, Hans Verkuil wrote:

On Friday 07 October 2011 09:57:42 Hans de Goede wrote:

Hi,

Hmm, nasty...

On 10/06/2011 01:13 PM, Hans Verkuil wrote:

Hi Hans!

I've been looking into a problem with libv4l2 that occurs when you change
TV standard or video preset using VIDIOC_S_STD or VIDIOC_S_DV_PRESET.
These calls will change the format implicitly (e.g. if the current
format is set for PAL at 720x576 and you select NTSC, then the format
will be reset to 720x480).

However, libv4l2 isn't taking this into account and will keep using the
cached dest_fmt value. It is easy to reproduce this using qv4l2.

The same problem is likely to occur with S_CROP (haven't tested that yet,
though): calling S_CROP can also change the format.

To be precise: S_STD and S_DV_PRESET can change both the crop rectangle
and the format, and S_CROP can change the format.


First of all it would be good to actually document this behavior of
VIDIOC_S_STD or VIDIOC_S_DV_PRESET, the current docs don't mention this at
all: http://linuxtv.org/downloads/v4l-dvb-apis/standard.html


Odd, I'd have sworn that it was in the docs.

The full list of ioctls that can change both the crop settings and the format
is:

VIDIOC_S_STD
VIDIOC_S_DV_PRESET


The patch already handles these 2 :)


VIDIOC_S_DV_TIMINGS
VIDIOC_S_INPUT (can implicitly change standard/preset)


I'll add these 2.


VIDIOC_S_OUTPUT (ditto)


libv4l2 only cares about capture, all the rest it just passes
through completely unmodified.


VIDIOC_S_CROP


Hmm, can this also change the fmt? That would be an unexpected
side effect. But if it does I can handle it the same way, right?


Note that I suspect that there are quite a few drivers that do not handle this
correctly. After all, for normal SDTV capture cards you almost never change
the TV standard once it is set up at the start so I doubt if this has been
tested much. For DV_PRESET it is much more common to switch from e.g.
720p to 1080p. That is how I found this issue.


I've attached 2 patches which should make libv4l2 deal with this correctly.
I assume you've a reproducer for this and I would appreciate it if you
could test if these patches actually fix the issue you are seeing.


Almost working. The second patch forgot to set src_fmt.type, so I got an error
back. After initializing it to BUF_TYPE_VIDEO_CAPTURE it worked fine.


Thanks for testing, and duh wrt my G_FMT mistake. If you can answer my question
about S_CROP then I'll go add the other ioctls which need similar handling to
my 2nd patch and push both patches.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git

Em 07-10-2011 03:05, Hans Verkuil escreveu:
 On Friday, October 07, 2011 04:07:38 Mauro Carvalho Chehab wrote:
 Em 06-10-2011 14:24, Mauro Carvalho Chehab escreveu:
 Em 06-10-2011 10:27, Mauro Carvalho Chehab escreveu:
 Em 06-10-2011 09:23, Hans Verkuil escreveu:
 Currently we have three repositories containing libraries and utilities 
 that
 are relevant to the media drivers:

 dvb-apps (http://linuxtv.org/hg/dvb-apps/)
 v4l-utils (http://git.linuxtv.org/v4l-utils.git)
 media-ctl (git://git.ideasonboard.org/media-ctl.git)

 It makes no sense to me to have three separate repositories, one still 
 using
 mercurial and one that isn't even on linuxtv.org.

 I propose to combine them all to one media-utils.git repository. I think 
 it
 makes a lot of sense to do this.

 After the switch the other repositories are frozen (with perhaps a README
 pointing to the new media-utils.git).

 I'm not sure if there are plans to make new stable releases of either of 
 these
 repositories any time soon. If there are, then it might make sense to wait
 until that new stable release before merging.

 Comments?

 I like that idea. It helps to have the basic tools into one single 
 repository,
 and to properly distribute it.

 Ok, I found some time to do an experimental merge of the repositories. It is 
 available
 at:

 http://git.linuxtv.org/mchehab/media-utils.git

 For now, all dvb-apps stuff is on a separate directory. It makes sense to 
 latter
 re-organize the directories. Anyway, the configure script will allow disable
 dvb-apps, v4l-utils and/or libv4l. The default is to have all enabled.

 One problem I noticed is that the dvb-apps are at version 1.1. So, if we're
 releasing a new version, we'll need to jump from 0.9 to dvb-apps version + 1.
 So, IMO, the first version with the merge should be version 1.2.

 Comments?
 
 Strange:
 
 $ git clone git://git.linuxtv.org/mchehab/media-utils.git 
 
 Cloning into media-utils...   

 fatal: The remote end hung up unexpectedly
 
 I've no problem with other git trees.

Hans,

FYI, I'm getting this when compiling from the v4l-utils tree (even before the 
merge):

g++  -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o 
moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o-L/usr/lib 
-L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt 
-L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -lQtCore -lpthread 
qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)':
/home/v4l/work_trees/media-utils/utils/qv4l2/qv4l2.cpp:149: undefined reference 
to `libv4l2_default_dev_ops'
collect2: ld returned 1 exit status

This error occurs at the upstream tree (and also on my tree, as I didn't fix it 
there)

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git


Hi,

On 10/07/2011 03:02 PM, Mauro Carvalho Chehab wrote:

Em 07-10-2011 03:05, Hans Verkuil escreveu:

On Friday, October 07, 2011 04:07:38 Mauro Carvalho Chehab wrote:

Em 06-10-2011 14:24, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 10:27, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 09:23, Hans Verkuil escreveu:

Currently we have three repositories containing libraries and utilities that
are relevant to the media drivers:

dvb-apps (http://linuxtv.org/hg/dvb-apps/)
v4l-utils (http://git.linuxtv.org/v4l-utils.git)
media-ctl (git://git.ideasonboard.org/media-ctl.git)

It makes no sense to me to have three separate repositories, one still using
mercurial and one that isn't even on linuxtv.org.

I propose to combine them all to one media-utils.git repository. I think it
makes a lot of sense to do this.

After the switch the other repositories are frozen (with perhaps a README
pointing to the new media-utils.git).

I'm not sure if there are plans to make new stable releases of either of these
repositories any time soon. If there are, then it might make sense to wait
until that new stable release before merging.

Comments?


I like that idea. It helps to have the basic tools into one single repository,
and to properly distribute it.


Ok, I found some time to do an experimental merge of the repositories. It is 
available
at:

http://git.linuxtv.org/mchehab/media-utils.git

For now, all dvb-apps stuff is on a separate directory. It makes sense to latter
re-organize the directories. Anyway, the configure script will allow disable
dvb-apps, v4l-utils and/or libv4l. The default is to have all enabled.

One problem I noticed is that the dvb-apps are at version 1.1. So, if we're
releasing a new version, we'll need to jump from 0.9 to dvb-apps version + 1.
So, IMO, the first version with the merge should be version 1.2.

Comments?


Strange:

$ git clone git://git.linuxtv.org/mchehab/media-utils.git
Cloning into media-utils...
fatal: The remote end hung up unexpectedly

I've no problem with other git trees.


Hans,

FYI, I'm getting this when compiling from the v4l-utils tree (even before the 
merge):

g++  -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o 
moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o-L/usr/lib 
-L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt 
-L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -lQtCore -lpthread
qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)':
/home/v4l/work_trees/media-utils/utils/qv4l2/qv4l2.cpp:149: undefined reference 
to `libv4l2_default_dev_ops'
collect2: ld returned 1 exit status



Yeah, that is because qmake is stupid and add /usr/lib[64] to the library path 
and adds it *before* the
paths we've specified in its template, so if you've an older libv4l2 installed 
in /usr/lib[64] when building
you get this.

To fix it, first do a make; make install in the lib subdir, with LIBDIR setup 
up to overwrite the old version.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] Staging: cx25821: off by on in cx25821_vidioc_s_input()

2011-10-07 Thread Dan Carpenter

If i is 2 then when we call cx25821_video_mux() we'd end up going
past the end of the cx25821_boards[dev-board]-input[].

The INPUT() macro obfuscates what's going on in that function so it's
a bit hard to follow.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
I don't have this hardware, so I can't actually test this.  Please
review this carefully.

diff --git a/drivers/staging/cx25821/cx25821-video.c 
b/drivers/staging/cx25821/cx25821-video.c
index 084fc08..acd7c4b 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -1312,7 +1312,7 @@ int cx25821_vidioc_s_input(struct file *file, void *priv, 
unsigned int i)
return err;
}
 
-   if (i  2) {
+   if (i = 2) {
dprintk(1, %s(): -EINVAL\n, __func__);
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tvtime at linuxtv.org

2011-10-07 Thread Devin Heitmueller

On Thu, Oct 6, 2011 at 9:59 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Devin,

 I had some discussions with Mikael today at the #linuxtv channel about
 tvtime. Mikael has write access to the tvtime site at sourceforge and he
 is doing some maintainance on it for some time, and worked on some bugs
 from Gentoo, and also imported some stuff from Ubuntu.

 I've merged his patches on my repository:
        http://git.linuxtv.org/mchehab/tvtime.git

 Tvtime is compiling, at least on Fedora 15. I also added your patch there,
 and changed the latency delay to 50ms. I didn't test it yet. I'll do it
 later
 today or tomorrow.

 Btw, Mikael updated the Related Sites there to point to the LinuxTV site:
        http://tvtime.sourceforge.net/links.html

 He will try to contact Vektor again, in order to get his ack about adding
 a note at the main page pointing to us.

 I think we should move those patches to the main repository after testing
 the
 merges, and give write rights to the ones that are interested on maintaining
 tvtime.

 I'm interested on it, and also Mikael.

 IMHO, after testing it and applying a few other patches that Mikael might
 have,
 it is time for us to rename the version to 1.10 and do a tvtime release.

 Would that work for you?

 Thank you!
 Mauro

Hi Mauro,

It's good to hear that patches are continuing to be merged, and of
course contributors are always welcome.

The more I think about this, the more I recognize that I'm not really
adding any value to this process.  While I would really like to put
more time/energy into tvtime, I just don't have the time and it
appears I'm actually slowing down a community of contributors who are
trying to move things forward.

At this point I would recommend the LinuxTV community just take over
the project, give yourself write access to the main repo, and spin a
release.  I would indeed recommend calling it 1.10, to prevent
confusion with the various vendor branches where I believe some of
which may actually already be calling themselves 1.03.

Regarding expanding the list of individuals with commit rights, I
might suggest keeping the list of write privileges for the main repo
to a minimum in the short term (starting with yourself), until
developers have demonstrated their ability to author coherent patches
which won't cause breakage as well as the ability to review the work
of others.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git


Em 07-10-2011 10:05, Hans de Goede escreveu:

Hi,

On 10/07/2011 03:02 PM, Mauro Carvalho Chehab wrote:

Em 07-10-2011 03:05, Hans Verkuil escreveu:

On Friday, October 07, 2011 04:07:38 Mauro Carvalho Chehab wrote:

Em 06-10-2011 14:24, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 10:27, Mauro Carvalho Chehab escreveu:

Em 06-10-2011 09:23, Hans Verkuil escreveu:

Currently we have three repositories containing libraries and utilities that
are relevant to the media drivers:

dvb-apps (http://linuxtv.org/hg/dvb-apps/)
v4l-utils (http://git.linuxtv.org/v4l-utils.git)
media-ctl (git://git.ideasonboard.org/media-ctl.git)

It makes no sense to me to have three separate repositories, one still using
mercurial and one that isn't even on linuxtv.org.

I propose to combine them all to one media-utils.git repository. I think it
makes a lot of sense to do this.

After the switch the other repositories are frozen (with perhaps a README
pointing to the new media-utils.git).

I'm not sure if there are plans to make new stable releases of either of these
repositories any time soon. If there are, then it might make sense to wait
until that new stable release before merging.

Comments?


I like that idea. It helps to have the basic tools into one single repository,
and to properly distribute it.


Ok, I found some time to do an experimental merge of the repositories. It is 
available
at:

http://git.linuxtv.org/mchehab/media-utils.git

For now, all dvb-apps stuff is on a separate directory. It makes sense to latter
re-organize the directories. Anyway, the configure script will allow disable
dvb-apps, v4l-utils and/or libv4l. The default is to have all enabled.

One problem I noticed is that the dvb-apps are at version 1.1. So, if we're
releasing a new version, we'll need to jump from 0.9 to dvb-apps version + 1.
So, IMO, the first version with the merge should be version 1.2.

Comments?


Strange:

$ git clone git://git.linuxtv.org/mchehab/media-utils.git
Cloning into media-utils...
fatal: The remote end hung up unexpectedly

I've no problem with other git trees.


Hans,

FYI, I'm getting this when compiling from the v4l-utils tree (even before the 
merge):

g++ -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o 
moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o -L/usr/lib 
-L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt 
-L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -lQtCore -lpthread
qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)':
/home/v4l/work_trees/media-utils/utils/qv4l2/qv4l2.cpp:149: undefined reference 
to `libv4l2_default_dev_ops'
collect2: ld returned 1 exit status



Yeah, that is because qmake is stupid and add /usr/lib[64] to the library path 
and adds it *before* the
paths we've specified in its template, so if you've an older libv4l2 installed 
in /usr/lib[64] when building
you get this.

To fix it, first do a make; make install in the lib subdir, with LIBDIR setup 
up to overwrite the old version.


Didn't work, as the Fedora package installed it at /usr/lib, while make install 
installed at /usr/local/lib.

(ok, I forced it anyway, by renaming the old library, but this sucks)

The right thing to do is to get rid of it from qv4l2.pro. I can see two 
possible solutions:

1) add a logic at the build target that would do something like cat qv4l2.pro|sed 
s,\-L/usr/lib,,;

2) Don't use -L for the libraries. In this case, we'll need to add some logic 
to include either the .so or the
.a version of the library, depending on the type of the libraries that were 
generated.

Cheers,
Mauro




Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in xawtv with libjpeg v8

2011-10-07 Thread Markus Königshaus

Using streamer from xawtv-3.102 segfaults with jpeg-output and libjpeg 
v8. Attached patch will resolve the problem.


Regards, Markus

-- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten.
Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen 
auf Grundlage dieser Aussagen treffen.

Wiesemann  Theis GmbH, Porschestr. 12, D-42279 Wuppertal
Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis
Registergericht: Amtsgericht Wuppertal, HRB 6377 
Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.defrom https://bugs.gentoo.org/show_bug.cgi?id=294488
[...]
explicitly set do_fancy_downsampling to FALSE 

Apparently, when settings dinfo.raw_data_in,
previous version jpeg automatically set dinfo.do_fancy_downsampling to
FALSE. Newer versions (since 7) of media-libs/jpeg do not do that anymore and
the program must do it explicitly (although I have not found any documentation
to that effect). 

Compile tested only, but a similar fix in mjpegtools (but output rather than
input) works.
--- xawtv-3.102.org/libng/plugins/conv-mjpeg.c	2011-09-05 19:26:02.0 +0200
+++ xawtv-3.102/libng/plugins/conv-mjpeg.c	2011-10-07 15:57:52.413003003 +0200
@@ -229,6 +229,7 @@
 jpeg_set_quality(h-mjpg_cinfo, ng_jpeg_quality, TRUE);
 
 h-mjpg_cinfo.raw_data_in = TRUE;
+h-mjpg_cinfo.do_fancy_downsampling = FALSE;  // fix segfaulst with libjpeg v7++
 jpeg_set_colorspace(h-mjpg_cinfo,JCS_YCbCr);
 
 h-mjpg_ptrs[0] = malloc(h-fmt.height*sizeof(char*));

Re: tvtime at linuxtv.org


Em 07-10-2011 10:38, Devin Heitmueller escreveu:

On Thu, Oct 6, 2011 at 9:59 PM, Mauro Carvalho Chehab
mche...@redhat.com  wrote:

Hi Devin,

I had some discussions with Mikael today at the #linuxtv channel about
tvtime. Mikael has write access to the tvtime site at sourceforge and he
is doing some maintainance on it for some time, and worked on some bugs
from Gentoo, and also imported some stuff from Ubuntu.

I've merged his patches on my repository:
http://git.linuxtv.org/mchehab/tvtime.git

Tvtime is compiling, at least on Fedora 15. I also added your patch there,
and changed the latency delay to 50ms. I didn't test it yet. I'll do it
later
today or tomorrow.

Btw, Mikael updated the Related Sites there to point to the LinuxTV site:
http://tvtime.sourceforge.net/links.html

He will try to contact Vektor again, in order to get his ack about adding
a note at the main page pointing to us.

I think we should move those patches to the main repository after testing
the
merges, and give write rights to the ones that are interested on maintaining
tvtime.

I'm interested on it, and also Mikael.

IMHO, after testing it and applying a few other patches that Mikael might
have,
it is time for us to rename the version to 1.10 and do a tvtime release.

Would that work for you?

Thank you!
Mauro


Hi Mauro,

It's good to hear that patches are continuing to be merged, and of
course contributors are always welcome.

The more I think about this, the more I recognize that I'm not really
adding any value to this process.  While I would really like to put
more time/energy into tvtime, I just don't have the time and it
appears I'm actually slowing down a community of contributors who are
trying to move things forward.

At this point I would recommend the LinuxTV community just take over
the project, give yourself write access to the main repo, and spin a
release.  I would indeed recommend calling it 1.10, to prevent
confusion with the various vendor branches where I believe some of
which may actually already be calling themselves 1.03.


Ok, I've added myself into it.

I've just pushed everything into:
http://git.linuxtv.org/tvtime.git

For now, it is showing as version 1.0.4. I'll rename it to 1.1.0 after getting
some feedback and maybe some additional fixes, and add an announcement about
that when we'll be there.

I tested it yesterday, and it seems to be working properly. Mikael patches
were putting it on a borderless mode, with looked weird on my eyes ;)
So, I added a new parameter (-L) to allow selecting the borderless mode
for those that prefer that way. The default is to have borders.


Regarding expanding the list of individuals with commit rights, I
might suggest keeping the list of write privileges for the main repo
to a minimum in the short term (starting with yourself), until
developers have demonstrated their ability to author coherent patches
which won't cause breakage as well as the ability to review the work
of others.


Maybe Hans de Goede would also like to get his hands on it, as he wrote
a few patches for it on Fedora.

Thanks,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media-ctl PATCH 0/7] Move functionality to libraries, debug changes

Hi,

This patchset moves the string parsing functionality to libraries from the
test program, making the libraries much more useful.

Printing informative messages is also left to debug handler; the libraries
won't print anything anymore. Error messages are also printed by media-ctl.

Regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media-ctl PATCH 1/7] Rename files to match the names of the libraries

Rename media.* to mediactl.* and subdev.* v4l2subdev.*.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/Makefile.am  |6 +-
 src/main.c   |4 +-
 src/media.c  |  475 --
 src/media.h  |  161 --
 src/mediactl.c   |  475 ++
 src/mediactl.h   |  161 ++
 src/subdev.c |  188 -
 src/subdev.h |  162 ---
 src/v4l2subdev.c |  188 +
 src/v4l2subdev.h |  162 +++
 10 files changed, 991 insertions(+), 991 deletions(-)
 delete mode 100644 src/media.c
 delete mode 100644 src/media.h
 create mode 100644 src/mediactl.c
 create mode 100644 src/mediactl.h
 delete mode 100644 src/subdev.c
 delete mode 100644 src/subdev.h
 create mode 100644 src/v4l2subdev.c
 create mode 100644 src/v4l2subdev.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 52628d2..2583464 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,8 +1,8 @@
 lib_LTLIBRARIES = libmediactl.la libv4l2subdev.la
-libmediactl_la_SOURCES = media.c
-libv4l2subdev_la_SOURCES = subdev.c
+libmediactl_la_SOURCES = mediactl.c
+libv4l2subdev_la_SOURCES = v4l2subdev.c
 mediactl_includedir=$(includedir)/mediactl
-mediactl_include_HEADERS = media.h subdev.h
+mediactl_include_HEADERS = mediactl.h v4l2subdev.h
 
 bin_PROGRAMS = media-ctl
 media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
diff --git a/src/main.c b/src/main.c
index b9b9150..55a6e2d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -36,9 +36,9 @@
 #include linux/v4l2-subdev.h
 #include linux/videodev2.h
 
-#include media.h
+#include mediactl.h
 #include options.h
-#include subdev.h
+#include v4l2subdev.h
 #include tools.h
 
 /* 
-
diff --git a/src/media.c b/src/media.c
deleted file mode 100644
index f443d0c..000
--- a/src/media.c
+++ /dev/null
@@ -1,475 +0,0 @@
-/*
- * Media controller test application
- *
- * Copyright (C) 2010 Ideas on board SPRL laurent.pinch...@ideasonboard.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- */
-
-#include config.h
-
-#include sys/ioctl.h
-#include sys/stat.h
-#include sys/types.h
-
-#include unistd.h
-#include stdio.h
-#include stdlib.h
-#include string.h
-#include fcntl.h
-#include errno.h
-
-#include linux/videodev2.h
-#include linux/media.h
-
-#include media.h
-#include tools.h
-
-struct media_pad *media_entity_remote_source(struct media_pad *pad)
-{
-   unsigned int i;
-
-   if (!(pad-flags  MEDIA_PAD_FL_SINK))
-   return NULL;
-
-   for (i = 0; i  pad-entity-num_links; ++i) {
-   struct media_link *link = pad-entity-links[i];
-
-   if (!(link-flags  MEDIA_LNK_FL_ENABLED))
-   continue;
-
-   if (link-sink == pad)
-   return link-source;
-   }
-
-   return NULL;
-}
-
-struct media_entity *media_get_entity_by_name(struct media_device *media,
- const char *name, size_t length)
-{
-   unsigned int i;
-
-   for (i = 0; i  media-entities_count; ++i) {
-   struct media_entity *entity = media-entities[i];
-
-   if (strncmp(entity-info.name, name, length) == 0)
-   return entity;
-   }
-
-   return NULL;
-}
-
-struct media_entity *media_get_entity_by_id(struct media_device *media,
-   __u32 id)
-{
-   unsigned int i;
-
-   for (i = 0; i  media-entities_count; ++i) {
-   struct media_entity *entity = media-entities[i];
-
-   if (entity-info.id == id)
-   return entity;
-   }
-
-   return NULL;
-}
-
-int media_setup_link(struct media_device *media,
-struct media_pad *source,
-struct media_pad *sink,
-__u32 flags)
-{
-   struct media_link *link;
-   struct media_link_desc ulink;
-   unsigned int i;
-   int ret;
-
-   for (i = 0; i  source-entity-num_links; i++) {
-   link = source-entity-links[i];
-
-   if (link-source-entity == source-entity 
-   link-source-index == source-index 
-   link-sink-entity == sink-entity 
-

[media-ctl PATCH 3/7] Move V4L2 subdev format parsing from main.c to subdev.c

This makes format parsing a part of the libv4l2subdev and thus available on
all who use the library.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/main.c   |  340 +-
 src/v4l2subdev.c |  343 ++
 src/v4l2subdev.h |   37 ++
 3 files changed, 382 insertions(+), 338 deletions(-)

diff --git a/src/main.c b/src/main.c
index 02cdecd..0d68ff6 100644
--- a/src/main.c
+++ b/src/main.c
@@ -45,61 +45,6 @@
  * Printing
  */
 
-static struct {
-   const char *name;
-   enum v4l2_mbus_pixelcode code;
-} mbus_formats[] = {
-   { Y8, V4L2_MBUS_FMT_Y8_1X8},
-   { Y10, V4L2_MBUS_FMT_Y10_1X10 },
-   { Y12, V4L2_MBUS_FMT_Y12_1X12 },
-   { YUYV, V4L2_MBUS_FMT_YUYV8_1X16 },
-   { UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
-   { SBGGR8, V4L2_MBUS_FMT_SBGGR8_1X8 },
-   { SGBRG8, V4L2_MBUS_FMT_SGBRG8_1X8 },
-   { SGRBG8, V4L2_MBUS_FMT_SGRBG8_1X8 },
-   { SRGGB8, V4L2_MBUS_FMT_SRGGB8_1X8 },
-   { SBGGR10, V4L2_MBUS_FMT_SBGGR10_1X10 },
-   { SGBRG10, V4L2_MBUS_FMT_SGBRG10_1X10 },
-   { SGRBG10, V4L2_MBUS_FMT_SGRBG10_1X10 },
-   { SRGGB10, V4L2_MBUS_FMT_SRGGB10_1X10 },
-   { SBGGR10_DPCM8, V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 },
-   { SGBRG10_DPCM8, V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 },
-   { SGRBG10_DPCM8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 },
-   { SRGGB10_DPCM8, V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 },
-   { SBGGR12, V4L2_MBUS_FMT_SBGGR12_1X12 },
-   { SGBRG12, V4L2_MBUS_FMT_SGBRG12_1X12 },
-   { SGRBG12, V4L2_MBUS_FMT_SGRBG12_1X12 },
-   { SRGGB12, V4L2_MBUS_FMT_SRGGB12_1X12 },
-};
-
-static const char *pixelcode_to_string(enum v4l2_mbus_pixelcode code)
-{
-   unsigned int i;
-
-   for (i = 0; i  ARRAY_SIZE(mbus_formats); ++i) {
-   if (mbus_formats[i].code == code)
-   return mbus_formats[i].name;
-   }
-
-   return unknown;
-}
-
-static enum v4l2_mbus_pixelcode string_to_pixelcode(const char *string,
-unsigned int length)
-{
-   unsigned int i;
-
-   for (i = 0; i  ARRAY_SIZE(mbus_formats); ++i) {
-   if (strncmp(mbus_formats[i].name, string, length) == 0)
-   break;
-   }
-
-   if (i == ARRAY_SIZE(mbus_formats))
-   return (enum v4l2_mbus_pixelcode)-1;
-
-   return mbus_formats[i].code;
-}
-
 static void v4l2_subdev_print_format(struct media_entity *entity,
unsigned int pad, enum v4l2_subdev_format_whence which)
 {
@@ -111,7 +56,7 @@ static void v4l2_subdev_print_format(struct media_entity 
*entity,
if (ret != 0)
return;
 
-   printf([%s %ux%u, pixelcode_to_string(format.code),
+   printf([%s %ux%u, v4l2_subdev_pixelcode_to_string(format.code),
   format.width, format.height);
 
ret = v4l2_subdev_get_crop(entity, rect, pad, which);
@@ -334,287 +279,6 @@ void media_print_topology(struct media_device *media, int 
dot)
media_print_topology_text(media);
 }
 
-/* 
-
- * Formats setup
- */
-
-static int parse_format(struct v4l2_mbus_framefmt *format, const char *p, char 
**endp)
-{
-   enum v4l2_mbus_pixelcode code;
-   unsigned int width, height;
-   char *end;
-
-   for (; isspace(*p); ++p);
-   for (end = (char *)p; !isspace(*end)  *end != '\0'; ++end);
-
-   code = string_to_pixelcode(p, end - p);
-   if (code == (enum v4l2_mbus_pixelcode)-1)
-   return -EINVAL;
-
-   for (p = end; isspace(*p); ++p);
-   width = strtoul(p, end, 10);
-   if (*end != 'x')
-   return -EINVAL;
-
-   p = end + 1;
-   height = strtoul(p, end, 10);
-   *endp = end;
-
-   memset(format, 0, sizeof(*format));
-   format-width = width;
-   format-height = height;
-   format-code = code;
-
-   return 0;
-}
-
-static int parse_crop(struct v4l2_rect *crop, const char *p, char **endp)
-{
-   char *end;
-
-   if (*p++ != '(')
-   return -EINVAL;
-
-   crop-left = strtoul(p, end, 10);
-   if (*end != ',')
-   return -EINVAL;
-
-   p = end + 1;
-   crop-top = strtoul(p, end, 10);
-   if (*end++ != ')')
-   return -EINVAL;
-   if (*end != '/')
-   return -EINVAL;
-
-   p = end + 1;
-   crop-width = strtoul(p, end, 10);
-   if (*end != 'x')
-   return -EINVAL;
-
-   p = end + 1;
-   crop-height = strtoul(p, end, 10);
-   *endp = end;
-
-   return 0;
-}
-
-static int parse_frame_interval(struct v4l2_fract *interval, const char *p, 
char **endp)
-{
-   char *end;
-
-   for (; isspace(*p); ++p);
-
-   interval-numerator = strtoul(p, end, 10);
-
-   for (p = end; isspace(*p); ++p);
-   if (*p++ != '/')
-   return -EINVAL;
-
-   for

[media-ctl PATCH 4/7] libv4l2subdev and libmediactl are not test programs

Call the libraries libraries rather than test programs.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/mediactl.c   |2 +-
 src/mediactl.h   |2 +-
 src/v4l2subdev.c |2 +-
 src/v4l2subdev.h |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mediactl.c b/src/mediactl.c
index dc5b022..a03c19a 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -1,5 +1,5 @@
 /*
- * Media controller test application
+ * Media controller interface library
  *
  * Copyright (C) 2010 Ideas on board SPRL laurent.pinch...@ideasonboard.com
  *
diff --git a/src/mediactl.h b/src/mediactl.h
index 5627cd7..9ebad9f 100644
--- a/src/mediactl.h
+++ b/src/mediactl.h
@@ -1,5 +1,5 @@
 /*
- * Media controller test application
+ * Media controller interface library
  *
  * Copyright (C) 2010 Ideas on board SPRL laurent.pinch...@ideasonboard.com
  *
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index 0b4793d..80365e6 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -1,5 +1,5 @@
 /*
- * Media controller test application
+ * V4L2 subdev interface library
  *
  * Copyright (C) 2010 Ideas on board SPRL laurent.pinch...@ideasonboard.com
  *
diff --git a/src/v4l2subdev.h b/src/v4l2subdev.h
index db85491..d9ab692 100644
--- a/src/v4l2subdev.h
+++ b/src/v4l2subdev.h
@@ -1,5 +1,5 @@
 /*
- * Media controller test application
+ * V4L2 subdev interface library
  *
  * Copyright (C) 2010 Ideas on board SPRL laurent.pinch...@ideasonboard.com
  *
-- 
1.7.2.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media-ctl PATCH 7/7] Remove extra verbosity

Remove extra verbosity by default; -v option brings back what used to be
there. The error messages are now being printed by main.c with the possibly
helpful error code attached.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/main.c |   48 ++--
 src/mediactl.c |   21 ++---
 src/mediactl.h |6 ++
 3 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/src/main.c b/src/main.c
index 40ab13e..57bbc16 100644
--- a/src/main.c
+++ b/src/main.c
@@ -288,10 +288,16 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
 
/* Open the media device and enumerate entities, pads and links. */
-   media = media_open_debug(media_opts.devname, media_opts.verbose,
-(void (*)(void *, ...))fprintf, stdout);
-   if (media == NULL)
+   if (media_opts.verbose)
+   media = media_open_debug(
+   media_opts.devname,
+   (void (*)(void *, ...))fprintf, stdout);
+   else
+   media = media_open(media_opts.devname);
+   if (media == NULL) {
+   printf(Failed to open %s\n, media_opts.devname);
goto out;
+   }
 
if (media_opts.entity) {
struct media_entity *entity;
@@ -326,15 +332,34 @@ int main(int argc, char **argv)
}
 
if (media_opts.reset) {
-   printf(Resetting all links to inactive\n);
-   media_reset_links(media);
+   if (media_opts.verbose)
+   printf(Resetting all links to inactive\n);
+   ret = media_reset_links(media);
+   if (ret) {
+   printf(Unable to reset links: %s (%d)\n,
+  strerror(-ret), -ret);
+   goto out;
+   }
}
 
-   if (media_opts.links)
-   media_parse_setup_links(media, media_opts.links);
+   if (media_opts.links) {
+   ret = media_parse_setup_links(media, media_opts.links);
+   if (ret) {
+   printf(Unable to parse link: %s (%d)\n,
+  strerror(-ret), -ret);
+   goto out;
+   }
+   }
 
-   if (media_opts.formats)
-   v4l2_subdev_parse_setup_formats(media, media_opts.formats);
+   if (media_opts.formats) {
+   ret = v4l2_subdev_parse_setup_formats(media,
+ media_opts.formats);
+   if (ret) {
+   printf(Unable to parse format: %s (%d)\n,
+  strerror(-ret), -ret);
+   goto out;
+   }
+   }
 
if (media_opts.interactive) {
while (1) {
@@ -348,7 +373,10 @@ int main(int argc, char **argv)
if (buffer[0] == '\n')
break;
 
-   media_parse_setup_link(media, buffer, end);
+   ret = media_parse_setup_link(media, buffer, end);
+   if (ret)
+   printf(Unable to parse link: %s (%d)\n,
+  strerror(-ret), -ret);
}
}
 
diff --git a/src/mediactl.c b/src/mediactl.c
index 43d1b6a..b9c2a10 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -270,7 +270,7 @@ static inline void media_udev_close(struct udev *udev)
 }
 
 static int media_get_devname_udev(struct udev *udev,
-   struct media_entity *entity, int verbose)
+   struct media_entity *entity)
 {
struct udev_device *device;
dev_t devnum;
@@ -281,9 +281,8 @@ static int media_get_devname_udev(struct udev *udev,
return -EINVAL;
 
devnum = makedev(entity-info.v4l.major, entity-info.v4l.minor);
-   if (verbose)
-   media_dbg(entity-media, looking up device: %u:%u\n,
- major(devnum), minor(devnum));
+   media_dbg(entity-media, looking up device: %u:%u\n,
+ major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
if (device) {
p = udev_device_get_devnode(device);
@@ -308,7 +307,7 @@ static inline int media_udev_open(struct udev **udev) { 
return 0; }
 static inline void media_udev_close(struct udev *udev) { }
 
 static inline int media_get_devname_udev(struct udev *udev,
-   struct media_entity *entity, int verbose)
+   struct media_entity *entity)
 {
return -ENOTSUP;
 }
@@ -351,7 +350,7 @@ static int media_get_devname_sysfs(struct media_entity 
*entity)
return 0;
 }
 
-static int media_enum_entities(struct media_device *media, int verbose)
+static int media_enum_entities(struct media_device *media)
 {
struct media_entity *entity;
struct udev *udev;
@@ -400,7

[media-ctl PATCH 5/7] Add link to media_device from the media_entity

This makes it possible to obtain the media device an entity belongs to.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 src/mediactl.c |1 +
 src/mediactl.h |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/mediactl.c b/src/mediactl.c
index a03c19a..8cc338d 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -372,6 +372,7 @@ static int media_enum_entities(struct media_device *media, 
int verbose)
memset(entity, 0, sizeof(*entity));
entity-fd = -1;
entity-info.id = id | MEDIA_ENT_ID_FLAG_NEXT;
+   entity-media = media;
 
ret = ioctl(media-fd, MEDIA_IOC_ENUM_ENTITIES, entity-info);
if (ret  0) {
diff --git a/src/mediactl.h b/src/mediactl.h
index 9ebad9f..98b47fd 100644
--- a/src/mediactl.h
+++ b/src/mediactl.h
@@ -38,6 +38,7 @@ struct media_pad {
 };
 
 struct media_entity {
+   struct media_device *media;
struct media_entity_desc info;
struct media_pad *pads;
struct media_link *links;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[media-ctl PATCH 6/7] Add debugging handler