요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: V4L
.. _diff-v4l:
********************************
Differences between V4L and V4L2
********************************
The Video For Linux API was first introduced in Linux 2.1 to unify and
replace various TV and radio device related interfaces, developed
independently by driver writers in prior years. Starting with Linux 2.5
the much improved V4L2 API replaces the V4L API. The support for the old
V4L calls were removed from Kernel, but the library :ref:`libv4l`
supports the conversion of a V4L API system call into a V4L2 one.
Opening and Closing Devices
===========================
For compatibility reasons the character device file names recommended
for V4L2 video capture, overlay, radio and raw vbi capture devices did
not change from those used by V4L. They are listed in :ref:`devices`
and below in :ref:`v4l-dev`.
The teletext devices (minor range 192-223) have been removed in V4L2 and
no longer exist. There is no hardware available anymore for handling
pure teletext. Instead raw or sliced VBI is used.
The V4L ``videodev`` module automatically assigns minor numbers to
drivers in load order, depending on the registered device type. We
recommend that V4L2 drivers by default register devices with the same
numbers, but the system administrator can assign arbitrary minor numbers
using driver module options. The major device number remains 81.
.. _v4l-dev:
.. flat-table:: V4L Device Types, Names and Numbers
:header-rows: 1
:stub-columns: 0
* - Device Type
- File Name
- Minor Numbers
* - Video capture and overlay
- ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
``/dev/video63``
- 0-63
* - Radio receiver
- ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
- 64-127
* - Raw VBI capture
- ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
- 224-255
V4L prohibits (or used to prohibit) multiple opens of a device file.
V4L2 drivers *may* support multiple opens, see :ref:`open` for details
and consequences.
V4L drivers respond to V4L2 ioctls with an ``EINVAL`` error code.
Querying Capabilities
=====================
The V4L ``VIDIOCGCAP`` ioctl is equivalent to V4L2's
:ref:`VIDIOC_QUERYCAP`.
The ``name`` field in struct ``video_capability`` became
``card`` in struct :c:type:`v4l2_capability`, ``type``
was replaced by ``capabilities``. Note V4L2 does not distinguish between
device types like this, better think of basic video input, video output
and radio devices supporting a set of related functions like video
capturing, video overlay and VBI capturing. See :ref:`open` for an
introduction.
.. raw:: latex
\small
.. tabularcolumns:: |p{5.3cm}|p{6.7cm}|p{5.3cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - ``struct video_capability`` ``type``
- struct :c:type:`v4l2_capability`
``capabilities`` flags
- Purpose
* - ``VID_TYPE_CAPTURE``
- ``V4L2_CAP_VIDEO_CAPTURE``
- The :ref:`video capture <capture>` interface is supported.
* - ``VID_TYPE_TUNER``
- ``V4L2_CAP_TUNER``
- The device has a :ref:`tuner or modulator <tuner>`.
* - ``VID_TYPE_TELETEXT``
- ``V4L2_CAP_VBI_CAPTURE``
- The :ref:`raw VBI capture <raw-vbi>` interface is supported.
* - ``VID_TYPE_OVERLAY``
- ``V4L2_CAP_VIDEO_OVERLAY``
- The :ref:`video overlay <overlay>` interface is supported.
* - ``VID_TYPE_CHROMAKEY``
- ``V4L2_FBUF_CAP_CHROMAKEY`` in field ``capability`` of struct
:c:type:`v4l2_framebuffer`
- Whether chromakey overlay is supported. For more information on
overlay see :ref:`overlay`.
* - ``VID_TYPE_CLIPPING``
- ``V4L2_FBUF_CAP_LIST_CLIPPING`` and
``V4L2_FBUF_CAP_BITMAP_CLIPPING`` in field ``capability`` of
struct :c:type:`v4l2_framebuffer`
- Whether clipping the overlaid image is supported, see
:ref:`overlay`.
* - ``VID_TYPE_FRAMERAM``
- ``V4L2_FBUF_CAP_EXTERNOVERLAY`` *not set* in field ``capability``
of struct :c:type:`v4l2_framebuffer`
- Whether overlay overwrites frame buffer memory, see
:ref:`overlay`.
* - ``VID_TYPE_SCALES``
- ``-``
- This flag indicates if the hardware can scale images. The V4L2 API
implies the scale factor by setting the cropping dimensions and
image size with the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, respectively. The
driver returns the closest sizes possible. For more information on
cropping and scaling see :ref:`crop`.
* - ``VID_TYPE_MONOCHROME``
- ``-``
- Applications can enumerate the supported image formats with the
:ref:`VIDIOC_ENUM_FMT` ioctl to determine if
the device supports grey scale capturing only. For more
information on image formats see :ref:`pixfmt`.
* - ``VID_TYPE_SUBCAPTURE``
- ``-``
- Applications can call the :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>`
ioctl to determine if the device supports capturing a subsection
of the full picture ("cropping" in V4L2). If not, the ioctl
returns the ``EINVAL`` error code. For more information on cropping
and scaling see :ref:`crop`.
* - ``VID_TYPE_MPEG_DECODER``
- ``-``
- Applications can enumerate the supported image formats with the
:ref:`VIDIOC_ENUM_FMT` ioctl to determine if
the device supports MPEG streams.
* - ``VID_TYPE_MPEG_ENCODER``
- ``-``
- See above.
* - ``VID_TYPE_MJPEG_DECODER``
- ``-``
- See above.
* - ``VID_TYPE_MJPEG_ENCODER``
- ``-``
- See above.
.. raw:: latex
\normalsize
The ``audios`` field was replaced by ``capabilities`` flag
``V4L2_CAP_AUDIO``, indicating *if* the device has any audio inputs or
outputs. To determine their number applications can enumerate audio
inputs with the :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` ioctl. The
audio ioctls are described in :ref:`audio`.
The ``maxwidth``, ``maxheight``, ``minwidth`` and ``minheight`` fields
were removed. Calling the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl with the desired
dimensions returns the closest size possible, taking into account the
current video standard, cropping and scaling limitations.
Video Sources
=============
V4L provides the ``VIDIOCGCHAN`` and ``VIDIOCSCHAN`` ioctl using struct
``video_channel`` to enumerate the video inputs of a V4L
device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_ENUMINPUT`,
:ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
:ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` using struct
:c:type:`v4l2_input` as discussed in :ref:`video`.
The ``channel`` field counting inputs was renamed to ``index``, the
video input types were renamed as follows:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_channel`` ``type``
- struct :c:type:`v4l2_input` ``type``
* - ``VIDEO_TYPE_TV``
- ``V4L2_INPUT_TYPE_TUNER``
* - ``VIDEO_TYPE_CAMERA``
- ``V4L2_INPUT_TYPE_CAMERA``
Unlike the ``tuners`` field expressing the number of tuners of this
input, V4L2 assumes each video input is connected to at most one tuner.
However a tuner can have more than one input, i. e. RF connectors, and a
device can have multiple tuners. The index number of the tuner
associated with the input, if any, is stored in field ``tuner`` of
struct :c:type:`v4l2_input`. Enumeration of tuners is
discussed in :ref:`tuner`.
The redundant ``VIDEO_VC_TUNER`` flag was dropped. Video inputs
associated with a tuner are of type ``V4L2_INPUT_TYPE_TUNER``. The
``VIDEO_VC_AUDIO`` flag was replaced by the ``audioset`` field. V4L2
considers devices with up to 32 audio inputs. Each set bit in the
``audioset`` field represents one audio input this video input combines
with. For information about audio inputs and how to switch between them
see :ref:`audio`.
The ``norm`` field describing the supported video standards was replaced
by ``std``. The V4L specification mentions a flag ``VIDEO_VC_NORM``
indicating whether the standard can be changed. This flag was a later
addition together with the ``norm`` field and has been removed in the
meantime. V4L2 has a similar, albeit more comprehensive approach to
video standards, see :ref:`standard` for more information.
Tuning
======
The V4L ``VIDIOCGTUNER`` and ``VIDIOCSTUNER`` ioctl and struct
``video_tuner`` can be used to enumerate the tuners of a
V4L TV or radio device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
:ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` using struct
:c:type:`v4l2_tuner`. Tuners are covered in :ref:`tuner`.
The ``tuner`` field counting tuners was renamed to ``index``. The fields
``name``, ``rangelow`` and ``rangehigh`` remained unchanged.
The ``VIDEO_TUNER_PAL``, ``VIDEO_TUNER_NTSC`` and ``VIDEO_TUNER_SECAM``
flags indicating the supported video standards were dropped. This
information is now contained in the associated struct
:c:type:`v4l2_input`. No replacement exists for the
``VIDEO_TUNER_NORM`` flag indicating whether the video standard can be
switched. The ``mode`` field to select a different video standard was
replaced by a whole new set of ioctls and structures described in
:ref:`standard`. Due to its ubiquity it should be mentioned the BTTV
driver supports several standards in addition to the regular
``VIDEO_MODE_PAL`` (0), ``VIDEO_MODE_NTSC``, ``VIDEO_MODE_SECAM`` and
``VIDEO_MODE_AUTO`` (3). Namely N/PAL Argentina, M/PAL, N/PAL, and NTSC
Japan with numbers 3-6 (sic).
The ``VIDEO_TUNER_STEREO_ON`` flag indicating stereo reception became
``V4L2_TUNER_SUB_STEREO`` in field ``rxsubchans``. This field also
permits the detection of monaural and bilingual audio, see the
definition of struct :c:type:`v4l2_tuner` for details.
Presently no replacement exists for the ``VIDEO_TUNER_RDS_ON`` and
``VIDEO_TUNER_MBS_ON`` flags.
The ``VIDEO_TUNER_LOW`` flag was renamed to ``V4L2_TUNER_CAP_LOW`` in
the struct :c:type:`v4l2_tuner` ``capability`` field.
The ``VIDIOCGFREQ`` and ``VIDIOCSFREQ`` ioctl to change the tuner
frequency where renamed to
:ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>`. They take a pointer
to a struct :c:type:`v4l2_frequency` instead of an
unsigned long integer.
.. _v4l-image-properties:
Image Properties
================
V4L2 has no equivalent of the ``VIDIOCGPICT`` and ``VIDIOCSPICT`` ioctl
and struct ``video_picture``. The following fields where
replaced by V4L2 controls accessible with the
:ref:`VIDIOC_QUERYCTRL`,
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_picture``
- V4L2 Control ID
* - ``brightness``
- ``V4L2_CID_BRIGHTNESS``
* - ``hue``
- ``V4L2_CID_HUE``
* - ``colour``
- ``V4L2_CID_SATURATION``
* - ``contrast``
- ``V4L2_CID_CONTRAST``
* - ``whiteness``
- ``V4L2_CID_WHITENESS``
The V4L picture controls are assumed to range from 0 to 65535 with no
particular reset value. The V4L2 API permits arbitrary limits and
defaults which can be queried with the
:ref:`VIDIOC_QUERYCTRL` ioctl. For general
information about controls see :ref:`control`.
The ``depth`` (average number of bits per pixel) of a video image is
implied by the selected image format. V4L2 does not explicitly provide
such information assuming applications recognizing the format are aware
of the image depth and others need not know. The ``palette`` field moved
into the struct :c:type:`v4l2_pix_format`:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_picture`` ``palette``
- struct :c:type:`v4l2_pix_format` ``pixfmt``
* - ``VIDEO_PALETTE_GREY``
- :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
* - ``VIDEO_PALETTE_HI240``
- :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
* - ``VIDEO_PALETTE_RGB565``
- :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB555``
- :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB24``
- :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB32``
- :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
* - ``VIDEO_PALETTE_YUV422``
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
* - ``VIDEO_PALETTE_YUYV``\ [#f5]_
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
* - ``VIDEO_PALETTE_UYVY``
- :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
* - ``VIDEO_PALETTE_YUV420``
- None
* - ``VIDEO_PALETTE_YUV411``
- :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
* - ``VIDEO_PALETTE_RAW``
- None [#f7]_
* - ``VIDEO_PALETTE_YUV422P``
- :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
* - ``VIDEO_PALETTE_YUV411P``
- :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
* - ``VIDEO_PALETTE_YUV420P``
- :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
* - ``VIDEO_PALETTE_YUV410P``
- :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
V4L2 image formats are defined in :ref:`pixfmt`. The image format can
be selected with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
Audio
=====
The ``VIDIOCGAUDIO`` and ``VIDIOCSAUDIO`` ioctl and struct
``video_audio`` are used to enumerate the audio inputs
of a V4L device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
:ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` using struct
:c:type:`v4l2_audio` as discussed in :ref:`audio`.
The ``audio`` "channel number" field counting audio inputs was renamed
to ``index``.
On ``VIDIOCSAUDIO`` the ``mode`` field selects *one* of the
``VIDEO_SOUND_MONO``, ``VIDEO_SOUND_STEREO``, ``VIDEO_SOUND_LANG1`` or
``VIDEO_SOUND_LANG2`` audio demodulation modes. When the current audio
standard is BTSC ``VIDEO_SOUND_LANG2`` refers to SAP and
``VIDEO_SOUND_LANG1`` is meaningless. Also undocumented in the V4L
specification, there is no way to query the selected mode. On
``VIDIOCGAUDIO`` the driver returns the *actually received* audio
programmes in this field. In the V4L2 API this information is stored in
the struct :c:type:`v4l2_tuner` ``rxsubchans`` and
``audmode`` fields, respectively. See :ref:`tuner` for more
information on tuners. Related to audio modes struct
:c:type:`v4l2_audio` also reports if this is a mono or
stereo input, regardless if the source is a tuner.
The following fields where replaced by V4L2 controls accessible with the
:ref:`VIDIOC_QUERYCTRL`,
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_audio``
- V4L2 Control ID
* - ``volume``
- ``V4L2_CID_AUDIO_VOLUME``
* - ``bass``
- ``V4L2_CID_AUDIO_BASS``
* - ``treble``
- ``V4L2_CID_AUDIO_TREBLE``
* - ``balance``
- ``V4L2_CID_AUDIO_BALANCE``
To determine which of these controls are supported by a driver V4L
provides the ``flags`` ``VIDEO_AUDIO_VOLUME``, ``VIDEO_AUDIO_BASS``,
``VIDEO_AUDIO_TREBLE`` and ``VIDEO_AUDIO_BALANCE``. In the V4L2 API the
:ref:`VIDIOC_QUERYCTRL` ioctl reports if the
respective control is supported. Accordingly the ``VIDEO_AUDIO_MUTABLE``
and ``VIDEO_AUDIO_MUTE`` flags where replaced by the boolean
``V4L2_CID_AUDIO_MUTE`` control.
All V4L2 controls have a ``step`` attribute replacing the struct
``video_audio`` ``step`` field. The V4L audio controls
are assumed to range from 0 to 65535 with no particular reset value. The
V4L2 API permits arbitrary limits and defaults which can be queried with
the :ref:`VIDIOC_QUERYCTRL` ioctl. For general
information about controls see :ref:`control`.
Frame Buffer Overlay
====================
The V4L2 ioctls equivalent to ``VIDIOCGFBUF`` and ``VIDIOCSFBUF`` are
:ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
:ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The ``base`` field of struct
``video_buffer`` remained unchanged, except V4L2 defines
a flag to indicate non-destructive overlays instead of a ``NULL``
pointer. All other fields moved into the struct
:c:type:`v4l2_pix_format` ``fmt`` substructure of
struct :c:type:`v4l2_framebuffer`. The ``depth``
field was replaced by ``pixelformat``. See :ref:`pixfmt-rgb` for a
list of RGB formats and their respective color depths.
Instead of the special ioctls ``VIDIOCGWIN`` and ``VIDIOCSWIN`` V4L2
uses the general-purpose data format negotiation ioctls
:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
:c:type:`v4l2_format` as argument. Here the ``win`` member
of the ``fmt`` union is used, a struct
:c:type:`v4l2_window`.
The ``x``, ``y``, ``width`` and ``height`` fields of struct
``video_window`` moved into struct
:c:type:`v4l2_rect` substructure ``w`` of struct
:c:type:`v4l2_window`. The ``chromakey``, ``clips``, and
``clipcount`` fields remained unchanged. Struct
``video_clip`` was renamed to struct
:c:type:`v4l2_clip`, also containing a struct
:c:type:`v4l2_rect`, but the semantics are still the same.
The ``VIDEO_WINDOW_INTERLACE`` flag was dropped. Instead applications
must set the ``field`` field to ``V4L2_FIELD_ANY`` or
``V4L2_FIELD_INTERLACED``. The ``VIDEO_WINDOW_CHROMAKEY`` flag moved
into struct :c:type:`v4l2_framebuffer`, under the new
name ``V4L2_FBUF_FLAG_CHROMAKEY``.
In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
has a separate ``bitmap`` pointer field for this purpose and the bitmap
size is determined by ``w.width`` and ``w.height``.
The ``VIDIOCCAPTURE`` ioctl to enable or disable overlay was renamed to
:ref:`VIDIOC_OVERLAY`.
Cropping
========
To capture only a subsection of the full picture V4L defines the
``VIDIOCGCAPTURE`` and ``VIDIOCSCAPTURE`` ioctls using struct
``video_capture``. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
:ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` using struct
:c:type:`v4l2_crop`, and the related
:ref:`VIDIOC_CROPCAP` ioctl. This is a rather
complex matter, see :ref:`crop` for details.
The ``x``, ``y``, ``width`` and ``height`` fields moved into struct
:c:type:`v4l2_rect` substructure ``c`` of struct
:c:type:`v4l2_crop`. The ``decimation`` field was dropped. In
the V4L2 API the scaling factor is implied by the size of the cropping
rectangle and the size of the captured or overlaid image.
The ``VIDEO_CAPTURE_ODD`` and ``VIDEO_CAPTURE_EVEN`` flags to capture
only the odd or even field, respectively, were replaced by
``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM`` in the field named
``field`` of struct :c:type:`v4l2_pix_format` and
struct :c:type:`v4l2_window`. These structures are used to
select a capture or overlay format with the
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
Reading Images, Memory Mapping
==============================
Capturing using the read method
-------------------------------
There is no essential difference between reading images from a V4L or
V4L2 device using the :c:func:`read()` function, however V4L2
drivers are not required to support this I/O method. Applications can
determine if the function is available with the
:ref:`VIDIOC_QUERYCAP` ioctl. All V4L2 devices
exchanging data with applications must support the
:c:func:`select()` and :c:func:`poll()`
functions.
To select an image format and size, V4L provides the ``VIDIOCSPICT`` and
``VIDIOCSWIN`` ioctls. V4L2 uses the general-purpose data format
negotiation ioctls :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
:c:type:`v4l2_format` as argument, here the struct
:c:type:`v4l2_pix_format` named ``pix`` of its
``fmt`` union is used.
For more information about the V4L2 read interface see :ref:`rw`.
Capturing using memory mapping
------------------------------
Applications can read from V4L devices by mapping buffers in device
memory, or more often just buffers allocated in DMA-able system memory,
into their address space. This avoids the data copying overhead of the
read method. V4L2 supports memory mapping as well, with a few
differences.
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - V4L
- V4L2
* -
- The image format must be selected before buffers are allocated,
with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When no
format is selected the driver may use the last, possibly by
another application requested format.
* - Applications cannot change the number of buffers. The it is built
into the driver, unless it has a module option to change the
number when the driver module is loaded.
- The :ref:`VIDIOC_REQBUFS` ioctl allocates the
desired number of buffers, this is a required step in the
initialization sequence.
* - Drivers map all buffers as one contiguous range of memory. The
``VIDIOCGMBUF`` ioctl is available to query the number of buffers,
the offset of each buffer from the start of the virtual file, and
the overall amount of memory used, which can be used as arguments
for the :c:func:`mmap()` function.
- Buffers are individually mapped. The offset and size of each
buffer can be determined with the
:ref:`VIDIOC_QUERYBUF` ioctl.
* - The ``VIDIOCMCAPTURE`` ioctl prepares a buffer for capturing. It
also determines the image format for this buffer. The ioctl
returns immediately, eventually with an ``EAGAIN`` error code if no
video signal had been detected. When the driver supports more than
one buffer applications can call the ioctl multiple times and thus
have multiple outstanding capture requests.
The ``VIDIOCSYNC`` ioctl suspends execution until a particular
buffer has been filled.
- Drivers maintain an incoming and outgoing queue.
:ref:`VIDIOC_QBUF` enqueues any empty buffer into
the incoming queue. Filled buffers are dequeued from the outgoing
queue with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. To wait
until filled buffers become available this function,
:c:func:`select()` or :c:func:`poll()` can
be used. The :ref:`VIDIOC_STREAMON` ioctl
must be called once after enqueuing one or more buffers to start
capturing. Its counterpart
:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` stops capturing and
dequeues all buffers from both queues. Applications can query the
signal status, if known, with the
:ref:`VIDIOC_ENUMINPUT` ioctl.
For a more in-depth discussion of memory mapping and examples, see
:ref:`mmap`.
Reading Raw VBI Data
====================
Originally the V4L API did not specify a raw VBI capture interface, only
the device file ``/dev/vbi`` was reserved for this purpose. The only
driver supporting this interface was the BTTV driver, de-facto defining
the V4L VBI interface. Reading from the device yields a raw VBI image
with the following parameters:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct :c:type:`v4l2_vbi_format`
- V4L, BTTV driver
* - sampling_rate
- 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
and SECAM (625-line standards)
* - offset
- ?
* - samples_per_line
- 2048
* - sample_format
- V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
integer) contain a frame counter.
* - start[]
- 10, 273 NTSC; 22, 335 PAL and SECAM
* - count[]
- 16, 16 [#f9]_
* - flags
- 0
Undocumented in the V4L specification, in Linux 2.3 the
``VIDIOCGVBIFMT`` and ``VIDIOCSVBIFMT`` ioctls using struct
``vbi_format`` were added to determine the VBI image
parameters. These ioctls are only partially compatible with the V4L2 VBI
interface specified in :ref:`raw-vbi`.
An ``offset`` field does not exist, ``sample_format`` is supposed to be
``VIDEO_PALETTE_RAW``, equivalent to ``V4L2_PIX_FMT_GREY``. The
remaining fields are probably equivalent to struct
:c:type:`v4l2_vbi_format`.
Apparently only the Zoran (ZR 36120) driver implements these ioctls. The
semantics differ from those specified for V4L2 in two ways. The
parameters are reset on :c:func:`open()` and
``VIDIOCSVBIFMT`` always returns an ``EINVAL`` error code if the parameters
are invalid.
Miscellaneous
=============
V4L2 has no equivalent of the ``VIDIOCGUNIT`` ioctl. Applications can
find the VBI device associated with a video capture device (or vice
versa) by reopening the device and requesting VBI data. For details see
:ref:`open`.
No replacement exists for ``VIDIOCKEY``, and the V4L functions for
microcode programming. A new interface for MPEG compression and playback
devices is documented in :ref:`extended-controls`.
.. [#f1]
According to Documentation/admin-guide/devices.rst these should be symbolic links
to ``/dev/video0``. Note the original bttv interface is not
compatible with V4L or V4L2.
.. [#f2]
According to ``Documentation/admin-guide/devices.rst`` a symbolic link to
``/dev/radio0``.
.. [#f3]
This is a custom format used by the BTTV driver, not one of the V4L2
standard formats.
.. [#f4]
Presumably all V4L RGB formats are little-endian, although some
drivers might interpret them according to machine endianness. V4L2
defines little-endian, big-endian and red/blue swapped variants. For
details see :ref:`pixfmt-rgb`.
.. [#f5]
``VIDEO_PALETTE_YUV422`` and ``VIDEO_PALETTE_YUYV`` are the same
formats. Some V4L drivers respond to one, some to the other.
.. [#f6]
Not to be confused with ``V4L2_PIX_FMT_YUV411P``, which is a planar
format.
.. [#f7]
V4L explains this as: "RAW capture (BT848)"
.. [#f8]
Not to be confused with ``V4L2_PIX_FMT_Y41P``, which is a packed
format.
.. [#f9]
Old driver versions used different values, eventually the custom
``BTTV_VBISIZE`` ioctl was added to query the correct values.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
V4L에서 V4L2로의 전환
1-16이 문서는 `GFDL-1.1-no-invariants-or-later` 조건으로 제공되며 C namespace는 `V4L`입니다.
Video For Linux API는 driver 작성자들이 독립적으로 만들었던 TV·radio device interface를 통합하고 대체하기 위해 Linux 2.1에서 처음 도입되었습니다.
Linux 2.5부터 크게 개선된 V4L2 API가 V4L API를 대체했습니다. Kernel에서는 옛 V4L call 지원이 제거됐지만 `libv4l` library는 V4L API system call을 대응하는 V4L2 call로 변환할 수 있습니다.
옛 장치별 interface가 V4L2로 수렴한 흐름입니다.
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: V4L
.. _diff-v4l:
********************************
Differences between V4L and V4L2
********************************
The Video For Linux API was first introduced in Linux 2.1 to unify and
replace various TV and radio device related interfaces, developed
independently by driver writers in prior years. Starting with Linux 2.5
the much improved V4L2 API replaces the V4L API. The support for the old
V4L calls were removed from Kernel, but the library :ref:`libv4l`
supports the conversion of a V4L API system call into a V4L2 one.
장치 열기·닫기와 device number
17-60호환성을 위해 V4L2 video capture, overlay, radio, raw VBI capture character device의 권장 파일 이름은 V4L에서 쓰던 이름을 유지합니다.
V4L2에서는 minor 192~223의 teletext device가 제거되어 더 이상 존재하지 않습니다. 순수 teletext를 처리할 hardware가 남아 있지 않으므로 raw VBI 또는 sliced VBI를 사용합니다.
V4L `videodev` module은 등록된 device type과 driver load 순서에 따라 minor number를 자동 배정합니다. V4L2 driver도 기본적으로 같은 번호를 등록하는 것이 권장되지만 administrator가 module option으로 임의의 minor를 지정할 수 있습니다. Major number는 계속 81입니다.
V4L2에서도 호환성을 위해 유지하는 node 이름과 minor 범위입니다.
V4L은 device file을 여러 번 여는 것을 금지했거나 금지한 것으로 취급했습니다. V4L2 driver는 multiple open을 지원할 수 있으며 세부 결과는 `open` 절을 따릅니다.
V4L driver가 V4L2 ioctl을 받으면 `EINVAL` error code로 응답합니다.
Opening and Closing Devices
===========================
For compatibility reasons the character device file names recommended
for V4L2 video capture, overlay, radio and raw vbi capture devices did
not change from those used by V4L. They are listed in :ref:`devices`
and below in :ref:`v4l-dev`.
The teletext devices (minor range 192-223) have been removed in V4L2 and
no longer exist. There is no hardware available anymore for handling
pure teletext. Instead raw or sliced VBI is used.
The V4L ``videodev`` module automatically assigns minor numbers to
drivers in load order, depending on the registered device type. We
recommend that V4L2 drivers by default register devices with the same
numbers, but the system administrator can assign arbitrary minor numbers
using driver module options. The major device number remains 81.
.. _v4l-dev:
.. flat-table:: V4L Device Types, Names and Numbers
:header-rows: 1
:stub-columns: 0
* - Device Type
- File Name
- Minor Numbers
* - Video capture and overlay
- ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
``/dev/video63``
- 0-63
* - Radio receiver
- ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
- 64-127
* - Raw VBI capture
- ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
- 224-255
V4L prohibits (or used to prohibit) multiple opens of a device file.
V4L2 drivers *may* support multiple opens, see :ref:`open` for details
and consequences.
V4L drivers respond to V4L2 ioctls with an ``EINVAL`` error code.
Capability 조회와 type flag 대응
61-170V4L `VIDIOCGCAP` ioctl은 V4L2의 `VIDIOC_QUERYCAP`에 해당합니다. `video_capability.name`은 `v4l2_capability.card`가 되었고 `type`은 `capabilities`로 대체됐습니다.
V4L2는 capture·output·radio 같은 device type을 단일 값으로 구분하기보다, video capture·overlay·VBI capture 등 서로 관련된 기능의 capability flag 집합으로 장치를 표현합니다.
V4L type flag를 V4L2 capability 또는 별도 조회 방식으로 옮긴 결과입니다.
V4L `audios` field는 장치에 audio input 또는 output이 있는지를 나타내는 `V4L2_CAP_AUDIO` capability로 바뀌었습니다. 개수는 `VIDIOC_G_AUDIO`로 audio input을 열거해 확인합니다.
`maxwidth`, `maxheight`, `minwidth`, `minheight` field는 제거됐습니다. 원하는 크기로 `VIDIOC_S_FMT` 또는 `VIDIOC_TRY_FMT`를 호출하면 현재 video standard, cropping, scaling 제한을 고려한 가장 가까운 크기를 반환합니다.
단일 type 대신 기능과 format을 단계적으로 조회합니다.
Querying Capabilities
=====================
The V4L ``VIDIOCGCAP`` ioctl is equivalent to V4L2's
:ref:`VIDIOC_QUERYCAP`.
The ``name`` field in struct ``video_capability`` became
``card`` in struct :c:type:`v4l2_capability`, ``type``
was replaced by ``capabilities``. Note V4L2 does not distinguish between
device types like this, better think of basic video input, video output
and radio devices supporting a set of related functions like video
capturing, video overlay and VBI capturing. See :ref:`open` for an
introduction.
.. raw:: latex
\small
.. tabularcolumns:: |p{5.3cm}|p{6.7cm}|p{5.3cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - ``struct video_capability`` ``type``
- struct :c:type:`v4l2_capability`
``capabilities`` flags
- Purpose
* - ``VID_TYPE_CAPTURE``
- ``V4L2_CAP_VIDEO_CAPTURE``
- The :ref:`video capture <capture>` interface is supported.
* - ``VID_TYPE_TUNER``
- ``V4L2_CAP_TUNER``
- The device has a :ref:`tuner or modulator <tuner>`.
* - ``VID_TYPE_TELETEXT``
- ``V4L2_CAP_VBI_CAPTURE``
- The :ref:`raw VBI capture <raw-vbi>` interface is supported.
* - ``VID_TYPE_OVERLAY``
- ``V4L2_CAP_VIDEO_OVERLAY``
- The :ref:`video overlay <overlay>` interface is supported.
* - ``VID_TYPE_CHROMAKEY``
- ``V4L2_FBUF_CAP_CHROMAKEY`` in field ``capability`` of struct
:c:type:`v4l2_framebuffer`
- Whether chromakey overlay is supported. For more information on
overlay see :ref:`overlay`.
* - ``VID_TYPE_CLIPPING``
- ``V4L2_FBUF_CAP_LIST_CLIPPING`` and
``V4L2_FBUF_CAP_BITMAP_CLIPPING`` in field ``capability`` of
struct :c:type:`v4l2_framebuffer`
- Whether clipping the overlaid image is supported, see
:ref:`overlay`.
* - ``VID_TYPE_FRAMERAM``
- ``V4L2_FBUF_CAP_EXTERNOVERLAY`` *not set* in field ``capability``
of struct :c:type:`v4l2_framebuffer`
- Whether overlay overwrites frame buffer memory, see
:ref:`overlay`.
* - ``VID_TYPE_SCALES``
- ``-``
- This flag indicates if the hardware can scale images. The V4L2 API
implies the scale factor by setting the cropping dimensions and
image size with the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, respectively. The
driver returns the closest sizes possible. For more information on
cropping and scaling see :ref:`crop`.
* - ``VID_TYPE_MONOCHROME``
- ``-``
- Applications can enumerate the supported image formats with the
:ref:`VIDIOC_ENUM_FMT` ioctl to determine if
the device supports grey scale capturing only. For more
information on image formats see :ref:`pixfmt`.
* - ``VID_TYPE_SUBCAPTURE``
- ``-``
- Applications can call the :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>`
ioctl to determine if the device supports capturing a subsection
of the full picture ("cropping" in V4L2). If not, the ioctl
returns the ``EINVAL`` error code. For more information on cropping
and scaling see :ref:`crop`.
* - ``VID_TYPE_MPEG_DECODER``
- ``-``
- Applications can enumerate the supported image formats with the
:ref:`VIDIOC_ENUM_FMT` ioctl to determine if
the device supports MPEG streams.
* - ``VID_TYPE_MPEG_ENCODER``
- ``-``
- See above.
* - ``VID_TYPE_MJPEG_DECODER``
- ``-``
- See above.
* - ``VID_TYPE_MJPEG_ENCODER``
- ``-``
- See above.
.. raw:: latex
\normalsize
The ``audios`` field was replaced by ``capabilities`` flag
``V4L2_CAP_AUDIO``, indicating *if* the device has any audio inputs or
outputs. To determine their number applications can enumerate audio
inputs with the :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` ioctl. The
audio ioctls are described in :ref:`audio`.
The ``maxwidth``, ``maxheight``, ``minwidth`` and ``minheight`` fields
were removed. Calling the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl with the desired
dimensions returns the closest size possible, taking into account the
current video standard, cropping and scaling limitations.
Video input source
171-219V4L은 `VIDIOCGCHAN`, `VIDIOCSCHAN`과 `video_channel`로 video input을 열거했습니다. V4L2에서는 `VIDIOC_ENUMINPUT`, `VIDIOC_G_INPUT`, `VIDIOC_S_INPUT`과 `v4l2_input`을 사용합니다.
Input 수를 세던 `channel` field는 `index`로 이름이 바뀌었습니다.
V4L video_channel type과 V4L2 v4l2_input type의 대응입니다.
V4L의 `tuners`는 해당 input의 tuner 수를 나타냈지만 V4L2는 각 video input이 최대 tuner 하나에 연결된다고 봅니다. 반대로 tuner 하나는 여러 RF connector input을 가질 수 있고 장치에 tuner가 여러 개 있을 수도 있습니다. 연결된 tuner index는 `v4l2_input.tuner`에 저장됩니다.
중복된 `VIDEO_VC_TUNER` flag는 제거됐으며 tuner 연결 input은 `V4L2_INPUT_TYPE_TUNER` type으로 표현합니다. `VIDEO_VC_AUDIO`는 `audioset` field로 바뀌었고, 최대 32개 audio input 가운데 함께 사용하는 input을 각 bit로 표시합니다.
지원 video standard를 설명하던 `norm` field는 `std`로 바뀌었습니다. Standard 변경 가능 여부를 나타내던 `VIDEO_VC_NORM`은 제거됐고 V4L2의 더 포괄적인 video-standard API가 이를 대신합니다.
Video Sources
=============
V4L provides the ``VIDIOCGCHAN`` and ``VIDIOCSCHAN`` ioctl using struct
``video_channel`` to enumerate the video inputs of a V4L
device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_ENUMINPUT`,
:ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
:ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` using struct
:c:type:`v4l2_input` as discussed in :ref:`video`.
The ``channel`` field counting inputs was renamed to ``index``, the
video input types were renamed as follows:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_channel`` ``type``
- struct :c:type:`v4l2_input` ``type``
* - ``VIDEO_TYPE_TV``
- ``V4L2_INPUT_TYPE_TUNER``
* - ``VIDEO_TYPE_CAMERA``
- ``V4L2_INPUT_TYPE_CAMERA``
Unlike the ``tuners`` field expressing the number of tuners of this
input, V4L2 assumes each video input is connected to at most one tuner.
However a tuner can have more than one input, i. e. RF connectors, and a
device can have multiple tuners. The index number of the tuner
associated with the input, if any, is stored in field ``tuner`` of
struct :c:type:`v4l2_input`. Enumeration of tuners is
discussed in :ref:`tuner`.
The redundant ``VIDEO_VC_TUNER`` flag was dropped. Video inputs
associated with a tuner are of type ``V4L2_INPUT_TYPE_TUNER``. The
``VIDEO_VC_AUDIO`` flag was replaced by the ``audioset`` field. V4L2
considers devices with up to 32 audio inputs. Each set bit in the
``audioset`` field represents one audio input this video input combines
with. For information about audio inputs and how to switch between them
see :ref:`audio`.
The ``norm`` field describing the supported video standards was replaced
by ``std``. The V4L specification mentions a flag ``VIDEO_VC_NORM``
indicating whether the standard can be changed. This flag was a later
addition together with the ``norm`` field and has been removed in the
meantime. V4L2 has a similar, albeit more comprehensive approach to
video standards, see :ref:`standard` for more information.
Tuner와 frequency
220-264V4L `VIDIOCGTUNER`, `VIDIOCSTUNER`와 `video_tuner`는 V4L2의 `VIDIOC_G_TUNER`, `VIDIOC_S_TUNER`와 `v4l2_tuner`에 해당합니다. Tuner 수를 세던 `tuner` field는 `index`로 바뀌었고 `name`, `rangelow`, `rangehigh`는 유지됐습니다.
지원 video standard를 나타내던 `VIDEO_TUNER_PAL`, `VIDEO_TUNER_NTSC`, `VIDEO_TUNER_SECAM`은 제거되고 관련 `v4l2_input`에 정보가 들어갑니다. `VIDEO_TUNER_NORM`의 직접 대체 항목은 없으며, `mode`는 video-standard ioctl과 구조체 집합으로 대체됐습니다.
BTTV driver는 일반 `VIDEO_MODE_PAL`(0), `VIDEO_MODE_NTSC`, `VIDEO_MODE_SECAM`, `VIDEO_MODE_AUTO`(3) 외에도 N/PAL Argentina, M/PAL, N/PAL, NTSC Japan을 번호 3~6으로 지원합니다. 번호 3이 겹치는 것은 원문 그대로입니다.
Stereo 수신의 `VIDEO_TUNER_STEREO_ON`은 `rxsubchans`의 `V4L2_TUNER_SUB_STEREO`가 됐으며 mono와 bilingual audio도 탐지할 수 있습니다. `VIDEO_TUNER_RDS_ON`과 `VIDEO_TUNER_MBS_ON`에는 현재 대체 항목이 없습니다.
`VIDEO_TUNER_LOW`는 `v4l2_tuner.capability`의 `V4L2_TUNER_CAP_LOW`로 바뀌었습니다. Frequency 변경용 `VIDIOCGFREQ`, `VIDIOCSFREQ`는 `VIDIOC_G_FREQUENCY`, `VIDIOC_S_FREQUENCY`로 바뀌고 unsigned long 대신 `v4l2_frequency` pointer를 받습니다.
이름이 바뀌거나 대체가 없는 핵심 항목입니다.
Tuning
======
The V4L ``VIDIOCGTUNER`` and ``VIDIOCSTUNER`` ioctl and struct
``video_tuner`` can be used to enumerate the tuners of a
V4L TV or radio device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
:ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` using struct
:c:type:`v4l2_tuner`. Tuners are covered in :ref:`tuner`.
The ``tuner`` field counting tuners was renamed to ``index``. The fields
``name``, ``rangelow`` and ``rangehigh`` remained unchanged.
The ``VIDEO_TUNER_PAL``, ``VIDEO_TUNER_NTSC`` and ``VIDEO_TUNER_SECAM``
flags indicating the supported video standards were dropped. This
information is now contained in the associated struct
:c:type:`v4l2_input`. No replacement exists for the
``VIDEO_TUNER_NORM`` flag indicating whether the video standard can be
switched. The ``mode`` field to select a different video standard was
replaced by a whole new set of ioctls and structures described in
:ref:`standard`. Due to its ubiquity it should be mentioned the BTTV
driver supports several standards in addition to the regular
``VIDEO_MODE_PAL`` (0), ``VIDEO_MODE_NTSC``, ``VIDEO_MODE_SECAM`` and
``VIDEO_MODE_AUTO`` (3). Namely N/PAL Argentina, M/PAL, N/PAL, and NTSC
Japan with numbers 3-6 (sic).
The ``VIDEO_TUNER_STEREO_ON`` flag indicating stereo reception became
``V4L2_TUNER_SUB_STEREO`` in field ``rxsubchans``. This field also
permits the detection of monaural and bilingual audio, see the
definition of struct :c:type:`v4l2_tuner` for details.
Presently no replacement exists for the ``VIDEO_TUNER_RDS_ON`` and
``VIDEO_TUNER_MBS_ON`` flags.
The ``VIDEO_TUNER_LOW`` flag was renamed to ``V4L2_TUNER_CAP_LOW`` in
the struct :c:type:`v4l2_tuner` ``capability`` field.
The ``VIDIOCGFREQ`` and ``VIDIOCSFREQ`` ioctl to change the tuner
frequency where renamed to
:ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>`. They take a pointer
to a struct :c:type:`v4l2_frequency` instead of an
unsigned long integer.
.. _v4l-image-properties:
Image control과 pixel format
265-347V4L2에는 `VIDIOCGPICT`, `VIDIOCSPICT`, `video_picture`와 일대일 대응하는 단일 API가 없습니다. Image property는 `VIDIOC_QUERYCTRL`, `VIDIOC_G_CTRL`, `VIDIOC_S_CTRL`로 접근하는 V4L2 control로 분리됐습니다.
video_picture field와 V4L2 control ID의 대응입니다.
V4L picture control은 0~65535 범위이고 특정 reset value가 없다고 가정했습니다. V4L2는 임의의 limit와 default를 허용하며 `VIDIOC_QUERYCTRL`로 조회합니다.
Image의 평균 bits-per-pixel인 `depth`는 선택한 image format에서 암시됩니다. V4L2는 format을 아는 application이 depth도 안다고 보고 별도 값을 제공하지 않습니다. `palette`는 `v4l2_pix_format.pixfmt`로 이동했습니다.
V4L video_picture.palette를 V4L2 pixel format으로 옮긴 표입니다.
V4L2 image format은 `pixfmt` 절에 정의되며 `VIDIOC_S_FMT`으로 선택합니다.
Image Properties
================
V4L2 has no equivalent of the ``VIDIOCGPICT`` and ``VIDIOCSPICT`` ioctl
and struct ``video_picture``. The following fields where
replaced by V4L2 controls accessible with the
:ref:`VIDIOC_QUERYCTRL`,
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_picture``
- V4L2 Control ID
* - ``brightness``
- ``V4L2_CID_BRIGHTNESS``
* - ``hue``
- ``V4L2_CID_HUE``
* - ``colour``
- ``V4L2_CID_SATURATION``
* - ``contrast``
- ``V4L2_CID_CONTRAST``
* - ``whiteness``
- ``V4L2_CID_WHITENESS``
The V4L picture controls are assumed to range from 0 to 65535 with no
particular reset value. The V4L2 API permits arbitrary limits and
defaults which can be queried with the
:ref:`VIDIOC_QUERYCTRL` ioctl. For general
information about controls see :ref:`control`.
The ``depth`` (average number of bits per pixel) of a video image is
implied by the selected image format. V4L2 does not explicitly provide
such information assuming applications recognizing the format are aware
of the image depth and others need not know. The ``palette`` field moved
into the struct :c:type:`v4l2_pix_format`:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_picture`` ``palette``
- struct :c:type:`v4l2_pix_format` ``pixfmt``
* - ``VIDEO_PALETTE_GREY``
- :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
* - ``VIDEO_PALETTE_HI240``
- :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
* - ``VIDEO_PALETTE_RGB565``
- :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB555``
- :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB24``
- :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
* - ``VIDEO_PALETTE_RGB32``
- :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
* - ``VIDEO_PALETTE_YUV422``
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
* - ``VIDEO_PALETTE_YUYV``\ [#f5]_
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
* - ``VIDEO_PALETTE_UYVY``
- :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
* - ``VIDEO_PALETTE_YUV420``
- None
* - ``VIDEO_PALETTE_YUV411``
- :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
* - ``VIDEO_PALETTE_RAW``
- None [#f7]_
* - ``VIDEO_PALETTE_YUV422P``
- :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
* - ``VIDEO_PALETTE_YUV411P``
- :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
* - ``VIDEO_PALETTE_YUV420P``
- :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
* - ``VIDEO_PALETTE_YUV410P``
- :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
V4L2 image formats are defined in :ref:`pixfmt`. The image format can
be selected with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
Audio input과 control
348-410V4L의 `VIDIOCGAUDIO`, `VIDIOCSAUDIO`, `video_audio`는 V4L2의 `VIDIOC_G_AUDIO`, `VIDIOC_S_AUDIO`, `v4l2_audio`에 해당합니다. Audio input 수를 세던 `audio` channel number는 `index`로 바뀌었습니다.
`VIDIOCSAUDIO.mode`는 `VIDEO_SOUND_MONO`, `VIDEO_SOUND_STEREO`, `VIDEO_SOUND_LANG1`, `VIDEO_SOUND_LANG2` 중 하나를 선택합니다. BTSC에서 LANG2는 SAP를 뜻하고 LANG1은 의미가 없습니다. V4L에서는 선택 mode를 조회할 수 없고 `VIDIOCGAUDIO`가 실제 수신 audio programme을 반환했습니다.
V4L2에서는 실제 수신 programme과 선택 mode를 각각 `v4l2_tuner.rxsubchans`와 `audmode`에 저장합니다. `v4l2_audio`는 tuner source와 관계없이 해당 input이 mono인지 stereo인지도 보고합니다.
video_audio field가 독립적인 V4L2 control ID로 바뀌었습니다.
V4L은 `VIDEO_AUDIO_VOLUME`, `VIDEO_AUDIO_BASS`, `VIDEO_AUDIO_TREBLE`, `VIDEO_AUDIO_BALANCE` flag로 control 지원 여부를 표시했습니다. V4L2에서는 `VIDIOC_QUERYCTRL`이 이를 보고하며 `VIDEO_AUDIO_MUTABLE`, `VIDEO_AUDIO_MUTE`는 boolean `V4L2_CID_AUDIO_MUTE` control로 대체됐습니다.
모든 V4L2 control은 `video_audio.step`을 대신하는 `step` attribute를 가집니다. V4L의 고정 0~65535 가정과 달리 V4L2의 limit와 default는 임의 값이며 `VIDIOC_QUERYCTRL`로 조회할 수 있습니다.
Audio
=====
The ``VIDIOCGAUDIO`` and ``VIDIOCSAUDIO`` ioctl and struct
``video_audio`` are used to enumerate the audio inputs
of a V4L device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
:ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` using struct
:c:type:`v4l2_audio` as discussed in :ref:`audio`.
The ``audio`` "channel number" field counting audio inputs was renamed
to ``index``.
On ``VIDIOCSAUDIO`` the ``mode`` field selects *one* of the
``VIDEO_SOUND_MONO``, ``VIDEO_SOUND_STEREO``, ``VIDEO_SOUND_LANG1`` or
``VIDEO_SOUND_LANG2`` audio demodulation modes. When the current audio
standard is BTSC ``VIDEO_SOUND_LANG2`` refers to SAP and
``VIDEO_SOUND_LANG1`` is meaningless. Also undocumented in the V4L
specification, there is no way to query the selected mode. On
``VIDIOCGAUDIO`` the driver returns the *actually received* audio
programmes in this field. In the V4L2 API this information is stored in
the struct :c:type:`v4l2_tuner` ``rxsubchans`` and
``audmode`` fields, respectively. See :ref:`tuner` for more
information on tuners. Related to audio modes struct
:c:type:`v4l2_audio` also reports if this is a mono or
stereo input, regardless if the source is a tuner.
The following fields where replaced by V4L2 controls accessible with the
:ref:`VIDIOC_QUERYCTRL`,
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct ``video_audio``
- V4L2 Control ID
* - ``volume``
- ``V4L2_CID_AUDIO_VOLUME``
* - ``bass``
- ``V4L2_CID_AUDIO_BASS``
* - ``treble``
- ``V4L2_CID_AUDIO_TREBLE``
* - ``balance``
- ``V4L2_CID_AUDIO_BALANCE``
To determine which of these controls are supported by a driver V4L
provides the ``flags`` ``VIDEO_AUDIO_VOLUME``, ``VIDEO_AUDIO_BASS``,
``VIDEO_AUDIO_TREBLE`` and ``VIDEO_AUDIO_BALANCE``. In the V4L2 API the
:ref:`VIDIOC_QUERYCTRL` ioctl reports if the
respective control is supported. Accordingly the ``VIDEO_AUDIO_MUTABLE``
and ``VIDEO_AUDIO_MUTE`` flags where replaced by the boolean
``V4L2_CID_AUDIO_MUTE`` control.
All V4L2 controls have a ``step`` attribute replacing the struct
``video_audio`` ``step`` field. The V4L audio controls
are assumed to range from 0 to 65535 with no particular reset value. The
V4L2 API permits arbitrary limits and defaults which can be queried with
the :ref:`VIDIOC_QUERYCTRL` ioctl. For general
information about controls see :ref:`control`.
Framebuffer overlay
411-456V4L `VIDIOCGFBUF`, `VIDIOCSFBUF`에 대응하는 V4L2 ioctl은 `VIDIOC_G_FBUF`, `VIDIOC_S_FBUF`입니다. `video_buffer.base`는 유지되지만, V4L2는 `NULL` pointer 대신 non-destructive overlay를 나타내는 flag를 정의합니다.
나머지 field는 `v4l2_framebuffer` 안의 `v4l2_pix_format fmt` substructure로 이동했고 `depth`는 `pixelformat`으로 바뀌었습니다.
전용 `VIDIOCGWIN`, `VIDIOCSWIN` 대신 V4L2는 범용 format 협상 ioctl `VIDIOC_G_FMT`, `VIDIOC_S_FMT`를 사용합니다. Argument는 `v4l2_format`이며 `fmt` union의 `v4l2_window win` member를 씁니다.
`video_window`의 `x`, `y`, `width`, `height`는 `v4l2_window.w`의 `v4l2_rect`로 이동했습니다. `chromakey`, `clips`, `clipcount`는 유지됐고 `video_clip`은 같은 semantics를 가진 `v4l2_clip`으로 이름이 바뀌었습니다.
`VIDEO_WINDOW_INTERLACE`는 제거되고 `field`를 `V4L2_FIELD_ANY` 또는 `V4L2_FIELD_INTERLACED`로 설정합니다. `VIDEO_WINDOW_CHROMAKEY`는 `v4l2_framebuffer`의 `V4L2_FBUF_FLAG_CHROMAKEY`가 됐습니다.
V4L bitmap clipping은 `clips`에 bitmap pointer를 넣고 `clipcount`를 `VIDEO_CLIP_BITMAP`(-1)으로 설정해 고정 1024×625-bit bitmap을 요청했습니다. V4L2는 별도 `v4l2_window.bitmap` pointer를 사용하고 크기는 `w.width`와 `w.height`로 결정합니다.
Overlay enable/disable ioctl `VIDIOCCAPTURE`는 `VIDIOC_OVERLAY`로 이름이 바뀌었습니다.
Framebuffer와 window 관련 주요 이동입니다.
Frame Buffer Overlay
====================
The V4L2 ioctls equivalent to ``VIDIOCGFBUF`` and ``VIDIOCSFBUF`` are
:ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
:ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The ``base`` field of struct
``video_buffer`` remained unchanged, except V4L2 defines
a flag to indicate non-destructive overlays instead of a ``NULL``
pointer. All other fields moved into the struct
:c:type:`v4l2_pix_format` ``fmt`` substructure of
struct :c:type:`v4l2_framebuffer`. The ``depth``
field was replaced by ``pixelformat``. See :ref:`pixfmt-rgb` for a
list of RGB formats and their respective color depths.
Instead of the special ioctls ``VIDIOCGWIN`` and ``VIDIOCSWIN`` V4L2
uses the general-purpose data format negotiation ioctls
:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
:c:type:`v4l2_format` as argument. Here the ``win`` member
of the ``fmt`` union is used, a struct
:c:type:`v4l2_window`.
The ``x``, ``y``, ``width`` and ``height`` fields of struct
``video_window`` moved into struct
:c:type:`v4l2_rect` substructure ``w`` of struct
:c:type:`v4l2_window`. The ``chromakey``, ``clips``, and
``clipcount`` fields remained unchanged. Struct
``video_clip`` was renamed to struct
:c:type:`v4l2_clip`, also containing a struct
:c:type:`v4l2_rect`, but the semantics are still the same.
The ``VIDEO_WINDOW_INTERLACE`` flag was dropped. Instead applications
must set the ``field`` field to ``V4L2_FIELD_ANY`` or
``V4L2_FIELD_INTERLACED``. The ``VIDEO_WINDOW_CHROMAKEY`` flag moved
into struct :c:type:`v4l2_framebuffer`, under the new
name ``V4L2_FBUF_FLAG_CHROMAKEY``.
In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
has a separate ``bitmap`` pointer field for this purpose and the bitmap
size is determined by ``w.width`` and ``w.height``.
The ``VIDIOCCAPTURE`` ioctl to enable or disable overlay was renamed to
:ref:`VIDIOC_OVERLAY`.
Cropping과 field 선택
457-482V4L은 전체 picture의 일부만 capture하기 위해 `VIDIOCGCAPTURE`, `VIDIOCSCAPTURE`와 `video_capture`를 사용했습니다. V4L2는 `VIDIOC_G_CROP`, `VIDIOC_S_CROP`, `v4l2_crop` 및 관련 `VIDIOC_CROPCAP`을 사용합니다.
`x`, `y`, `width`, `height`는 `v4l2_crop.c`의 `v4l2_rect`로 이동했습니다. `decimation` field는 제거됐고 V4L2에서 scaling factor는 crop rectangle 크기와 capture 또는 overlay image 크기의 관계로 암시됩니다.
Odd field 또는 even field만 capture하던 `VIDEO_CAPTURE_ODD`, `VIDEO_CAPTURE_EVEN`은 `v4l2_pix_format`과 `v4l2_window`의 `field`에 쓰는 `V4L2_FIELD_TOP`, `V4L2_FIELD_BOTTOM`으로 바뀌었습니다. Capture/overlay format은 `VIDIOC_S_FMT`으로 선택합니다.
Geometry와 field를 별도 구조체로 명확히 표현합니다.
Cropping
========
To capture only a subsection of the full picture V4L defines the
``VIDIOCGCAPTURE`` and ``VIDIOCSCAPTURE`` ioctls using struct
``video_capture``. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
:ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` using struct
:c:type:`v4l2_crop`, and the related
:ref:`VIDIOC_CROPCAP` ioctl. This is a rather
complex matter, see :ref:`crop` for details.
The ``x``, ``y``, ``width`` and ``height`` fields moved into struct
:c:type:`v4l2_rect` substructure ``c`` of struct
:c:type:`v4l2_crop`. The ``decimation`` field was dropped. In
the V4L2 API the scaling factor is implied by the size of the cropping
rectangle and the size of the captured or overlaid image.
The ``VIDEO_CAPTURE_ODD`` and ``VIDEO_CAPTURE_EVEN`` flags to capture
only the odd or even field, respectively, were replaced by
``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM`` in the field named
``field`` of struct :c:type:`v4l2_pix_format` and
struct :c:type:`v4l2_window`. These structures are used to
select a capture or overlay format with the
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
Read와 memory-mapped capture
483-568`read()`로 V4L 또는 V4L2 장치에서 image를 읽는 방식에는 본질적인 차이가 없지만 V4L2 driver가 read I/O를 반드시 지원할 필요는 없습니다. `VIDIOC_QUERYCAP`으로 지원 여부를 확인합니다. Application과 data를 교환하는 모든 V4L2 device는 `select()`와 `poll()`을 지원해야 합니다.
V4L은 image format과 크기 선택에 `VIDIOCSPICT`, `VIDIOCSWIN`을 사용했습니다. V4L2는 `VIDIOC_G_FMT`, `VIDIOC_S_FMT`과 `v4l2_format.fmt.pix`의 `v4l2_pix_format`을 사용합니다.
Memory mapping은 device memory 또는 DMA 가능한 system-memory buffer를 application address space에 mapping해 read 방식의 data copy overhead를 피합니다. V4L2도 mmap을 지원하지만 초기화와 queue model이 다릅니다.
V4L의 고정 buffer 모델과 V4L2 queue 모델을 비교합니다.
V4L `VIDIOCMCAPTURE`는 buffer와 그 image format을 capture 준비 상태로 만들고 즉시 반환하며 video signal이 없으면 `EAGAIN`일 수 있습니다. 여러 buffer가 있으면 capture request를 동시에 여러 개 outstanding 상태로 둘 수 있고 `VIDIOCSYNC`가 특정 buffer가 채워질 때까지 기다립니다.
명시적인 buffer allocation과 양방향 queue 수명주기입니다.
Reading Images, Memory Mapping
==============================
Capturing using the read method
-------------------------------
There is no essential difference between reading images from a V4L or
V4L2 device using the :c:func:`read()` function, however V4L2
drivers are not required to support this I/O method. Applications can
determine if the function is available with the
:ref:`VIDIOC_QUERYCAP` ioctl. All V4L2 devices
exchanging data with applications must support the
:c:func:`select()` and :c:func:`poll()`
functions.
To select an image format and size, V4L provides the ``VIDIOCSPICT`` and
``VIDIOCSWIN`` ioctls. V4L2 uses the general-purpose data format
negotiation ioctls :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
:c:type:`v4l2_format` as argument, here the struct
:c:type:`v4l2_pix_format` named ``pix`` of its
``fmt`` union is used.
For more information about the V4L2 read interface see :ref:`rw`.
Capturing using memory mapping
------------------------------
Applications can read from V4L devices by mapping buffers in device
memory, or more often just buffers allocated in DMA-able system memory,
into their address space. This avoids the data copying overhead of the
read method. V4L2 supports memory mapping as well, with a few
differences.
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - V4L
- V4L2
* -
- The image format must be selected before buffers are allocated,
with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When no
format is selected the driver may use the last, possibly by
another application requested format.
* - Applications cannot change the number of buffers. The it is built
into the driver, unless it has a module option to change the
number when the driver module is loaded.
- The :ref:`VIDIOC_REQBUFS` ioctl allocates the
desired number of buffers, this is a required step in the
initialization sequence.
* - Drivers map all buffers as one contiguous range of memory. The
``VIDIOCGMBUF`` ioctl is available to query the number of buffers,
the offset of each buffer from the start of the virtual file, and
the overall amount of memory used, which can be used as arguments
for the :c:func:`mmap()` function.
- Buffers are individually mapped. The offset and size of each
buffer can be determined with the
:ref:`VIDIOC_QUERYBUF` ioctl.
* - The ``VIDIOCMCAPTURE`` ioctl prepares a buffer for capturing. It
also determines the image format for this buffer. The ioctl
returns immediately, eventually with an ``EAGAIN`` error code if no
video signal had been detected. When the driver supports more than
one buffer applications can call the ioctl multiple times and thus
have multiple outstanding capture requests.
The ``VIDIOCSYNC`` ioctl suspends execution until a particular
buffer has been filled.
- Drivers maintain an incoming and outgoing queue.
:ref:`VIDIOC_QBUF` enqueues any empty buffer into
the incoming queue. Filled buffers are dequeued from the outgoing
queue with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. To wait
until filled buffers become available this function,
:c:func:`select()` or :c:func:`poll()` can
be used. The :ref:`VIDIOC_STREAMON` ioctl
must be called once after enqueuing one or more buffers to start
capturing. Its counterpart
:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` stops capturing and
dequeues all buffers from both queues. Applications can query the
signal status, if known, with the
:ref:`VIDIOC_ENUMINPUT` ioctl.
For a more in-depth discussion of memory mapping and examples, see
:ref:`mmap`.
Raw VBI data
569-618초기 V4L API는 raw VBI capture interface를 명시하지 않고 `/dev/vbi`만 예약했습니다. 이 interface를 지원한 유일한 BTTV driver가 사실상 V4L VBI interface를 정의했습니다.
Device read가 반환한 raw VBI image parameter를 v4l2_vbi_format field 기준으로 정리합니다.
V4L 명세에는 없지만 Linux 2.3에서 `vbi_format`을 사용하는 `VIDIOCGVBIFMT`, `VIDIOCSVBIFMT`가 VBI image parameter 조회·설정용으로 추가됐습니다. 이 ioctl은 V4L2 raw VBI interface와 일부만 호환됩니다.
V4L 구조에는 `offset` field가 없고 `sample_format`은 `V4L2_PIX_FMT_GREY`와 같은 `VIDEO_PALETTE_RAW`로 간주됩니다. 나머지 field는 `v4l2_vbi_format`과 대체로 대응하는 것으로 보입니다.
이 ioctl은 Zoran(ZR 36120) driver만 구현한 것으로 보입니다. V4L2와 달리 parameter가 `open()` 때 reset되고, `VIDIOCSVBIFMT`는 parameter가 invalid하면 항상 `EINVAL`을 반환합니다.
Reading Raw VBI Data
====================
Originally the V4L API did not specify a raw VBI capture interface, only
the device file ``/dev/vbi`` was reserved for this purpose. The only
driver supporting this interface was the BTTV driver, de-facto defining
the V4L VBI interface. Reading from the device yields a raw VBI image
with the following parameters:
.. flat-table::
:header-rows: 1
:stub-columns: 0
* - struct :c:type:`v4l2_vbi_format`
- V4L, BTTV driver
* - sampling_rate
- 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
and SECAM (625-line standards)
* - offset
- ?
* - samples_per_line
- 2048
* - sample_format
- V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
integer) contain a frame counter.
* - start[]
- 10, 273 NTSC; 22, 335 PAL and SECAM
* - count[]
- 16, 16 [#f9]_
* - flags
- 0
Undocumented in the V4L specification, in Linux 2.3 the
``VIDIOCGVBIFMT`` and ``VIDIOCSVBIFMT`` ioctls using struct
``vbi_format`` were added to determine the VBI image
parameters. These ioctls are only partially compatible with the V4L2 VBI
interface specified in :ref:`raw-vbi`.
An ``offset`` field does not exist, ``sample_format`` is supposed to be
``VIDEO_PALETTE_RAW``, equivalent to ``V4L2_PIX_FMT_GREY``. The
remaining fields are probably equivalent to struct
:c:type:`v4l2_vbi_format`.
Apparently only the Zoran (ZR 36120) driver implements these ioctls. The
semantics differ from those specified for V4L2 in two ways. The
parameters are reset on :c:func:`open()` and
``VIDIOCSVBIFMT`` always returns an ``EINVAL`` error code if the parameters
are invalid.
기타 차이와 format 각주
619-667V4L2에는 `VIDIOCGUNIT` 대응 ioctl이 없습니다. Video capture device와 연결된 VBI device 또는 그 반대를 찾으려면 장치를 다시 열고 VBI data를 요청합니다.
`VIDIOCKEY`와 V4L의 microcode programming function에는 대체 API가 없습니다. MPEG compression·playback 장치용 새 interface는 extended controls에 정의됩니다.
Node와 pixel format 대응에서 주의할 예외를 모두 보존합니다.
Miscellaneous
=============
V4L2 has no equivalent of the ``VIDIOCGUNIT`` ioctl. Applications can
find the VBI device associated with a video capture device (or vice
versa) by reopening the device and requesting VBI data. For details see
:ref:`open`.
No replacement exists for ``VIDIOCKEY``, and the V4L functions for
microcode programming. A new interface for MPEG compression and playback
devices is documented in :ref:`extended-controls`.
.. [#f1]
According to Documentation/admin-guide/devices.rst these should be symbolic links
to ``/dev/video0``. Note the original bttv interface is not
compatible with V4L or V4L2.
.. [#f2]
According to ``Documentation/admin-guide/devices.rst`` a symbolic link to
``/dev/radio0``.
.. [#f3]
This is a custom format used by the BTTV driver, not one of the V4L2
standard formats.
.. [#f4]
Presumably all V4L RGB formats are little-endian, although some
drivers might interpret them according to machine endianness. V4L2
defines little-endian, big-endian and red/blue swapped variants. For
details see :ref:`pixfmt-rgb`.
.. [#f5]
``VIDEO_PALETTE_YUV422`` and ``VIDEO_PALETTE_YUYV`` are the same
formats. Some V4L drivers respond to one, some to the other.
.. [#f6]
Not to be confused with ``V4L2_PIX_FMT_YUV411P``, which is a planar
format.
.. [#f7]
V4L explains this as: "RAW capture (BT848)"
.. [#f8]
Not to be confused with ``V4L2_PIX_FMT_Y41P``, which is a packed
format.
.. [#f9]
Old driver versions used different values, eventually the custom
``BTTV_VBISIZE`` ioctl was added to query the correct values.
요약·해설
diff-v4l.rst:1-667V4L2는 V4L의 단일 type과 고정 범위 field를 capability flag, format enumeration, 독립 control, 명시적인 구조체로 분해했습니다. Porting할 때 이름만 바꾸지 말고 지원 여부·limit·geometry를 ioctl로 다시 조회해야 합니다.
가장 큰 I/O 차이는 V4L2의 명시적인 buffer queue입니다. Format을 먼저 확정한 뒤 REQBUFS, QUERYBUF, QBUF, STREAMON, DQBUF, STREAMOFF 순서를 따라야 하며 multiple open과 per-device capability도 고려해야 합니다.