5791fdc1cb
Packed formats make it difficult to calculate stride as well as frame size with the fields that PixelFormatInfo currently has. bitsPerPixel is defined as the average number of bits per pixel, and only counts effective bits, so it is not useful for calculating stride and frame size. To fix this, we introduce a concept of a "pixel group". The size of this group is defined as the minimum number of pixels (including padding) necessary in a row when the image has only one column of effective pixels. The pixel group has one more attribute, that is the "bytes per group". This determines how many bytes one pixel group consumes. These are the fields pixelsPerGroup and bytesPerGroup that are defined in this patch. Defining these two values makes it really simple to calculate bytes-per-line, as ceil(width / pixelsPerGroup) * bytesPerGroup, where width is measured in number of pixels. The ceiling accounts for padding. The pixel group has another contraint, which is that the pixel group (bytesPerGroup and pixelsPerGroup) is the smallest repeatable unit. What this means is that, for example, in the IPU3 formats, if there is only one column of effective pixels, it looks like it could be fit in 5 bytes with 3 padding pixels (for a total of 4 pixels over 5 bytes). However, this unit is not repeatable, as at the 7th group in the same row, the pattern is broken. Therefore, the pixel group for IPU3 formats must be 25 pixels over 32 bytes. Clearly, pixelsPerGroup must be constant for all planes in the format. The bytesPerGroup then, must be a per-plane attribute. There is one more field, verticalSubSampling, that is per-plane. This is simply a divider, to divide the number of rows of pixels by the sub-sampling value, to obtain the number of rows of pixels for the subsampled plane. For example, for something simple like BGR888, it is self-explanatory: the pixel group size is 1, and the bytes necessary is 3, and there is only one plane with no (= 1) vertical subsampling. For YUYV, the CbCr pair is shared between two pixels, so even if you have only one pixel, you would still need a padded second Y, therefore the pixel group size is 2, and bytes necessary is 4 (as opposed to 1 and 2). YUYV also has no vertical subsampling. NV12 has a pixel group size of 2 pixels, due to the CbCr plane. The bytes per group then, for both planes, is 2. The first plane has no vertical subsampling, but the second plane is subsampled by a factor of 2. The IPU3 formats are also self-explanatory, as they are single-planar, and have a pixel group size of 25, consuming 32 bytes. Although a comment in the driver suggests that it should be 50 and 64, respectively, this is an attribute of the driver, and not the format, so this shall be set by the ipu3 pipeline handler. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
.. SPDX-License-Identifier: CC-BY-SA-4.0
.. section-begin-libcamera
===========
libcamera
===========
**A complex camera support library for Linux, Android, and ChromeOS**
Cameras are complex devices that need heavy hardware image processing
operations. Control of the processing is based on advanced algorithms that must
run on a programmable processor. This has traditionally been implemented in a
dedicated MCU in the camera, but in embedded devices algorithms have been moved
to the main CPU to save cost. Blurring the boundary between camera devices and
Linux often left the user with no other option than a vendor-specific
closed-source solution.
To address this problem the Linux media community has very recently started
collaboration with the industry to develop a camera stack that will be
open-source-friendly while still protecting vendor core IP. libcamera was born
out of that collaboration and will offer modern camera support to Linux-based
systems, including traditional Linux distributions, ChromeOS and Android.
.. section-end-libcamera
.. section-begin-getting-started
Getting Started
---------------
To fetch the sources, build and install:
::
git clone git://linuxtv.org/libcamera.git
cd libcamera
meson build
ninja -C build install
Dependencies
~~~~~~~~~~~~
The following Debian/Ubuntu packages are required for building libcamera.
Other distributions may have differing package names:
A C++ toolchain: [required]
Either {g++, clang}
for libcamera: [required]
meson (>= 0.47) ninja-build python3-yaml
If your distribution doesn't provide a recent enough version of meson,
you can install or upgrade it using pip3.
.. code::
pip3 install --user meson
pip3 install --user --upgrade meson
for device hotplug enumeration: [optional]
pkg-config libudev-dev
for documentation: [optional]
python3-sphinx doxygen
for gstreamer: [optional]
libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
for IPA module signing: [required]
libgnutls28-dev openssl
for qcam: [optional]
qtbase5-dev libqt5core5a libqt5gui5 libqt5widgets5
Using GStreamer plugin
~~~~~~~~~~~~~~~~~~~~~~
To use GStreamer plugin from source tree, set the following environment so that
GStreamer can find it.
export GST_PLUGIN_PATH=$(pwd)/build/src/gstreamer
The debugging tool `gst-launch-1.0` can be used to construct and pipeline and test
it. The following pipeline will stream from the camera named "Camera 1" onto the
default video display element on your system.
.. code::
gst-launch-1.0 libcamerasrc camera-name="Camera 1" ! videoconvert ! autovideosink
.. section-end-getting-started