Re: metadata node

[Stanimir Varbanov <stanimir.varbanov@linaro.org>]

Hi Guennadi,

On 01/11/2017 11:42 AM, Guennadi Liakhovetski wrote:
> Hi Laurent,
> 
> As you know, I'm working on a project, that involves streaming metadata, 
> obtained from UVC payload headers to the userspace. Luckily, you have 
> created "metadata node" patces a while ago. The core patch has also been 
> acked by Hans, so, I decided it would be a safe enough bet to base my work 
> on top of that.
> 
> Your patch makes creating /dev/video* metadata device nodes possible, but 
> it doesn't provide any means to associate metadata nodes to respective 
> video (image) nodes. Another important aspect of using per-frame metadata 
> is synchronisation between metadata and image buffers.  The user is 
> supposed to use buffer sequence numbers for that. That should be possible, 
> but might be difficult if buffers lose synchronisation at some point. As a 
> solution to the latter problem the use of requests with buffers for both 
> nodes has been proposed, which should be possible once the request API is 
> available.
> 
> An alternative approach to metadata support, e.g. heterogeneous 
> multi-plain buffers with one plain carrying image data and another plain 
> carrying metadata would be possible. It could also have other uses. E.g. 
> we have come across cameras, streaming buffers, containing multiple images 
> (e.g. A and B). Possibly both images have supported fourcc format, but 
> they cannot be re-used, because A+B now are transferred in a single 
> buffer. Instead a new fourcc code has to be invented for such cases to 
> describe A+B.
> 
> As an important argument in favour of having a separate video node for 
> metadata you named cases, when metadata has to be obtained before a 
> complete image is available. Do you remember specifically what those cases 
> are? Or have you got a link to that discussion?
> 
> In any case, _if_ we do keep the current approach of separate /dev/video* 
> nodes, we need a way to associate video and metadata nodes. Earlier I 
> proposed using media controller links for that. In your implementation of 

I don't think that media controller links is a good idea. This metadata
api could be used by mem2mem drivers which don't have media controller
links so we will need a generic v4l2 way to bound image buffer and its
metadata buffer.


-- 
regards,
Stan