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@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
