Hello Hans
As you already know, I like to test gspca V2 & libv4l. I had big troubles to get the source from linuxtv.org working on my Ubuntu 8.04. But now it's working. And when the times go by, Ubuntu released 8.10. I upgrade to 8.10 on my "test Laptop". Here gspca v2 is already included. Thus, I decided to use the Ubuntu stock gspca V2 module to test at the beginning.
gspca V2 is a V4L2 driver and therefor should work with a V4L2 frame grabber application. As far as I know the only formats which are allowed by V4L2 is MJPG and YUYV. When the cam cannot provide this format your libv4l is needed to convert from a vendor specific format to the known format of V4L2.
So, I decided to use luvcview (which should be some reference implementation for a V4L2 grabber application?) to test my cams.
I used following cam: Bus 002 Device 004: ID 041e:401c Creative Technology, Ltd WebCam NX [PD1110] because this one was working quite good in gspca V1 and this was the cam which got my attraction to work with webcams. It was my first one....
When I just run luvcview, I get: thomas@LAPI01:~$ luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
So, now it's time to use libv4l: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
Unfortunately, it looks that libv4l cant convert to any format luvcview knows.
Lets check a v4l1 grabber: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so gqcam -v /dev/video0 thomas@LAPI01:~$
No error messages and I got a picture :-)
Long mail for 3 simple question:
Why cant v4l2convert.so convert to YUYV? (Which should be V4L2 conform)
Or I am wrong to use luvcview to test V4L2 webcams?
Is there any other reference implementation for a V4L2 (webcam) grabber?
Regards, Thomas
PS: The cam is working in cheese, too. Looks like cheese is compiled against your lib :-) . I hope all application which deal with webcams will be soon including your libs!
Thomas Kaiser wrote:
......snip.......
Correction: The cam is working in cheese without preloading the libv4l..., too.
PS: The cam is working in cheese, too. Looks like cheese is compiled against your lib :-) . I hope all application which deal with webcams will be soon including your libs!
Thomas Kaiser wrote:
Hello Hans
As you already know, I like to test gspca V2 & libv4l. I had big troubles to get the source from linuxtv.org working on my Ubuntu 8.04. But now it's working. And when the times go by, Ubuntu released 8.10. I upgrade to 8.10 on my "test Laptop". Here gspca v2 is already included. Thus, I decided to use the Ubuntu stock gspca V2 module to test at the beginning.
gspca V2 is a V4L2 driver and therefor should work with a V4L2 frame grabber application. As far as I know the only formats which are allowed by V4L2 is MJPG and YUYV.
Nope, v4l2 does not say anything about which formats are allowed, the whole idea is to expose the hardware to userspace as is, without doing any format conversions or fancy stuff in the kernel. So when using a v4l2 /dev/videoX device the apps get the formats the hardware can handle, nothing more and nothing less.
When the cam cannot provide this format your libv4l is needed to convert from a vendor specific format to the known format of V4L2.
Thats not entirely true, the new gspca driver provides perfectly valid /dev/videoX devices which 100% correctly implement the v4l2 api. The problem is that no app knows how to handle for example pac207 video format, which is sort of not practicable. This is where libv4l comes in. libv4l does format conversion from a wide range of formats to a few often used formats so that not every application has to implement support for the wide range of formats out there itself.
So, I decided to use luvcview (which should be some reference implementation for a V4L2 grabber application?)
luvcview is not really a reference implementation, also I'm not sure if it still is being actively developed.
I used following cam: Bus 002 Device 004: ID 041e:401c Creative Technology, Ltd WebCam NX [PD1110] because this one was working quite good in gspca V1 and this was the cam which got my attraction to work with webcams. It was my first one....
When I just run luvcview, I get: thomas@LAPI01:~$ luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
What happens if you don't pass -f yuv, or pass a different format such as rgb24 ?
So, now it's time to use libv4l: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
Unfortunately, it looks that libv4l cant convert to any format luvcview knows.
I don't know that (I don't know luvcview all that well), your are forcing luvcview to use a format which libv4l cannot convert to, hence things do not work.
libv4l supports converting to: rgb24, bgr24 and yu12 (planar), these are the most often used formats. I'm planning on also adding yv12 as that is popular too. In general apps want either rgb or yuv planar formats, the yuv packed formats are not popular on the applications side.
The list of destination formats libv4l supports is limited because the number of needed conversion functions grows explosively. Currently we support 18 different source formats, and 3 dest formats. So that means that if implemented straight forward we need 18 * 3 = 54 different conversion functions. If we want to add support for YUYV dest format, that means adding another 18 conversion functions! Also each dest format we add makes it harder to add new source formats.
Lets check a v4l1 grabber: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so gqcam -v /dev/video0 thomas@LAPI01:~$
No error messages and I got a picture :-)
Long mail for 3 simple question:
Why cant v4l2convert.so convert to YUYV?
See above.
(Which should be V4L2 conform)
No it wouldn't even if it would only be able to conver everything back to raw bayer that would still be v4l2 conform.
Or I am wrong to use luvcview to test V4L2 webcams?
I don't think that is the nest app to use yes.
Is there any other reference implementation for a V4L2 (webcam) grabber?
Not that I know of, also its important to use a number of different applications, because each app has its own interesting ways of (ab)using the v4l2 api.
PS: The cam is working in cheese, too. Looks like cheese is compiled against your lib :-) . I hope all application which deal with webcams will be soon including your libs!
Yes, in ubuntu 8.10 cheese (all gstreamer based apps) and ekiga atleast should work without problems, ubunutu has done a good job of borrowing all the patches I wrote for Fedora (and send upstream). No if only they would actually write some patches themselves and send those back upstream :( (there are still enough v4l applications not patched to use v4l).
Regards,
Hans
Hans de Goede wrote:
Thomas Kaiser wrote:
Hello Hans
As you already know, I like to test gspca V2 & libv4l. I had big troubles to get the source from linuxtv.org working on my Ubuntu 8.04. But now it's working. And when the times go by, Ubuntu released 8.10. I upgrade to 8.10 on my "test Laptop". Here gspca v2 is already included. Thus, I decided to use the Ubuntu stock gspca V2 module to test at the beginning.
gspca V2 is a V4L2 driver and therefor should work with a V4L2 frame grabber application. As far as I know the only formats which are allowed by V4L2 is MJPG and YUYV.
Nope, v4l2 does not say anything about which formats are allowed, the whole idea is to expose the hardware to userspace as is, without doing any format conversions or fancy stuff in the kernel. So when using a v4l2 /dev/videoX device the apps get the formats the hardware can handle, nothing more and nothing less.
When the cam cannot provide this format your libv4l is needed to convert from a vendor specific format to the known format of V4L2.
Thats not entirely true, the new gspca driver provides perfectly valid /dev/videoX devices which 100% correctly implement the v4l2 api. The problem is that no app knows how to handle for example pac207 video format, which is sort of not practicable. This is where libv4l comes in. libv4l does format conversion from a wide range of formats to a few often used formats so that not every application has to implement support for the wide range of formats out there itself.
So, I decided to use luvcview (which should be some reference implementation for a V4L2 grabber application?)
luvcview is not really a reference implementation, also I'm not sure if it still is being actively developed.
I used following cam: Bus 002 Device 004: ID 041e:401c Creative Technology, Ltd WebCam NX [PD1110] because this one was working quite good in gspca V1 and this was the cam which got my attraction to work with webcams. It was my first one....
When I just run luvcview, I get: thomas@LAPI01:~$ luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
What happens if you don't pass -f yuv, or pass a different format such as rgb24 ?
So, now it's time to use libv4l: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so luvcview -f yuv luvcview 0.2.4
SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal
Unfortunately, it looks that libv4l cant convert to any format luvcview knows.
I don't know that (I don't know luvcview all that well), your are forcing luvcview to use a format which libv4l cannot convert to, hence things do not work.
libv4l supports converting to: rgb24, bgr24 and yu12 (planar), these are the most often used formats. I'm planning on also adding yv12 as that is popular too. In general apps want either rgb or yuv planar formats, the yuv packed formats are not popular on the applications side.
The list of destination formats libv4l supports is limited because the number of needed conversion functions grows explosively. Currently we support 18 different source formats, and 3 dest formats. So that means that if implemented straight forward we need 18 * 3 = 54 different conversion functions. If we want to add support for YUYV dest format, that means adding another 18 conversion functions! Also each dest format we add makes it harder to add new source formats.
Lets check a v4l1 grabber: thomas@LAPI01:~$ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so gqcam -v /dev/video0 thomas@LAPI01:~$
No error messages and I got a picture :-)
Long mail for 3 simple question:
Why cant v4l2convert.so convert to YUYV?
See above.
(Which should be V4L2 conform)
No it wouldn't even if it would only be able to conver everything back to raw bayer that would still be v4l2 conform.
Or I am wrong to use luvcview to test V4L2 webcams?
I don't think that is the nest app to use yes.
Is there any other reference implementation for a V4L2 (webcam) grabber?
Not that I know of, also its important to use a number of different applications, because each app has its own interesting ways of (ab)using the v4l2 api.
PS: The cam is working in cheese, too. Looks like cheese is compiled against your lib :-) . I hope all application which deal with webcams will be soon including your libs!
Yes, in ubuntu 8.10 cheese (all gstreamer based apps) and ekiga atleast should work without problems, ubunutu has done a good job of borrowing all the patches I wrote for Fedora (and send upstream). No if only they would actually write some patches themselves and send those back upstream :( (there are still enough v4l applications not patched to use v4l).
Regards,
Hans
Hello Hans
Thanks for the explanations.
Yes, I know that we should us as many as possible application to test. But my idea is to first use a V4L2 reference application to test a webcam and then start trying as many as possible application which make use of a webcam.
luvcview only supports YUYV and MJPG.
So, it looks like there is no reference viewer/grabber application :-( I will just pick one which I like most.
I will post my results on the 4VL mail list.
Thanks again for your time.
Regards, Thomas
Hi Thomas,
On Wed, 12 Nov 2008 16:23:33 +0100 Thomas Kaiser v4l@kaiser-linux.li wrote:
Yes, I know that we should us as many as possible application to test. But my idea is to first use a V4L2 reference application to test a webcam and then start trying as many as possible application which make use of a webcam.
luvcview only supports YUYV and MJPG.
So, it looks like there is no reference viewer/grabber application :-( I will just pick one which I like most.
I will post my results on the 4VL mail list.
The application that is becoming a good reference for V4L2 API, at least for me, is mplayer, since it supports both mmap and read() method, has lots of different decoders there, and implements both V4L1 and V4L2 API, works fine with mpeg encoded and raw formats, and allows you to select what you want via command line.
So, if you want to randomly pick a reference application, I would suggest you to use mplayer.
As all applications, I bet it won't work with certain hardware.
Cheers, Mauro
-
Hans de Goede -
Mauro Carvalho Chehab -
Thomas Kaiser