Devices supporting the raw VBI capturing or output API set the
``V4L2_CAP_VBI_CAPTURE`` or ``V4L2_CAP_VBI_OUTPUT`` flags, respectively,
in the ``capabilities`` field of struct
-:ref:`v4l2_capability <v4l2-capability>` returned by the
+:c:type:`v4l2_capability` returned by the
:ref:`VIDIOC_QUERYCAP` ioctl. At least one of the
read/write, streaming or asynchronous I/O methods must be supported. VBI
devices may or may not have a tuner or modulator.
parameters and then checking if the actual parameters are suitable.
To query the current raw VBI capture parameters applications set the
-``type`` field of a struct :ref:`v4l2_format <v4l2-format>` to
+``type`` field of a struct :c:type:`v4l2_format` to
``V4L2_BUF_TYPE_VBI_CAPTURE`` or ``V4L2_BUF_TYPE_VBI_OUTPUT``, and call
the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
structure. Drivers fill the struct
-:ref:`v4l2_vbi_format <v4l2-vbi-format>` ``vbi`` member of the
+:c:type:`v4l2_vbi_format` ``vbi`` 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_vbi_format <v4l2-vbi-format>`
+struct :c:type:`v4l2_format` as above and initialize all
+fields of the struct :c:type:`v4l2_vbi_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 return an ``EINVAL`` error
and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
-
-.. _v4l2-vbi-format:
-
.. tabularcolumns:: |p{2.4cm}|p{4.4cm}|p{10.7cm}|
+.. c:type:: v4l2_vbi_format
+
.. cssclass:: longtable
.. flat-table:: struct v4l2_vbi_format
:stub-columns: 0
:widths: 1 1 2
-
- - .. row 1
-
- - __u32
-
- - ``sampling_rate``
-
- - Samples per second, i. e. unit 1 Hz.
-
- - .. row 2
-
- - __u32
-
- - ``offset``
-
- - Horizontal offset of the VBI image, relative to the leading edge
- of the line synchronization pulse and counted in samples: The
- first sample in the VBI image will be located ``offset`` /
- ``sampling_rate`` seconds following the leading edge. See also
- :ref:`vbi-hsync`.
-
- - .. row 3
-
- - __u32
-
- - ``samples_per_line``
-
- -
-
- - .. row 4
-
- - __u32
-
- - ``sample_format``
-
- - Defines the sample format as in :ref:`pixfmt`, a
- four-character-code. [#f2]_ Usually this is ``V4L2_PIX_FMT_GREY``,
- i. e. each sample consists of 8 bits with lower values oriented
- towards the black level. Do not assume any other correlation of
- values with the signal level. For example, the MSB does not
- necessarily indicate if the signal is 'high' or 'low' because 128
- may not be the mean value of the signal. Drivers shall not convert
- the sample format by software.
-
- - .. row 5
-
- - __u32
-
- - ``start``\ [#f2]_
-
- - This is the scanning system line number associated with the first
- line of the VBI image, of the first and the second field
- respectively. See :ref:`vbi-525` and :ref:`vbi-625` for valid
- values. The ``V4L2_VBI_ITU_525_F1_START``,
- ``V4L2_VBI_ITU_525_F2_START``, ``V4L2_VBI_ITU_625_F1_START`` and
- ``V4L2_VBI_ITU_625_F2_START`` defines give the start line numbers
- for each field for each 525 or 625 line format as a convenience.
- Don't forget that ITU line numbering starts at 1, not 0. VBI input
- drivers can return start values 0 if the hardware cannot reliable
- identify scanning lines, VBI acquisition may not require this
- information.
-
- - .. row 6
-
- - __u32
-
- - ``count``\ [#f2]_
-
- - The number of lines in the first and second field image,
- respectively.
-
- - .. row 7
-
- - :cspan:`2`
-
- Drivers should be as flexibility as possible. For example, it may
- be possible to extend or move the VBI capture window down to the
- picture area, implementing a 'full field mode' to capture data
- service transmissions embedded in the picture.
-
- An application can set the first or second ``count`` value to zero
- if no data is required from the respective field; ``count``\ [1]
- if the scanning system is progressive, i. e. not interlaced. The
- corresponding start value shall be ignored by the application and
- driver. Anyway, drivers may not support single field capturing and
- return both count values non-zero.
-
- Both ``count`` values set to zero, or line numbers are outside the
- bounds depicted\ [#f4]_, or a field image covering lines of two
- fields, are invalid and shall not be returned by the driver.
-
- To initialize the ``start`` and ``count`` fields, applications
- must first determine the current video standard selection. The
- :ref:`v4l2_std_id <v4l2-std-id>` or the ``framelines`` field
- of struct :ref:`v4l2_standard <v4l2-standard>` can be evaluated
- for this purpose.
-
- - .. row 8
-
- - __u32
-
- - ``flags``
-
- - See :ref:`vbifmt-flags` below. Currently only drivers set flags,
- applications must set this field to zero.
-
- - .. row 9
-
- - __u32
-
- - ``reserved``\ [#f2]_
-
- - This array is reserved for future extensions. Drivers and
- applications must set it to zero.
+ * - __u32
+ - ``sampling_rate``
+ - Samples per second, i. e. unit 1 Hz.
+ * - __u32
+ - ``offset``
+ - Horizontal offset of the VBI image, relative to the leading edge
+ of the line synchronization pulse and counted in samples: The
+ first sample in the VBI image will be located ``offset`` /
+ ``sampling_rate`` seconds following the leading edge. See also
+ :ref:`vbi-hsync`.
+ * - __u32
+ - ``samples_per_line``
+ -
+ * - __u32
+ - ``sample_format``
+ - Defines the sample format as in :ref:`pixfmt`, a
+ four-character-code. [#f2]_ Usually this is ``V4L2_PIX_FMT_GREY``,
+ i. e. each sample consists of 8 bits with lower values oriented
+ towards the black level. Do not assume any other correlation of
+ values with the signal level. For example, the MSB does not
+ necessarily indicate if the signal is 'high' or 'low' because 128
+ may not be the mean value of the signal. Drivers shall not convert
+ the sample format by software.
+ * - __u32
+ - ``start``\ [#f2]_
+ - This is the scanning system line number associated with the first
+ line of the VBI image, of the first and the second field
+ respectively. See :ref:`vbi-525` and :ref:`vbi-625` for valid
+ values. The ``V4L2_VBI_ITU_525_F1_START``,
+ ``V4L2_VBI_ITU_525_F2_START``, ``V4L2_VBI_ITU_625_F1_START`` and
+ ``V4L2_VBI_ITU_625_F2_START`` defines give the start line numbers
+ for each field for each 525 or 625 line format as a convenience.
+ Don't forget that ITU line numbering starts at 1, not 0. VBI input
+ drivers can return start values 0 if the hardware cannot reliable
+ identify scanning lines, VBI acquisition may not require this
+ information.
+ * - __u32
+ - ``count``\ [#f2]_
+ - The number of lines in the first and second field image,
+ respectively.
+ * - :cspan:`2`
+
+ Drivers should be as flexibility as possible. For example, it may
+ be possible to extend or move the VBI capture window down to the
+ picture area, implementing a 'full field mode' to capture data
+ service transmissions embedded in the picture.
+
+ An application can set the first or second ``count`` value to zero
+ if no data is required from the respective field; ``count``\ [1]
+ if the scanning system is progressive, i. e. not interlaced. The
+ corresponding start value shall be ignored by the application and
+ driver. Anyway, drivers may not support single field capturing and
+ return both count values non-zero.
+
+ Both ``count`` values set to zero, or line numbers are outside the
+ bounds depicted\ [#f4]_, or a field image covering lines of two
+ fields, are invalid and shall not be returned by the driver.
+
+ To initialize the ``start`` and ``count`` fields, applications
+ must first determine the current video standard selection. The
+ :ref:`v4l2_std_id <v4l2-std-id>` or the ``framelines`` field
+ of struct :c:type:`v4l2_standard` can be evaluated
+ for this purpose.
+ * - __u32
+ - ``flags``
+ - See :ref:`vbifmt-flags` below. Currently only drivers set flags,
+ applications must set this field to zero.
+ * - __u32
+ - ``reserved``\ [#f2]_
+ - This array is reserved for future extensions. Drivers and
+ applications must set it to zero.
+.. tabularcolumns:: |p{4.0cm}|p{1.5cm}|p{12.0cm}|
.. _vbifmt-flags:
-.. tabularcolumns:: |p{4.0cm}|p{1.5cm}|p{12.0cm}|
-
.. flat-table:: Raw VBI Format Flags
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
-
- - .. row 1
-
- - ``V4L2_VBI_UNSYNC``
-
- - 0x0001
-
- - This flag indicates hardware which does not properly distinguish
- between fields. Normally the VBI image stores the first field
- (lower scanning line numbers) first in memory. This may be a top
- or bottom field depending on the video standard. When this flag is
- set the first or second field may be stored first, however the
- fields are still in correct temporal order with the older field
- first in memory. [#f3]_
-
- - .. row 2
-
- - ``V4L2_VBI_INTERLACED``
-
- - 0x0002
-
- - By default the two field images will be passed sequentially; all
- lines of the first field followed by all lines of the second field
- (compare :ref:`field-order` ``V4L2_FIELD_SEQ_TB`` and
- ``V4L2_FIELD_SEQ_BT``, whether the top or bottom field is first in
- memory depends on the video standard). When this flag is set, the
- two fields are interlaced (cf. ``V4L2_FIELD_INTERLACED``). The
- first line of the first field followed by the first line of the
- second field, then the two second lines, and so on. Such a layout
- may be necessary when the hardware has been programmed to capture
- or output interlaced video images and is unable to separate the
- fields for VBI capturing at the same time. For simplicity setting
- this flag implies that both ``count`` values are equal and
- non-zero.
+ * - ``V4L2_VBI_UNSYNC``
+ - 0x0001
+ - This flag indicates hardware which does not properly distinguish
+ between fields. Normally the VBI image stores the first field
+ (lower scanning line numbers) first in memory. This may be a top
+ or bottom field depending on the video standard. When this flag is
+ set the first or second field may be stored first, however the
+ fields are still in correct temporal order with the older field
+ first in memory. [#f3]_
+ * - ``V4L2_VBI_INTERLACED``
+ - 0x0002
+ - By default the two field images will be passed sequentially; all
+ lines of the first field followed by all lines of the second field
+ (compare :ref:`field-order` ``V4L2_FIELD_SEQ_TB`` and
+ ``V4L2_FIELD_SEQ_BT``, whether the top or bottom field is first in
+ memory depends on the video standard). When this flag is set, the
+ two fields are interlaced (cf. ``V4L2_FIELD_INTERLACED``). The
+ first line of the first field followed by the first line of the
+ second field, then the two second lines, and so on. Such a layout
+ may be necessary when the hardware has been programmed to capture
+ or output interlaced video images and is unable to separate the
+ fields for VBI capturing at the same time. For simplicity setting
+ this flag implies that both ``count`` values are equal and
+ non-zero.
projects / cascardo / linux.git / blobdiff