[libcamera-devel] [EXTERNAL] Re: Porting libCamera in to RDKC

[Laurent Pinchart]

Hi Vijay,

On Mon, Jun 08, 2020 at 02:30:08PM +0000, Dubey, Vijayanand wrote:
> Hi Laurent
> 
> Thanks for the response. RDKC's hardware platform is Ambarella (Armv7
> and Arm8 architecture).

Is there any public documentation about the hardware ? I had a quick at
https://www.ambarella.com/, are the camera-related chips co-processors
that need to be paired with a traditional SoC, or are they full ARM SoCs
? Will there be any upstream Linux kernel support for those products ?

> On 6/5/20, 9:09 PM, "Laurent Pinchart" <laurent.pinchart at ideasonboard.com> wrote:
> > On Fri, Jun 05, 2020 at 07:13:06PM +0000, Dubey, Vijayanand wrote:
> > > Hi,
> > >
> > > This is Vijay form RDK for Camera (RDKC) team in Comcast.
> >
> > Nice to meet you, and thanks for your interest in libcamera.
> >
> > > We are trying to understand how can we fit libCamera in our current
> > > architecture. In our current RDKC architecture as shown in the block diagram,
> > >
> > > [cid]
> > >
> > > camera  has process called xStreamer. It runs as a web server (producer )and
> > > provides H264 /PCM/G711/AAC/YUV data to client applications (e.g.;  live, cvr,
> > > video analytics etc.). Moreover it
> > >
> > >   ● Controls the encoding parameter
> > >   ● control single and multi-stream encoding
> > >   ● Overlay on stream
> > >
> > > Camera has separate processes  for Live, CVR and video analytics  which connect
> > > to xStreamer and send the request to configure the encoding  parameter and get
> > > the encoded or RAW AV data over socket.
> > >
> > > Based on our initial investigation of libCamera  architecture I have couple of
> > > questions
> > >
> > > It seems current architecture of  libCamera requires to have a single process
> > > with  all functionalities(Live/CVR/Analytics etc.) Is our understanding
> > > correct? If yes is their plan to support the RDKC use case in libCamera? In no
> > > how can we align RDKC architecture with libCamera?
> >
> > Your understanding is correct. While libcamera allows access to
> > different cameras from the same process, it doesn't support multiple
> > processes sharing the same camera concurrently.
> >
> > This is a feature we don't plan to add to libcamera at the moment, as we
> > consider it out of scope. libcamera is meant to be a low-level library
> > to control cameras, and especially computational cameras requiring
> > algorithms running on the main CPU. Sharing cameras between different
> > processes is a feature of a higher-level component in the stack. On
> > desktop Linux systems, pipewire will fulfil this (as well as offering
> > access control features), based on libcamera as the camera provider. I
> > believe embedded Linux systems would also benefit from pipewire usage.
> >
> > I would assume there are other middlewares that allow sharing cameras
> > between multiple processes. It maye make sense to add libcamera support
> > to one of such existing middlewares, or to develop a new one specific to
> > RDKC. I haven't researched this topic in details, so I can't tell which
> > option would be best, but I'm available for further discussions on this
> > topic.
> >
> > Which hardware platforms does RDKC officially support or plans to
> > support ?

-- 
Regards,

Laurent Pinchart