Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Hans,

On Wednesday, 23 May 2018 19:19:37 EEST Hans Verkuil wrote:
> On 18/05/18 13:24, Mauro Carvalho Chehab wrote:
> > One of the biggest reasons why we decided to start libv4l project,
> > in the past, was to ensure an open source solution. The problem we
> > faced on that time is to ensure that, when a new media driver were
> > added with some proprietary output format, an open source decoding
> > software were also added at libv4l.
> > 
> > This approach ensured that all non-MC cameras are supported by all
> > V4L2 applications.
> > 
> > Before libv4l, media support for a given device were limited to a few
> > apps that knew how to decode the format. There were even cases were a
> > proprietary app were required, as no open source decoders were available.
> > 
> > From my PoV, the biggest gain with libv4l is that the same group of
> > maintainers can ensure that the entire solution (Kernel driver and
> > low level userspace support) will provide everything required for an
> > open source app to work with it.
> > 
> > I'm not sure how we would keep enforcing it if the pipeline setting
> > and control propagation logic for an specific hardware will be
> > delegated to PipeWire. It seems easier to keep doing it on a libv4l
> > (version 2) and let PipeWire to use it.
> 
> I've decided not to attend this meeting. It is not quite my core expertise
> and it is a bit too far to make it worth my time. If there are good reasons
> for me being there that I missed, then please let me know asap and I might
> reconsider this.
> 
> What I would like to say though it that I think libv4l is a bit of a dead
> end and probably not suitable for adding support for this.
> 
> Currently libv4l2 is too intertwined with libv4lconvert and too messy.
> Its original motivation was for converting custom formats and that is
> mostly obsolete now that UVC has standardized formats to just a few.
> 
> I think a core library is needed that provides the basic functionality
> and that can be used directly by applications if they don't want to use
> v4l2_open() and friends.
> 
> I.e. it should be possible for e.g. gstreamer to use this core library
> to easily configure and use the MC instead of having to call v4l2_open()
> etc. and rely on magic code to do this for them. It's simply ugly to
> overload mmap with v4l2_mmap or to emulate read() if the driver doesn't
> support it.
> 
> We might still have a libv4l2-like library sitting on top of this, but
> perhaps with limited functionality. For example, I think it would be
> reasonable to no longer support custom formats. If an application wants
> to support that, then it should call conversion functions for the core
> library explicitly. This has the big advantage of solving the dmabuf
> and mmap issues in today's libv4l2.

I agree with all that. I also believe we need to design a clean solution 
without caring about the existing libv4l2 API, and then implement a 
compatibility layer on top of our new library. The way to move away from the 
stone age is to design a new technology for the future, and then help the past 
climb on the bandwagon.

-- 
Regards,

Laurent Pinchart