Re: [RFC] Motion Detection API

Sakari Ailus
2013-05-08T16:26:53Z

Hi Sylwester,

On Tue, May 07, 2013 at 04:04:10PM +0200, Sylwester Nawrocki wrote:
> On 05/07/2013 02:35 PM, Hans Verkuil wrote:
> > A metadata plane works well if you have substantial amounts of data (e.g. histogram
> > data) but it has the disadvantage of requiring you to use the MPLANE buffer types,
> > something which standard apps do not support. I definitely think that is overkill
> > for things like this.
>
> Standard application could use the MPLANE interface through the libv4l-mplane
> plugin [1]. And meta-data plane could be handled in libv4l, passed in raw form
> from the kernel.
>
> There can be substantial amount of meta-data per frame and we were considering
> e.g. creating separate buffer queue for meta-data, to be able to use mmaped
> buffer at user space, rather than parsing and copying data multiple times in
> the kernel until it gets into user space and is further processed there.

What kind of metadata do you have?

> I'm actually not sure if performance is a real issue here, were are talking
> of 1.5 KiB order amounts of data per frame. Likely on x86 desktop machines
> it is not a big deal, for ARM embedded platforms we would need to do some
> profiling.
>
> I'm not sure myself yet how much such motion/object detection data should be
> interpreted in the kernel, rather than in user space. I suspect some generic
> API like in your $subject RFC makes sense, it would cover as many cases as
> possible. But I was wondering how much it makes sense to design a sort of
> raw interface/buffer queue (similar to raw sockets concept), that would allow
> user space libraries to parse meta-data.

This was proposed as one possible solution in the Cambourne meeting.

<URL:http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/36587>

I'm in favour of using a separate video buffer queue for passing low-level
metadata to user space.

> The format of meta-data could for example have changed after switching to
> a new version of device's firmware. It might be rare, I'm just trying to say
> I would like to avoid designing a kernel interface that might soon become a
> limitation.

On some devices it seems the metadata consists of much higher level
information.

--
kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk