Video4Linux2 - en - 图文(4)

There are several planar YUV formats in use as well. Drawing them all out does not help much, so we'll go with one example. The commonly-used \V4L2_PIX_FMT_YUV422, fourcc 422P) uses three separate arrays. A 4x4 image would be represented like this:

Y plane:

U plane:

V plane:

As with the Bayer format, YUV 4:2:2 has one U and one V value for every other Y value; displaying the image requires interpolating across the missing values. The other planar YUV formats are:

?

V4L2_PIX_FMT_YUV420: the YUV 4:2:0 format, with one U and one V value for every four

? ? ?

Y values. U and V must be interpolated in both the horizontal and vertical directions. The planes are stored in Y-U-V order, as with the example above.

V4L2_PIX_FMT_YVU420: like YUV 4:2:0, except that the positions of the U and V arrays are swapped.

V4L2_PIX_FMT_YUV410: A single U and V value for each sixteen Y values. The arrays are in the order Y-U-V.

V4L2_PIX_FMT_YVU410: A single U and V value for each sixteen Y values. The arrays are in the order Y-V-U.

A few other YUV formats exist, but they are rarely used; see this page for the full list. Other formats

A couple of formats which might be useful for some drivers are:

? ?

V4L2_PIX_FMT_JPEG: a vaguely-defined JPEG stream; a little more information can be

found here.

V4L2_PIX_FMT_MPEG: an MPEG stream. There are a few variants on the MPEG stream

format; controlling these streams will be discussed in a future installment.

There are a number of other, miscellaneous formats, some of them proprietary; this page has a list of them.

Describing formats

Now that we have an understanding of color formats, we can take a look at how the V4L2 API describes image formats in general. The key structure here is struct v4l2_pix_format (defined in , which contains these fields:

? ? ? ?

__u32 width: the width of the image in pixels. __u32 height: the height of the image in pixels.

__u32 pixelformat: the fourcc code describing the image format.

enum v4l2_field field: many image sources will interlace the data - transferring all of

the even scan lines first, followed by the odd lines. Real camera devices normally do not do interlacing. The V4L2 API allows the application to work with interlaced fields in a surprising number of ways. Common values include V4L2_FIELD_NONE (fields are not interlaced),V4l2_FIELD_TOP (top field only), or V4L2_FIELD_ANY (don't care). See this page for a full list. ?

__u32 bytesperline: the number of bytes between two adjacent scan lines. It includes

? ?

any padding the device may require. For planar formats, this value describes the largest (Y) plane.

__u32 sizeimage: the size of the buffer required to hold the full image. enum v4l2_colorspace colorspace: the colorspace being used.

All together, these parameters describe a buffer of video data in a reasonably complete manner. An application can fill out av4l2_pix_format structure asking for just about any sort of format that a user-space developer can imagine. On the driver side, however, things have to be restrained to the formats the hardware can work with. So every V4L2 application must go through a negotiation process with the driver in an attempt to arrive at an image format that is both supported by the hardware and adequate for the application's needs. The next installment in this series will describe how this negotiation works from the device driver's point of view. Video4Linux2 part 5b: format negotiation [Posted March 23, 2007 by corbet] The LWN.net Video4Linux2 API series. This article is a continuation of the irregular LWN series on writing video drivers for Linux. The introductory article describes the series and contains pointers to the previous articles. In the last episode, we looked at how the Video4Linux2 API describes video formats: image sizes and the representation of pixels within them. This article will complete the discussion by describing the process of coming to an agreement with an application on an actual video format supported by the hardware. As we saw in the previous article, there are many ways of representing image data in memory. There is probably no video device on the market which can handle all of the formats understood by the Video4Linux interface. Drivers are not expected to support formats not understood by the underlying hardware; in fact, performing format conversions within the kernel is explicitly frowned upon. So the driver must make it possible for the application to select a format which works with the hardware.

The first step is to simply allow the application to query the supported formats.

The VIDIOC_ENUM_FMT ioctl() is provided for the purpose; within the driver this command turns into a call to this callback (if a video capture device is being queried):

int (*vidioc_enum_fmt_cap)(struct file *file, void *private_data, struct v4l2_fmtdesc *f);

This callback will ask a video capture device to describe one of its formats. The application will pass in a v4l2_fmtdesc structure:

struct v4l2_fmtdesc {

__u32 index; enum v4l2_buf_type type; …… 此处隐藏：7975字，全部文档内容请下载后查看。喜欢就下载吧 ……