Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 169
Star 36
Fork 7
cloud-kernel
cloud-kernel
提交 c2b66caf 编写于 作者: L Laurent Pinchart 提交者： 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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
上级 c1958488
展开全部 隐藏空白更改
内联 并排
Showing with 15726 addition and 31353 deletion
Documentation/media/uapi/v4l/control.rst
浏览文件 @ c2b66caf
......@@ -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.
......
Documentation/media/uapi/v4l/dev-raw-vbi.rst
浏览文件 @ c2b66caf
......@@ -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.
......
Documentation/media/uapi/v4l/dev-rds.rst
浏览文件 @ c2b66caf
......@@ -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.
Documentation/media/uapi/v4l/dev-sdr.rst
浏览文件 @ c2b66caf
......@@ -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
......
Documentation/media/uapi/v4l/dev-subdev.rst
浏览文件 @ c2b66caf
......@@ -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
......
Documentation/media/uapi/v4l/diff-v4l.rst
浏览文件 @ c2b66caf
......@@ -39,39 +39,19 @@ using driver module options. The major device number remains 81.
:header-rows: 1
:stub-columns: 0
- .. row 1
- Device Type
- File Name
- Minor Numbers
- .. row 2
- Video capture and overlay
- ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
``/dev/video63``
- 0-63
- .. row 3
- Radio receiver
- ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
- 64-127
- .. row 4
- Raw VBI capture
- ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
- 224-255
* - 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.
......@@ -103,148 +83,73 @@ introduction.
:header-rows: 1
:stub-columns: 0
- .. row 1
- ``struct video_capability`` ``type``
- struct :c:type:`v4l2_capability`
``capabilities`` flags
- Purpose
- .. row 2
- ``VID_TYPE_CAPTURE``
- ``V4L2_CAP_VIDEO_CAPTURE``
- The :ref:`video capture <capture>` interface is supported.
- .. row 3
- ``VID_TYPE_TUNER``
- ``V4L2_CAP_TUNER``
- The device has a :ref:`tuner or modulator <tuner>`.
- .. row 4
- ``VID_TYPE_TELETEXT``
- ``V4L2_CAP_VBI_CAPTURE``
- The :ref:`raw VBI capture <raw-vbi>` interface is supported.
- .. row 5
- ``VID_TYPE_OVERLAY``
- ``V4L2_CAP_VIDEO_OVERLAY``
- The :ref:`video overlay <overlay>` interface is supported.
- .. row 6
- ``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`.
- .. row 7
- ``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`.
- .. row 8
- ``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`.
- .. row 9
- ``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`.
- .. row 10
- ``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`.
- .. row 11
- ``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`.
- .. row 12
- ``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.
- .. row 13
- ``VID_TYPE_MPEG_ENCODER``
- ``-``
- See above.
- .. row 14
- ``VID_TYPE_MJPEG_DECODER``
- ``-``
- See above.
- .. row 15
- ``VID_TYPE_MJPEG_ENCODER``
- ``-``
- See above.
* - ``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.
The ``audios`` field was replaced by ``capabilities`` flag
......@@ -280,24 +185,12 @@ video input types were renamed as follows:
:header-rows: 1
:stub-columns: 0
- .. row 1
- struct ``video_channel`` ``type``
- struct :c:type:`v4l2_input` ``type``
- .. row 2
- ``VIDEO_TYPE_TV``
- ``V4L2_INPUT_TYPE_TUNER``
- .. row 3
- ``VIDEO_TYPE_CAMERA``
- ``V4L2_INPUT_TYPE_CAMERA``
* - 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
......@@ -386,42 +279,18 @@ replaced by V4L2 controls accessible with the
:header-rows: 1
:stub-columns: 0
- .. row 1
- struct ``video_picture``
- V4L2 Control ID
- .. row 2
- ``brightness``
- ``V4L2_CID_BRIGHTNESS``
- .. row 3
- ``hue``
- ``V4L2_CID_HUE``
- .. row 4
- ``colour``
- ``V4L2_CID_SATURATION``
- .. row 5
- ``contrast``
- ``V4L2_CID_CONTRAST``
- .. row 6
- ``whiteness``
- ``V4L2_CID_WHITENESS``
* - 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
......@@ -442,108 +311,40 @@ into the struct :c:type:`v4l2_pix_format`:
:header-rows: 1
:stub-columns: 0
- .. row 1
- struct ``video_picture`` ``palette``
- struct :c:type:`v4l2_pix_format` ``pixfmt``
- .. row 2
- ``VIDEO_PALETTE_GREY``
- :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
- .. row 3
- ``VIDEO_PALETTE_HI240``
- :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
- .. row 4
- ``VIDEO_PALETTE_RGB565``
- :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
- .. row 5
- ``VIDEO_PALETTE_RGB555``
- :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
- .. row 6
- ``VIDEO_PALETTE_RGB24``
- :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
- .. row 7
- ``VIDEO_PALETTE_RGB32``
- :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
- .. row 8
- ``VIDEO_PALETTE_YUV422``
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
- .. row 9
- ``VIDEO_PALETTE_YUYV``\ [#f5]_
- :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
- .. row 10
- ``VIDEO_PALETTE_UYVY``
- :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
- .. row 11
- ``VIDEO_PALETTE_YUV420``
- None
- .. row 12
- ``VIDEO_PALETTE_YUV411``
- :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
- .. row 13
- ``VIDEO_PALETTE_RAW``
- None [#f7]_
- .. row 14
- ``VIDEO_PALETTE_YUV422P``
- :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
- .. row 15
- ``VIDEO_PALETTE_YUV411P``
- :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
- .. row 16
- ``VIDEO_PALETTE_YUV420P``
- :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
- .. row 17
- ``VIDEO_PALETTE_YUV410P``
- :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
* - 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
......@@ -588,36 +389,16 @@ The following fields where replaced by V4L2 controls accessible with the
:header-rows: 1
:stub-columns: 0
- .. row 1
- struct ``video_audio``
- V4L2 Control ID
- .. row 2
- ``volume``
- ``V4L2_CID_AUDIO_VOLUME``
- .. row 3
- ``bass``
- ``V4L2_CID_AUDIO_BASS``
- .. row 4
- ``treble``
- ``V4L2_CID_AUDIO_TREBLE``
- .. row 5
- ``balance``
- ``V4L2_CID_AUDIO_BALANCE``
* - 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
......@@ -752,68 +533,49 @@ differences.
:header-rows: 1
:stub-columns: 0
- .. row 1
- V4L
- V4L2
- .. row 2
-
- 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.
- .. row 3
- 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.
- .. row 4
- 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 :ref:`mmap() <func-mmap>` function.
- Buffers are individually mapped. The offset and size of each
buffer can be determined with the
:ref:`VIDIOC_QUERYBUF` ioctl.
- .. row 5
- 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,
:ref:`select() <func-select>` or :ref:`poll() <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.
* - 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 :ref:`mmap() <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,
:ref:`select() <func-select>` or :ref:`poll() <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
......@@ -835,56 +597,24 @@ with the following parameters:
:header-rows: 1
:stub-columns: 0
- .. row 1
- struct :c:type:`v4l2_vbi_format`
- V4L, BTTV driver
- .. row 2
- sampling_rate
- 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
and SECAM (625-line standards)
- .. row 3
- offset
- ?
- .. row 4
- samples_per_line
- 2048
- .. row 5
- sample_format
- V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
integer) contain a frame counter.
- .. row 6
- start[]
- 10, 273 NTSC; 22, 335 PAL and SECAM
- .. row 7
- count[]
- 16, 16 [#f9]_
- .. row 8
- flags
- 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
......
Documentation/media/uapi/v4l/field-order.rst
浏览文件 @ c2b66caf
......@@ -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.
......
Documentation/media/uapi/v4l/hist-v4l2.rst
浏览文件 @ c2b66caf
......@@ -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.
......
Documentation/media/uapi/v4l/pixfmt-002.rst
浏览文件 @ c2b66caf
......@@ -15,185 +15,119 @@ Single-planar format structure
:stub-columns: 0
:widths: 1 1 2
- .. row 1
- __u32
- ``width``
- Image width in pixels.
- .. row 2
- __u32
- ``height``
- Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
refers to the number of lines in the field, otherwise it refers to
the number of lines in the frame (which is twice the field height
for interlaced formats).
- .. row 3
- :cspan:`2` Applications set these fields to request an image
size, drivers return the closest possible values. In case of
planar formats the ``width`` and ``height`` applies to the largest
plane. To avoid ambiguities drivers must return values rounded up
to a multiple of the scale factor of any smaller planes. For
example when the image format is YUV 4:2:0, ``width`` and
``height`` must be multiples of two.
- .. row 4
- __u32
- ``pixelformat``
- The pixel format or type of compression, set by the application.
This is a little endian
:ref:`four character code <v4l2-fourcc>`. V4L2 defines standard
RGB formats in :ref:`rgb-formats`, YUV formats in
:ref:`yuv-formats`, and reserved codes in
:ref:`reserved-formats`
- .. row 5
- enum :c:type::`v4l2_field`
- ``field``
- Video images are typically interlaced. Applications can request to
capture or output only the top or bottom field, or both fields
interlaced or sequentially stored in one buffer or alternating in
separate buffers. Drivers return the actual field order selected.
For more details on fields see :ref:`field-order`.
- .. row 6
- __u32
- ``bytesperline``
- Distance in bytes between the leftmost pixels in two adjacent
lines.
- .. row 7
- :cspan:`2`
Both applications and drivers can set this field to request
padding bytes at the end of each line. Drivers however may ignore
the value requested by the application, returning ``width`` times
bytes per pixel or a larger value required by the hardware. That
implies applications can just set this field to zero to get a
reasonable default.
Video hardware may access padding bytes, therefore they must
reside in accessible memory. Consider cases where padding bytes
after the last line of an image cross a system page boundary.
Input devices may write padding bytes, the value is undefined.
Output devices ignore the contents of padding bytes.
When the image format is planar the ``bytesperline`` value applies
to the first plane and is divided by the same factor as the
``width`` field for the other planes. For example the Cb and Cr
planes of a YUV 4:2:0 image have half as many padding bytes
following each line as the Y plane. To avoid ambiguities drivers
must return a ``bytesperline`` value rounded up to a multiple of
the scale factor.
For compressed formats the ``bytesperline`` value makes no sense.
Applications and drivers must set this to 0 in that case.
- .. row 8
- __u32
- ``sizeimage``
- Size in bytes of the buffer to hold a complete image, set by the
driver. Usually this is ``bytesperline`` times ``height``. When
the image consists of variable length compressed data this is the
maximum number of bytes required to hold an image.
- .. row 9
- enum :c:type:`v4l2_colorspace`
- ``colorspace``
- This information supplements the ``pixelformat`` and must be set
by the driver for capture streams and by the application for
output streams, see :ref:`colorspaces`.
- .. row 10
- __u32
- ``priv``
- This field indicates whether the remaining fields of the
struct :c:type:`v4l2_pix_format`, also called the
extended fields, are valid. When set to
``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
have been correctly initialized. When set to any other value it
indicates that the extended fields contain undefined values.
Applications that wish to use the pixel format extended fields
must first ensure that the feature is supported by querying the
device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>`
capability. If the capability isn't set the pixel format extended
fields are not supported and using the extended fields will lead
to undefined results.
To use the extended fields, applications must set the ``priv``
field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
fields and zero the unused bytes of the
struct :c:type:`v4l2_format` ``raw_data`` field.
When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
drivers must act as if all the extended fields were set to zero.
On return drivers must set the ``priv`` field to
``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to
applicable values.
- .. row 11
- __u32
- ``flags``
- Flags set by the application or driver, see :ref:`format-flags`.
- .. row 12
- 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 13
- 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 14
- 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`.
* - __u32
- ``width``
- Image width in pixels.
* - __u32
- ``height``
- Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
refers to the number of lines in the field, otherwise it refers to
the number of lines in the frame (which is twice the field height
for interlaced formats).
* - :cspan:`2` Applications set these fields to request an image
size, drivers return the closest possible values. In case of
planar formats the ``width`` and ``height`` applies to the largest
plane. To avoid ambiguities drivers must return values rounded up
to a multiple of the scale factor of any smaller planes. For
example when the image format is YUV 4:2:0, ``width`` and
``height`` must be multiples of two.
* - __u32
- ``pixelformat``
- The pixel format or type of compression, set by the application.
This is a little endian
:ref:`four character code <v4l2-fourcc>`. V4L2 defines standard
RGB formats in :ref:`rgb-formats`, YUV formats in
:ref:`yuv-formats`, and reserved codes in
:ref:`reserved-formats`
* - enum :c:type::`v4l2_field`
- ``field``
- Video images are typically interlaced. Applications can request to
capture or output only the top or bottom field, or both fields
interlaced or sequentially stored in one buffer or alternating in
separate buffers. Drivers return the actual field order selected.
For more details on fields see :ref:`field-order`.
* - __u32
- ``bytesperline``
- Distance in bytes between the leftmost pixels in two adjacent
lines.
* - :cspan:`2`
Both applications and drivers can set this field to request
padding bytes at the end of each line. Drivers however may ignore
the value requested by the application, returning ``width`` times
bytes per pixel or a larger value required by the hardware. That
implies applications can just set this field to zero to get a
reasonable default.
Video hardware may access padding bytes, therefore they must
reside in accessible memory. Consider cases where padding bytes
after the last line of an image cross a system page boundary.
Input devices may write padding bytes, the value is undefined.
Output devices ignore the contents of padding bytes.
When the image format is planar the ``bytesperline`` value applies
to the first plane and is divided by the same factor as the
``width`` field for the other planes. For example the Cb and Cr
planes of a YUV 4:2:0 image have half as many padding bytes
following each line as the Y plane. To avoid ambiguities drivers
must return a ``bytesperline`` value rounded up to a multiple of
the scale factor.
For compressed formats the ``bytesperline`` value makes no sense.
Applications and drivers must set this to 0 in that case.
* - __u32
- ``sizeimage``
- Size in bytes of the buffer to hold a complete image, set by the
driver. Usually this is ``bytesperline`` times ``height``. When
the image consists of variable length compressed data this is the
maximum number of bytes required to hold an image.
* - enum :c:type:`v4l2_colorspace`
- ``colorspace``
- This information supplements the ``pixelformat`` and must be set
by the driver for capture streams and by the application for
output streams, see :ref:`colorspaces`.
* - __u32
- ``priv``
- This field indicates whether the remaining fields of the
struct :c:type:`v4l2_pix_format`, also called the
extended fields, are valid. When set to
``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
have been correctly initialized. When set to any other value it
indicates that the extended fields contain undefined values.
Applications that wish to use the pixel format extended fields
must first ensure that the feature is supported by querying the
device for the :ref:`V4L2_CAP_EXT_PIX_FORMAT <querycap>`
capability. If the capability isn't set the pixel format extended
fields are not supported and using the extended fields will lead
to undefined results.
To use the extended fields, applications must set the ``priv``
field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
fields and zero the unused bytes of the
struct :c:type:`v4l2_format` ``raw_data`` field.
When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
drivers must act as if all the extended fields were set to zero.
On return drivers must set the ``priv`` field to
``V4L2_PIX_FMT_PRIV_MAGIC`` and all the extended fields to
applicable values.
* - __u32
- ``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`.
Documentation/media/uapi/v4l/pixfmt-003.rst
浏览文件 @ c2b66caf
......@@ -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.
Documentation/media/uapi/v4l/pixfmt-006.rst
浏览文件 @ c2b66caf
......@@ -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].
Documentation/media/uapi/v4l/pixfmt-sdr-cs08.rst
浏览文件 @ c2b66caf
......@@ -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`
Documentation/media/uapi/v4l/pixfmt-sdr-cs14le.rst
浏览文件 @ c2b66caf
......@@ -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]`
Documentation/media/uapi/v4l/pixfmt-sdr-cu08.rst
浏览文件 @ c2b66caf
......@@ -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`
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或