Thanks for your answer > I think this should be handled in the same way as the output direction. We > are currently discussing this with several V4L developers. For output we have > to capture different data types to different buffers, running multiplexed on > the bus, e.g. over CSI-2. Using the MPLANE API would be one option, but you > don't want to define a new pixel format for each combination of each > standard pixel format with each accompanying data type, be it metadata or > anything else. So, you would have to add support for per-plane format, > which would contradict the current MPLANE API concept. Dont know what are the other use cases you are discussing But in our case there is only one combination: The first plane should contain the header data, and the second one should contain the slice data At the end the compressed frame is just the concatenation of the first buffer (header) and the second one (slice data) So there is no reason to have multiple combinations in the future > > Therefore we're currently considering a different option of transferring > different buffer types via different buffer queues. Initially we thought about > simply using multiple video device nodes. That has a disadvantage when the > number of those streams is variable and potentially large. So, another option > is to add support for multiple buffer queues per video node. Those buffer > queues would then have to get some form of identification, perhaps a > stream ID. That stream ID would also be used to associate those streams to > links between subdevice pads. That's all still very raw... Quite a bit of design > and implementation work ahead. > In our case using separate buffer queues does not look very appropriate, because there is a strong ordering constraint, and we always want to get a header and slice data together So my current feeling is really that MPLANE is the best fit for our need Regards Sebastien -- 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
