USB Video Class and V4L2

[Laurent Pinchart <laurent.pinchart@xxxxxxxxx>]

Hi everybody,

as I plan to post quite a few mails to this mailing list, I'll start by 
introducing myself.

My name is Laurent Pinchart, and I'm a Belgian electrical engineer with some 
experience in Linux kernel development (I worked on the zoran driver).

I've been interested in the USB Video Class standard for some time. While 
looking at the Logitech webcams a few months ago, I noticed that the newer 
models seemed to be UVC compliant. I ran to the store, bought a Logitech 
webcam (Quickcam Fusion, 046d:08c1), plugged it in my Linux box, and found 
out it advertised a vendor class. Damn.

After further investigation, help from Michel Xhaard (spc5xx Linux driver) and 
from a developper at Logitech, and some coding in usbtools, I was relieved to 
find out that the webcam was indeed UVC (1.0) compliant, with the exception 
that it doesn't advertise the UVC class for a few technical reasons (namely 
that the UVC Windows driver is not mature yet).

As there was no UVC Linux driver, I started coding a few weeks ago. The device 
behaves nicely, it answers simple requests, and I'm not very far from getting 
a very first image.

That was the good news.

Some of you have probably read the UVC spec. The spec is quite broad, but not 
that complicated, if you decide to support only simple devices, which is my 
goal here (the definition of a webcam for my driver is a camera sensor 
connected to a usb port, through an optional processing unit and extension 
units).

V4L2 supports functionnalities which seem to be missing from the UVC spec 
(cropping is one of them, scaling is another), but also misses some of the 
functionnalities defined in the spec.

Some of those functionnalities are extra controls, which can either be mapped 
directly to a private control (using VIDIOC_G_CTRL and VIDIOC_S_CTRL), or 
mapped to several V4L2 controls (one example is the white balance control, 
which is a single control in UVC, but uses several controls in V4L2). It 
might be useful to standardize those controls in V4L2, but that will come 
later.

Some other functionnalities are more difficult to implement in V4L2. The 
problem comes from the way UVC negociates streaming parameters (image size, 
frame rate and compression parameters).

A UVC device advertises several image formats (YUY2 and MJPEG for the device 
I'm working with). For each format, it advertises several image sizes (width 
and height), and for each of these sizes it advertises several frame rates 
(called frame intervals).

The UVC driver selects a format and a frame size (easily done in V4L2 using 
VIDIOC_S_FMT), and then negociates the frame interval and compression 
parameters (quality, key frame rate and P frame rate). The host sets desired 
values and ask the device to compute the actual parameters it can support. 
For instance, the host could set the frame interval and ask the device to 
compute the quality.

I'm now sure how to map that to the V4L2 API. If I'm not mistaken, V4L2 
requires all other parameters (compression, frame rate, ...) to be set before 
calling VIDIOC_S_FMT. My problem is that, depending on the image format and 
frame size, the frame rates supported by the devices may vary. What if an 
application requests a frame rate (VIDIOC_S_PARM) and then selects a format 
for which the selected frame rate is not supported ?

The UVC spec also allows for dynamic format changes (either host initiated or 
device initiated) and still image transfer during streaming.

If someone here has read the UVC spec and thought about implementation details 
(either how to map UVC to V4L2 or how to change V4L2 is needed), help will be 
welcome.

Laurent Pinchart

--

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