After four years of development, the first release of the libcamera project (0.0.1) has been formed, offering a software stack for working with camcorders, cameras and TV tuners on Linux, Android and ChromeOS, which continues the development of the V4L2 API and will eventually replace it. Since the API of the library is still changing and not fully stabilized, so far the project has developed without branching individual releases using a continuous development model. In response to the need for distributions to keep track of API changes that affect compatibility, and to make it easier to ship the library in packages, it has now been decided to periodically generate releases that reflect the extent of ABI and API changes. The project code is written in C++ and distributed under the LGPLv2.1 license.
The project is being developed by developers of Linux kernel multimedia subsystems together with some camera manufacturers to normalize Linux support for cameras for smartphones and embedded devices that are tied to proprietary drivers. The V4L2 API already available in the Linux kernel was once created to work with traditional stand-alone webcams and is poorly adapted to the recent trend of moving MCU functionality to the CPU.
Unlike traditional cameras, in which primary image processing operations are carried out on the special purpose processor (MCU) built into the camera, in embedded devices, to reduce cost, these functions are placed on the shoulders of the main CPU and require a sophisticated driver that includes licensed components that cannot be opened. As part of the libcamera project, free software proponents and hardware manufacturers tried to create a compromise solution that, on the one hand, satisfies the needs of open source developers, and, on the other hand, allows protecting the intellectual property of camera manufacturers.
The stack offered by the libcamera library is implemented entirely in user space. To ensure compatibility with existing programming environments and applications, layers are provided for compatibility with the V4L API, Gstreamer and the Android Camera HAL. Camera-specific proprietary hardware interaction components are packaged as modules that run in separate processes and interact with the library via IPC. Modules do not have direct access to the device and access the equipment through an intermediate API, through which requests are checked, filtered and limited to accessing the functionality necessary to control the camera.
The library also provides access to algorithms for processing and improving the quality of images and videos (white balance correction, noise removal, video stabilization, autofocus, exposure selection, etc.), which can be connected as open external libraries or proprietary isolated modules. The API provides access to functions such as determining the functionality of existing external and built-in cameras, using device profiles, handling camera connection and disconnection events, managing camera data capture at the individual frame level, and synchronizing pictures with flash operation. It is possible to work separately with several cameras in the system and organize the capture of several video streams from one camera at the same time (for example, one with a low resolution for a video conference, and the other with a high resolution for archive recording to disk).
Source: opennet.ru