Complex cameras are (were?) complex
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Mondi, Jacopo
The 'complex camera' user-space library is a fairly new and hot topic in the Linux kernel video community. The issue is debated and targets a real technical debt of Linux systems. Device producers have been tackling this with in-house solutions that proved not to scale once brought in the open space, so a generic solution is now required to address the issue. The Linux kernel video input subsystem and its APIs changed greatly in the last years to keep up with the increasing complexity and processing power embedded in modern SoCs. Namely, the biggest game-changing feature introduced already 5 years ago is the media controller subsystem and its pad oriented APIs, that allows composing pipelines of processing blocks to model the acquisition and re-processing of video and images. While most of the media subsystem drivers in mainline Linux have been ported to fully support media-controller, the real missing component is now user space support to automate setting up and controlling the image processing pipelines. The Video4Linux community is now tackling the issue by implementing support for "complex camera" systems by providing a user space library that aims to support the most recent use cases represented by mobile consumer devices and high end laptops. This talks provides an overview of modern media-controller capable video device drivers, their userspace APIs and the challenges the currently in-development "libcamera" library has to face. It also aims to provide to both driver and application developers an overview of the most modern implementation of the Linux video input stack architecture, that will likely be found in most system in next years.
 Okay, hello, hello. Is it working? Sorry, it took some time to set it up, but here we are. So, my name is Jacobo, I'm going to talk to you about complex cameras, and now we are trying to make it less complex. So, my name is Jacobo, I'm an embedded Linux software engineer. I mostly work on integrating camera systems and multimedia devices. Here are a few of my contacts here, you're welcome to ping me. And why we're given this talk, why we're doing this work in first place, that's because the increasing complexity we are used to in embedded systems regarding the camera acquisition process, it's coming into canonical computing space like laptops and tablets. And Linux systems have a problem with that. Are Linux system ready? No, they're not. And so we have a problem, and we're trying to solve that. It's pretty not necessary to state either this here in this room, but digital imaging is a complex task. It's not complex that it's complicated, but it's computational expensive. It's computational expensive during the acquisition phase, because you go through all the debiring and interpolation and pixel transformations. It's complex where you have to do image quality tuning like out balancing white balancing out exposure, whatever. And we usually work with very big buffers, like not that big resolution in the quite common format. It's four megabytes of data and we are transporting this back and forth different devices. If we look at the architecture of the system, like it is today, like it presents itself today, regarding the image capture part. Let me... It doesn't go away, I'm sorry. Regarding the image acquisition part, we usually have a few acquisition ports. Today is mostly CSI too, backed by a big, fat ISP. The ISP interfaces itself with a system memory for doing DMA transfer of images. It interfaces with other system components like DRM. It interfaces with a CPU. It has very fast interconnection because it's a system peripheral and externally we have a sensor, of course, to provide the image data. What's an ISP? An ISP, it's an image signal processor, which is nothing but the set of digital processing blocks that performs transformational images. It's composed by configurable blocks, so you can create a pipeline of transformation that does different kind of transformations. What it usually does, it's interfacing with memory, so DMA transfers, reskiling, resizing, cropping, all kind of transformations. It can convert formats from one format to another, pixel encoding, make it easy to present image to application, or whatever. It can do a lot of advanced image processing features like 3A and reprocessing, tuning, etc. It's very efficient because it's a system peripheral, so it runs a very high frequency. It has a high speed interconnection with CPUs, and the design is very platform specific. For system-on-chip that maybe are targeted to the automotive markets, you would like to have a lot of DMA channels because you're maybe transferring a lot of different images from different sources. If you have an SoC which is designed from the mobile application space, you maybe would like to have different outputs with different pixel encodings to present images like still capture, review finder, easy to be application. That's what the system looked like 10 years ago, and the thing was kind of different from what we have today, because we have maybe one acquisition port, a few acquisition port that usually parallel, backed by maybe a scaler, maybe a pixel converter, but nothing complex, and we just have interfacing to the system memory. Of course, the sensor outside dealt with most of the complexity at the time that was called the smart sensor, that's why, because they were doing most of the things that nowadays run on the AISP. Vitofer Linux has been designed, Vitofer Linux API, in a time where system looked more like this. So we have a single device, no abstraction, user space that controls the whole acquisition process. That fits very well if your acquisition process is basically just moving frames back and forth from the system memory. That allows you to link the different processing blocks and create different pipelines, and through the before and to sub devs API, that allows you to control what formats and what transformation each block performs. This is very nice and powerful, used to capture images through the device, through the Vitofer Linux API like it used to do, and this is very nice and powerful, but it has a problem. The problem is that the system usually doesn't boot in a usable state. You have, before you can do anything, you have to configure the pipeline, set up links, set up the formats, and to do that, all the applications that want to interface with that need to have a very good knowledge of the underlying hardware, so this is very platform specific. Also, to perform a capturing application is not just like we used to do with a start stream on the Vito device node, but you have to set up precisely all the pipeline components because otherwise you got back what an E-pipe and error and you cannot stream. So, for embedded system, this is okay because, okay, it's acceptable because you usually bait your own root of FES, you can embed script there, you can do whatever you want, it's very system specific, but if you think about something like that running on a laptop, that doesn't work for real because distribution are not ready for that, they aim to be generic, so that doesn't work very well. And until today, that was not a problem because most cameras or laptops and tablets were USB cameras. USB cameras are much sensor, they just connect through a USB, they are very platform-agnostic because USB is universal, and it fits very well in the Vito4LiUx2 single device node abstraction. You have a single entry point for the whole control, image capture process, and you control everything that goes on through that single entry point. We have a library, V4L, or V4L2, which controls, which work with most of the sensor that we have today, USB sensor, and does format conversion and makes easy to write application for Vito4Linux. But something's happening and we start receiving bug rapers, that's very recent one, it was on the Linux media mailing list one week ago, I guess, and basically says, I have a laptop and I cannot see the webcam. That's a complex camera, it's an IPv3, it's Intel ISP. And you need a driver, of course, but you also need user space to do all the configuration and tuning, so that's not going to be supported. What's happening is that we start to see Intel, so Caby Lake and Skylake platforms, which have better complex ISP, and producers have started making laptops and tablets using that one. Driver is okay, it's in staging right now, it has been submitted to Linux media, so good work with that, but we're still missing the user space part, because this device simply doesn't work in Linux. That's how, just to give an idea how an ISP works, that's a simplified model of what happens on the IPv3, so we have two different blocks, one that is in charge. IMGU, IMAGING unit, which does all sorts of complicated transformations, and you've got three different outputs, one that you, which is scaled, one that is full-size, and the set of metadata, which is used for tuning a very complex 3A and tuning machinery, which is fed to another input, which controls how the next images are captured. So this is complex, and this is a complex camera, so in order to work, to have something like that to work, you have to bake some script that's up all the pipeline, all the formats, and it's a single piece of the capturing pipeline, and that's very complicated. So the discussion starts like, I think, was July, there was a meeting in Tokyo for the Vitoferlinus community, that there are meeting notes, and the issue is that we have devices which are not working. Mauro gave a very nice presentation at ELC about complex cameras and why they are complex, and now they work so far, and the output from that was that a project, a start, which is called libcamera, which is a joint effort between the Vitoferlinus community and part of some industry partners. When libcamera is not just a library, it tends to be a complete, full-stack in user space to deal with camera, with complex camera or Linux systems. Libcamera aims to obstruct away all the complexity to setting up and controlling the media controller and the Vitoferus sub-devices, and it tends to be compatible, first of all, with Linux, because we want to solve that problem with the Vitoferlinus system, but also with very widespread systems like Android and Chrome OS, because a lot of devices that run with IPU3 and other ISPs are Chromebooks. In 25 minutes, I won't have time to go into technical details for that, but Laurent gave a very nice talk that details the architecture of libcamera and the internals at ELC. It's available on YouTube or the ELC website, so if you want to know more details about the technical specificities, you should prefer to this talk. But I would like just to give an idea of the architecture, and that's a stack of applications that capture images, and starting from the top, we might have frameworks like Gistreamer, we might have applications that use libv4l like they are doing today, we will hopefully have native libcamera application and maybe web Android on top of that. There will be an adaption layer and there will be libcamera on the camera, object concept. If you have worked with media console, nowadays we have to specify which media device you want to work on, which video device node you want to operate on, libcamera aims, the pipeline ender will receive a request for formats and capture profiles from the camera and the camera manager, and we'll apply that to the underlying hardware. As we've seen the 3A in tuning, it's kind of important on those kind of platforms. So we design an RPC system to isolate processes that run 3A algorithm because those kind of processes are usually provided by the vendors. So we don't want to tie in any binary and we want to give space for open source 3A implementation to compete with the vendor ones, so we are designing an RPC interface to isolate that process in a separate other space and interface with libcamera separately. Of course, we got set of outbursts to interface with actual devices and that's what we have in the application, that's a very brief introduction and I would like to concentrate since we don't have much time on how we are actually doing that because libcamera is a new project, it started a few months ago, but we still, we already have something that is usable and it's, you're welcome to interact with. So we have a Git repository which is hosted at Linux TV where the old VDF for Linux development happens and we are doing development on the mailing list. I know or you love it or you rate it, but that's how we decide that it was best to do that, to guarantee that we keep following a development process that is as much distributed as possible. We're using Mason and Ninja, which I don't know how many people know that, I didn't know about those kind of, those two projects before starting with libcamera, but if you use outer tools, those two things are amazing because it makes very easy to distribute an application and track dependencies and also helps with testing a lot. We do Enforce a Coding Style which is something that most projects do and we do that because we want to have the code that which, which level of quality does it, as close as possible as the kernel one, so it's partly to satisfy our OCD and have the code that looks nice, but it's also because we are using that, we are developing in C++ and C++ it's a language that makes very easy to mess up. So since a few years there is a lot of attention on concept of ownership since Rust came out and doing that in C++ requires a lot of enforcing and coding style and coding rules and in order to do that, since we are doing C++ and we don't have support from the language itself, we love peak reviews. So if you're used to the level of reviews of peakingness of reviews on the Linux kernel mailing list, that's what we aim to add. So you're welcome to buy shed, the bike shed on the variable declaration order, names of the variable and stuff like that, but also we invite you to be, to take part in that and help to be, to keep the code quality very high and we would like to add. We also try to be serious at documentation and testing. We found out that writing proper documentation, it's more difficult and takes more time than writing code possibly and we're using Doxygen for that which is great. We generate the website from the source code as well as well as the documentation and we enforce testing because we would like to have all major components that gets in to be associated with the test and we aim to have much more platform as possible that support those kind of testing. Where are we right now? The project is very young, very, very young, just two months old and we have support for UBC cameras which are the traditional USB cameras and we have a homeless fully working support for Intel IPv3 which is the first and most urgent targets that we have. We can list and detect OTPlag and OTPlag of cameras and we can capture frames actually which is kind of a nice thing considering that until a few months ago those devices were not working at all in Linux. Where do we want to go? Lib camera one ideally should support OISP that has a media controller compliant kernel support. So there are a lot of ISP that are possible targets for next development. There is Rockchip ISP. There are other platform which has a good support in kernel space and we aim to support all of that. Of course in mobile space there is a big competitor for all Linux system which is sort of Linux system which is Android and Android has a very complex camera stack. If you are used to work with Android cameras you know that camera output V3 supports per frame request. So each frame is associated with a set of capture parameters which is something that requires development both in the library and both in the Videfer Linux API which today is not totally ready for doing that. Also we would like to get in touch and work as much as possible with vendors because we would like to have something like when you supply a driver for Videfer Linux and for media controller that should be associated with the support for Lib camera in order to have a complete user space and kernel space support for the camera itself. One of the reasons which is C++ for that is because we want to interface with vendors and we know that most people there know C maybe they are kernel developers so it's easy for them to drag people in using a language which is more familiar. So I would also like to, well this are a few references, we have a website, we have a mailing list where we share patches, we will have a patchwork possibly and we have an RFC channel like most projects do and you're welcome to give a hint because the project is very young and we want to know as much as possible for people that is working with cameras. Before going to question which I hope you have some, I would also like to give a brief, I would say that's not a demo because it's very very simple that this device is the device with as an IP3, it's a Chromebook as an IP3 device and was not supported by Linux system until a few months ago and right now I think we can do, we have a small utility which is called com that allows you to write wonderful so it was working before. Oh I'm not rude, my bad. There you go, we have two cameras, wait wait that's not all and we can also catch you from cameras, as you can see you identify cameras by name, the name is now created by parsing the the not the ACPI table but just parsing the sensor name, you can identify camera by calling that by name, you don't care about which media devices they are connected to and we can capture frames hopefully and thanks to with a bit of conversion there is an image there, trust me it's it's very dark because we don't have all the machinery to do the tuning in place but at least we can capture frames which is something that until a few times ago was not possible so I think it's a good achievement so I hope you have questions for me, I hope you have questions for us in general there are other people which is involved in the in the project here so feel free. So should I repeat the question is there any overlap between what G-streamer does or lib camera does not really because G-streamer is one layer up to the camera nowadays G-streamer is what is called the V4L2S or SRC element which interfaces with the V-device we hope to that we will have a lib camera element where you can just interface this as you can see in future also being picked up by the embedded community or are they just happy before that. So are we focusing just on laptops and tablets or is that something that should be used also in embedded systems or embedded systems are fine the way they are I don't think some embedded system are fine the way they are because every today everyone is baking his own solution so all you have a script using media CTL but it's very difficult to kick truck over the resolution along the pipeline or people may be right their own application using the interfacing with the device drivers interface but I don't think some of the system are fine the way they are so we hope to have all the ISPs and platforms that have a kernel support which is mainline to use lib camera as well so we I think that they are on the same level you know this is more pressing because you buy you buy a laptop and the camera is not working on Linux so that's very bad on the better system they are already used to work with that so yes well I should repeat the question it's a very long one by the way so the problem with 3a and statistic it's usually that is very system-specific and vendors are not not keen on giving away documentation on those things but 3a and tuning is very important time's up so I'll be very quick okay thank you so what is the situation with IP3 is Intel behaving well in this case and is Intel providing documentation I would not say that is yeah it's providing documentation they're doing in a way that they are doing development on mainline so we have the driving staging and it comes with documentation on the parameter and everything as far as I know there are no private IUCT else which are vendor-specific so that's a good thing so yeah Intel is doing good on that in this case and we want more vendors to do that because lib camera works only on mainline and standard beautiful Linux interface okay thank you
 Okay, hello, hello. Is it working? Sorry, it took some time to set it up, but here we  are. So, my name is Jacobo, I'm going to talk to you about complex cameras, and now we are  trying to make it less complex. So, my name is Jacobo, I'm an embedded Linux software  engineer. I mostly work on integrating camera systems and multimedia devices. Here are a  few of my contacts here, you're welcome to ping me. And why we're given this talk, why we're  doing this work in first place, that's because the increasing complexity we are used to in  embedded systems regarding the camera acquisition process, it's coming into canonical computing  space like laptops and tablets. And Linux systems have a problem with that. Are Linux  system ready? No, they're not. And so we have a problem, and we're trying to solve that. It's  pretty not necessary to state either this here in this room, but digital imaging is a complex  task. It's not complex that it's complicated, but it's computational expensive. It's computational  expensive during the acquisition phase, because you go through all the debiring and interpolation  and pixel transformations. It's complex where you have to do image quality tuning like out balancing  white balancing out exposure, whatever. And we usually work with very big buffers, like not  that big resolution in the quite common format. It's four megabytes of data and we are transporting  this back and forth different devices. If we look at the architecture of the system, like it is  today, like it presents itself today, regarding the image capture part. Let me... It doesn't go away,  I'm sorry. Regarding the image acquisition part, we usually have a few acquisition ports. Today is  mostly CSI too, backed by a big, fat ISP. The ISP interfaces itself with a system memory for doing  DMA transfer of images. It interfaces with other system components like DRM. It interfaces with  a CPU. It has very fast interconnection because it's a system peripheral and externally we have a  sensor, of course, to provide the image data. What's an ISP? An ISP, it's an image signal processor,  which is nothing but the set of digital processing blocks that performs transformational images.  It's composed by configurable blocks, so you can create a pipeline of transformation that does  different kind of transformations. What it usually does, it's interfacing with memory,  so DMA transfers, reskiling, resizing, cropping, all kind of transformations. It can convert  formats from one format to another, pixel encoding, make it easy to present image to application,  or whatever. It can do a lot of advanced image processing features like 3A and reprocessing,  tuning, etc. It's very efficient because it's a system peripheral, so it runs a very high frequency.  It has a high speed interconnection with CPUs, and the design is very platform specific. For  system-on-chip that maybe are targeted to the automotive markets, you would like to have a lot  of DMA channels because you're maybe transferring a lot of different images from different sources.  If you have an SoC which is designed from the mobile application space, you maybe would like to  have different outputs with different pixel encodings to present images like still capture,  review finder, easy to be application. That's what the system looked like 10 years ago,  and the thing was kind of different from what we have today, because we have maybe one acquisition  port, a few acquisition port that usually parallel, backed by maybe a scaler, maybe a pixel converter,  but nothing complex, and we just have interfacing to the system memory. Of course, the sensor outside  dealt with most of the complexity at the time that was called the smart sensor, that's why,  because they were doing most of the things that nowadays run on the AISP. Vitofer Linux has been  designed, Vitofer Linux API, in a time where system looked more like this. So we have a single device,  no abstraction, user space that controls the whole acquisition process. That fits very well  if your acquisition process is basically just moving frames back and forth from the system memory.  That allows you to link the different processing blocks and create different pipelines, and through  the before and to sub devs API, that allows you to control what formats and what transformation  each block performs. This is very nice and powerful, used to capture images through the device,  through the Vitofer Linux API like it used to do, and this is very nice and powerful,  but it has a problem. The problem is that the system usually doesn't boot in a usable state.  You have, before you can do anything, you have to configure the pipeline, set up links, set up  the formats, and to do that, all the applications that want to interface with that need to have a  very good knowledge of the underlying hardware, so this is very platform specific. Also, to perform  a capturing application is not just like we used to do with a start stream on the Vito device node,  but you have to set up precisely all the pipeline components because otherwise you got back what  an E-pipe and error and you cannot stream. So, for embedded system, this is okay because, okay,  it's acceptable because you usually bait your own root of FES, you can embed script there,  you can do whatever you want, it's very system specific, but if you think about something like  that running on a laptop, that doesn't work for real because distribution are not ready for that,  they aim to be generic, so that doesn't work very well. And until today, that was not a problem  because most cameras or laptops and tablets were USB cameras. USB cameras are much sensor,  they just connect through a USB, they are very platform-agnostic because USB is universal,  and it fits very well in the Vito4LiUx2 single device node abstraction. You have a single entry  point for the whole control, image capture process, and you control everything that goes on through  that single entry point. We have a library, V4L, or V4L2, which controls, which work with most  of the sensor that we have today, USB sensor, and does format conversion and makes easy to  write application for Vito4Linux. But something's happening and we start receiving bug rapers,  that's very recent one, it was on the Linux media mailing list one week ago, I guess,  and basically says, I have a laptop and I cannot see the webcam. That's a complex camera,  it's an IPv3, it's Intel ISP. And you need a driver, of course, but you also need user space  to do all the configuration and tuning, so that's not going to be supported. What's happening  is that we start to see Intel, so Caby Lake and Skylake platforms, which have better complex ISP,  and producers have started making laptops and tablets using that one. Driver is okay,  it's in staging right now, it has been submitted to Linux media, so good work with that, but we're  still missing the user space part, because this device simply doesn't work in Linux.  That's how, just to give an idea how an ISP works, that's a simplified model of what happens on the  IPv3, so we have two different blocks, one that is in charge. IMGU, IMAGING unit, which does all  sorts of complicated transformations, and you've got three different outputs, one that you, which is  scaled, one that is full-size, and the set of metadata, which is used for tuning a very complex  3A and tuning machinery, which is fed to another input, which controls how the next images are  captured. So this is complex, and this is a complex camera, so in order to work, to have something  like that to work, you have to bake some script that's up all the pipeline, all the formats,  and it's a single piece of the capturing pipeline, and that's very complicated. So the discussion  starts like, I think, was July, there was a meeting in Tokyo for the Vitoferlinus community,  that there are meeting notes, and the issue is that we have devices which are not working.  Mauro gave a very nice presentation at ELC about complex cameras and why they are complex,  and now they work so far, and the output from that was that a project, a start, which is called  libcamera, which is a joint effort between the Vitoferlinus community and part of some industry  partners. When libcamera is not just a library, it tends to be a complete, full-stack in user space  to deal with camera, with complex camera or Linux systems. Libcamera aims to obstruct away all the  complexity to setting up and controlling the media controller and the Vitoferus sub-devices,  and it tends to be compatible, first of all, with Linux, because we want to solve that problem  with the Vitoferlinus system, but also with very widespread systems like Android and Chrome OS,  because a lot of devices that run with IPU3 and other ISPs are Chromebooks. In 25 minutes,  I won't have time to go into technical details for that, but Laurent gave a very nice talk that  details the architecture of libcamera and the internals at ELC. It's available on YouTube or  the ELC website, so if you want to know more details about the technical specificities,  you should prefer to this talk. But I would like just to give an idea of the architecture,  and that's a stack of applications that capture images, and starting from the top,  we might have frameworks like Gistreamer, we might have applications that use libv4l  like they are doing today, we will hopefully have native libcamera application and maybe web Android  on top of that. There will be an adaption layer and there will be libcamera on the camera,  object concept. If you have worked with media console, nowadays we have to specify which  media device you want to work on, which video device node you want to operate on, libcamera  aims, the pipeline ender will receive a request for formats and capture profiles from the camera  and the camera manager, and we'll apply that to the underlying hardware. As we've seen the 3A  in tuning, it's kind of important on those kind of platforms. So we design an RPC system to isolate  processes that run 3A algorithm because those kind of processes are usually provided by the  vendors. So we don't want to tie in any binary and we want to give space for open source 3A  implementation to compete with the vendor ones, so we are designing an RPC interface to isolate  that process in a separate other space and interface with libcamera separately. Of course,  we got set of outbursts to interface with actual devices and that's what we have in the application,  that's a very brief introduction and I would like to concentrate since we don't have much time on  how we are actually doing that because libcamera is a new project, it started a few months ago,  but we still, we already have something that is usable and it's, you're welcome to interact with.  So we have a Git repository which is hosted at Linux TV where the old VDF for Linux development  happens and we are doing development on the mailing list. I know or you love it or you rate it,  but that's how we decide that it was best to do that, to guarantee that we keep following a  development process that is as much distributed as possible. We're using Mason and Ninja,  which I don't know how many people know that, I didn't know about those kind of, those two  projects before starting with libcamera, but if you use outer tools, those two things are amazing  because it makes very easy to distribute an application and track dependencies and also helps  with testing a lot. We do Enforce a Coding Style which is something that most projects do and we  do that because we want to have the code that which, which level of quality does it, as close as  possible as the kernel one, so it's partly to satisfy our OCD and have the code that looks nice,  but it's also because we are using that, we are developing in C++ and C++ it's a language that  makes very easy to mess up. So since a few years there is a lot of attention on concept of ownership  since Rust came out and doing that in C++ requires a lot of enforcing and coding style and coding  rules and in order to do that, since we are doing C++ and we don't have support from the language  itself, we love peak reviews. So if you're used to the level of reviews of peakingness of reviews  on the Linux kernel mailing list, that's what we aim to add. So you're welcome to buy shed,  the bike shed on the variable declaration order, names of the variable and stuff like that, but  also we invite you to be, to take part in that and help to be, to keep the code quality very high  and we would like to add. We also try to be serious at documentation and testing. We found out that  writing proper documentation, it's more difficult and takes more time than writing code possibly  and we're using Doxygen for that which is great. We generate the website from the source code as  well as well as the documentation and we enforce testing because we would like to have all major  components that gets in to be associated with the test and we aim to have much more platform as  possible that support those kind of testing. Where are we right now? The project is very young,  very, very young, just two months old and we have support for UBC cameras which are the traditional  USB cameras and we have a homeless fully working support for Intel IPv3 which is the first and  most urgent targets that we have. We can list and detect OTPlag and OTPlag of cameras and we  can capture frames actually which is kind of a nice thing considering that until a few months  ago those devices were not working at all in Linux. Where do we want to go? Lib camera one  ideally should support OISP that has a media controller compliant kernel support. So there are  a lot of ISP that are possible targets for next development. There is Rockchip ISP. There are  other platform which has a good support in kernel space and we aim to support all of that. Of course  in mobile space there is a big competitor for all Linux system which is sort of Linux system which  is Android and Android has a very complex camera stack. If you are used to work with Android cameras  you know that camera output V3 supports per frame request. So each frame is associated with a set  of capture parameters which is something that requires development both in the library and  both in the Videfer Linux API which today is not totally ready for doing that. Also we would like  to get in touch and work as much as possible with vendors because we would like to have something like  when you supply a driver for Videfer Linux and for media controller that should be associated with  the support for Lib camera in order to have a complete user space and kernel space support for  the camera itself. One of the reasons which is C++ for that is because we want to interface with  vendors and we know that most people there know C maybe they are kernel developers so it's easy  for them to drag people in using a language which is more familiar. So I would also like to, well  this are a few references, we have a website, we have a mailing list where we share patches,  we will have a patchwork possibly and we have an RFC channel like most projects do and you're  welcome to give a hint because the project is very young and we want to know as much as possible  for people that is working with cameras. Before going to question which I hope you have some,  I would also like to give a brief, I would say that's not a demo because it's very very simple  that this device is the device with as an IP3, it's a Chromebook as an IP3 device and was not  supported by Linux system until a few months ago and right now I think we can do, we have a small  utility which is called com that allows you to write wonderful so it was working before.  Oh I'm not rude, my bad. There you go, we have two cameras, wait wait that's not all and we can  also catch you from cameras, as you can see you identify cameras by name, the name is now  created by parsing the the not the ACPI table but just parsing the sensor name, you can identify  camera by calling that by name, you don't care about which media devices they are connected to  and we can capture frames hopefully and thanks to with a bit of conversion there is an image there,  trust me it's it's very dark because we don't have all the machinery to do the tuning in place  but at least we can capture frames which is something that until a few times ago was not  possible so I think it's a good achievement so I hope you have questions for me, I hope you have  questions for us in general there are other people which is involved in the in the project here so  feel free. So should I repeat the question is there any overlap between what G-streamer does  or lib camera does not really because G-streamer is one layer up to the camera nowadays G-streamer  is what is called the V4L2S or SRC element which interfaces with the V-device we hope to  that we will have a lib camera element where you can just interface this as you  can see in future also being picked up by the embedded community or are they just happy before  that. So are we focusing just on laptops and tablets or is that something that should be used  also in embedded systems or embedded systems are fine the way they are I don't think some  embedded system are fine the way they are because every today everyone is baking his own  solution so all you have a script using media CTL but it's very difficult to kick truck over the  resolution along the pipeline or people may be right their own application using the interfacing  with the device drivers interface but I don't think some of the system are fine the way they are  so we hope to have all the ISPs and platforms that have a kernel support which is mainline to use  lib camera as well so we I think that they are on the same level you know this is more pressing  because you buy you buy a laptop and the camera is not working on Linux so that's very bad on  the better system they are already used to work with that so yes  well I should repeat the question it's a very long one by the way so the problem with 3a and  statistic it's usually that is very system-specific and vendors are not not keen on giving away  documentation on those things but 3a and tuning is very important time's up so I'll be very quick  okay thank you so what is the situation with IP3 is Intel behaving well in this case and is  Intel providing documentation I would not say that is yeah it's providing documentation they're  doing in a way that they are doing development on mainline so we have the driving staging and it  comes with documentation on the parameter and everything as far as I know there are no private  IUCT else which are vendor-specific so that's a good thing so yeah Intel is doing good on that  in this case and we want more vendors to do that because lib camera works only on mainline and  standard beautiful Linux interface okay thank you
Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__0_167.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__168_503.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__504_839.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__840_1415.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__1416_1499.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__1500_2579.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__2580_2843.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__2844_2891.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__2892_3707.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__3708_5795.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__5796_6563.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__6564_6743.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__6744_7175.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__7176_8351.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__8352_9299.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__9300_9947.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__9948_11099.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__11100_11735.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__11736_14843.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__14844_15671.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__15672_17279.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__17280_18311.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__18312_20543.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__20544_24875.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__24876_25763.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__25764_28295.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__28296_28559.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__28560_29063.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__29064_29111.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__29112_30875.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__30876_30959.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__30960_31019.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__31020_31499.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__31500_31583.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__31584_36743.png Complex_cameras_are__were___complex_How_to_make_complex_cameras_easier__an_update_from_the_Libcamer__36744_36859.png