Re: [RFC] Motion Detection API

Sylwester Nawrocki
2013-06-09T17:56:28Z

Hi Sakari,

On 06/03/2013 03:25 AM, Sakari Ailus wrote:
> On Wed, May 22, 2013 at 11:41:50PM +0200, Sylwester Nawrocki wrote:
>> [...]
>>>>> I'm in favour of using a separate video buffer queue for passing
>>>>> low-level
>>>>> metadata to user space.
>>>>
>>>> Sure. I certainly see a need for such an interface. I wouldn't like to
>>>> see it
>>>> as the only option, however. One of the main reasons of introducing
>>>> MPLANE
>>>> API was to allow capture of meta-data. We are going to finally prepare
>>>> some
>>>> RFC regarding usage of a separate plane for meta-data capture. I'm not
>>>> sure
>>>> yet how it would look exactly in detail, we've just discussed this topic
>>>> roughly with Andrzej.
>>>
>>> I'm fine that being not the only option; however it's unbeatable when it
>>> comes to latencies. So perhaps we should allow using multi-plane buffers
>>> for the same purpose as well.
>>>
>>> But how to choose between the two?
>>
>> I think we need some example implementation for metadata capture over
>> multi-plane interface and with a separate video node. Without such
>> implementation/API draft it is a bit difficult to discuss this further.
>
> Yes, that'd be quite nice.

I still haven't found time to look into that, got stuck with debugging some
hardware related issues which took much longer than expected..

> There are actually a number of things that I think would be needed to
> support what's discussed above. Extended frame descriptors (I'm preparing
> RFC v2 --- yes, really!) are one.

Sounds great, I'm really looking forward to improving this part and
having it
used in more drivers.

> Also creating video nodes based on how many different content streams there
> are doesn't make much sense to me. A quick and dirty solution would be to
> create a low level metadata queue type to avoid having to create more video
> nodes. I think I'd prefer a more generic solution though.

Hmm, does it mean having multiple buffer queues on a video device node,
similarly to, e.g. the M2M interface ? Not sure if it would have been a bad
idea at all. The number of video/subdev nodes can get ridiculously high in
case of more complex devices. For example in case of the Samsung Exynos
SoC imaging subsystem the total number of various device nodes is getting
near *30*, and it is going to be at least that many for sure once all
functionality is covered.

So one video node per a DMA engine is probably fair rule, but there might
be reasons to avoid adding more device nodes for covering "logical" streams.

Regards,
Sylwester