linux-uvc-devel — Linux UVC development

[Linux-uvc-devel] UVC Device

[Simo L. <si...@ar...>]

Hello, I saw the request on the homepage about reporting UVC devices.

I own a Fuji Finepix E500, it is a digital camera that can be put into a
webcam mode. When in this mode, it appears to act as a UVC device. 
I would be willing to do testing as well, feel free to contact me if it
is needed.

-Simo


lsusb -v output from it follows:

--snip--
Bus 004 Device 002: ID 04cb:0169 Fuji Photo Film Co., Ltd 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 Common Class
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x04cb Fuji Photo Film Co., Ltd
  idProduct          0x0169 
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                2 USB Web Camera
  iSerial                 3 A-Serial-Number
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          156
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower               50mA
    UNRECOGNIZED:  08 0b 00 02 0e 03 00 00
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass        14 Video
      bInterfaceSubClass      1 Video Control
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass        14 Video
      bInterfaceSubClass      2 Video Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
--snip--

[Linux-uvc-devel] Initial use of UVC driver

[James W. S. <jws...@co...>]

I retried the test script under a gnome terminal and it
completed correctly. I will continue to duplicate
the lockup I first experienced.

I need to thank you for developing this driver.

James

Re: [Linux-uvc-devel] Re: Test of the driver on GNU/Debian amd64

[<Oli...@id...>]

Hello,

<comment>
A little bit off-topic, as this talk about OpenCV...
Next questions about OpenCV should maybe done on the OpenCV mailing
list: http://www.yahoogroups.com/group/OpenCV
</comment>

> I was wondering if you had a sample piece of code for changing the
> camera resolution? I seem to be getting 640x480 nice and smooth, but i
> would rather work in 320x240, limitations on my processing algorithms.
> Is there a way to grab straight from the camera at this resolution or
> should i just convert in my application? There is already a heavy load
> on the processors by the way.

here is the Python code for doing this:
  # set the wanted image size from the camera
  highgui.cvSetCaptureProperty (capture, highgui.CV_CAP_PROP_FRAME_WIDTH, 320)
  highgui.cvSetCaptureProperty (capture, highgui.CV_CAP_PROP_FRAME_HEIGHT,240)

I will let you make the C code as an exercice. ;-)

Have a nice night.

        Olivier
-- 
   . __    . ___  __.  | Olivier Bornet         Oli...@id...
  / /  `  / /  / /  /  | IDIAP             http://www.idiap.ch/~bornet/
 / /   / / /--/ /--'   | CP 592        http://www.idiap.ch/~bornet/pgp/
/ /__.' / /  / /       | CH-1920 Martigny           PGP-key: 0xC53D9218

[Linux-uvc-devel] uvcview videograbber with preview available for testing

[michel X. <mx...@ma...>]

Aujourd'hui 19:51:24
   
Hi
uvcview grabber is available  for testing : 
http://mxhaard.free.fr/spca50x/Investigation/uvc/
need libSDL installed
 linux framebuffer or X11
        features 
        display in overlay all surfaces from the uvcvideo webcam. without 
colors 
transformations (all done by your videocard)
        controls are set by mouse or keyboard
        windows are resizable on the fly
        get picture in jpeg mode only
to run the apps
uvcview -d /dev/video0 -f jpg -s 960x720
ask uvcvideo on video0, palette jpeg, width 960, height 720

uvcview -d /dev/video0 -f yuv -s 1024x576
ask uvcvideo on video0, palette yuyv, width 1024, height 576

If the size is not good uvcview will follow uvcvideo transaction and run the 
first nearest available resolution with the same palette.

Know bugs:
Crash Laurent Pinchart box with ATI card ( maybe FIXED by this release)
-- 
Michel Xhaard
http://mxhaard.free.fr

[Linux-uvc-devel] Slackware 10.2 - 2.6.15 vanilla

[Drew O. <ost...@gm...>]

Hi,

> full speed means USB 1.1, 12Mb/s. Uncompressed YUYV formats won't be
> available. If your hardware supports USB 2.0, please investigate. Have you
> loaded the EHCI module ?

I have EHCI built into the kernel, however i noticed by looking into
the specs of my main board that it is only USB 1.1. I do wish to let
you know that i can capture from the camera using OpenCV, so the
driver is working correctly on my system.

Keep up the great work on this driver, I can honestly say that the
hardware is good, and your driver is awesome. To my eyes i am
receiving a better image on my Linux box with USB 1.1 then i do on my
Notebook with USB 2.0 with windows.

I also receive these emails in a digest, and can't for the life of me
figure out the subject line i should be replying with to keep my
emails in the thread. If you know could you please let me know, i hate
creating new threads for nothing.

Regards,

Drew Ostheimer

[Linux-uvc-devel] Re: Test of the driver on GNU/Debian amd64

[Drew O. <ost...@gm...>]

Hello,

> Just download the CVS version of OpenCV from:
>
>     http://sourceforge.net/cvs/?group_id=3D22870

Did that yesterday and actually got it to compile.

> Build and install. Then, try one of the sample in samples/c/ or
> samples/python/. To see how to use the camera, you can look at
> samples/c/camshiftdemo.c or samples/python/cam-histo.py (my preference
> goes to the python version :-) ).

I compiled the C version yesterday and the samples seem to be working
properly. Thanks for you help with this matter.

I was wondering if you had a sample piece of code for changing the
camera resolution? I seem to be getting 640x480 nice and smooth, but i
would rather work in 320x240, limitations on my processing algorithms.
Is there a way to grab straight from the camera at this resolution or
should i just convert in my application? There is already a heavy load
on the processors by the way.

Regards,

Drew Ostheimer

Re: [Linux-uvc-devel] Slackware 10.2 - 2.6.15 vanilla

[Laurent P. <lau...@sk...>]

> Here is my dmesg output:
>
> usb 2-2: new full speed USB device using ohci_hcd and address 2

full speed means USB 1.1, 12Mb/s. Uncompressed YUYV formats won't be 
available. If your hardware supports USB 2.0, please investigate. Have you 
loaded the EHCI module ?

Laurent Pinchart

Re: [Linux-uvc-devel] Test of the driver on GNU/Debian amd64

[<Oli...@id...>]

Hello,

> Olivier: Would it be possible to post a simple OpenCV application to
> grab 1 frame from the camera? Would be greatly appreciated and help me
> in my endeavor.

Just download the CVS version of OpenCV from:

    http://sourceforge.net/cvs/?group_id=22870

Build and install. Then, try one of the sample in samples/c/ or
samples/python/. To see how to use the camera, you can look at
samples/c/camshiftdemo.c or samples/python/cam-histo.py (my preference
goes to the python version :-) ).

In general, I'm testing uvc with cam-histo.py. (don't have try the C
version at with uvc, but it should works without problems). If you just
want to grab 1 frame from the cam, this simple python code should works:

    from opencv import highgui
    device_nb = 0
    capture = highgui.cvCaptureFromCAM (device_nb)
    frame = highgui.cvQueryFrame (capture)
    highgui.cvSaveImage ('my-frame.jpg', frame)

Hope this help.

        Olivier
-- 
   . __    . ___  __.  | Olivier Bornet         Oli...@id...
  / /  `  / /  / /  /  | IDIAP             http://www.idiap.ch/~bornet/
 / /   / / /--/ /--'   | CP 592        http://www.idiap.ch/~bornet/pgp/
/ /__.' / /  / /       | CH-1920 Martigny           PGP-key: 0xC53D9218

[Linux-uvc-devel] Slackware 10.2 - 2.6.15 vanilla

[Drew O. <ost...@gm...>]

Hey All,

Sorry about the last message, hit send when i was meaning to past in
some of the results.

Here is my dmesg output:

usb 2-2: new full speed USB device using ohci_hcd and address 2
usbvideo: Probing device 2
Format MJPEG found
usbvideo: Found a Status endpoint (addr 87).
usbvideo: Found UVC device (1.00)
usbvideo: Scanning UVC chain: OT 5 <- Unit 4 <- Unit 3 <- Unit 2 <- IT 1
usbvideo: Found a valid video chain (1 -> 5).
usbvideo: UVC device initialized.
usbcore: registered new driver usbvideo
USB Video Class driver (v0.1.0)


And my output running the previous test application which was posted
in the mailing list:

Device /dev/video0 opened: .
Unable to set format: 22.

Hopefully this will be able to give you guys a better idea on what i
am working with. If you should require anything don't hesitate to ask.

And again, work on a driver like this is amazing! Keep it up!

Regards,

Drew Ostheimer

---------- Original message ----------
From: Drew Ostheimer <ost...@gm...>
Date: Jan 6, 2006 3:46 PM
Subject: Re: [Linux-uvc-devel] Test of the driver on GNU/Debian amd64
To: lin...@li...


Hello Olivier Et All,

It's great to see some people working on this driver. I am working
with a Quickcam for Notebooks Pro, megapixle edition. I have installed
and got the uvcvideo module to load and when i connect the camera
everything is recognized properly. The only thing i see lacking is it
not informing me that it is attached to /dev/video*. I am unsure of
where it is getting attached and that could be half my problem.



Olivier: Would it be possible to post a simple OpenCV application to
grab 1 frame from the camera? Would be greatly appreciated and help me
in my endeavor.

Re: [Linux-uvc-devel] Test of the driver on GNU/Debian amd64

[Drew O. <ost...@gm...>]

Hello Olivier Et All,

It's great to see some people working on this driver. I am working
with a Quickcam for Notebooks Pro, megapixle edition. I have installed
and got the uvcvideo module to load and when i connect the camera
everything is recognized properly. The only thing i see lacking is it
not informing me that it is attached to /dev/video*. I am unsure of
where it is getting attached and that could be half my problem.



Olivier: Would it be possible to post a simple OpenCV application to
grab 1 frame from the camera? Would be greatly appreciated and help me
in my endeavor.

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 16:31, Luc Saillard a écrit :
> On Fri, Jan 06, 2006 at 03:04:25PM +0100, michel Xhaard wrote:
> > Le Vendredi 6 Janvier 2006 13:57, michel Xhaard a écrit :
> > > Le Vendredi 6 Janvier 2006 13:54, Laurent Pinchart a écrit :
> > > > > Look like i need to read the spec before ask :)
> > > > > Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all
> > > > > i get is a black screen on boot.
>
> Have you try maxcpus=1 ?
>
> > > > > Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am
> > > > > wrong but spca5xx or pwc are working fine with this SMP box so that
> > > > > should not be a controller issue.
> > > >
> > > > Except that spca5xx and pwc are USB 1.1 devices. I would have liked
> > > > to make sure that this is not a high speed isochronous transfer
> > > > issue.
>
> Try to remove the ehci driver, so you disconnect the usb2.0 device, and you
> will return in usb1.1. Even if you have ehci loaded and an usb device, ehci
> is not used.
>
> Luc
maxcpus=1 boot with only cpu0 thanks :) 
but seem not FIX our problem i get the same data corruption with
 data[0] = 0 :( 
removing ehci_hcd : uvcvideo did not accept 1024x576 nor 1280x960 in yuyv 
without usb2.
 My SDL grabber return Unable to set format !! 
-- 
Michel Xhaard
http://mxhaard.free.fr

[Linux-uvc-devel] Re: [ANNOUNCE] Linux UVC driver available

[William B. <wb...@gm...>]

I've got a short amount of time, so I'll just answer part of this to
you and the list.

> Why does it fail with the 2.6.13 kernel ? What happens ?

My bad. It seems I was trying to load the 2.6.15 version in the wee
hours of the mornig while running under 2.6.13-15.7. When I load the
right version with the right kernel, it loads just fine. Sorry.

> V4L2 is an API... You will need to code V4L2 support in ffmpeg.

Yep. That's the answer I was afraid of. Thanks.

On 1/6/06, Laurent Pinchart <lau...@sk...> wrote:
> Hi William,
>
> I cc'ed my answer to lin...@li..., please use the mailing
> list instead of contacting me directly (so that other people can learn from
> your problems and/or help you).
>
...
>
> V4L2 is an API. It describes the way user-space applications (in your case
> ffmpeg) communicate with the driver. You can't "install" V4L2. You will need
> to code V4L2 support in ffmpeg. Or ask nicely someone to do it for you :-)
>
> Laurent Pinchart
>

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[Luc S. <lu...@sa...>]

On Fri, Jan 06, 2006 at 03:04:25PM +0100, michel Xhaard wrote:
> Le Vendredi 6 Janvier 2006 13:57, michel Xhaard a écrit :
> > Le Vendredi 6 Janvier 2006 13:54, Laurent Pinchart a écrit :
> > > > Look like i need to read the spec before ask :)
> > > > Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all i
> > > > get is a black screen on boot.

Have you try maxcpus=1 ?

> > > > Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am wrong
> > > > but spca5xx or pwc are working fine with this SMP box so that should
> > > > not be a controller issue.
> > >
> > > Except that spca5xx and pwc are USB 1.1 devices. I would have liked to
> > > make sure that this is not a high speed isochronous transfer issue.

Try to remove the ehci driver, so you disconnect the usb2.0 device, and you
will return in usb1.1. Even if you have ehci loaded and an usb device, ehci
is not used.

Luc

[Linux-uvc-devel] [FIXED] Crash with tvtime on second open

[Laurent P. <lau...@sk...>]

Hi everybody,

I just commited release 8 of uvcvideo.c which fixes a bad crash when trying to 
open the webcam two times in a row with tvtime (or actually with anything the 
second time).

Laurent Pinchart

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 13:57, michel Xhaard a écrit :
> Le Vendredi 6 Janvier 2006 13:54, Laurent Pinchart a écrit :
> > > Look like i need to read the spec before ask :)
> > > Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all i
> > > get is a black screen on boot.
> > >
> > :-(
> > :
> > > Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am wrong
> > > but spca5xx or pwc are working fine with this SMP box so that should
> > > not be a controller issue.
> >
> > Except that spca5xx and pwc are USB 1.1 devices. I would have liked to
> > make sure that this is not a high speed isochronous transfer issue.
> >
> > Laurent Pinchart
>
> Laurent,
> Good point :)
> I am just compiling a fresh 2.6.15 kernel on the HP
Maybe a little to mutch enthousiast 2.6.15 did not boot on my HP
Waiting for /dev/hda3 to appear ...... look like it never appear nor resume ;(
-- 
Michel Xhaard
http://mxhaard.free.fr

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 13:54, Laurent Pinchart a écrit :
> > Look like i need to read the spec before ask :)
> > Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all i get
> > is a black screen on boot.
> >
> :-(
> :
> > Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am wrong but
> > spca5xx or pwc are working fine with this SMP box so that should not be a
> > controller issue.
>
> Except that spca5xx and pwc are USB 1.1 devices. I would have liked to make
> sure that this is not a high speed isochronous transfer issue.
>
> Laurent Pinchart
Laurent,
Good point :) 
I am just compiling a fresh 2.6.15 kernel on the HP 
-- 
Michel Xhaard
http://mxhaard.free.fr

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[Laurent P. <lau...@sk...>]

> Look like i need to read the spec before ask :)
> Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all i get
> is a black screen on boot.

:-(

> Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am wrong but
> spca5xx or pwc are working fine with this SMP box so that should not be a
> controller issue.

Except that spca5xx and pwc are USB 1.1 devices. I would have liked to make 
sure that this is not a high speed isochronous transfer issue.

Laurent Pinchart

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 11:59, Laurent Pinchart a écrit :
> > Laurent,
> > I am still trying to figure out where the corruption come from on the SMP
> > box. After some usefull uvc_printk() and moving some part of code from
> > uvc_video_decode() to uvc_video_complete() i can make MJPEG working or
> > not
> >
> > :( even if my code do nothing exept take the value in the iso desc buffer
> >
> > brr .
>
> Mmmmm... Sounds like a timing issue... I don't like those.
>
> > On each usb packet desc (data[0]) the first field reffer to the packet
> > header lenght ?
>
> (from the UVC specs)
>
> "Each Uncompressed frame is considered a single video sample. A video
> sample is made up of one or more payload transfers (as defined in the USB
> Device Class Specification for Video Devices).
>
> For an isochronous pipe, each (micro) frame will contain a single payload
> transfer. Each payload transfer will consist of a payload header
> immediately followed by payload data in one or more data transactions (up
> to 3 data transactions for high speed high bandwidth endpoints)."
>
> So each frame contains a header followed by data. The frame can span up to
> 3 data transactions, but that's handled by the USB layer and transparent
> for the driver.
>
> > with yuyv palette the stream start with that field set to 0
> > then toggle to 12 in the stream and  for a short  times ( ~2 usb packet)
> > goes to 0 when the packet length is full ? this feature only appear on
> > yuyv palette.
>
> That shouldn't happen. From my understanding of the spec, the header length
> should always be at least 2 (the HLE and BFH fields seem to be required,
> the PTS and SCR fields are optional).
>
> > On a UP box this field is constant and always egal to 12.
>
> That's how it should be.
>
> > I think we are not getting the right data from the urb buffer here :(
>
> Might... I'd like you to run the same tests on the SMP box with SMP
> disabled. I'd like to be sure it's not a USB controller issue. Which kernel
> version are you running ?
>
> > In my experiment i have get some good kernel crash :)  I suspect on
> > restart the last synchro bit in the queue is not reset or maybe my
> > grabber is wrong and need to dequeue all buffers on stop ?
>
> The synchro bit is reset on restart, but I had forgotten to mark the
> buffers as idle. This is fixed in svn.
>
> If the last packet of a frame is lost (which can happen with isochronous
> transfers), the EOF bit will not be seen and the FID bit will toggle on the
> next frame. The driver currently doesn't handle that properly, but it
> shouldn't result in a 0 header length. Try to print the second header byte
> as well (data[1]) as an hexadecimal number, and see if it tells you
> anything (have a look at USB_Video_Payload_Uncompressed_1.1.pdf to find the
> stream header description).
>
> Laurent Pinchart
Laurent,
http://mxhaard.free.fr/spca50x/Investigation/uvc/
messages.tar.gz from my /var/log/messages
first part MJPEG stream working
second part YUYV not working
I have also set here the uvc_video_complete() used for this record 
for a best understanding (without pass by indent sorry :))
The only difference from the original is i bypass when len <= data[0] as i did 
not want to fill all my harddrive :)
-- 
Michel Xhaard
http://mxhaard.free.fr

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 11:59, Laurent Pinchart a écrit :
> > Laurent,
> > I am still trying to figure out where the corruption come from on the SMP
> > box. After some usefull uvc_printk() and moving some part of code from
> > uvc_video_decode() to uvc_video_complete() i can make MJPEG working or
> > not
> >
> > :( even if my code do nothing exept take the value in the iso desc buffer
> >
> > brr .
>
> Mmmmm... Sounds like a timing issue... I don't like those.
>
> > On each usb packet desc (data[0]) the first field reffer to the packet
> > header lenght ?
>
> (from the UVC specs)
>
> "Each Uncompressed frame is considered a single video sample. A video
> sample is made up of one or more payload transfers (as defined in the USB
> Device Class Specification for Video Devices).
>
> For an isochronous pipe, each (micro) frame will contain a single payload
> transfer. Each payload transfer will consist of a payload header
> immediately followed by payload data in one or more data transactions (up
> to 3 data transactions for high speed high bandwidth endpoints)."
>
> So each frame contains a header followed by data. The frame can span up to
> 3 data transactions, but that's handled by the USB layer and transparent
> for the driver.
>
> > with yuyv palette the stream start with that field set to 0
> > then toggle to 12 in the stream and  for a short  times ( ~2 usb packet)
> > goes to 0 when the packet length is full ? this feature only appear on
> > yuyv palette.
>
> That shouldn't happen. From my understanding of the spec, the header length
> should always be at least 2 (the HLE and BFH fields seem to be required,
> the PTS and SCR fields are optional).
>
> > On a UP box this field is constant and always egal to 12.
>
> That's how it should be.
>
> > I think we are not getting the right data from the urb buffer here :(
>
> Might... I'd like you to run the same tests on the SMP box with SMP
> disabled. I'd like to be sure it's not a USB controller issue. Which kernel
> version are you running ?
>
> > In my experiment i have get some good kernel crash :)  I suspect on
> > restart the last synchro bit in the queue is not reset or maybe my
> > grabber is wrong and need to dequeue all buffers on stop ?
>
> The synchro bit is reset on restart, but I had forgotten to mark the
> buffers as idle. This is fixed in svn.
>
> If the last packet of a frame is lost (which can happen with isochronous
> transfers), the EOF bit will not be seen and the FID bit will toggle on the
> next frame. The driver currently doesn't handle that properly, but it
> shouldn't result in a 0 header length. Try to print the second header byte
> as well (data[1]) as an hexadecimal number, and see if it tells you
> anything (have a look at USB_Video_Payload_Uncompressed_1.1.pdf to find the
> stream header description).
>
> Laurent Pinchart
Laurent,
Look like i need to read the spec before ask :)
Unfortunnatelly i cannot get nosmp nor noht working on my HP :( all i get is a 
black screen on boot.
Kernel is set with a Suse 2.6.11 smp on the two box. Maybe i am wrong but 
spca5xx or pwc are working fine with this SMP box so that should not be a 
controller issue. 
-- 
Michel Xhaard
http://mxhaard.free.fr

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[Laurent P. <lau...@sk...>]

> Laurent,
> I am still trying to figure out where the corruption come from on the SMP
> box. After some usefull uvc_printk() and moving some part of code from
> uvc_video_decode() to uvc_video_complete() i can make MJPEG working or not
> :( even if my code do nothing exept take the value in the iso desc buffer
> brr .

Mmmmm... Sounds like a timing issue... I don't like those.

> On each usb packet desc (data[0]) the first field reffer to the packet
> header lenght ?

(from the UVC specs)

"Each Uncompressed frame is considered a single video sample. A video sample 
is made up of one or more payload transfers (as defined in the USB Device 
Class Specification for Video Devices).

For an isochronous pipe, each (micro) frame will contain a single payload 
transfer. Each payload transfer will consist of a payload header immediately 
followed by payload data in one or more data transactions (up to 3 data 
transactions for high speed high bandwidth endpoints)."

So each frame contains a header followed by data. The frame can span up to 3 
data transactions, but that's handled by the USB layer and transparent for 
the driver.

> with yuyv palette the stream start with that field set to 0 
> then toggle to 12 in the stream and  for a short  times ( ~2 usb packet)
> goes to 0 when the packet length is full ? this feature only appear on yuyv
> palette.

That shouldn't happen. From my understanding of the spec, the header length 
should always be at least 2 (the HLE and BFH fields seem to be required, the 
PTS and SCR fields are optional).

> On a UP box this field is constant and always egal to 12. 

That's how it should be.

> I think we are not getting the right data from the urb buffer here :(

Might... I'd like you to run the same tests on the SMP box with SMP disabled. 
I'd like to be sure it's not a USB controller issue. Which kernel version are 
you running ?

> In my experiment i have get some good kernel crash :)  I suspect on restart
> the last synchro bit in the queue is not reset or maybe my grabber is wrong
> and need to dequeue all buffers on stop ?

The synchro bit is reset on restart, but I had forgotten to mark the buffers 
as idle. This is fixed in svn.

If the last packet of a frame is lost (which can happen with isochronous 
transfers), the EOF bit will not be seen and the FID bit will toggle on the 
next frame. The driver currently doesn't handle that properly, but it 
shouldn't result in a 0 header length. Try to print the second header byte as 
well (data[1]) as an hexadecimal number, and see if it tells you anything 
(have a look at USB_Video_Payload_Uncompressed_1.1.pdf to find the stream 
header description).

Laurent Pinchart

Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Mercredi 4 Janvier 2006 23:02, Laurent Pinchart a écrit :
> Hi Michel,
>
> > Just test the rev 4 with my HP zd8000 P4 64 bits 3Go with a smp kernel,
> > graphic card ATI Mobility X600 and the uvcview SDL grabber
> > the good news
> > the driver work fine with all jpeg/size
> > SDL yuv overlay never crash :)
> > the bad news :
> > driver return EIO on VIDIOC_DQBUF with all yuyv palette in my grabbing
> > routine. SDL open a black screen but did not crash the box :)
> > to be sure
> > tested with my Athlon 2200+ Nvidia card, all size/palette are working
> > like a charm .
>
> -EIO means that the buffer has been marked as erroneous. Either because the
> URB completion handler received more data than expected or because it
> received a non-zero status. Could you check dmesg to see if it prints a
> debug message ? If not, please have a look at uvc_video_complete and add
> printks to see where it fails.
>
> Laurent Pinchart
Laurent,
I am still trying to figure out where the corruption come from on the SMP box. 
After some usefull uvc_printk() and moving some part of code from 
uvc_video_decode() to uvc_video_complete() i can make MJPEG working or not :(
even if my code do nothing exept take the value in the iso desc buffer brr .

On each usb packet desc (data[0]) the first field reffer to the packet header 
lenght ?with yuyv palette the stream start with that field set to 0 then 
toggle to 12 in the stream and  for a short  times ( ~2 usb packet) goes to 0 
when the packet length is full ? this feature only appear on yuyv palette.
On a UP box this field is constant and always egal to 12. 
I think we are not getting the right data from the urb buffer here :(
In my experiment i have get some good kernel crash :)  I suspect on restart 
the last synchro bit in the queue is not reset or maybe my grabber is wrong 
and need to dequeue all buffers on stop ?  
-- 
Michel Xhaard
http://mxhaard.free.fr

[Linux-uvc-devel] Success with tvtime

[Laurent P. <lau...@sk...>]

Hi everybody,

I commited a patch which fixes an issue with the video buffers queue (the 
buffers were not properly uninitialized when disabling the queue). I'm now 
able to use the driver with tvtime. You will have to patch tvtime with 
http://svn.berlios.de/wsvn/linux-uvc/patches/tvtime/tvtime-1.0.2-videoinput.patch?op=file&rev=0&sc=0 
(I submitted a bug report, the patch should hopefully be commited soon).

I noticed that controls (brightness, saturation, ...) sometimes timeout when 
using tvtime, I'm investigating the issue.

Have fun, and report bugs :-).

Laurent Pinchart

Re: [Linux-uvc-devel] Initial use of UVC driver

[Laurent P. <lau...@sk...>]

> >>In doing some additional analsyis I downloaded compiled then ran the
> >> test.c program you posted.  It does access the camera but it tnen
> >> completly locks up the system. It appears to me that the Fedora 4 kernel
> >> has some differences than a stock kernel that is affecting how the
> >> driver functions.
> >
> >Can you run the test program in a virtual console (not under X) and see if
> > you get a kernel oops ? If so, please post the report.
>
> Laurent,
>
> I configured my system into runlevel 3.
> I successfully ran and stoppe your  test program.

Can you reproduce the problem when you run the test program in X ? If so, 
could you try to get a kernel oops report using a serial console (or a net 
console) ?

Laurent Pinchart

Re: [Linux-uvc-devel] patch 490952 test on dual athlon MP smp box at work :)

[Laurent P. <lau...@sk...>]

Hi Michel,

> here is the message from the patch from last night .
> First part are MJPG palette (working)  second part YUYV palette (unworking)

Thanks. Can you try the same with SMP disabled ?

Laurent Pinchart

[Linux-uvc-devel] Re: [ANNOUNCE] Linux UVC driver available

[Laurent P. <lau...@sk...>]

Hi William,

I cc'ed my answer to lin...@li..., please use the mailing 
list instead of contacting me directly (so that other people can learn from 
your problems and/or help you).

> Thank you for doing all of this work. I pulled down the sources from
> SVN and built the driver under SuSE 10, for on the stock 2.6.13 kernel
> supplied with the distribution, then under 2.6.15 which I built. It
> does not load under 2.6.13, but does load fine under 2.6.15. There is,
> however, a problem when I try to use it.

Why does it fail with the 2.6.13 kernel ? What happens ?

> First, I've written an application that uses ffmpeg and SDL to perform
> image processing. It works with either pre-recorded videos or webcams.
> The webcam section works with a Logitech 4000 Pro and the pwc driver
> from Saillard. This is the section of my application code that fails
> with your driver:
>
>         // Hard code this for now.
>         //
>         params.device = filename;
>         params.channel = 0;
>         params.standard = "ntsc";
>         params.width = 640;
>         params.height = 480;
>         params.time_base.den = 24;
>         params.time_base.num = 1;
>         AVInputFormat
>             *ciformat = av_find_input_format(videoSubsystem);
>
>         if (ciformat)
>         {
>             DBG << "Found " << videoSubsystem << std::endl;
>         }
>         else
>         {
>             ERR << "AVInputFormat from av_find_input_format "
>                 "for " << videoSubsystem << " is null!" << std::endl;
>         }
>
>         DBG << "Attempting to open device: " << filename << std::endl;
>
>         if (av_open_input_file(&fmtContext, filename, ciformat, 0, &params)
> < 0) {
>             ERR << "Could not open device: " << filename << std::endl;
>             return 0;
>         }
>
> Evreything works fine for the older driver and the 4000 Pro. When I
> load your driver and plug in the Logitech Fusion I get "VIDIOCGCAP:
> Invalid argument" when calling av_open_input_file(...). I set up
> ciformat with av_find_input_format(...) where videoSubsystem is a
> const cstring equal to "video4linux". I know that you state that your
> driver does not support V4L, but V4L2. My basic questions are do I
> have V4L2 installed on my SuSE distribution, and how to I invoke it
> from ffmpeg?

V4L2 is an API. It describes the way user-space applications (in your case 
ffmpeg) communicate with the driver. You can't "install" V4L2. You will need 
to code V4L2 support in ffmpeg. Or ask nicely someone to do it for you :-)

Laurent Pinchart