Commit c2b66caf authored by Laurent Pinchart's avatar Laurent Pinchart Committed by Mauro Carvalho Chehab

[media] v4l: doc: Remove row numbers from tables

Shorten the tables by removing row numbers in comments, allowing for
later insertion of rows with minimal diffs.

All changes have been generated by the following script.

import io
import re
import sys

def process_table(fname, data):
	if fname.endswith('hist-v4l2.rst'):
		data = re.sub(u'\n{1,2}\t( ?)  -( ?) ?', u'\n\t\\1 -\\2', data, flags = re.MULTILINE)
		data = re.sub(u'\n(\t|       )-  \.\. row [0-9]+\n\t  ?-( ?) ?', u'\\1* -\\2', data, flags = re.MULTILINE)
	else:
		data = re.sub(u'\n{1,2}       -( ?) ?', u'\n      -\\1', data, flags = re.MULTILINE)
		data = re.sub(u'(\n?)(\n\n    -  \.\. row 1\n)', u'\n\\2', data, flags = re.MULTILINE)
		data = re.sub(u'\n    -  \.\. row [0-9]+\n      -( ?) ?', u'    * -\\1', data, flags = re.MULTILINE)
		data = re.sub(u'\n    -  \.\. row [0-9]+\n       \.\. (_[A-Z0-9_`-]*:)', u'\n    -  .. \\1', data, flags = re.MULTILINE)
		data = re.sub(u'\n    -  \.\. (_[A-Z0-9_`-]*:)\n      -', u'    * .. \\1\n\n      -', data, flags = re.MULTILINE)
		data = re.sub(u'^       - ', u'      -', data, flags = re.MULTILINE)
		data = re.sub(u'^(\t{1,2})  ', u'\\1', data, flags = re.MULTILINE)

	return data

def process_file(fname, data):
	buf = io.StringIO(data)
	output = ''
	in_table = False
	table_separator = 0

	for line in buf.readlines():
		if line.find('.. flat-table::') != -1:
			in_table = True
			table = ''
		elif in_table and not re.match('^[\t\n]|(    )', line):
			in_table = False
			output += process_table(fname, table)

		if in_table:
			table += line
		else:
			output += line

	if in_table:
		in_table = False
		output += process_table(fname, table)

	return output

fname = sys.argv[1]

data = file(fname, 'rb').read().decode('utf-8')
data = process_file(fname, data)
file(fname, 'wb').write(data.encode('utf-8'))
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
parent c1958488
This diff is collapsed.
......@@ -198,104 +198,41 @@ Control IDs
:stub-columns: 0
:widths: 11 24
- .. row 1
- ``V4L2_COLORFX_NONE``
- Color effect is disabled.
- .. row 2
- ``V4L2_COLORFX_ANTIQUE``
- An aging (old photo) effect.
- .. row 3
- ``V4L2_COLORFX_ART_FREEZE``
- Frost color effect.
- .. row 4
- ``V4L2_COLORFX_AQUA``
- Water color, cool tone.
- .. row 5
- ``V4L2_COLORFX_BW``
- Black and white.
- .. row 6
- ``V4L2_COLORFX_EMBOSS``
- Emboss, the highlights and shadows replace light/dark boundaries
and low contrast areas are set to a gray background.
- .. row 7
- ``V4L2_COLORFX_GRASS_GREEN``
- Grass green.
- .. row 8
- ``V4L2_COLORFX_NEGATIVE``
- Negative.
- .. row 9
- ``V4L2_COLORFX_SEPIA``
- Sepia tone.
- .. row 10
- ``V4L2_COLORFX_SKETCH``
- Sketch.
- .. row 11
- ``V4L2_COLORFX_SKIN_WHITEN``
- Skin whiten.
- .. row 12
- ``V4L2_COLORFX_SKY_BLUE``
- Sky blue.
- .. row 13
- ``V4L2_COLORFX_SOLARIZATION``
- Solarization, the image is partially reversed in tone, only color
values above or below a certain threshold are inverted.
- .. row 14
- ``V4L2_COLORFX_SILHOUETTE``
- Silhouette (outline).
- .. row 15
- ``V4L2_COLORFX_VIVID``
- Vivid colors.
- .. row 16
- ``V4L2_COLORFX_SET_CBCR``
- The Cb and Cr chroma components are replaced by fixed coefficients
determined by ``V4L2_CID_COLORFX_CBCR`` control.
* - ``V4L2_COLORFX_NONE``
- Color effect is disabled.
* - ``V4L2_COLORFX_ANTIQUE``
- An aging (old photo) effect.
* - ``V4L2_COLORFX_ART_FREEZE``
- Frost color effect.
* - ``V4L2_COLORFX_AQUA``
- Water color, cool tone.
* - ``V4L2_COLORFX_BW``
- Black and white.
* - ``V4L2_COLORFX_EMBOSS``
- Emboss, the highlights and shadows replace light/dark boundaries
and low contrast areas are set to a gray background.
* - ``V4L2_COLORFX_GRASS_GREEN``
- Grass green.
* - ``V4L2_COLORFX_NEGATIVE``
- Negative.
* - ``V4L2_COLORFX_SEPIA``
- Sepia tone.
* - ``V4L2_COLORFX_SKETCH``
- Sketch.
* - ``V4L2_COLORFX_SKIN_WHITEN``
- Skin whiten.
* - ``V4L2_COLORFX_SKY_BLUE``
- Sky blue.
* - ``V4L2_COLORFX_SOLARIZATION``
- Solarization, the image is partially reversed in tone, only color
values above or below a certain threshold are inverted.
* - ``V4L2_COLORFX_SILHOUETTE``
- Silhouette (outline).
* - ``V4L2_COLORFX_VIVID``
- Vivid colors.
* - ``V4L2_COLORFX_SET_CBCR``
- The Cb and Cr chroma components are replaced by fixed coefficients
determined by ``V4L2_CID_COLORFX_CBCR`` control.
......
......@@ -110,120 +110,77 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
: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 :c:type:`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}|
......@@ -235,40 +192,30 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
: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.
......
......@@ -102,30 +102,15 @@ RDS datastructures
:stub-columns: 0
:widths: 1 1 5
- .. row 1
- __u8
- ``lsb``
- Least Significant Byte of RDS Block
- .. row 2
- __u8
- ``msb``
- Most Significant Byte of RDS Block
- .. row 3
- __u8
- ``block``
- Block description
* - __u8
- ``lsb``
- Least Significant Byte of RDS Block
* - __u8
- ``msb``
- Most Significant Byte of RDS Block
* - __u8
- ``block``
- Block description
......@@ -138,33 +123,17 @@ RDS datastructures
:stub-columns: 0
:widths: 1 5
- .. row 1
- Bits 0-2
- Block (aka offset) of the received data.
- .. row 2
- Bits 3-5
- Deprecated. Currently identical to bits 0-2. Do not use these
bits.
- .. row 3
- Bit 6
- Corrected bit. Indicates that an error was corrected for this data
block.
- .. row 4
- Bit 7
- Error bit. Indicates that an uncorrectable error occurred during
reception of this block.
* - Bits 0-2
- Block (aka offset) of the received data.
* - Bits 3-5
- Deprecated. Currently identical to bits 0-2. Do not use these
bits.
* - Bit 6
- Corrected bit. Indicates that an error was corrected for this data
block.
* - Bit 7
- Error bit. Indicates that an uncorrectable error occurred during
reception of this block.
......@@ -177,87 +146,39 @@ RDS datastructures
:stub-columns: 0
:widths: 1 1 1 5
- .. row 1
- V4L2_RDS_BLOCK_MSK
-
- 7
- Mask for bits 0-2 to get the block ID.
- .. row 2
- V4L2_RDS_BLOCK_A
-
- 0
- Block A.
- .. row 3
- V4L2_RDS_BLOCK_B
-
- 1
- Block B.
- .. row 4
- V4L2_RDS_BLOCK_C
-
- 2
- Block C.
- .. row 5
- V4L2_RDS_BLOCK_D
-
- 3
- Block D.
- .. row 6
- V4L2_RDS_BLOCK_C_ALT
-
- 4
- Block C'.
- .. row 7
- V4L2_RDS_BLOCK_INVALID
- read-only
- 7
- An invalid block.
- .. row 8
- V4L2_RDS_BLOCK_CORRECTED
- read-only
- 0x40
- A bit error was detected but corrected.
- .. row 9
- V4L2_RDS_BLOCK_ERROR
- read-only
- 0x80
- An uncorrectable error occurred.
* - V4L2_RDS_BLOCK_MSK
-
- 7
- Mask for bits 0-2 to get the block ID.
* - V4L2_RDS_BLOCK_A
-
- 0
- Block A.
* - V4L2_RDS_BLOCK_B
-
- 1
- Block B.
* - V4L2_RDS_BLOCK_C
-
- 2
- Block C.
* - V4L2_RDS_BLOCK_D
-
- 3
- Block D.
* - V4L2_RDS_BLOCK_C_ALT
-
- 4
- Block C'.
* - V4L2_RDS_BLOCK_INVALID
- read-only
- 7
- An invalid block.
* - V4L2_RDS_BLOCK_CORRECTED
- read-only
- 0x40
- A bit error was detected but corrected.
* - V4L2_RDS_BLOCK_ERROR
- read-only
- 0x80
- An uncorrectable error occurred.
......@@ -87,35 +87,20 @@ data transfer, set by the driver in order to inform application.
:stub-columns: 0
:widths: 1 1 2
- .. row 1
- __u32
- ``pixelformat``
- The data format or type of compression, set by the application.
This is a little endian
:ref:`four character code <v4l2-fourcc>`. V4L2 defines SDR
formats in :ref:`sdr-formats`.
- .. row 2
- __u32
- ``buffersize``
- Maximum size in bytes required for data. Value is set by the
driver.
- .. row 3
- __u8
- ``reserved[24]``
- This array is reserved for future extensions. Drivers and
applications must set it to zero.
* - __u32
- ``pixelformat``
- The data format or type of compression, set by the application.
This is a little endian
:ref:`four character code <v4l2-fourcc>`. V4L2 defines SDR
formats in :ref:`sdr-formats`.
* - __u32
- ``buffersize``
- Maximum size in bytes required for data. Value is set by the
driver.
* - __u8
- ``reserved[24]``
- This array is reserved for future extensions. Drivers and
applications must set it to zero.
An SDR device may support :ref:`read/write <rw>` and/or streaming
......
......@@ -215,85 +215,41 @@ list entity names and pad numbers).
:stub-columns: 0
:widths: 5 5 5 5 5 5 5
- .. row 1
-
- Sensor/0 format
- Frontend/0 format
- Frontend/1 format
- Scaler/0 format
- Scaler/0 compose selection rectangle
- Scaler/1 format
- .. row 2
- Initial state
- 2048x1536/SGRBG8_1X8
- (default)
- (default)
- (default)
- (default)
- (default)
- .. row 3
- Configure frontend sink format
- 2048x1536/SGRBG8_1X8
- *2048x1536/SGRBG8_1X8*
- *2046x1534/SGRBG8_1X8*
- (default)
- (default)
- (default)
- .. row 4
- Configure scaler sink format
- 2048x1536/SGRBG8_1X8
- 2048x1536/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- *2046x1534/SGRBG8_1X8*
- *0,0/2046x1534*
- *2046x1534/SGRBG8_1X8*
- .. row 5
- Configure scaler sink compose selection
- 2048x1536/SGRBG8_1X8
- 2048x1536/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- *0,0/1280x960*
- *1280x960/SGRBG8_1X8*
* -
- Sensor/0 format
- Frontend/0 format
- Frontend/1 format
- Scaler/0 format
- Scaler/0 compose selection rectangle
- Scaler/1 format
* - Initial state
- 2048x1536/SGRBG8_1X8
- (default)
- (default)
- (default)
- (default)
- (default)
* - Configure frontend sink format
- 2048x1536/SGRBG8_1X8
- *2048x1536/SGRBG8_1X8*
- *2046x1534/SGRBG8_1X8*
- (default)
- (default)
- (default)
* - Configure scaler sink format
- 2048x1536/SGRBG8_1X8
- 2048x1536/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- *2046x1534/SGRBG8_1X8*
- *0,0/2046x1534*
- *2046x1534/SGRBG8_1X8*
* - Configure scaler sink compose selection
- 2048x1536/SGRBG8_1X8
- 2048x1536/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- 2046x1534/SGRBG8_1X8
- *0,0/1280x960*
- *1280x960/SGRBG8_1X8*
.. raw:: latex
......
This diff is collapsed.
......@@ -64,125 +64,75 @@ enum v4l2_field
:stub-columns: 0
:widths: 3 1 4
- .. row 1
- ``V4L2_FIELD_ANY``
- 0
- Applications request this field order when any one of the
``V4L2_FIELD_NONE``, ``V4L2_FIELD_TOP``, ``V4L2_FIELD_BOTTOM``, or
``V4L2_FIELD_INTERLACED`` formats is acceptable. Drivers choose
depending on hardware capabilities or e. g. the requested image
size, and return the actual field order. Drivers must never return
``V4L2_FIELD_ANY``. If multiple field orders are possible the
driver must choose one of the possible field orders during
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
:c:type:`v4l2_buffer` ``field`` can never be
``V4L2_FIELD_ANY``.
- .. row 2
- ``V4L2_FIELD_NONE``
- 1
- Images are in progressive format, not interlaced. The driver may
also indicate this order when it cannot distinguish between
``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM``.
- .. row 3
- ``V4L2_FIELD_TOP``
- 2
- Images consist of the top (aka odd) field only.
- .. row 4
- ``V4L2_FIELD_BOTTOM``
- 3
- Images consist of the bottom (aka even) field only. Applications
may wish to prevent a device from capturing interlaced images
because they will have "comb" or "feathering" artefacts around
moving objects.
- .. row 5
- ``V4L2_FIELD_INTERLACED``
- 4
- Images contain both fields, interleaved line by line. The temporal
order of the fields (whether the top or bottom field is first
transmitted) depends on the current video standard. M/NTSC
transmits the bottom field first, all other standards the top
field first.
- .. row 6
- ``V4L2_FIELD_SEQ_TB``
- 5
- Images contain both fields, the top field lines are stored first
in memory, immediately followed by the bottom field lines. Fields
are always stored in temporal order, the older one first in
memory. Image sizes refer to the frame, not fields.
- .. row 7
- ``V4L2_FIELD_SEQ_BT``
- 6
- Images contain both fields, the bottom field lines are stored
first in memory, immediately followed by the top field lines.
Fields are always stored in temporal order, the older one first in
memory. Image sizes refer to the frame, not fields.
- .. row 8
- ``V4L2_FIELD_ALTERNATE``
- 7
- The two fields of a frame are passed in separate buffers, in
temporal order, i. e. the older one first. To indicate the field
parity (whether the current field is a top or bottom field) the
driver or application, depending on data direction, must set
struct :c:type:`v4l2_buffer` ``field`` to
``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
fields pair to build a frame. If fields are successive, without
any dropped fields between them (fields can drop individually),
can be determined from the struct
:c:type:`v4l2_buffer` ``sequence`` field. This
format cannot be selected when using the read/write I/O method
since there is no way to communicate if a field was a top or
bottom field.
- .. row 9
- ``V4L2_FIELD_INTERLACED_TB``
- 8
- Images contain both fields, interleaved line by line, top field
first. The top field is transmitted first.
- .. row 10
- ``V4L2_FIELD_INTERLACED_BT``
- 9
- Images contain both fields, interleaved line by line, top field
first. The bottom field is transmitted first.
* - ``V4L2_FIELD_ANY``
- 0
- Applications request this field order when any one of the
``V4L2_FIELD_NONE``, ``V4L2_FIELD_TOP``, ``V4L2_FIELD_BOTTOM``, or
``V4L2_FIELD_INTERLACED`` formats is acceptable. Drivers choose
depending on hardware capabilities or e. g. the requested image
size, and return the actual field order. Drivers must never return
``V4L2_FIELD_ANY``. If multiple field orders are possible the
driver must choose one of the possible field orders during
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
:c:type:`v4l2_buffer` ``field`` can never be
``V4L2_FIELD_ANY``.
* - ``V4L2_FIELD_NONE``
- 1
- Images are in progressive format, not interlaced. The driver may
also indicate this order when it cannot distinguish between
``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM``.
* - ``V4L2_FIELD_TOP``
- 2
- Images consist of the top (aka odd) field only.
* - ``V4L2_FIELD_BOTTOM``
- 3
- Images consist of the bottom (aka even) field only. Applications
may wish to prevent a device from capturing interlaced images
because they will have "comb" or "feathering" artefacts around
moving objects.
* - ``V4L2_FIELD_INTERLACED``
- 4
- Images contain both fields, interleaved line by line. The temporal
order of the fields (whether the top or bottom field is first
transmitted) depends on the current video standard. M/NTSC
transmits the bottom field first, all other standards the top
field first.
* - ``V4L2_FIELD_SEQ_TB``
- 5
- Images contain both fields, the top field lines are stored first
in memory, immediately followed by the bottom field lines. Fields
are always stored in temporal order, the older one first in
memory. Image sizes refer to the frame, not fields.
* - ``V4L2_FIELD_SEQ_BT``
- 6
- Images contain both fields, the bottom field lines are stored
first in memory, immediately followed by the top field lines.
Fields are always stored in temporal order, the older one first in
memory. Image sizes refer to the frame, not fields.
* - ``V4L2_FIELD_ALTERNATE``
- 7
- The two fields of a frame are passed in separate buffers, in
temporal order, i. e. the older one first. To indicate the field
parity (whether the current field is a top or bottom field) the
driver or application, depending on data direction, must set
struct :c:type:`v4l2_buffer` ``field`` to
``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
fields pair to build a frame. If fields are successive, without
any dropped fields between them (fields can drop individually),
can be determined from the struct
:c:type:`v4l2_buffer` ``sequence`` field. This
format cannot be selected when using the read/write I/O method
since there is no way to communicate if a field was a top or
bottom field.
* - ``V4L2_FIELD_INTERLACED_TB``
- 8
- Images contain both fields, interleaved line by line, top field
first. The top field is transmitted first.
* - ``V4L2_FIELD_INTERLACED_BT``
- 9
- Images contain both fields, interleaved line by line, top field
first. The bottom field is transmitted first.
......
......@@ -447,90 +447,34 @@ This unnamed version was finally merged into Linux 2.5.46.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Old defines
- enum :c:type:`v4l2_buf_type`
- .. row 2
- ``V4L2_BUF_TYPE_CAPTURE``
- ``V4L2_BUF_TYPE_VIDEO_CAPTURE``
- .. row 3
- ``V4L2_BUF_TYPE_CODECIN``
- Omitted for now
- .. row 4
- ``V4L2_BUF_TYPE_CODECOUT``
- Omitted for now
- .. row 5
- ``V4L2_BUF_TYPE_EFFECTSIN``
- Omitted for now
- .. row 6
- ``V4L2_BUF_TYPE_EFFECTSIN2``
- Omitted for now
- .. row 7
- ``V4L2_BUF_TYPE_EFFECTSOUT``
- Omitted for now
- .. row 8
- ``V4L2_BUF_TYPE_VIDEOOUT``
- ``V4L2_BUF_TYPE_VIDEO_OUTPUT``
- .. row 9
- ``-``
- ``V4L2_BUF_TYPE_VIDEO_OVERLAY``
- .. row 10
- ``-``
- ``V4L2_BUF_TYPE_VBI_CAPTURE``
- .. row 11
- ``-``
- ``V4L2_BUF_TYPE_VBI_OUTPUT``
- .. row 12
- ``-``
- ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE``
- .. row 13
- ``-``
- ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT``
- .. row 14
- ``V4L2_BUF_TYPE_PRIVATE_BASE``
- ``V4L2_BUF_TYPE_PRIVATE`` (but this is deprecated)
* - Old defines
- enum :c:type:`v4l2_buf_type`
* - ``V4L2_BUF_TYPE_CAPTURE``
- ``V4L2_BUF_TYPE_VIDEO_CAPTURE``
* - ``V4L2_BUF_TYPE_CODECIN``
- Omitted for now
* - ``V4L2_BUF_TYPE_CODECOUT``
- Omitted for now
* - ``V4L2_BUF_TYPE_EFFECTSIN``
- Omitted for now
* - ``V4L2_BUF_TYPE_EFFECTSIN2``
- Omitted for now
* - ``V4L2_BUF_TYPE_EFFECTSOUT``
- Omitted for now
* - ``V4L2_BUF_TYPE_VIDEOOUT``
- ``V4L2_BUF_TYPE_VIDEO_OUTPUT``
* - ``-``
- ``V4L2_BUF_TYPE_VIDEO_OVERLAY``
* - ``-``
- ``V4L2_BUF_TYPE_VBI_CAPTURE``
* - ``-``
- ``V4L2_BUF_TYPE_VBI_OUTPUT``
* - ``-``
- ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE``
* - ``-``
- ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT``
* - ``V4L2_BUF_TYPE_PRIVATE_BASE``
- ``V4L2_BUF_TYPE_PRIVATE`` (but this is deprecated)
10. In struct :c:type:`v4l2_fmtdesc` a enum
......@@ -564,54 +508,22 @@ This unnamed version was finally merged into Linux 2.5.46.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Old flag
- enum :c:type:`v4l2_field`
- .. row 2
- ``V4L2_FMT_FLAG_NOT_INTERLACED``
- ?
- .. row 3
- ``V4L2_FMT_FLAG_INTERLACED`` = ``V4L2_FMT_FLAG_COMBINED``
- ``V4L2_FIELD_INTERLACED``
- .. row 4
- ``V4L2_FMT_FLAG_TOPFIELD`` = ``V4L2_FMT_FLAG_ODDFIELD``
- ``V4L2_FIELD_TOP``
- .. row 5
- ``V4L2_FMT_FLAG_BOTFIELD`` = ``V4L2_FMT_FLAG_EVENFIELD``
- ``V4L2_FIELD_BOTTOM``
- .. row 6
- ``-``
- ``V4L2_FIELD_SEQ_TB``
- .. row 7
- ``-``
- ``V4L2_FIELD_SEQ_BT``
- .. row 8
- ``-``
- ``V4L2_FIELD_ALTERNATE``
* - Old flag
- enum :c:type:`v4l2_field`
* - ``V4L2_FMT_FLAG_NOT_INTERLACED``
- ?
* - ``V4L2_FMT_FLAG_INTERLACED`` = ``V4L2_FMT_FLAG_COMBINED``
- ``V4L2_FIELD_INTERLACED``
* - ``V4L2_FMT_FLAG_TOPFIELD`` = ``V4L2_FMT_FLAG_ODDFIELD``
- ``V4L2_FIELD_TOP``
* - ``V4L2_FMT_FLAG_BOTFIELD`` = ``V4L2_FMT_FLAG_EVENFIELD``
- ``V4L2_FIELD_BOTTOM``
* - ``-``
- ``V4L2_FIELD_SEQ_TB``
* - ``-``
- ``V4L2_FIELD_SEQ_BT``
* - ``-``
- ``V4L2_FIELD_ALTERNATE``
The color space flags were replaced by a enum
......@@ -768,46 +680,21 @@ V4L2 2003-11-05
:header-rows: 1
:stub-columns: 0
- .. row 1
- Symbol
- In this document prior to revision 0.5
- Corrected
- .. row 2
- ``V4L2_PIX_FMT_RGB24``
- B, G, R
- R, G, B
- .. row 3
- ``V4L2_PIX_FMT_BGR24``
- R, G, B
- B, G, R
- .. row 4
- ``V4L2_PIX_FMT_RGB32``
- B, G, R, X
- R, G, B, X
- .. row 5
- ``V4L2_PIX_FMT_BGR32``
- R, G, B, X
- B, G, R, X
* - Symbol
- In this document prior to revision 0.5
- Corrected
* - ``V4L2_PIX_FMT_RGB24``
- B, G, R
- R, G, B
* - ``V4L2_PIX_FMT_BGR24``
- R, G, B
- B, G, R
* - ``V4L2_PIX_FMT_RGB32``
- B, G, R, X
- R, G, B, X
* - ``V4L2_PIX_FMT_BGR32``
- R, G, B, X
- B, G, R, X
The ``V4L2_PIX_FMT_BGR24`` example was always correct.
......
This diff is collapsed.
......@@ -21,32 +21,17 @@ describing all planes of that format.
:stub-columns: 0
:widths: 1 1 2
- .. row 1
- __u32
- ``sizeimage``
- Maximum size in bytes required for image data in this plane.
- .. row 2
- __u32
- ``bytesperline``
- Distance in bytes between the leftmost pixels in two adjacent
lines. See struct :c:type:`v4l2_pix_format`.
- .. row 3
- __u16
- ``reserved[6]``
- Reserved for future extensions. Should be zeroed by drivers and
applications.
* - __u32
- ``sizeimage``
- Maximum size in bytes required for image data in this plane.
* - __u32
- ``bytesperline``
- Distance in bytes between the leftmost pixels in two adjacent
lines. See struct :c:type:`v4l2_pix_format`.
* - __u16
- ``reserved[6]``
- Reserved for future extensions. Should be zeroed by drivers and
applications.
.. tabularcolumns:: |p{4.4cm}|p{5.6cm}|p{7.5cm}|
......@@ -58,112 +43,52 @@ describing all planes of that format.
:stub-columns: 0
:widths: 1 1 2
- .. row 1
- __u32
- ``width``
- Image width in pixels. See struct
:c:type:`v4l2_pix_format`.
- .. row 2
- __u32
- ``height``
- Image height in pixels. See struct
:c:type:`v4l2_pix_format`.
- .. row 3
- __u32
- ``pixelformat``
- The pixel format. Both single- and multi-planar four character
codes can be used.
- .. row 4
- enum :c:type:`v4l2_field`
- ``field``
- See struct :c:type:`v4l2_pix_format`.
- .. row 5
- enum :c:type:`v4l2_colorspace`
- ``colorspace``
- See struct :c:type:`v4l2_pix_format`.
- .. row 6
- struct :c:type:`v4l2_plane_pix_format`
- ``plane_fmt[VIDEO_MAX_PLANES]``
- An array of structures describing format of each plane this pixel
format consists of. The number of valid entries in this array has
to be put in the ``num_planes`` field.
- .. row 7
- __u8
- ``num_planes``
- Number of planes (i.e. separate memory buffers) for this format
and the number of valid entries in the ``plane_fmt`` array.
- .. row 8
- __u8
- ``flags``
- Flags set by the application or driver, see :ref:`format-flags`.
- .. row 9
- enum :c:type:`v4l2_ycbcr_encoding`
- ``ycbcr_enc``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
- .. row 10
- enum :c:type:`v4l2_quantization`
- ``quantization``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
- .. row 11
- enum :c:type:`v4l2_xfer_func`
- ``xfer_func``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
- .. row 12
- __u8
- ``reserved[7]``
- Reserved for future extensions. Should be zeroed by drivers and
applications.
* - __u32
- ``width``
- Image width in pixels. See struct
:c:type:`v4l2_pix_format`.
* - __u32
- ``height``
- Image height in pixels. See struct
:c:type:`v4l2_pix_format`.
* - __u32
- ``pixelformat``
- The pixel format. Both single- and multi-planar four character
codes can be used.
* - enum :c:type:`v4l2_field`
- ``field``
- See struct :c:type:`v4l2_pix_format`.
* - enum :c:type:`v4l2_colorspace`
- ``colorspace``
- See struct :c:type:`v4l2_pix_format`.
* - struct :c:type:`v4l2_plane_pix_format`
- ``plane_fmt[VIDEO_MAX_PLANES]``
- An array of structures describing format of each plane this pixel
format consists of. The number of valid entries in this array has
to be put in the ``num_planes`` field.
* - __u8
- ``num_planes``
- Number of planes (i.e. separate memory buffers) for this format
and the number of valid entries in the ``plane_fmt`` array.
* - __u8
- ``flags``
- Flags set by the application or driver, see :ref:`format-flags`.
* - enum :c:type:`v4l2_ycbcr_encoding`
- ``ycbcr_enc``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
* - enum :c:type:`v4l2_quantization`
- ``quantization``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
* - enum :c:type:`v4l2_xfer_func`
- ``xfer_func``
- This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
* - __u8
- ``reserved[7]``
- Reserved for future extensions. Should be zeroed by drivers and
applications.
......@@ -33,89 +33,37 @@ needs to be filled in.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Identifier
- Details
- .. row 2
- ``V4L2_COLORSPACE_DEFAULT``
- The default colorspace. This can be used by applications to let
the driver fill in the colorspace.
- .. row 3
- ``V4L2_COLORSPACE_SMPTE170M``
- See :ref:`col-smpte-170m`.
- .. row 4
- ``V4L2_COLORSPACE_REC709``
- See :ref:`col-rec709`.
- .. row 5
- ``V4L2_COLORSPACE_SRGB``
- See :ref:`col-srgb`.
- .. row 6
- ``V4L2_COLORSPACE_ADOBERGB``
- See :ref:`col-adobergb`.
- .. row 7
- ``V4L2_COLORSPACE_BT2020``
- See :ref:`col-bt2020`.
- .. row 8
- ``V4L2_COLORSPACE_DCI_P3``
- See :ref:`col-dcip3`.
- .. row 9
- ``V4L2_COLORSPACE_SMPTE240M``
- See :ref:`col-smpte-240m`.
- .. row 10
- ``V4L2_COLORSPACE_470_SYSTEM_M``
- See :ref:`col-sysm`.
- .. row 11
- ``V4L2_COLORSPACE_470_SYSTEM_BG``
- See :ref:`col-sysbg`.
- .. row 12
- ``V4L2_COLORSPACE_JPEG``
- See :ref:`col-jpeg`.
- .. row 13
- ``V4L2_COLORSPACE_RAW``
- The raw colorspace. This is used for raw image capture where the
image is minimally processed and is using the internal colorspace
of the device. The software that processes an image using this
'colorspace' will have to know the internals of the capture
device.
* - Identifier
- Details
* - ``V4L2_COLORSPACE_DEFAULT``
- The default colorspace. This can be used by applications to let
the driver fill in the colorspace.
* - ``V4L2_COLORSPACE_SMPTE170M``
- See :ref:`col-smpte-170m`.
* - ``V4L2_COLORSPACE_REC709``
- See :ref:`col-rec709`.
* - ``V4L2_COLORSPACE_SRGB``
- See :ref:`col-srgb`.
* - ``V4L2_COLORSPACE_ADOBERGB``
- See :ref:`col-adobergb`.
* - ``V4L2_COLORSPACE_BT2020``
- See :ref:`col-bt2020`.
* - ``V4L2_COLORSPACE_DCI_P3``
- See :ref:`col-dcip3`.
* - ``V4L2_COLORSPACE_SMPTE240M``
- See :ref:`col-smpte-240m`.
* - ``V4L2_COLORSPACE_470_SYSTEM_M``
- See :ref:`col-sysm`.
* - ``V4L2_COLORSPACE_470_SYSTEM_BG``
- See :ref:`col-sysbg`.
* - ``V4L2_COLORSPACE_JPEG``
- See :ref:`col-jpeg`.
* - ``V4L2_COLORSPACE_RAW``
- The raw colorspace. This is used for raw image capture where the
image is minimally processed and is using the internal colorspace
of the device. The software that processes an image using this
'colorspace' will have to know the internals of the capture
device.
......@@ -125,60 +73,24 @@ needs to be filled in.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Identifier
- Details
- .. row 2
- ``V4L2_XFER_FUNC_DEFAULT``
- Use the default transfer function as defined by the colorspace.
- .. row 3
- ``V4L2_XFER_FUNC_709``
- Use the Rec. 709 transfer function.
- .. row 4
- ``V4L2_XFER_FUNC_SRGB``
- Use the sRGB transfer function.
- .. row 5
- ``V4L2_XFER_FUNC_ADOBERGB``
- Use the AdobeRGB transfer function.
- .. row 6
- ``V4L2_XFER_FUNC_SMPTE240M``
- Use the SMPTE 240M transfer function.
- .. row 7
- ``V4L2_XFER_FUNC_NONE``
- Do not use a transfer function (i.e. use linear RGB values).
- .. row 8
- ``V4L2_XFER_FUNC_DCI_P3``
- Use the DCI-P3 transfer function.
- .. row 9
- ``V4L2_XFER_FUNC_SMPTE2084``
- Use the SMPTE 2084 transfer function.
* - Identifier
- Details
* - ``V4L2_XFER_FUNC_DEFAULT``
- Use the default transfer function as defined by the colorspace.
* - ``V4L2_XFER_FUNC_709``
- Use the Rec. 709 transfer function.
* - ``V4L2_XFER_FUNC_SRGB``
- Use the sRGB transfer function.
* - ``V4L2_XFER_FUNC_ADOBERGB``
- Use the AdobeRGB transfer function.
* - ``V4L2_XFER_FUNC_SMPTE240M``
- Use the SMPTE 240M transfer function.
* - ``V4L2_XFER_FUNC_NONE``
- Do not use a transfer function (i.e. use linear RGB values).
* - ``V4L2_XFER_FUNC_DCI_P3``
- Use the DCI-P3 transfer function.
* - ``V4L2_XFER_FUNC_SMPTE2084``
- Use the SMPTE 2084 transfer function.
......@@ -190,60 +102,24 @@ needs to be filled in.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Identifier
- Details
- .. row 2
- ``V4L2_YCBCR_ENC_DEFAULT``
- Use the default Y'CbCr encoding as defined by the colorspace.
- .. row 3
- ``V4L2_YCBCR_ENC_601``
- Use the BT.601 Y'CbCr encoding.
- .. row 4
- ``V4L2_YCBCR_ENC_709``
- Use the Rec. 709 Y'CbCr encoding.
- .. row 5
- ``V4L2_YCBCR_ENC_XV601``
- Use the extended gamut xvYCC BT.601 encoding.
- .. row 6
- ``V4L2_YCBCR_ENC_XV709``
- Use the extended gamut xvYCC Rec. 709 encoding.
- .. row 7
- ``V4L2_YCBCR_ENC_BT2020``
- Use the default non-constant luminance BT.2020 Y'CbCr encoding.
- .. row 8
- ``V4L2_YCBCR_ENC_BT2020_CONST_LUM``
- Use the constant luminance BT.2020 Yc'CbcCrc encoding.
- .. row 9
- ``V4L2_YCBCR_ENC_SMPTE_240M``
- Use the SMPTE 240M Y'CbCr encoding.
* - Identifier
- Details
* - ``V4L2_YCBCR_ENC_DEFAULT``
- Use the default Y'CbCr encoding as defined by the colorspace.
* - ``V4L2_YCBCR_ENC_601``
- Use the BT.601 Y'CbCr encoding.
* - ``V4L2_YCBCR_ENC_709``
- Use the Rec. 709 Y'CbCr encoding.
* - ``V4L2_YCBCR_ENC_XV601``
- Use the extended gamut xvYCC BT.601 encoding.
* - ``V4L2_YCBCR_ENC_XV709``
- Use the extended gamut xvYCC Rec. 709 encoding.
* - ``V4L2_YCBCR_ENC_BT2020``
- Use the default non-constant luminance BT.2020 Y'CbCr encoding.
* - ``V4L2_YCBCR_ENC_BT2020_CONST_LUM``
- Use the constant luminance BT.2020 Yc'CbcCrc encoding.
* - ``V4L2_YCBCR_ENC_SMPTE_240M``
- Use the SMPTE 240M Y'CbCr encoding.
......@@ -255,35 +131,19 @@ needs to be filled in.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Identifier
- Details
- .. row 2
- ``V4L2_QUANTIZATION_DEFAULT``
- Use the default quantization encoding as defined by the
colorspace. This is always full range for R'G'B' (except for the
BT.2020 colorspace) and usually limited range for Y'CbCr.
- .. row 3
- ``V4L2_QUANTIZATION_FULL_RANGE``
- Use the full range quantization encoding. I.e. the range [0…1] is
mapped to [0…255] (with possible clipping to [1…254] to avoid the
0x00 and 0xff values). Cb and Cr are mapped from [-0.5…0.5] to
[0…255] (with possible clipping to [1…254] to avoid the 0x00 and
0xff values).
- .. row 4
- ``V4L2_QUANTIZATION_LIM_RANGE``
- Use the limited range quantization encoding. I.e. the range [0…1]
is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to
[16…240].
* - Identifier
- Details
* - ``V4L2_QUANTIZATION_DEFAULT``
- Use the default quantization encoding as defined by the
colorspace. This is always full range for R'G'B' (except for the
BT.2020 colorspace) and usually limited range for Y'CbCr.
* - ``V4L2_QUANTIZATION_FULL_RANGE``
- Use the full range quantization encoding. I.e. the range [0…1] is
mapped to [0…255] (with possible clipping to [1…254] to avoid the
0x00 and 0xff values). Cb and Cr are mapped from [-0.5…0.5] to
[0…255] (with possible clipping to [1…254] to avoid the 0x00 and
0xff values).
* - ``V4L2_QUANTIZATION_LIM_RANGE``
- Use the limited range quantization encoding. I.e. the range [0…1]
is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to
[16…240].
This diff is collapsed.
This diff is collapsed.
......@@ -24,15 +24,7 @@ Each cell is one byte.
:header-rows: 0
:stub-columns: 0
- .. row 1
- start + 0:
- I'\ :sub:`0`
- .. row 2
- start + 1:
- Q'\ :sub:`0`
* - start + 0:
- I'\ :sub:`0`
* - start + 1:
- Q'\ :sub:`0`
......@@ -26,18 +26,9 @@ Each cell is one byte.
:header-rows: 0
:stub-columns: 0
- .. row 1
- start + 0:
- I'\ :sub:`0[7:0]`
- I'\ :sub:`0[13:8]`
- .. row 2
- start + 2:
- Q'\ :sub:`0[7:0]`
- Q'\ :sub:`0[13:8]`
* - start + 0:
- I'\ :sub:`0[7:0]`
- I'\ :sub:`0[13:8]`
* - start + 2:
- Q'\ :sub:`0[7:0]`
- Q'\ :sub:`0[13:8]`
......@@ -24,14 +24,7 @@ Each cell is one byte.
:header-rows: 0
:stub-columns: 0
- .. row 1
- start + 0:
- I'\ :sub:`0`
- .. row 2
- start + 1:
- Q'\ :sub:`0`
* - start + 0:
- I'\ :sub:`0`
* - start + 1:
- Q'\ :sub:`0`
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment