Skype and libv4l

Skype and libv4l

[Lamarque Vieira Souza]

	Hi all,

	I am trying to make Skype work with my webcam (Creative PC-CAM 880, driver 
zr364xx). By what I have found Skype only supports YU12, YUYV and UYVY pixel 
formats, which libv4l supports as source formats only and not as destination 
formats. I would like to have one of those pixel formats implement as 
destination format in libv4l but I need help to understand how to convert from 
YUV 4:2:0 to one of them. I think the UYVY (AKA YUV 4:2:2) is a good choice, 
well at least their names are very similar. It must be easy to convert once 
you have the Y, U and V components separated as they are in 
libv4lconvert/libv4lconvert.c. Could somebody help with this implementation?

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Hans de Goede]

On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
> 	Hi all,
>
> 	I am trying to make Skype work with my webcam (Creative PC-CAM 880, driver
> zr364xx). By what I have found Skype only supports YU12, YUYV and UYVY pixel
> formats, which libv4l supports as source formats only and not as destination
> formats.

YU12 is the same as YUV420 (planar) which skype does support. I assure you that
skype works with libv4l for cams which have a native format which skype does
not understand.

What is an other issue with skype is that it insists on asking 320x240, so if the
driver for your cam cannot deliver 320x240 and libv4l fails to make 320x240 out of
it in someway (see below) then skype will fail.

libv4l will crop 352x288 to 320x240 especially for skype, and it will downscale
640x480 to 320x240 for the same reason.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Lamarque Vieira Souza]

	Hi,

Em Tuesday 24 March 2009, Hans de Goede escreveu:
> On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
> > 	Hi all,
> >
> > 	I am trying to make Skype work with my webcam (Creative PC-CAM 880,
> > driver zr364xx). By what I have found Skype only supports YU12, YUYV and
> > UYVY pixel formats, which libv4l supports as source formats only and not
> > as destination formats.
>
> YU12 is the same as YUV420 (planar) which skype does support. I assure you
> that skype works with libv4l for cams which have a native format which
> skype does not understand.

	My fault here (+/-), I created a function to decode fourcc hex numbers to 
names and it returns V4L2_PIX_FMT_YU12 instead of V4L2_PIX_FMT_YUV420. I did 
not know they are synonyms. Anyway, it seems lib4l 0.5.9 (32-bit) is not 
working with Skype (32-bit) while lib4l 0.5.3 (64-bit) is working with Kopete 
(64-bit) patched to work with libv4l (no LD_PRELOAD). I will keep on trying to 
figure out why.

> What is an other issue with skype is that it insists on asking 320x240, so
> if the driver for your cam cannot deliver 320x240 and libv4l fails to make
> 320x240 out of it in someway (see below) then skype will fail.
>
> libv4l will crop 352x288 to 320x240 especially for skype, and it will
> downscale 640x480 to 320x240 for the same reason.

	The driver delivers 320x240 as default.

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Lamarque Vieira Souza]

	It must be some problem in LD_PRELOAD, even setting LIBV4L2_LOG_FILENAME the 
file is not created. I am running skype like this:

LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype

	/opt/skype/skype is the binary executable. There is not error message about 
LD_PRELOAD or libv4l. Skype returns:

Skype V4L2: Could not find a suitable capture format
Skype V4L2: Could not find a suitable capture format
Starting the process...
Skype Xv: Xv ports available: 4
Skype XShm: XShm support enabled
Skype Xv: Using Xv port 131
Skype Xv: No suitable overlay format found

	OBS: compat-ioctl32.ko is being used by the driver so it should support 32-
bit ioctl.

Em Tuesday 24 March 2009, Lamarque Vieira Souza escreveu:
> 	Hi,
>
> Em Tuesday 24 March 2009, Hans de Goede escreveu:
> > On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
> > > 	Hi all,
> > >
> > > 	I am trying to make Skype work with my webcam (Creative PC-CAM 880,
> > > driver zr364xx). By what I have found Skype only supports YU12, YUYV
> > > and UYVY pixel formats, which libv4l supports as source formats only
> > > and not as destination formats.
> >
> > YU12 is the same as YUV420 (planar) which skype does support. I assure
> > you that skype works with libv4l for cams which have a native format
> > which skype does not understand.
>
> 	My fault here (+/-), I created a function to decode fourcc hex numbers to
> names and it returns V4L2_PIX_FMT_YU12 instead of V4L2_PIX_FMT_YUV420. I
> did not know they are synonyms. Anyway, it seems lib4l 0.5.9 (32-bit) is
> not working with Skype (32-bit) while lib4l 0.5.3 (64-bit) is working with
> Kopete (64-bit) patched to work with libv4l (no LD_PRELOAD). I will keep on
> trying to figure out why.
>
> > What is an other issue with skype is that it insists on asking 320x240,
> > so if the driver for your cam cannot deliver 320x240 and libv4l fails to
> > make 320x240 out of it in someway (see below) then skype will fail.
> >
> > libv4l will crop 352x288 to 320x240 especially for skype, and it will
> > downscale 640x480 to 320x240 for the same reason.
>
> 	The driver delivers 320x240 as default.


-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Markus Rechberger]

On Tue, Mar 24, 2009 at 7:42 PM, Lamarque Vieira Souza
<lamarque@gmail.com> wrote:
>        It must be some problem in LD_PRELOAD, even setting LIBV4L2_LOG_FILENAME the
> file is not created. I am running skype like this:
>
> LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype
>
>        /opt/skype/skype is the binary executable. There is not error message about
> LD_PRELOAD or libv4l. Skype returns:
>
> Skype V4L2: Could not find a suitable capture format
> Skype V4L2: Could not find a suitable capture format
> Starting the process...
> Skype Xv: Xv ports available: 4
> Skype XShm: XShm support enabled
> Skype Xv: Using Xv port 131
> Skype Xv: No suitable overlay format found
>

this is a problem of your graphiccard or graphic driver, look for
xorg.org tweaks.

Markus

>        OBS: compat-ioctl32.ko is being used by the driver so it should support 32-
> bit ioctl.
>
> Em Tuesday 24 March 2009, Lamarque Vieira Souza escreveu:
>>       Hi,
>>
>> Em Tuesday 24 March 2009, Hans de Goede escreveu:
>> > On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
>> > >   Hi all,
>> > >
>> > >   I am trying to make Skype work with my webcam (Creative PC-CAM 880,
>> > > driver zr364xx). By what I have found Skype only supports YU12, YUYV
>> > > and UYVY pixel formats, which libv4l supports as source formats only
>> > > and not as destination formats.
>> >
>> > YU12 is the same as YUV420 (planar) which skype does support. I assure
>> > you that skype works with libv4l for cams which have a native format
>> > which skype does not understand.
>>
>>       My fault here (+/-), I created a function to decode fourcc hex numbers to
>> names and it returns V4L2_PIX_FMT_YU12 instead of V4L2_PIX_FMT_YUV420. I
>> did not know they are synonyms. Anyway, it seems lib4l 0.5.9 (32-bit) is
>> not working with Skype (32-bit) while lib4l 0.5.3 (64-bit) is working with
>> Kopete (64-bit) patched to work with libv4l (no LD_PRELOAD). I will keep on
>> trying to figure out why.
>>
>> > What is an other issue with skype is that it insists on asking 320x240,
>> > so if the driver for your cam cannot deliver 320x240 and libv4l fails to
>> > make 320x240 out of it in someway (see below) then skype will fail.
>> >
>> > libv4l will crop 352x288 to 320x240 especially for skype, and it will
>> > downscale 640x480 to 320x240 for the same reason.
>>
>>       The driver delivers 320x240 as default.
>
>
> --
> Lamarque V. Souza
> http://www.geographicguide.com/brazil.htm
> Linux User #57137 - http://counter.li.org/
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Markus Rechberger]

On Tue, Mar 24, 2009 at 7:58 PM, Markus Rechberger
<mrechberger@gmail.com> wrote:
> On Tue, Mar 24, 2009 at 7:42 PM, Lamarque Vieira Souza
> <lamarque@gmail.com> wrote:
>>        It must be some problem in LD_PRELOAD, even setting LIBV4L2_LOG_FILENAME the
>> file is not created. I am running skype like this:
>>
>> LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype
>>
>>        /opt/skype/skype is the binary executable. There is not error message about
>> LD_PRELOAD or libv4l. Skype returns:
>>
>> Skype V4L2: Could not find a suitable capture format
>> Skype V4L2: Could not find a suitable capture format
>> Starting the process...
>> Skype Xv: Xv ports available: 4
>> Skype XShm: XShm support enabled
>> Skype Xv: Using Xv port 131
>> Skype Xv: No suitable overlay format found
>>
>
> this is a problem of your graphiccard or graphic driver, look for
> xorg.org tweaks.
>

should be x.org of course.

> Markus
>
>>        OBS: compat-ioctl32.ko is being used by the driver so it should support 32-
>> bit ioctl.
>>
>> Em Tuesday 24 March 2009, Lamarque Vieira Souza escreveu:
>>>       Hi,
>>>
>>> Em Tuesday 24 March 2009, Hans de Goede escreveu:
>>> > On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
>>> > >   Hi all,
>>> > >
>>> > >   I am trying to make Skype work with my webcam (Creative PC-CAM 880,
>>> > > driver zr364xx). By what I have found Skype only supports YU12, YUYV
>>> > > and UYVY pixel formats, which libv4l supports as source formats only
>>> > > and not as destination formats.
>>> >
>>> > YU12 is the same as YUV420 (planar) which skype does support. I assure
>>> > you that skype works with libv4l for cams which have a native format
>>> > which skype does not understand.
>>>
>>>       My fault here (+/-), I created a function to decode fourcc hex numbers to
>>> names and it returns V4L2_PIX_FMT_YU12 instead of V4L2_PIX_FMT_YUV420. I
>>> did not know they are synonyms. Anyway, it seems lib4l 0.5.9 (32-bit) is
>>> not working with Skype (32-bit) while lib4l 0.5.3 (64-bit) is working with
>>> Kopete (64-bit) patched to work with libv4l (no LD_PRELOAD). I will keep on
>>> trying to figure out why.
>>>
>>> > What is an other issue with skype is that it insists on asking 320x240,
>>> > so if the driver for your cam cannot deliver 320x240 and libv4l fails to
>>> > make 320x240 out of it in someway (see below) then skype will fail.
>>> >
>>> > libv4l will crop 352x288 to 320x240 especially for skype, and it will
>>> > downscale 640x480 to 320x240 for the same reason.
>>>
>>>       The driver delivers 320x240 as default.
>>
>>
>> --
>> Lamarque V. Souza
>> http://www.geographicguide.com/brazil.htm
>> Linux User #57137 - http://counter.li.org/
>>
>> --
>> video4linux-list mailing list
>> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/video4linux-list
>>
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Lamarque Vieira Souza]

Em Tuesday 24 March 2009, Markus Rechberger escreveu:
> On Tue, Mar 24, 2009 at 7:42 PM, Lamarque Vieira Souza
>
> <lamarque@gmail.com> wrote:
> >        It must be some problem in LD_PRELOAD, even setting
> > LIBV4L2_LOG_FILENAME the file is not created. I am running skype like
> > this:
> >
> > LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype
> >
> >        /opt/skype/skype is the binary executable. There is not error
> > message about LD_PRELOAD or libv4l. Skype returns:
> >
> > Skype V4L2: Could not find a suitable capture format
> > Skype V4L2: Could not find a suitable capture format
> > Starting the process...
> > Skype Xv: Xv ports available: 4
> > Skype XShm: XShm support enabled
> > Skype Xv: Using Xv port 131
> > Skype Xv: No suitable overlay format found
>
> this is a problem of your graphiccard or graphic driver, look for
> xorg.org tweaks.

	Well, there are two problems above: the "Skype V4L2: Could not find a 
suitable capture format" and the "Skype Xv: No suitable overlay format found". 
I am trying to fix the first one for now, after that I am going to try to fix 
the other. As I said before the webcam works with Kopete (64-bit) and with 
mplayer (32-bit and 64-bit), so the Xv problem must be Skype specific, but I 
cannot test this problem until I fix the first one.

> Markus
>
> >        OBS: compat-ioctl32.ko is being used by the driver so it should
> > support 32- bit ioctl.
> >
> > Em Tuesday 24 March 2009, Lamarque Vieira Souza escreveu:
> >>       Hi,
> >>
> >> Em Tuesday 24 March 2009, Hans de Goede escreveu:
> >> > On 03/23/2009 09:08 PM, Lamarque Vieira Souza wrote:
> >> > >   Hi all,
> >> > >
> >> > >   I am trying to make Skype work with my webcam (Creative PC-CAM
> >> > > 880, driver zr364xx). By what I have found Skype only supports YU12,
> >> > > YUYV and UYVY pixel formats, which libv4l supports as source formats
> >> > > only and not as destination formats.
> >> >
> >> > YU12 is the same as YUV420 (planar) which skype does support. I assure
> >> > you that skype works with libv4l for cams which have a native format
> >> > which skype does not understand.
> >>
> >>       My fault here (+/-), I created a function to decode fourcc hex
> >> numbers to names and it returns V4L2_PIX_FMT_YU12 instead of
> >> V4L2_PIX_FMT_YUV420. I did not know they are synonyms. Anyway, it seems
> >> lib4l 0.5.9 (32-bit) is not working with Skype (32-bit) while lib4l
> >> 0.5.3 (64-bit) is working with Kopete (64-bit) patched to work with
> >> libv4l (no LD_PRELOAD). I will keep on trying to figure out why.
> >>
> >> > What is an other issue with skype is that it insists on asking
> >> > 320x240, so if the driver for your cam cannot deliver 320x240 and
> >> > libv4l fails to make 320x240 out of it in someway (see below) then
> >> > skype will fail.
> >> >
> >> > libv4l will crop 352x288 to 320x240 especially for skype, and it will
> >> > downscale 640x480 to 320x240 for the same reason.
> >>
> >>       The driver delivers 320x240 as default.
> >
> > --
> > Lamarque V. Souza
> > http://www.geographicguide.com/brazil.htm
> > Linux User #57137 - http://counter.li.org/
> >
> > --
> > video4linux-list mailing list
> > Unsubscribe
> > mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/video4linux-list


-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Theodoros V. Kalamatianos]

On Tue, 24 Mar 2009, Lamarque Vieira Souza wrote:
>>> LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype
>>>
>>>        /opt/skype/skype is the binary executable. There is not error
>>> message about LD_PRELOAD or libv4l. Skype returns:
>>>
>>> Skype V4L2: Could not find a suitable capture format
>>> Skype V4L2: Could not find a suitable capture format
>>> Starting the process...
>>> Skype Xv: Xv ports available: 4
>>> Skype XShm: XShm support enabled
>>> Skype Xv: Using Xv port 131
>>> Skype Xv: No suitable overlay format found

Keep in mind that LD_PRELOAD will be silently ignored for static binaries 
and it will simply NOT WORK. Are you certain that you are not using the 
static version of Skype?

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4l

[Lamarque Vieira Souza]

Em Tuesday 24 March 2009, Theodoros V. Kalamatianos escreveu:
> On Tue, 24 Mar 2009, Lamarque Vieira Souza wrote:
> >>> LD_PRELOAD=/usr/lib32/libv4l2.so /opt/skype/skype
> >>>
> >>>        /opt/skype/skype is the binary executable. There is not error
> >>> message about LD_PRELOAD or libv4l. Skype returns:
> >>>
> >>> Skype V4L2: Could not find a suitable capture format
> >>> Skype V4L2: Could not find a suitable capture format
> >>> Starting the process...
> >>> Skype Xv: Xv ports available: 4
> >>> Skype XShm: XShm support enabled
> >>> Skype Xv: Using Xv port 131
> >>> Skype Xv: No suitable overlay format found
>
> Keep in mind that LD_PRELOAD will be silently ignored for static binaries
> and it will simply NOT WORK. Are you certain that you are not using the
> static version of Skype?

	I am using the static version of Skype, but Skype is statically linked 
against Qt4 only, it is dynamically linked against all other libraries. Now I 
can get log using LIBV4L2_LOG_FILENAME if I preload this way:

LD_PRELOAD=/usr/lib32/libv4l/v4l2convert.so /opt/skype/skype

	I have found the problem. The vidioc_try_fmt_vid_cap function in the driver 
return -EINVAL if the fmt.pix.field is different from V4L2_FIELD_ANY or 
V4L2_FIELD_NONE. Skype seems to set this field as V4L2_FIELD_INTERLACED. 
Because of that libv4l assumes that all destination formats (YUV420 included) 
are invalid. Commenting this part of the driver makes Skype work and it is 
showing pictures. YES!!! :-)

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Lamarque Vieira Souza]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

	Hi,

	Applying this patch to libv4l makes Skype works with my webcam without 
changing the driver. Do you think the patch is ok?

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

[-- Attachment #2: libv4l-0.5.9.patch --]
[-- Type: text/x-patch, Size: 588 bytes --]

*** libv4l-0.5.9/libv4lconvert/libv4lconvert.c	2009-03-13 08:05:56.000000000 -0300
--- libv4l-0.5.9-lvs/libv4lconvert/libv4lconvert.c	2009-03-24 19:07:14.000000000 -0300
*************** static int v4lconvert_do_try_format(stru
*** 307,312 ****
--- 307,315 ----
      try_fmt = *dest_fmt;
      try_fmt.fmt.pix.pixelformat = supported_src_pixfmts[i].fmt;
  
+     /* Lamarque 24/03/2009 */
+     try_fmt.fmt.pix.field = V4L2_FIELD_ANY;
+ 
      if (!syscall(SYS_ioctl, data->fd, VIDIOC_TRY_FMT, &try_fmt))
      {
        if (try_fmt.fmt.pix.pixelformat == supported_src_pixfmts[i].fmt) {

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Lamarque Vieira Souza]

	By the way, the message "Skype Xv: No suitable overlay format found" was gone 
when I apply this patch, it was only one problem, not two. That makes the 
think that this message is misleading. It is not a Xv overlay problem, it is 
just Skype that does not recognize the format returned by the v4l2's driver 
(or libv4l in my case).

Em Tuesday 24 March 2009, Lamarque Vieira Souza escreveu:
> 	Hi,
>
> 	Applying this patch to libv4l makes Skype works with my webcam without
> changing the driver. Do you think the patch is ok?


-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Hans de Goede]

On 03/24/2009 11:09 PM, Lamarque Vieira Souza wrote:
> 	Hi,
>
> 	Applying this patch to libv4l makes Skype works with my webcam without
> changing the driver. Do you think the patch is ok?
>

No it is not ok, luckily I've also read the rest of this thread, where you write:

 > 	I have found the problem. The vidioc_try_fmt_vid_cap function in the driver
 > return -EINVAL if the fmt.pix.field is different from V4L2_FIELD_ANY or
 > V4L2_FIELD_NONE. Skype seems to set this field as V4L2_FIELD_INTERLACED.
 > Because of that libv4l assumes that all destination formats (YUV420 included)
 > are invalid. Commenting this part of the driver makes Skype work and it is
 > showing pictures. YES!!! :-)
 >

What you are seeing is a bug in the driver. VIDIOC_TRY_FMT should *never*
return -EINVAL, except, and that is the only exception when it does not
support the passed in type, so v4l2_format.type is something which is not
supported, note that when vidioc_try_fmt_vid_cap is called the type is
already checked (hence the _vid_ in the function name).

When any member of fmt.pix. is not supported it should set it to something
which it does support (and the app should check what it got) so the proper
fix is to always set fmt.pix.field to V4L2_FIELD_NONE in the driver
(V4L2_FIELD_ANY is an input only value, a format returned by a driver
should never have V4L2_FIELD_ANY).

Regards,

Hans


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Lamarque Vieira Souza]

Em Wednesday 25 March 2009, Hans de Goede escreveu:
> On 03/24/2009 11:09 PM, Lamarque Vieira Souza wrote:
> > 	Hi,
> >
> > 	Applying this patch to libv4l makes Skype works with my webcam without
> > changing the driver. Do you think the patch is ok?
>
> No it is not ok, luckily I've also read the rest of this thread, where you 
write:
>  > 	I have found the problem. The vidioc_try_fmt_vid_cap function in the
>  > driver return -EINVAL if the fmt.pix.field is different from
>  > V4L2_FIELD_ANY or V4L2_FIELD_NONE. Skype seems to set this field as
>  > V4L2_FIELD_INTERLACED. Because of that libv4l assumes that all
>  > destination formats (YUV420 included) are invalid. Commenting this part
>  > of the driver makes Skype work and it is showing pictures. YES!!! :-)
>
> What you are seeing is a bug in the driver. VIDIOC_TRY_FMT should *never*
> return -EINVAL, except, and that is the only exception when it does not
> support the passed in type, so v4l2_format.type is something which is not
> supported, note that when vidioc_try_fmt_vid_cap is called the type is
> already checked (hence the _vid_ in the function name).

	Well, so there are some drivers in the kernel with this bug too (all in 
linux/drivers/media/video/ directory): meye.c and soc_camera.c (those two does 
exactly as zr364xx.c does); bt8xx/bttv-driver.c (this one returns -EINVAL if a 
combination of field (V4L2_FIELD_SEQ_TB) and flags (FORMAT_FLAGS_PLANAR) is 
invalid) or when field value is unknow, if it is unknow it really should 
return -EINVAL. Some drivers (cx18/cx18-ioctl.c, em28xx/em28xx-video.c, 
ivtv/ivtv-ioctl.c and stk-webcam.c) just set the field value to one they 
accept without even reading what value was passed to them and some 
(cx23885/cx23885-417.c and gspca/gspca.c) just ignores the field value 
returning what as passed to them. cx23885/cx23885-video.c, cx88/cx88-video.c 
and saa7134/saa7134-video.c will return -EINVAL if you pass 
V4L2_FIELD_ALTERNATE or V4L2_FIELD_SEQ_TB in the field field, if you pass 
V4L2_FIELD_ANY they will try to find one field value that is ok for them. 
s2255drv.c does more effort to validate the field value, in some cases it will 
return -EINVAL if it does not find a good value for the field field.

	Besides, vivi.c does something similar to zr364xx.c. It returns -EINVAL if 
the field value is different from V4L2_FIELD_ANY or V4L2_FIELD_INTERLACED. So 
if you pass V4L2_FIELD_NONE to vivi.c's try_fmt it will return -EINVAL too.

	What I am seeing here is that each driver behaves differently. So what is the 
correct behaviour?:

1. ignores the field value.
2. set the field value inconditionally to one value that the driver accepts.
3. only set the field value to one value that the driver accepts if 
V4L2_FIELD_ANY is passed to the driver (this one is what zr364xx.c and vivi.c 
do).

> When any member of fmt.pix. is not supported it should set it to something
> which it does support (and the app should check what it got) so the proper
> fix is to always set fmt.pix.field to V4L2_FIELD_NONE in the driver
> (V4L2_FIELD_ANY is an input only value, a format returned by a driver
> should never have V4L2_FIELD_ANY).

	So the behaviour number two is the correct one. So someone must change vivi.c 
as it is used as a guide to create new v4l2 drivers, although I still thinks 
the zr364xx.c and vivi.c do the logical thing: only changes the field value if 
the application allowed them to (when passing V4L2_FIELD_ANY).

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Lamarque Vieira Souza]

Em Thursday 26 March 2009, Hans de Goede escreveu:
> Hi all,
>
> Not quite, the correct behaviour is:
> "If the field value is set to an unsupported value, then set the field
> value to *a* value that the driver accepts"

	Now I get it. This webcam only accepts V4L2_FIELD_NONE, so commenting that 
part of try_fmt makes it compliant with v4l2 standard. Thank you for helping 
me with this. The zr364xx's maintainer contacted me yesterday, he is busy 
theses days, when he has more time he is going to take a look at my changes. 
With lucky the changes will be in 2.6.30. At least 2.6.29 sets the 
compat_ioctl32 automatically for all drivers, in 2.6.28.8 I had to set it in 
the driver to make Skype and mplayer (32-bit) work, one less change for the 
driver :-)

> This takes in to account certain devices can support multiple field types,
> which is the whole purpose of the field value.
>
> And yes unfortunately many many v4l drivers have various bugs in their
> implementation, in some cases I do work around driver bugs in libv4l, but
> it this case that would hurt proper use of the field value, and that is not
> acceptable, so fixing the driver is the only solution.

	Have you tried to contact the drivers' maintainers for fixing those bugs?

> Note, that the v4l2 API is pretty well documented, and the correct
> behaviour as I describe it can be found in the docs too:
> http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r10944.htm
>
> And the "Return Value" section, note how EINVAL is only supposed to be
> returned up on an invalid, or unsupported type value. And also from the
> description: "Drivers should not return an error code unless the input is
> ambiguous"


-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Re: Skype and libv4

[dean]

Hi, Please see comments below:

> Subject:
> Re: Skype and libv4
> From:
> Lamarque Vieira Souza <lamarque@gmail.com>
> Date:
> Thu, 26 Mar 2009 10:36:56 -0300
> To:
> Hans de Goede <hdegoede@redhat.com>
> 
> To:
> Hans de Goede <hdegoede@redhat.com>
> CC:
> video4linux-list@redhat.com
> 
> 
> 
> Em Thursday 26 March 2009, Hans de Goede escreveu:
>> Hi all,
>>
>> Not quite, the correct behaviour is:
>> "If the field value is set to an unsupported value, then set the field
>> value to *a* value that the driver accepts"
> 
> 	Now I get it. This webcam only accepts V4L2_FIELD_NONE, so commenting that 
> part of try_fmt makes it compliant with v4l2 standard. Thank you for helping 
> me with this. The zr364xx's maintainer contacted me yesterday, he is busy 
> theses days, when he has more time he is going to take a look at my changes. 
> With lucky the changes will be in 2.6.30. At least 2.6.29 sets the 
> compat_ioctl32 automatically for all drivers, in 2.6.28.8 I had to set it in 
> the driver to make Skype and mplayer (32-bit) work, one less change for the 
> driver :-)

The lack of V4L2_FIELD_NONE caused what sort of problems in these 
applications/drivers?  Did you the driver recover without it?

> 
>> This takes in to account certain devices can support multiple field types,
>> which is the whole purpose of the field value.
>>
>> And yes unfortunately many many v4l drivers have various bugs in their
>> implementation, in some cases I do work around driver bugs in libv4l, but
>> it this case that would hurt proper use of the field value, and that is not
>> acceptable, so fixing the driver is the only solution.

Can you elaborate on the V4L drivers with bugs?  If they aren't 
identified, they won't be fixed.

> 
> 	Have you tried to contact the drivers' maintainers for fixing those bugs?
> 
>> Note, that the v4l2 API is pretty well documented, and the correct
>> behaviour as I describe it can be found in the docs too:
>> http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r10944.htm
>>
>> And the "Return Value" section, note how EINVAL is only supposed to be
>> returned up on an invalid, or unsupported type value. And also from the
>> description: "Drivers should not return an error code unless the input is
>> ambiguous"
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list


I also have a question about the removal of videobuf_waiton in the 
patch.  Only 3 other drivers are using videobuf_waiton. Should 
videobuf_waiton be removed from them also?  I believe it was in vivi.c 
at some point, but I'll have to double check...




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Skype and libv4

[Lamarque Vieira Souza]

Em Thursday 26 March 2009, dean escreveu:
> Hi, Please see comments below:
> > Subject:
> > Re: Skype and libv4
> > From:
> > Lamarque Vieira Souza <lamarque@gmail.com>
> > Date:
> > Thu, 26 Mar 2009 10:36:56 -0300
> > To:
> > Hans de Goede <hdegoede@redhat.com>
> >
> > To:
> > Hans de Goede <hdegoede@redhat.com>
> > CC:
> > video4linux-list@redhat.com
> >
> > Em Thursday 26 March 2009, Hans de Goede escreveu:
> >> Hi all,
> >>
> >> Not quite, the correct behaviour is:
> >> "If the field value is set to an unsupported value, then set the field
> >> value to *a* value that the driver accepts"
> >
> > 	Now I get it. This webcam only accepts V4L2_FIELD_NONE, so commenting
> > that part of try_fmt makes it compliant with v4l2 standard. Thank you for
> > helping me with this. The zr364xx's maintainer contacted me yesterday, he
> > is busy theses days, when he has more time he is going to take a look at
> > my changes. With lucky the changes will be in 2.6.30. At least 2.6.29
> > sets the compat_ioctl32 automatically for all drivers, in 2.6.28.8 I had
> > to set it in the driver to make Skype and mplayer (32-bit) work, one less
> > change for the driver :-)
>
> The lack of V4L2_FIELD_NONE caused what sort of problems in these
> applications/drivers?  Did you the driver recover without it?

	Skype+libv4l did not work and let the driver in unsable state (no application 
worked until I reloaded the driver). mplayer and Kopete+libv4l work without 
changing this part of the driver because they probably passed V4L2_FIELD_ANY, 
which makes the driver return V4L2_FIELD_NONE. Skypes passes 
V4L2_FIELD_INTERLACED, which this card does not support. 

	One strange thing is that Skype returns two error messages: one about the 
v4l2 format and this one "Skype Xv: No suitable overlay format found". I think 
this message is misleading because there is no problem with Xv's overlay, it 
just the stream format from the v4l2's driver that was not recognized. I have 
seen several people on the Internet with problem with Skype and this error 
message, maybe the drivers they are using is doing the wrong thing in try_fmt 
too. meye.c is another one which probably has this problem with Skype.

> >> This takes in to account certain devices can support multiple field
> >> types, which is the whole purpose of the field value.
> >>
> >> And yes unfortunately many many v4l drivers have various bugs in their
> >> implementation, in some cases I do work around driver bugs in libv4l,
> >> but it this case that would hurt proper use of the field value, and that
> >> is not acceptable, so fixing the driver is the only solution.
>
> Can you elaborate on the V4L drivers with bugs?  If they aren't
> identified, they won't be fixed.
>
> > 	Have you tried to contact the drivers' maintainers for fixing those
> > bugs?
> >
> >> Note, that the v4l2 API is pretty well documented, and the correct
> >> behaviour as I describe it can be found in the docs too:
> >> http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r10944.ht
> >>m
> >>
> >> And the "Return Value" section, note how EINVAL is only supposed to be
> >> returned up on an invalid, or unsupported type value. And also from the
> >> description: "Drivers should not return an error code unless the input
> >> is ambiguous"
> >
> > ------------------------------------------------------------------------
> >
> > --
> > video4linux-list mailing list
> > Unsubscribe
> > mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/video4linux-list
>
> I also have a question about the removal of videobuf_waiton in the
> patch.  Only 3 other drivers are using videobuf_waiton. Should
> videobuf_waiton be removed from them also?  I believe it was in vivi.c
> at some point, but I'll have to double check...

	I think it should be removed. As far as I understand videobuf_waiton(&buf-
>vb, 0, 0) will block forever until the video buffer list is emptied, but if 
the driver is an unload module state nobody will empty the list. If the 
application works as expected it will empty the list before closing the device 
and everything works, but Skype was not working properly because of the 
V4L2_FIELD_INTERLACED problem, it issued some vidioc_qbuf calls but no 
vidioc_dqbuf calls reached the driver accordingly to my logs, so the dead lock 
when trying to unload the driver's module.

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list