1 .. -*- coding: utf-8; mode: rst -*-
5 ********************************
6 Differences between V4L and V4L2
7 ********************************
9 The Video For Linux API was first introduced in Linux 2.1 to unify and
10 replace various TV and radio device related interfaces, developed
11 independently by driver writers in prior years. Starting with Linux 2.5
12 the much improved V4L2 API replaces the V4L API. The support for the old
13 V4L calls were removed from Kernel, but the library :ref:`libv4l`
14 supports the conversion of a V4L API system call into a V4L2 one.
17 Opening and Closing Devices
18 ===========================
20 For compatibility reasons the character device file names recommended
21 for V4L2 video capture, overlay, radio and raw vbi capture devices did
22 not change from those used by V4L. They are listed in :ref:`devices`
23 and below in :ref:`v4l-dev`.
25 The teletext devices (minor range 192-223) have been removed in V4L2 and
26 no longer exist. There is no hardware available anymore for handling
27 pure teletext. Instead raw or sliced VBI is used.
29 The V4L ``videodev`` module automatically assigns minor numbers to
30 drivers in load order, depending on the registered device type. We
31 recommend that V4L2 drivers by default register devices with the same
32 numbers, but the system administrator can assign arbitrary minor numbers
33 using driver module options. The major device number remains 81.
38 .. flat-table:: V4L Device Types, Names and Numbers
53 - Video capture and overlay
55 - ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
64 - ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
72 - ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
77 V4L prohibits (or used to prohibit) multiple opens of a device file.
78 V4L2 drivers *may* support multiple opens, see :ref:`open` for details
81 V4L drivers respond to V4L2 ioctls with an ``EINVAL`` error code.
87 The V4L ``VIDIOCGCAP`` ioctl is equivalent to V4L2's
88 :ref:`VIDIOC_QUERYCAP`.
90 The ``name`` field in struct :c:type:`struct video_capability` became
91 ``card`` in struct :ref:`v4l2_capability <v4l2-capability>`, ``type``
92 was replaced by ``capabilities``. Note V4L2 does not distinguish between
93 device types like this, better think of basic video input, video output
94 and radio devices supporting a set of related functions like video
95 capturing, video overlay and VBI capturing. See :ref:`open` for an
98 .. tabularcolumns:: |p{5.5cm}|p{6.5cm}|p{5.5cm}
100 .. cssclass:: longtable
109 - ``struct video_capability`` ``type``
111 - struct :ref:`v4l2_capability <v4l2-capability>`
112 ``capabilities`` flags
118 - ``VID_TYPE_CAPTURE``
120 - ``V4L2_CAP_VIDEO_CAPTURE``
122 - The :ref:`video capture <capture>` interface is supported.
130 - The device has a :ref:`tuner or modulator <tuner>`.
134 - ``VID_TYPE_TELETEXT``
136 - ``V4L2_CAP_VBI_CAPTURE``
138 - The :ref:`raw VBI capture <raw-vbi>` interface is supported.
142 - ``VID_TYPE_OVERLAY``
144 - ``V4L2_CAP_VIDEO_OVERLAY``
146 - The :ref:`video overlay <overlay>` interface is supported.
150 - ``VID_TYPE_CHROMAKEY``
152 - ``V4L2_FBUF_CAP_CHROMAKEY`` in field ``capability`` of struct
153 :ref:`v4l2_framebuffer <v4l2-framebuffer>`
155 - Whether chromakey overlay is supported. For more information on
156 overlay see :ref:`overlay`.
160 - ``VID_TYPE_CLIPPING``
162 - ``V4L2_FBUF_CAP_LIST_CLIPPING`` and
163 ``V4L2_FBUF_CAP_BITMAP_CLIPPING`` in field ``capability`` of
164 struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`
166 - Whether clipping the overlaid image is supported, see
171 - ``VID_TYPE_FRAMERAM``
173 - ``V4L2_FBUF_CAP_EXTERNOVERLAY`` *not set* in field ``capability``
174 of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`
176 - Whether overlay overwrites frame buffer memory, see
181 - ``VID_TYPE_SCALES``
185 - This flag indicates if the hardware can scale images. The V4L2 API
186 implies the scale factor by setting the cropping dimensions and
187 image size with the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` and
188 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, respectively. The
189 driver returns the closest sizes possible. For more information on
190 cropping and scaling see :ref:`crop`.
194 - ``VID_TYPE_MONOCHROME``
198 - Applications can enumerate the supported image formats with the
199 :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
200 the device supports grey scale capturing only. For more
201 information on image formats see :ref:`pixfmt`.
205 - ``VID_TYPE_SUBCAPTURE``
209 - Applications can call the :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>`
210 ioctl to determine if the device supports capturing a subsection
211 of the full picture ("cropping" in V4L2). If not, the ioctl
212 returns the ``EINVAL`` error code. For more information on cropping
213 and scaling see :ref:`crop`.
217 - ``VID_TYPE_MPEG_DECODER``
221 - Applications can enumerate the supported image formats with the
222 :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
223 the device supports MPEG streams.
227 - ``VID_TYPE_MPEG_ENCODER``
235 - ``VID_TYPE_MJPEG_DECODER``
243 - ``VID_TYPE_MJPEG_ENCODER``
250 The ``audios`` field was replaced by ``capabilities`` flag
251 ``V4L2_CAP_AUDIO``, indicating *if* the device has any audio inputs or
252 outputs. To determine their number applications can enumerate audio
253 inputs with the :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` ioctl. The
254 audio ioctls are described in :ref:`audio`.
256 The ``maxwidth``, ``maxheight``, ``minwidth`` and ``minheight`` fields
257 were removed. Calling the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
258 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl with the desired
259 dimensions returns the closest size possible, taking into account the
260 current video standard, cropping and scaling limitations.
266 V4L provides the ``VIDIOCGCHAN`` and ``VIDIOCSCHAN`` ioctl using struct
267 :c:type:`struct video_channel` to enumerate the video inputs of a V4L
268 device. The equivalent V4L2 ioctls are
269 :ref:`VIDIOC_ENUMINPUT`,
270 :ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
271 :ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` using struct
272 :ref:`v4l2_input <v4l2-input>` as discussed in :ref:`video`.
274 The ``channel`` field counting inputs was renamed to ``index``, the
275 video input types were renamed as follows:
286 - struct :c:type:`struct video_channel` ``type``
288 - struct :ref:`v4l2_input <v4l2-input>` ``type``
294 - ``V4L2_INPUT_TYPE_TUNER``
298 - ``VIDEO_TYPE_CAMERA``
300 - ``V4L2_INPUT_TYPE_CAMERA``
303 Unlike the ``tuners`` field expressing the number of tuners of this
304 input, V4L2 assumes each video input is connected to at most one tuner.
305 However a tuner can have more than one input, i. e. RF connectors, and a
306 device can have multiple tuners. The index number of the tuner
307 associated with the input, if any, is stored in field ``tuner`` of
308 struct :ref:`v4l2_input <v4l2-input>`. Enumeration of tuners is
309 discussed in :ref:`tuner`.
311 The redundant ``VIDEO_VC_TUNER`` flag was dropped. Video inputs
312 associated with a tuner are of type ``V4L2_INPUT_TYPE_TUNER``. The
313 ``VIDEO_VC_AUDIO`` flag was replaced by the ``audioset`` field. V4L2
314 considers devices with up to 32 audio inputs. Each set bit in the
315 ``audioset`` field represents one audio input this video input combines
316 with. For information about audio inputs and how to switch between them
319 The ``norm`` field describing the supported video standards was replaced
320 by ``std``. The V4L specification mentions a flag ``VIDEO_VC_NORM``
321 indicating whether the standard can be changed. This flag was a later
322 addition together with the ``norm`` field and has been removed in the
323 meantime. V4L2 has a similar, albeit more comprehensive approach to
324 video standards, see :ref:`standard` for more information.
330 The V4L ``VIDIOCGTUNER`` and ``VIDIOCSTUNER`` ioctl and struct
331 :c:type:`struct video_tuner` can be used to enumerate the tuners of a
332 V4L TV or radio device. The equivalent V4L2 ioctls are
333 :ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
334 :ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` using struct
335 :ref:`v4l2_tuner <v4l2-tuner>`. Tuners are covered in :ref:`tuner`.
337 The ``tuner`` field counting tuners was renamed to ``index``. The fields
338 ``name``, ``rangelow`` and ``rangehigh`` remained unchanged.
340 The ``VIDEO_TUNER_PAL``, ``VIDEO_TUNER_NTSC`` and ``VIDEO_TUNER_SECAM``
341 flags indicating the supported video standards were dropped. This
342 information is now contained in the associated struct
343 :ref:`v4l2_input <v4l2-input>`. No replacement exists for the
344 ``VIDEO_TUNER_NORM`` flag indicating whether the video standard can be
345 switched. The ``mode`` field to select a different video standard was
346 replaced by a whole new set of ioctls and structures described in
347 :ref:`standard`. Due to its ubiquity it should be mentioned the BTTV
348 driver supports several standards in addition to the regular
349 ``VIDEO_MODE_PAL`` (0), ``VIDEO_MODE_NTSC``, ``VIDEO_MODE_SECAM`` and
350 ``VIDEO_MODE_AUTO`` (3). Namely N/PAL Argentina, M/PAL, N/PAL, and NTSC
351 Japan with numbers 3-6 (sic).
353 The ``VIDEO_TUNER_STEREO_ON`` flag indicating stereo reception became
354 ``V4L2_TUNER_SUB_STEREO`` in field ``rxsubchans``. This field also
355 permits the detection of monaural and bilingual audio, see the
356 definition of struct :ref:`v4l2_tuner <v4l2-tuner>` for details.
357 Presently no replacement exists for the ``VIDEO_TUNER_RDS_ON`` and
358 ``VIDEO_TUNER_MBS_ON`` flags.
360 The ``VIDEO_TUNER_LOW`` flag was renamed to ``V4L2_TUNER_CAP_LOW`` in
361 the struct :ref:`v4l2_tuner <v4l2-tuner>` ``capability`` field.
363 The ``VIDIOCGFREQ`` and ``VIDIOCSFREQ`` ioctl to change the tuner
364 frequency where renamed to
365 :ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
366 :ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>`. They take a pointer
367 to a struct :ref:`v4l2_frequency <v4l2-frequency>` instead of an
368 unsigned long integer.
371 .. _v4l-image-properties:
376 V4L2 has no equivalent of the ``VIDIOCGPICT`` and ``VIDIOCSPICT`` ioctl
377 and struct :c:type:`struct video_picture`. The following fields where
378 replaced by V4L2 controls accessible with the
379 :ref:`VIDIOC_QUERYCTRL`,
380 :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
381 :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
392 - struct :c:type:`struct video_picture`
400 - ``V4L2_CID_BRIGHTNESS``
412 - ``V4L2_CID_SATURATION``
418 - ``V4L2_CID_CONTRAST``
424 - ``V4L2_CID_WHITENESS``
427 The V4L picture controls are assumed to range from 0 to 65535 with no
428 particular reset value. The V4L2 API permits arbitrary limits and
429 defaults which can be queried with the
430 :ref:`VIDIOC_QUERYCTRL` ioctl. For general
431 information about controls see :ref:`control`.
433 The ``depth`` (average number of bits per pixel) of a video image is
434 implied by the selected image format. V4L2 does not explicitly provide
435 such information assuming applications recognizing the format are aware
436 of the image depth and others need not know. The ``palette`` field moved
437 into the struct :ref:`v4l2_pix_format <v4l2-pix-format>`:
448 - struct :c:type:`struct video_picture` ``palette``
450 - struct :ref:`v4l2_pix_format <v4l2-pix-format>` ``pixfmt``
454 - ``VIDEO_PALETTE_GREY``
456 - :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
460 - ``VIDEO_PALETTE_HI240``
462 - :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
466 - ``VIDEO_PALETTE_RGB565``
468 - :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
472 - ``VIDEO_PALETTE_RGB555``
474 - :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
478 - ``VIDEO_PALETTE_RGB24``
480 - :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
484 - ``VIDEO_PALETTE_RGB32``
486 - :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
490 - ``VIDEO_PALETTE_YUV422``
492 - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
496 - ``VIDEO_PALETTE_YUYV``\ [#f5]_
498 - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
502 - ``VIDEO_PALETTE_UYVY``
504 - :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
508 - ``VIDEO_PALETTE_YUV420``
514 - ``VIDEO_PALETTE_YUV411``
516 - :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
520 - ``VIDEO_PALETTE_RAW``
526 - ``VIDEO_PALETTE_YUV422P``
528 - :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
532 - ``VIDEO_PALETTE_YUV411P``
534 - :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
538 - ``VIDEO_PALETTE_YUV420P``
540 - :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
544 - ``VIDEO_PALETTE_YUV410P``
546 - :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
549 V4L2 image formats are defined in :ref:`pixfmt`. The image format can
550 be selected with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
556 The ``VIDIOCGAUDIO`` and ``VIDIOCSAUDIO`` ioctl and struct
557 :c:type:`struct video_audio` are used to enumerate the audio inputs
558 of a V4L device. The equivalent V4L2 ioctls are
559 :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
560 :ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` using struct
561 :ref:`v4l2_audio <v4l2-audio>` as discussed in :ref:`audio`.
563 The ``audio`` "channel number" field counting audio inputs was renamed
566 On ``VIDIOCSAUDIO`` the ``mode`` field selects *one* of the
567 ``VIDEO_SOUND_MONO``, ``VIDEO_SOUND_STEREO``, ``VIDEO_SOUND_LANG1`` or
568 ``VIDEO_SOUND_LANG2`` audio demodulation modes. When the current audio
569 standard is BTSC ``VIDEO_SOUND_LANG2`` refers to SAP and
570 ``VIDEO_SOUND_LANG1`` is meaningless. Also undocumented in the V4L
571 specification, there is no way to query the selected mode. On
572 ``VIDIOCGAUDIO`` the driver returns the *actually received* audio
573 programmes in this field. In the V4L2 API this information is stored in
574 the struct :ref:`v4l2_tuner <v4l2-tuner>` ``rxsubchans`` and
575 ``audmode`` fields, respectively. See :ref:`tuner` for more
576 information on tuners. Related to audio modes struct
577 :ref:`v4l2_audio <v4l2-audio>` also reports if this is a mono or
578 stereo input, regardless if the source is a tuner.
580 The following fields where replaced by V4L2 controls accessible with the
581 :ref:`VIDIOC_QUERYCTRL`,
582 :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
583 :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls:
594 - struct :c:type:`struct video_audio`
602 - ``V4L2_CID_AUDIO_VOLUME``
608 - ``V4L2_CID_AUDIO_BASS``
614 - ``V4L2_CID_AUDIO_TREBLE``
620 - ``V4L2_CID_AUDIO_BALANCE``
623 To determine which of these controls are supported by a driver V4L
624 provides the ``flags`` ``VIDEO_AUDIO_VOLUME``, ``VIDEO_AUDIO_BASS``,
625 ``VIDEO_AUDIO_TREBLE`` and ``VIDEO_AUDIO_BALANCE``. In the V4L2 API the
626 :ref:`VIDIOC_QUERYCTRL` ioctl reports if the
627 respective control is supported. Accordingly the ``VIDEO_AUDIO_MUTABLE``
628 and ``VIDEO_AUDIO_MUTE`` flags where replaced by the boolean
629 ``V4L2_CID_AUDIO_MUTE`` control.
631 All V4L2 controls have a ``step`` attribute replacing the struct
632 :c:type:`struct video_audio` ``step`` field. The V4L audio controls
633 are assumed to range from 0 to 65535 with no particular reset value. The
634 V4L2 API permits arbitrary limits and defaults which can be queried with
635 the :ref:`VIDIOC_QUERYCTRL` ioctl. For general
636 information about controls see :ref:`control`.
642 The V4L2 ioctls equivalent to ``VIDIOCGFBUF`` and ``VIDIOCSFBUF`` are
643 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
644 :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The ``base`` field of struct
645 :c:type:`struct video_buffer` remained unchanged, except V4L2 defines
646 a flag to indicate non-destructive overlays instead of a ``NULL``
647 pointer. All other fields moved into the struct
648 :ref:`v4l2_pix_format <v4l2-pix-format>` ``fmt`` substructure of
649 struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`. The ``depth``
650 field was replaced by ``pixelformat``. See :ref:`pixfmt-rgb` for a
651 list of RGB formats and their respective color depths.
653 Instead of the special ioctls ``VIDIOCGWIN`` and ``VIDIOCSWIN`` V4L2
654 uses the general-purpose data format negotiation ioctls
655 :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
656 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
657 :ref:`v4l2_format <v4l2-format>` as argument. Here the ``win`` member
658 of the ``fmt`` union is used, a struct
659 :ref:`v4l2_window <v4l2-window>`.
661 The ``x``, ``y``, ``width`` and ``height`` fields of struct
662 :c:type:`struct video_window` moved into struct
663 :ref:`v4l2_rect <v4l2-rect>` substructure ``w`` of struct
664 :c:type:`struct v4l2_window`. The ``chromakey``, ``clips``, and
665 ``clipcount`` fields remained unchanged. Struct
666 :c:type:`struct video_clip` was renamed to struct
667 :ref:`v4l2_clip <v4l2-clip>`, also containing a struct
668 :c:type:`struct v4l2_rect`, but the semantics are still the same.
670 The ``VIDEO_WINDOW_INTERLACE`` flag was dropped. Instead applications
671 must set the ``field`` field to ``V4L2_FIELD_ANY`` or
672 ``V4L2_FIELD_INTERLACED``. The ``VIDEO_WINDOW_CHROMAKEY`` flag moved
673 into struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`, under the new
674 name ``V4L2_FBUF_FLAG_CHROMAKEY``.
676 In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
677 to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
678 size bitmap of 1024 × 625 bits. Struct :c:type:`struct v4l2_window`
679 has a separate ``bitmap`` pointer field for this purpose and the bitmap
680 size is determined by ``w.width`` and ``w.height``.
682 The ``VIDIOCCAPTURE`` ioctl to enable or disable overlay was renamed to
683 :ref:`VIDIOC_OVERLAY`.
689 To capture only a subsection of the full picture V4L defines the
690 ``VIDIOCGCAPTURE`` and ``VIDIOCSCAPTURE`` ioctls using struct
691 :c:type:`struct video_capture`. The equivalent V4L2 ioctls are
692 :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
693 :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` using struct
694 :ref:`v4l2_crop <v4l2-crop>`, and the related
695 :ref:`VIDIOC_CROPCAP` ioctl. This is a rather
696 complex matter, see :ref:`crop` for details.
698 The ``x``, ``y``, ``width`` and ``height`` fields moved into struct
699 :ref:`v4l2_rect <v4l2-rect>` substructure ``c`` of struct
700 :c:type:`struct v4l2_crop`. The ``decimation`` field was dropped. In
701 the V4L2 API the scaling factor is implied by the size of the cropping
702 rectangle and the size of the captured or overlaid image.
704 The ``VIDEO_CAPTURE_ODD`` and ``VIDEO_CAPTURE_EVEN`` flags to capture
705 only the odd or even field, respectively, were replaced by
706 ``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM`` in the field named
707 ``field`` of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
708 struct :ref:`v4l2_window <v4l2-window>`. These structures are used to
709 select a capture or overlay format with the
710 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
713 Reading Images, Memory Mapping
714 ==============================
717 Capturing using the read method
718 -------------------------------
720 There is no essential difference between reading images from a V4L or
721 V4L2 device using the :ref:`read() <func-read>` function, however V4L2
722 drivers are not required to support this I/O method. Applications can
723 determine if the function is available with the
724 :ref:`VIDIOC_QUERYCAP` ioctl. All V4L2 devices
725 exchanging data with applications must support the
726 :ref:`select() <func-select>` and :ref:`poll() <func-poll>`
729 To select an image format and size, V4L provides the ``VIDIOCSPICT`` and
730 ``VIDIOCSWIN`` ioctls. V4L2 uses the general-purpose data format
731 negotiation ioctls :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
732 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
733 :ref:`v4l2_format <v4l2-format>` as argument, here the struct
734 :ref:`v4l2_pix_format <v4l2-pix-format>` named ``pix`` of its
735 ``fmt`` union is used.
737 For more information about the V4L2 read interface see :ref:`rw`.
740 Capturing using memory mapping
741 ------------------------------
743 Applications can read from V4L devices by mapping buffers in device
744 memory, or more often just buffers allocated in DMA-able system memory,
745 into their address space. This avoids the data copying overhead of the
746 read method. V4L2 supports memory mapping as well, with a few
765 - The image format must be selected before buffers are allocated,
766 with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When no
767 format is selected the driver may use the last, possibly by
768 another application requested format.
772 - Applications cannot change the number of buffers. The it is built
773 into the driver, unless it has a module option to change the
774 number when the driver module is loaded.
776 - The :ref:`VIDIOC_REQBUFS` ioctl allocates the
777 desired number of buffers, this is a required step in the
778 initialization sequence.
782 - Drivers map all buffers as one contiguous range of memory. The
783 ``VIDIOCGMBUF`` ioctl is available to query the number of buffers,
784 the offset of each buffer from the start of the virtual file, and
785 the overall amount of memory used, which can be used as arguments
786 for the :ref:`mmap() <func-mmap>` function.
788 - Buffers are individually mapped. The offset and size of each
789 buffer can be determined with the
790 :ref:`VIDIOC_QUERYBUF` ioctl.
794 - The ``VIDIOCMCAPTURE`` ioctl prepares a buffer for capturing. It
795 also determines the image format for this buffer. The ioctl
796 returns immediately, eventually with an ``EAGAIN`` error code if no
797 video signal had been detected. When the driver supports more than
798 one buffer applications can call the ioctl multiple times and thus
799 have multiple outstanding capture requests.
801 The ``VIDIOCSYNC`` ioctl suspends execution until a particular
802 buffer has been filled.
804 - Drivers maintain an incoming and outgoing queue.
805 :ref:`VIDIOC_QBUF` enqueues any empty buffer into
806 the incoming queue. Filled buffers are dequeued from the outgoing
807 queue with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. To wait
808 until filled buffers become available this function,
809 :ref:`select() <func-select>` or :ref:`poll() <func-poll>` can
810 be used. The :ref:`VIDIOC_STREAMON` ioctl
811 must be called once after enqueuing one or more buffers to start
812 capturing. Its counterpart
813 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` stops capturing and
814 dequeues all buffers from both queues. Applications can query the
815 signal status, if known, with the
816 :ref:`VIDIOC_ENUMINPUT` ioctl.
819 For a more in-depth discussion of memory mapping and examples, see
826 Originally the V4L API did not specify a raw VBI capture interface, only
827 the device file ``/dev/vbi`` was reserved for this purpose. The only
828 driver supporting this interface was the BTTV driver, de-facto defining
829 the V4L VBI interface. Reading from the device yields a raw VBI image
830 with the following parameters:
841 - struct :ref:`v4l2_vbi_format <v4l2-vbi-format>`
849 - 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
850 and SECAM (625-line standards)
868 - V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
869 integer) contain a frame counter.
875 - 10, 273 NTSC; 22, 335 PAL and SECAM
890 Undocumented in the V4L specification, in Linux 2.3 the
891 ``VIDIOCGVBIFMT`` and ``VIDIOCSVBIFMT`` ioctls using struct
892 :c:type:`struct vbi_format` were added to determine the VBI image
893 parameters. These ioctls are only partially compatible with the V4L2 VBI
894 interface specified in :ref:`raw-vbi`.
896 An ``offset`` field does not exist, ``sample_format`` is supposed to be
897 ``VIDEO_PALETTE_RAW``, equivalent to ``V4L2_PIX_FMT_GREY``. The
898 remaining fields are probably equivalent to struct
899 :ref:`v4l2_vbi_format <v4l2-vbi-format>`.
901 Apparently only the Zoran (ZR 36120) driver implements these ioctls. The
902 semantics differ from those specified for V4L2 in two ways. The
903 parameters are reset on :ref:`open() <func-open>` and
904 ``VIDIOCSVBIFMT`` always returns an ``EINVAL`` error code if the parameters
911 V4L2 has no equivalent of the ``VIDIOCGUNIT`` ioctl. Applications can
912 find the VBI device associated with a video capture device (or vice
913 versa) by reopening the device and requesting VBI data. For details see
916 No replacement exists for ``VIDIOCKEY``, and the V4L functions for
917 microcode programming. A new interface for MPEG compression and playback
918 devices is documented in :ref:`extended-controls`.
921 According to Documentation/devices.txt these should be symbolic links
922 to ``/dev/video0``. Note the original bttv interface is not
923 compatible with V4L or V4L2.
926 According to ``Documentation/devices.txt`` a symbolic link to
930 This is a custom format used by the BTTV driver, not one of the V4L2
934 Presumably all V4L RGB formats are little-endian, although some
935 drivers might interpret them according to machine endianness. V4L2
936 defines little-endian, big-endian and red/blue swapped variants. For
937 details see :ref:`pixfmt-rgb`.
940 ``VIDEO_PALETTE_YUV422`` and ``VIDEO_PALETTE_YUYV`` are the same
941 formats. Some V4L drivers respond to one, some to the other.
944 Not to be confused with ``V4L2_PIX_FMT_YUV411P``, which is a planar
948 V4L explains this as: "RAW capture (BT848)"
951 Not to be confused with ``V4L2_PIX_FMT_Y41P``, which is a packed
955 Old driver versions used different values, eventually the custom
956 ``BTTV_VBISIZE`` ioctl was added to query the correct values.
projects / cascardo / linux.git / blob