needed: libv4l and associated application patches (or "gspca stopped working in 2.6.27")

As you probably know I'm one of the authors of the v4l2 rewrite of the gspca usb
webcam driver framework (which supports more then 100 different cams), this v4l2
rewrite has been merged into the 2.6.27 kernel and thus will become available in
the official Linux kernel soon.

One of the parts of the v4l2 rewrite has been removing conversion from various
manufacturer cam specific video formats to more normal videoformats from the
drivers, as this really does not belong in userspace.

As a result of this the gspca subdrivers can generate raw video frames in the
following formats:

#define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x
compressed bayer
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S', '5', '0', '1') /* YUYV per line
#define V4L2_PIX_FMT_SPCA505 v4l2_fourcc('S', '5', '0', '5') /* YYUV per line
#define V4L2_PIX_FMT_SPCA508 v4l2_fourcc('S', '5', '0', '8') /* YUVY per line
#define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG
bayer
#define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR
bayer

As we do not want to see each application implement (nor having to implement)
support for these various formats, as we like to have one code base and only one
code base for these formats. A library has been written (with me as the main
author) to convert from these formats to BGR24 or YUV420. For more on this
library see:
http://hansdegoede.livejournal.com/3636.html

The attached patch adds support to the gstreamer v4l2 plugin to use this library
if available on the system, it has also been submitted upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=545033

libv4l will show up in rawhide as soon as a cvsadmin gets around to creating a
cvs module for it, see libv4l'2 review request: bug 456772

Getting this patch into Fedora is important for the F-10 better webcam support
feature:
https://fedoraproject.org/wiki/Features/BetterWebcamSupport

###

A note about the patch, the patch is actually quite simple, as libv4l has been
designed for quick porting of existing apps to libv4l, for this reason libv4l
fully mimicks the raw /dev/video interface (and if no conversion is needed and
for non relevant calls like setting ctrl's, passes through all calls unmodified).

All that the patch does and all that needs to be changed to use libv4l is
replace the relevant xxx calls on /dev/video with v4l2_xxx calls.

The only special thing about the patch is that it passes the
V4L2_ENABLE_ENUM_FMT_EMULATION flag to libv4l2 on open, this patch tells libv4l2
to report the "emulated" formats in the ENUM_FMT ioctl results. Which libv4l2
does not do be default so that ENUM_FMT only reports the really supported
formats (a TRY_FMT with one of the 2 supported emulated formats can then be done
to see if conversion is supported for the specific device). Given the working of
the v4l2 plugin, enabling the ENUM_FMT emulation is needed.

I've successfully tested this patch with cheese and 2 spca561 cams (quite
popular IC, used by both logitech and creative), 2 pac207 cams (another quite
popular IC), 3 SN9C10X cams (also very popular) and 1 spca501 cam. All of which
do not work without this patch, as gstrea...

Created attachment 312745
PATCH adding support for using libv4l to the v4l2 plugin

libv4l has just been build for rawhide, and should show up in the next rawhide
push, in the mean time you can get it from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=57774

Short intro: I'm a long time Linux developer currently working on improving
webcam support in Linux, see:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport

I'm one of the authors of the v4l2 rewrite of the gspca usb webcam driver
framework (which supports more then 100 different cams), this v4l2 rewrite has
been merged into the 2.6.27 kernel and thus will become available in the
official Linux kernel soon.

One of the parts of the v4l2 rewrite has been removing conversion from various
manufacturer cam specific video formats to more normal videoformats from the
drivers, as this really does not belong in kernel space.

As a result of this the gspca subdrivers can generate raw video frames in the
following formats:

#define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x
compressed bayer
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S', '5', '0', '1') /* YUYV per line
#define V4L2_PIX_FMT_SPCA505 v4l2_fourcc('S', '5', '0', '5') /* YYUV per line
#define V4L2_PIX_FMT_SPCA508 v4l2_fourcc('S', '5', '0', '8') /* YUVY per line
#define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed
GBRG bayer
#define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed
BGGR bayer

As we do not want to see each application implement (nor having to implement)
support for these various formats, as we like to have one code base and only
one code base for these formats. A library has been written (with me as the
main author) to convert from these formats to BGR24 or YUV420. For more on this
library see:
http://hansdegoede.livejournal.com/3636.html

The attached patch adds support to the pwlib v4l2 plugin to use this
library if available on the system.

It has also been submitted upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=545108

libv4l has just been build for rawhide, and should show up in the next rawhide
push, in the mean time you can get it from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=57774

###

A note about the patch, the patch is actually quite simple, as libv4l has been
designed for quick porting of existing apps to libv4l, for this reason libv4l
fully mimicks the raw /dev/video interface (and if no conversion is needed and
for non relevant calls like setting ctrl's, passes through all calls
unmodified).

All that the patch does and all that needs to be changed to use libv4l is
replace the relevant xxx calls on /dev/video with v4l2_xxx calls.

I've successfully tested this patch with ekiga and 2 spca561 cams (quite
popular IC, used by both logitech and creative), 2 pac207 cams (another quite
popular IC), 3 SN9C10X cams (also very popular) and 1 spca501 cam. All of which
do not work (unless using gspca version 1) without this patch, as pwlib does
not support their proprietary video formats (and rightfully so).

Created attachment 312759
PATCH: use libv4l in v4l2 plugin, adding support for many cam specific formats

Patch looks plausible, but I'm no expert. I'm curious to see how the upstream
bug goes.

(In reply to comment #3)
> Patch looks plausible, but I'm no expert. I'm curious to see how the upstream
> bug goes.

So am I :)

In the mean time can we have this patch go into rawhide please? We need to add
support to gstreamer's v4l2 plugin for the various cam specific formats oneway
or the other (I hope libv4l is the way), otherwise all the effort which has gone
into porting gspca to v4l2 and cleaning it up, which has lead to it being in the
mainline 2.6.27 kernel now, and thus in rawhide, is mostly in vain as people's
webcam's still won't work from an important group of applications.

I can co-maintain, or atleast request bugzilla watch rights for
gstreamer-plugins-good, if you want and then take care of any fallout this may
have. I already maintain gtsreamer-ffmpeg, gstreamer-plugins-ugly and
gstreamer-plugins-bad in that other repo.

If I become a co-maintainer I can also take care of adding the patch to CVS and
building it myself :)

There's still time before the beta. Please try to push the patch upstream first,
we'll see how this goes before adding it to rawhide.

I've submitted it upstream as noted in the original, but in my experience
upstream's response speed varies from fast to pretty slow. Also I would
preferably like to see this get some testing before the beta, the more testing
the better and remember release early release often :)

Note that this patch has just been accepted upstream, see:
http://bugzilla.gnome.org/show_bug.cgi?id=545108

If you want and the CVS ACL's allow it I can push this to rawhide myself.

Created attachment 313380
xawtv-3.95-fixes.patch

Short intro: I'm a long time Linux developer currently working on improving
webcam support in Linux, see:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport

I'm one of the authors of the v4l2 rewrite of the gspca usb webcam driver
framework (which supports more then 100 different cams), this v4l2 rewrite has
been merged into the 2.6.27 kernel and thus will become available in the
official Linux kernel soon.

One of the parts of the v4l2 rewrite has been removing conversion from various
manufacturer cam specific video formats to more normal videoformats from the
drivers, as this really does not belong in kernel space.

As a result of this the gspca subdrivers can generate raw video frames in the
following formats:

#define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x
compressed bayer
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S', '5', '0', '1') /* YUYV per line
#define V4L2_PIX_FMT_SPCA505 v4l2_fourcc('S', '5', '0', '5') /* YYUV per line
#define V4L2_PIX_FMT_SPCA508 v4l2_fourcc('S', '5', '0', '8') /* YUVY per line
#define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed
GBRG bayer
#define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed
BGGR bayer

As we do not want to see each application implement (nor having to implement)
support for these various formats, as we like to have one code base and only
one code base for these formats. A library has been written (with me as the
main author) to convert from these formats to BGR24 or YUV420. For more on this
library see:
http://hansdegoede.livejournal.com/3636.html

As such I've been working (for a number of days!) on a patch to add support for libv4l to xawtv. This has resulted in my doing a whole patch series, listed in the order in which the patches should be applied.

xawtv-3.95-fixes.patch
----------------------
Some small fixes which are needed for xawtv-3.95 to work with some v4l2 devices at all.

xawtv-3.95-libv4l2.patch
------------------------
Use libv4l2 to gain support for all kind of camera specific video formats

xawtv-3.95-no-dga.patch
-----------------------
xawtv does not work on many videocards without specifying -nodga, this patch
fixes this by catching the error and continuing as if the server does not support DGA at all

xawtv-3.95-v4l-conf-user-bpl.patch
----------------------------------
Allow root to override the detected number of bytes per line, this is needed
to get direct pci transfers to the framebuffer to work on my ati x1950pro

Note that for xawtv to work properly atleast version 0.4.0 of libv4l is needed,
rawhide currently has 0.3.9 and I cannot build 0.4.0 due to an error in the kernel-headers package.

p.s.

While writing all these patches and with all my recent v4l work in general I've become quite familiar with the xawtv code, so if you want I can become a co-maintainer (and push these patches myself).

Created attachment 313381
xawtv-3.95-libv4l2.patch

Created attachment 313382
xawtv-3.95-no-dga.patch

Created attachment 313392
xawtv-3.95-v4l-conf-user-bpl.patch

As I already was afraid little response from upstream sofar, could we please get this patch into rawhide so that it can get as much testing as possible. My offer to co-maintain still stands.

Feel free to commit and build using the latest patch I posted upstream on the bugzilla.

Built bastien's version of the patch in g-p-good 0.10.9-2.fc10.

Ping!

I really want to see this hit rawhide before we go into a beta freeze, and as the patch has been accepted upstream I so no reasons for not putting this in rawhide. If I get no response soon I'll commit it to rawhide myself (assuming the ACL's will let me).

Ping,

I would really like to see this fixed before F10-beta freeze so that the better webcam support feature can get some good testing in the Beta.

Pong.

I am still thinking how to make libv4l2 support optional...

It seems that an option is not suitable here, as there are several applications (xawtv, streamer, fbtv, ...) and it is not good to hack all their cmdline interfaces.

Perhaps LD_PRELOAD is a way? If the only application still used by "end users" is "xawtv", then maybe just add "LD_PRRELOAD=..." into its .desktop file? (Saving all another utils unchanged).

P.S. Could you add autoconf stuff for libv4l2 patch as well?

(In reply to comment #5)
> Pong.
>
> I am still thinking how to make libv4l2 support optional...
>

Why would you want todo that? libv4l was explicitly designed to be transparent to the application.

With the current patch, libv4l does not get used / linked in to the lowlevel v4l-info, v4l-conf and v4lctl programs, so those are not affected, all the others actually stream data from the cam in one form or the other and thus need libv4l to work with cams which have funky video formats (IOW most of them!!).

> P.S. Could you add autoconf stuff for libv4l2 patch as well?

Why? Its a distro specific patch and we will always want to enable libv4l support, I will take a look at autoconf support when a new upstream is formed and patches need to become non distro specific so that they can be merged upstream.

> libv4l does not get used / linked in to the lowlevel
> v4l-info, v4l-conf and v4lctl programs

"v4lctl" actually uses libng drivers, ie. the patch affects it as well.

(In reply to comment #7)
> > libv4l does not get used / linked in to the lowlevel
> > v4l-info, v4l-conf and v4lctl programs
>
> "v4lctl" actually uses libng drivers, ie. the patch affects it as well.

Ah I didn't know that even then though, this is not a problem as libv4l does not touch any of the CTRL related ioctl's it passes them through to the kernel *completely* unmodified.

OK

I've added your patches (I have a little touched them, and add manual stuff for the "-p pitch"). Additionally, I've added some debian ones.

The results are available in Koji:
http://kojipkgs.fedoraproject.org/packages/xawtv/3.95/10.fc10/

Looks (In reply to comment #9)
> OK
>
> I've added your patches (I have a little touched them, and add manual stuff for
> the "-p pitch"). Additionally, I've added some debian ones.
>
> The results are available in Koji:
> http://kojipkgs.fedoraproject.org/packages/xawtv/3.95/10.fc10/

Works like a charm, including accessing webcams which do not work without libv4l and using my bttv tv card.

Thanks!

Seems it's a bit late for that. Punting to F10Target.

(In reply to comment #4)
> Seems it's a bit late for that. Punting to F10Target.

Actually this is long fixed, byt I forgot to close the bug (woopsie) closing and removing from trackers.

(In reply to comment #25)
> Any progress on getting the webcams to work?

Still wondering if the webcams (specifically Logitech 9000) works with ispq 9.x and wine 1.4 with Ubuntu v 12.04 or Linux Mint v 14. Thanks for the help.

(In reply to comment #26)
> (In reply to comment #25)
> > Any progress on getting the webcams to work?
>
> Still wondering if the webcams (specifically Logitech 9000) works with ispq 9.x
> and wine 1.4 with Ubuntu v 12.04 or Linux Mint v 14. Thanks for the help.

   Logitech webcam 9000 works perfectly with ispq9.x in win 7 and win xp and the Mac too I believe. In Ubuntu 12.04 and Mint 14 with wine 1.4 it doesn't work. Some users said they could see me and read some text but I can't see users nor read see any text. The camera is great with Skype for Linux and is fine with that in Mint and Ubuntu. Also works with cheese but that isn't a video conferencing program I believe. Hope some day the webcam will work in Linux. Hate to use win 7 to chat with friends. Would love to stay in Linux and use ispq9.x. BTW, I emailed tech support in ispq late last year re: supporting Linux after they did it for the Mac. The reply was no, they have no interest in Linux at this time and it would be too difficult to have techs work on it now. Bummer.

MSN Messenger is now Skype, Yahoo Messenger crashes on login (#32695), iSpQ9 won't install due to MSI problems (https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/614546), so how do you even test this?

Otherwise I've made changes that allow VLC on Wine to capture video from my webcam, please retest with the latest Git or Wine version 1.4.2 when it comes out.

(In reply to comment #28)
> MSN Messenger is now Skype, Yahoo Messenger crashes on login (#32695), iSpQ9
> won't install due to MSI problems
> (https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/614546), so how do you
> even test this?
>
> Otherwise I've made changes that allow VLC on Wine to capture video from my
> webcam, please retest with the latest Git or Wine version 1.4.2 when it comes
> out.

Will wait for Wine 1.4.2 and test ispq again. Thanks

(In reply to comment #29)
> (In reply to comment #28)
> > MSN Messenger is now Skype, Yahoo Messenger crashes on login (#32695), iSpQ9
> > won't install due to MSI problems
> > (https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/614546), so how do you
> > even test this?
> >
> > Otherwise I've made changes that allow VLC on Wine to capture video from my
> > webcam, please retest with the latest Git or Wine version 1.4.2 when it comes
> > out.
>
> Will wait for Wine 1.4.2 and test ispq again. Thanks

Actually you can test with 1.5.22 as well.

fwink no longer runs in wine 1.5.22, it did in wine 1.5.18, it will take time to do the regressiont test.

Created attachment 43229
+qcap,+qcap_v4l in wine 1.5.22

Created attachment 43230
Patch to render even if the output pin is NULL

I tested it before my patches, and Fwink didn't work. I actually just wrote a patch that gets it to start. Doesn't seem to generate proper photos though, I suspect that gdiplus interpolation 7 fixme.

(In reply to comment #33)
> Created attachment 43230 [details]
> Patch to render even if the output pin is NULL
>
> I tested it before my patches, and Fwink didn't work. I actually just wrote a
> patch that gets it to start. Doesn't seem to generate proper photos though, I
> suspect that gdiplus interpolation 7 fixme.

 I can test ispq9.x by installing it in wine 1.4.x or try 1.5.x. Will make a clean install of either and try the .msi and report to you what results. Let me know which wine version is best to try. I am a novice and probably not much help other than simple testing as I mentioned above. Will try and follow simple instructions you may have if I understand them. Sorry for not being much help but I really appreciate every effort you guys make to get it to work. Hopefully others do too. Thanks again. Bob

Fwink creates a NullRenderer. It adds it to the filter graph. On the CaptureGraphBuilder2, it calls RenderStream(), asking it to link the preview pin to the the default renderer. Then it calls RenderStream() again, asking it to link the output pin to the NullRenderer. Finally it adds the sample grabber in front of the NullRenderer, allowing it to take photos.

Since the camera doesn't have a preview pin, CaptureGraphBuilder2 must support the SmartTeeFilter which creates one by duplicating the output pin. Wine's doesn't have that filter. Furthermore, Wine's CaptureGraphBuilder2 doesn't even link the pins correctly. With my patch above, it at least links both to the NullRenderer, allowing Fwink to take photos, but not show preview video (since that needs the SmartTeeFilter).

Those that believe Fwink worked before must have been using native qcap?

(In reply to comment #35)
> Fwink creates a NullRenderer. It adds it to the filter graph. On the
> CaptureGraphBuilder2, it calls RenderStream(), asking it to link the preview
> pin to the the default renderer. Then it calls RenderStream() again, asking it
> to link the output pin to the NullRenderer. Finally it adds the sample grabber
> in front of the NullRenderer, allowing it to take photos.
>
> Since the camera doesn't have a preview pin, CaptureGraphBuilder2 must support
> the SmartTeeFilter which creates one by duplicating the output pin. Wine's
> doesn't have that filter. Furthermore, Wine's CaptureGraphBuilder2 doesn't even
> link the pins correctly. With my patch above, it at least links both to the
> NullRenderer, allowing Fwink to take photos, but not show preview video (since
> that needs the SmartTeeFilter).
>
> Those that believe Fwink worked before must have been using native qcap?

 Thanks for your comments (#35). Don't understand it but from a previous comment I think it said to try and install ispq9.x with wine 1.4 or 1.4.2 when available if not already so. If this is a good idea I will try it and report what happens to you here if this is the correct place. Thanks. Bob

Does the bug still occur with wine-5.12?

Sorry, bug fixed after Sys update (facepalm)

On Tue, Jul 7, 2020 at 5:24 PM Jeremielapuree <email address hidden>
wrote:

> Does the bug still occur with wine-5.12?
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (283421).
> https://bugs.launchpad.net/bugs/260918
>
> Title:
> needed: libv4l and associated application patches (or "gspca stopped
> working in 2.6.27")
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/adobe-flash-plugin-tools/+bug/260918/+subscriptions
>