[RFC] media: v4l2: Variable length controls (for h265 slice headers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux