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 webcams, digital cameras, and TV tuners on Linux, Android, and ChromeOS, which continues the evolution of the V4L2 API and will eventually replace it. Since the library's API is still evolving and not fully stabilized, the project has continued to develop without branching off separate releases, using a continuous development model. In response to the need for distributions to track API changes affecting compatibility and to simplify library delivery in packages, it has now been decided to periodically create releases reflecting the degree of change in ABI and API. The project code is written in C++ and is distributed under the LGPLv2.1 license.
The project is being developed by developers of multimedia subsystems in the Linux kernel along with some camera manufacturers to normalize the support situation in Linux for smartphone and embedded device cameras, which are tied to proprietary drivers. The existing V4L2 API in the Linux kernel was originally created for working with traditional standalone webcams and is poorly adapted to the recent trend of offloading MCU functionality to the CPU.
Unlike traditional cameras, where primary image processing operations are performed on a specialized processor (MCU) built into the camera, in embedded devices, these functions are offloaded to the main CPU to reduce costs and require a more complex driver that includes non-open licensed components. Within the libcamera project, advocates of open-source software and hardware manufacturers have attempted to create a compromise solution that, on one hand, meets the needs of open software developers and, on the other hand, protects the intellectual property of camera manufacturers.
The libcamera library stack is fully implemented in user space. To ensure compatibility with existing software environments and applications, compatibility layers for V4L API, Gstreamer, and Android Camera HAL are provided. Camera-specific proprietary hardware interaction components are designed as modules that run in separate processes and communicate with the library through IPC. The modules do not have direct access to the device and interact with the hardware through an intermediate API, which checks, filters, and restricts requests to only the necessary functionality needed for camera control.
The library also provides access to algorithms for processing and improving the quality of images and videos (white balance adjustment, noise reduction, video stabilization, autofocus, exposure selection, etc.), which can be integrated as open external libraries or proprietary isolated modules. The API offers access to functions such as identifying the capabilities of existing external and built-in cameras, utilizing device profiles, handling camera connection and disconnection events, managing data capture from cameras at the individual frame level, and synchronizing snapshots with flash operations. Separate operation with multiple cameras in the system is possible, as well as organizing simultaneous capture of multiple video streams from a single camera (for example, one with low resolution for video conferencing and another with high resolution for archiving to disk).
Source: opennet.ru
