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. 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. 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. Besides, I have been thinking of allowing application/libs to request an additional meta-data plane, which would be driver-specific. For instance it turns the Samsung S5C73M3 camera can send meta-data for YUV formats as well as for interleaved JPEG/YUV. [1] http://git.linuxtv.org/v4l-utils.git/commit/ced1be346fe4f61c864cba9d81f66089d4e32a56 Regards, Sylwester -- 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
