cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

dev-capture.rst (4457B)


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