Hi all I am developing a H265 V4L2 stateless decoder. After some experimentation it looks like the best way to achieve performance would be to submit bitstream data for an entire frame in a single buffer with an array of slice headers that point into it. The number of slices in a frame can be very variable, often there will be just one, in nearly all cases there will be less than 16 but the worst case could be hundreds (actually theoretically it could be thousands but I'm prepared to, and it is probably sensible to, reject any stream that looks like this). Given the large range of possible array sizes a (large) fixed length array is very wasteful and probably slow in nearly all cases. As it stands V4L2 has no variable length structure so there is a problem here. My experience with v4l2 controls in minimal so trying to add a variable length array control myself seems brave. Luckily (in other channels) I was told "Hans offered multiple times to implement variable array controls himself, he just needs someone to send an RFC with details on what's needed." so here I am. So as a suggestion for the interface: >From the user point of view: Only the last dimension of the array can be dynamic (like a C array "int a[10][15][];") Otherwise we add a lot of complexity. VIDIOC_S_EXT_CTRLS In v4l2_ext_control the user can pass in any size that is a multiple of the element size. If greater than the max then .size is set to the max by the ioctl on return. VIDIOC_G_EXT_CTRLS On entry .size contains the buffer size to receive the values and on return it contains the size actually wanted - if the buffer can contain the data then it is also the number filled in. VIDIOC_QUERY_EXT_CTRLS Add a flag to indicate variable length and either use .maximum/.minimum or some of the currently reserved structure to give max/min sizes >From the driver point of view - frankly anything will do as long as I can find out how many headers I have. I think it is probably a good idea to dynamically allocate the storage for such an array rather than having a fixed size block on the end of the ctrl structure to avoid unnecessary overallocation. I imagine that I've missed many important details in the sketch above, but probably good to start the discussion and Hans, am I trying to take you up on an offer you didn't actually make? Regards John Cox
