[deliverable/linux.git] / Documentation / media / uapi / v4l / dev-capture.rst

.. -*- coding: utf-8; mode: rst -*-

.. _capture:

***********************
Video Capture Interface
***********************

Video capture devices sample an analog video signal and store the
digitized images in memory. Today nearly all devices can capture at full
25 or 30 frames/second. With this interface applications can control the
capture process and move images from the driver into user space.

Conventionally V4L2 video capture devices are accessed through character
device special files named ``/dev/video`` and ``/dev/video0`` to
``/dev/video63`` with major number 81 and minor numbers 0 to 63.
``/dev/video`` is typically a symbolic link to the preferred video
device.

.. note:: The same device file names are used for video output devices.


Querying Capabilities
=====================

Devices supporting the video capture interface set the
``V4L2_CAP_VIDEO_CAPTURE`` or ``V4L2_CAP_VIDEO_CAPTURE_MPLANE`` flag in
the ``capabilities`` field of struct
:ref:`v4l2_capability <v4l2-capability>` returned by the
:ref:`VIDIOC_QUERYCAP` ioctl. As secondary device
functions they may also support the :ref:`video overlay <overlay>`
(``V4L2_CAP_VIDEO_OVERLAY``) and the :ref:`raw VBI capture <raw-vbi>`
(``V4L2_CAP_VBI_CAPTURE``) interface. At least one of the read/write or
streaming I/O methods must be supported. Tuners and audio inputs are
optional.


Supplemental Functions
======================

Video capture devices shall support :ref:`audio input <audio>`,
:ref:`tuner`, :ref:`controls <control>`,
:ref:`cropping and scaling <crop>` and
:ref:`streaming parameter <streaming-par>` ioctls as needed. The
:ref:`video input <video>` and :ref:`video standard <standard>`
ioctls must be supported by all video capture devices.


Image Format Negotiation
========================

The result of a capture operation is determined by cropping and image
format parameters. The former select an area of the video picture to
capture, the latter how images are stored in memory, i. e. in RGB or YUV
format, the number of bits per pixel or width and height. Together they
also define how images are scaled in the process.

As usual these parameters are *not* reset at :ref:`open() <func-open>`
time to permit Unix tool chains, programming a device and then reading
from it as if it was a plain file. Well written V4L2 applications ensure
they really get what they want, including cropping and scaling.

Cropping initialization at minimum requires to reset the parameters to
defaults. An example is given in :ref:`crop`.

To query the current image format applications set the ``type`` field of
a struct :ref:`v4l2_format <v4l2-format>` to
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or
``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and call the
:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
structure. Drivers fill the struct
:ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
:ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``
member of the ``fmt`` union.

To request different parameters applications set the ``type`` field of a
struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
``vbi`` member of the ``fmt`` union, or better just modify the results
of :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
ioctl with a pointer to this structure. Drivers may adjust the
parameters and finally return the actual parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
does.

Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
can be used to learn about hardware limitations without disabling I/O or
possibly time consuming hardware preparations.

The contents of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
struct :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` are
discussed in :ref:`pixfmt`. See also the specification of the
:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` and :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctls for
details. Video capture devices must implement both the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all
requests and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.


Reading Images
==============

A video capture device may support the ::ref:`read() function <func-read>`
and/or streaming (:ref:`memory mapping <func-mmap>` or
:ref:`user pointer <userp>`) I/O. See :ref:`io` for details.
Commit	Line	Data
	1	.. -- coding: utf-8; mode: rst --
	2
	3	.. _capture:
	4
	5	***********************
	6	Video Capture Interface
	7	***********************
	8
	9	Video capture devices sample an analog video signal and store the
	10	digitized images in memory. Today nearly all devices can capture at full
	11	25 or 30 frames/second. With this interface applications can control the
	12	capture process and move images from the driver into user space.
	13
	14	Conventionally V4L2 video capture devices are accessed through character
	15	device special files named ``/dev/video`` and ``/dev/video0`` to
	16	``/dev/video63`` with major number 81 and minor numbers 0 to 63.
	17	``/dev/video`` is typically a symbolic link to the preferred video
	18	device.
	19
	20	.. note:: The same device file names are used for video output devices.
	21
	22
	23	Querying Capabilities
	24	=====================
	25
	26	Devices supporting the video capture interface set the
	27	``V4L2_CAP_VIDEO_CAPTURE`` or ``V4L2_CAP_VIDEO_CAPTURE_MPLANE`` flag in
	28	the ``capabilities`` field of struct
	29	:ref:`v4l2_capability <v4l2-capability>` returned by the
	30	:ref:`VIDIOC_QUERYCAP` ioctl. As secondary device
	31	functions they may also support the :ref:`video overlay <overlay>`
	32	(``V4L2_CAP_VIDEO_OVERLAY``) and the :ref:`raw VBI capture <raw-vbi>`
	33	(``V4L2_CAP_VBI_CAPTURE``) interface. At least one of the read/write or
	34	streaming I/O methods must be supported. Tuners and audio inputs are
	35	optional.
	36
	37
	38	Supplemental Functions
	39	======================
	40
	41	Video capture devices shall support :ref:`audio input <audio>`,
	42	:ref:`tuner`, :ref:`controls <control>`,
	43	:ref:`cropping and scaling <crop>` and
	44	:ref:`streaming parameter <streaming-par>` ioctls as needed. The
	45	:ref:`video input <video>` and :ref:`video standard <standard>`
	46	ioctls must be supported by all video capture devices.
	47
	48
	49	Image Format Negotiation
	50	========================
	51
	52	The result of a capture operation is determined by cropping and image
	53	format parameters. The former select an area of the video picture to
	54	capture, the latter how images are stored in memory, i. e. in RGB or YUV
	55	format, the number of bits per pixel or width and height. Together they
	56	also define how images are scaled in the process.
	57
	58	As usual these parameters are not reset at :ref:`open() <func-open>`
	59	time to permit Unix tool chains, programming a device and then reading
	60	from it as if it was a plain file. Well written V4L2 applications ensure
	61	they really get what they want, including cropping and scaling.
	62
	63	Cropping initialization at minimum requires to reset the parameters to
	64	defaults. An example is given in :ref:`crop`.
	65
	66	To query the current image format applications set the ``type`` field of
	67	a struct :ref:`v4l2_format <v4l2-format>` to
	68	``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or
	69	``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and call the
	70	:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
	71	structure. Drivers fill the struct
	72	:ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
	73	:ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``
	74	member of the ``fmt`` union.
	75
	76	To request different parameters applications set the ``type`` field of a
	77	struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
	78	fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
	79	``vbi`` member of the ``fmt`` union, or better just modify the results
	80	of :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
	81	ioctl with a pointer to this structure. Drivers may adjust the
	82	parameters and finally return the actual parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
	83	does.
	84
	85	Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
	86	can be used to learn about hardware limitations without disabling I/O or
	87	possibly time consuming hardware preparations.
	88
	89	The contents of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
	90	struct :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` are
	91	discussed in :ref:`pixfmt`. See also the specification of the
	92	:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` and :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctls for
	93	details. Video capture devices must implement both the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
	94	and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all
	95	requests and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
	96	:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
	97
	98
	99	Reading Images
	100	==============
	101
	102	A video capture device may support the ::ref:`read() function <func-read>`
	103	and/or streaming (:ref:`memory mapping <func-mmap>` or
	104	:ref:`user pointer <userp>`) I/O. See :ref:`io` for details.