The current video standard determines a nominal number of
frames per second. If less than this number of frames is to be
captured or output, applications can request frame skipping or
duplicating on the driver side. This is especially useful when using
the read() or write(), which
are not augmented by timestamps or sequence counters, and to avoid
unneccessary data copying.
Further these ioctls can be used to determine the number of
buffers used internally by a driver in read/write mode. For
implications see the section discussing the read()
function.
To get and set the streaming parameters applications call
the VIDIOC_G_PARM and
VIDIOC_S_PARM ioctl, respectively. They take a
pointer to a struct v4l2_streamparm which
contains a union holding separate parameters for input and output
devices.
Table 1. struct v4l2_streamparm
| enum v4l2_buf_type | type | The buffer (stream) type, same as struct v4l2_format
type, set by the application. | |
| union | parm | ||
| struct v4l2_captureparm | capture | Parameters for capture devices, used when
type is
V4L2_BUF_TYPE_VIDEO_CAPTURE. | |
| struct v4l2_outputparm | output | Parameters for output devices, used when
type is
V4L2_BUF_TYPE_VIDEO_OUTPUT. | |
| __u8 | raw_data[200] | A place holder for future extensions and custom
(driver defined) buffer types V4L2_BUF_TYPE_PRIVATE and
higher. |
Table 2. struct v4l2_captureparm
| __u32 | capability | See Table 4. |
| __u32 | capturemode | Set by drivers and applications, see Table 5. |
| struct v4l2_fract | timeperframe | This is is the desired period between successive frames captured by the driver, in seconds. The field is intended to skip frames on the driver side, saving I/O bandwidth. Applications store here the desired frame
period, drivers return the actual frame period, which must be greater
or equal to the nominal frame period determined by the current video
standard (struct v4l2_standard Drivers support this function only when they set the
|
| __u32 | extendedmode | Custom (driver specific) streaming parameters. When unused, applications and drivers must set this field to zero. Applications using this field should check the driver name and version, see Section 1.2. |
| __u32 | readbuffers | Applications set this field to the desired number
of buffers used internally by the driver in read() mode. Drivers
return the actual number of buffers. When an application requests zero
buffers, drivers should just return the current setting rather than
the minimum or an error code. For details see Section 3.1. |
| __u32 | reserved[4] | Reserved for future extensions. Drivers and applications must set the array to zero. |
Table 3. struct v4l2_outputparm
| __u32 | capability | See Table 4. |
| __u32 | outputmode | Set by drivers and applications, see Table 5. |
| struct v4l2_fract | timeperframe | This is is the desired period between successive frames output by the driver, in seconds. |
The field is intended to
repeat frames on the driver side in Applications store here the desired frame
period, drivers return the actual frame period, which must be greater
or equal to the nominal frame period determined by the current video
standard (struct v4l2_standard Drivers support this function only when they set the
| ||
| __u32 | extendedmode | Custom (driver specific) streaming parameters. When unused, applications and drivers must set this field to zero. Applications using this field should check the driver name and version, see Section 1.2. |
| __u32 | writebuffers | Applications set this field to the desired number
of buffers used internally by the driver in
write() mode. Drivers return the actual number of
buffers. When an application requests zero buffers, drivers should
just return the current setting rather than the minimum or an error
code. For details see Section 3.1. |
| __u32 | reserved[4] | Reserved for future extensions. Drivers and applications must set the array to zero. |
Table 4. Streaming Parameters Capabilites
V4L2_CAP_TIMEPERFRAME | 0x1000 | The frame skipping/repeating controlled by the
timeperframe field is supported. |
Table 5. Capture Parameters Flags
V4L2_MODE_HIGHQUALITY | 0x0001 | High quality imaging mode. High quality mode is intended for still imaging applications. The idea is to get the best possible image quality that the hardware can deliver. It is not defined how the driver writer may achieve that; it will depend on the hardware and the ingenuity of the driver writer. High quality mode is a different mode from the the regular motion video capture modes. In high quality mode:
|