Searched full:formats (Results 1 – 25 of 228) sorted by relevance
12345678910
| /Documentation/userspace-api/media/v4l/ |
| D | pixfmt.rst | 6 Image Formats
13 version (see :ref:`planar-apis`). Image formats are negotiated with
15 focus on video capturing and output, for overlay frame buffer formats
28 yuv-formats
29 hsv-formats
30 depth-formats
32 sdr-formats
33 tch-formats
34 meta-formats
|
| D | pixfmt-intro.rst | 4 Standard Image Formats
8 necessary to have standard image data formats which both sides will
9 interpret the same way. V4L2 includes several such formats, and this
11 image data formats in V4L2.
13 V4L2 drivers are not limited to these formats, however. Driver-specific
14 formats are possible. In that case the application may depend on a codec
15 to convert images to one of the standard formats when needed. But the
22 Even so, ultimately, some standard formats are needed, so the V4L2
24 formats.
26 The V4L2 standard formats are mainly uncompressed formats. The pixels
[all …]
|
| D | vidioc-g-dv-timings.rst | 60 the formats in the :ref:`cea861` and :ref:`vesadmt` standards. If
102 formats the height of the active video in each field is
128 - Vertical front porch in lines. For interlaced formats this refers
132 - Vertical sync length in lines. For interlaced formats this refers
136 - Vertical back porch in lines. For interlaced formats this refers
141 interlaced field formats. Must be 0 for progressive formats.
145 interlaced field formats. Must be 0 for progressive formats.
149 interlaced field formats. Must be 0 for progressive formats.
262 - CEA-861 specific: set for CEA-861 formats with a framerate that is
263 a multiple of six. These formats can be optionally played at 1 /
[all …]
|
| D | planar-apis.rst | 13 of such formats see :ref:`pixfmt`.
28 Multi-planar formats
31 Multi-planar API introduces new multi-planar formats. Those formats use
34 can handle all single-planar formats as well (as long as they are passed
36 handle multi-planar formats.
45 single- and multi-planar formats.
48 New structures for describing multi-planar formats are added: struct
51 Drivers may define new multi-planar formats, which have distinct
|
| D | format.rst | 7 Data Formats
15 within one kind many different formats are possible, in particular there is an
16 abundance of image formats. Although drivers must provide a default and
24 A single mechanism exists to negotiate all data formats using the
30 format. The data formats supported by the V4L2 API are covered in the
32 image formats see :ref:`pixfmt`.
74 enumerate all image formats supported by video capture, overlay or
82 Drivers are not supposed to convert image formats in kernel space.
83 They must enumerate only formats directly supported by the hardware.
88 Enumerating formats an application has no a-priori knowledge of
|
| D | dev-subdev.rst | 30 - negotiate image formats on individual pads
77 .. _pad-level-formats:
79 Pad-level Formats
84 Pad-level formats are only applicable to very complex devices that
94 Image formats are typically negotiated on video capture and output
122 configured differently. Applications need to configure the formats at
130 negotiate formats on a per-pad basis.
134 formats. The pipeline is checked for formats mismatch at
147 Acceptable formats on pads can (and usually do) depend on a number of
148 external parameters, such as formats on other pads, active links, or
[all …]
|
| D | vidioc-enum-fmt.rst | 13 VIDIOC_ENUM_FMT - Enumerate image formats
34 To enumerate image formats applications initialize the ``type``, ``mbus_code``
38 formats are enumerable by beginning at index zero and incrementing by
40 formats in preference order, where preferred formats are returned before
41 (that is, with lower ``index`` value) less-preferred formats.
51 Drivers shall enumerate all image formats.
56 formats may be different.
60 If the ``mbus_code`` field is zero, then all image formats
65 shall restrict enumeration to only the image formats that can produce
71 formats shall not depend on the active configuration of the video device
[all …]
|
| D | tch-formats.rst | 3 .. _tch-formats:
6 Touch Formats
9 These formats are used for :ref:`touch` interface only.
|
| D | hsv-formats.rst | 3 .. _hsv-formats:
6 HSV Formats
9 These formats store the color information of the image
|
| D | meta-formats.rst | 3 .. _meta-formats:
6 Metadata Formats
9 These formats are used for the :ref:`metadata` interface only.
|
| D | sdr-formats.rst | 3 .. _sdr-formats:
6 SDR Formats
9 These formats are used for :ref:`SDR <sdr>` interface only.
|
| D | pixfmt-packed-yuv.rst | 6 Packed YUV formats
9 Similarly to the packed RGB formats, the packed YUV formats store the Y, Cb and
25 These formats do not subsample the chroma components and store each pixels as a
28 The next table lists the packed YUV 4:4:4 formats with less than 8 bits per
44 .. flat-table:: Packed YUV 4:4:4 Image Formats (less than 8bpc)
150 For the YUV444 and YUV555 formats, the value of alpha bits is undefined
156 The next table lists the packed YUV 4:4:4 formats with 8 bits per component.
162 .. flat-table:: Packed YUV Image Formats (8bpc)
260 The next table lists the packed YUV 4:4:4 formats with 12 bits per component.
264 .. flat-table:: Packed YUV 4:4:4 Image Formats (12bpc)
[all …]
|
| D | pixfmt-bayer.rst | 6 Raw Bayer Formats
12 The raw Bayer formats are used by image sensors before much if any processing is
13 performed on the image. The formats contain green, red and blue components, with
|
| D | dev-stateless-decoder.rst | 29 Depending on the encoded formats supported by the decoder, a single decoded
31 with multiple slices per frame). Decoders that support such formats must also
38 1. To enumerate the set of coded formats supported by the decoder, the client
41 * The driver must always return the full set of supported ``OUTPUT`` formats,
48 2. To enumerate the set of supported raw formats, the client calls
51 * The driver must return only the formats supported for the format currently
55 formats may depend on the value of some codec-dependent controls.
58 default values for these controls being used, and a returned set of formats
97 etc.) required by the ``OUTPUT`` format to enumerate the ``CAPTURE`` formats.
129 4. *[optional]* Enumerate ``CAPTURE`` formats via :c:func:`VIDIOC_ENUM_FMT` on
[all …]
|
| D | pixfmt-yuv-luma.rst | 6 Luma-Only Formats
9 This family of formats only store the luma component of a Y'CbCr image. They
10 are often referred to as greyscale formats.
15 - Formats are described with the minimum number of pixels needed to create a
28 .. flat-table:: Luma-Only Image Formats
204 For the Y16 and Y16_BE formats, the actual sampling precision may be lower
209 For Y012 and Y12 formats, Y012 places its data in the 12 high bits, with
213 The 'P' variations of the Y10, Y12 and Y14 formats are packed according to
|
| D | depth-formats.rst | 3 .. _depth-formats:
6 Depth Formats
|
| D | vidioc-subdev-g-fmt.rst | 57 to ``V4L2_SUBDEV_FORMAT_TRY``. When set, 'try' formats are not applied
58 to the device by the driver, but are changed exactly as active formats
69 Try formats do not depend on active formats, but can depend on the
124 - Try formats, used for querying device capabilities.
127 - Active formats, applied to the hardware.
|
| D | vidioc-subdev-enum-mbus-code.rst | 13 VIDIOC_SUBDEV_ENUM_MBUS_CODE - Enumerate media bus formats
35 of media bus formats for the selected pad.
42 Therefore, to enumerate media bus formats available at a given sub-device pad,
57 Available media bus formats may depend on the current 'try' formats at
60 information about the try formats.
|
| D | dev-touch.rst | 50 The formats supported by touch devices are documented in
51 :ref:`Touch Formats <tch-formats>`.
|
| D | pixfmt-srggb10alaw8.rst | 15 10-bit Bayer formats compressed to 8 bits
21 These four pixel formats are raw sRGB / Bayer formats with 10 bits per
|
| D | pixfmt-srggb10dpcm8.rst | 18 10-bit Bayer formats compressed to 8 bits
24 These four pixel formats are raw sRGB / Bayer formats with 10 bits per
|
| /Documentation/devicetree/bindings/display/ |
| D | lvds.yaml | 18 It supports reversing the bit order on the formats defined there in order
19 to accommodate for even more specialized data formats, since a variety of
20 data formats and layouts is used to drive LVDS displays.
|
| /Documentation/core-api/ |
| D | printk-index.rst | 25 a dump of printk formats used all over the source code used for the kernel
28 The printk index helps to find changes in the message formats. Also it helps
35 The index of printk formats are split in into separate files. The files are
36 named according to the binaries where the printk formats are built-in. There
43 Note that only loaded modules are shown. Also printk formats from a module
103 for example, dev_printk(). As a result, the printk formats from
118 interface might then show the printk formats including these prefixes.
|
| /Documentation/devicetree/bindings/media/ |
| D | renesas,fdp1.yaml | 15 between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are
|
| /Documentation/fb/ |
| D | api.rst | 39 When supported, formats are configured using a FOURCC instead of manually
46 Pixels are stored in memory in hardware-dependent formats. Applications need
50 Formats are described by frame buffer types and visuals. Some visuals require
240 for applications when using RGB and grayscale formats, as well as legacy
241 non-standard formats.
247 - For grayscale formats, applications set the grayscale field to one. The red,
252 - For pseudocolor formats, applications set the grayscale field to zero. The
257 - For truecolor and directcolor formats, applications set the grayscale field
284 formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
285 and grayscale formats.
[all …]
|
12345678910