On 10/09/2018 06:23 AM, Tomasz Figa wrote: > On Mon, Oct 8, 2018 at 9:22 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> On 09/19/2018 12:17 PM, Tomasz Figa wrote: >>> Hi Hans, >>> >>> On Thu, Jul 26, 2018 at 7:20 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: >>>> >>>> Hi Hans, >>>> >>>> On Wed, Jul 25, 2018 at 8:59 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>>>> >>>>> Hi Tomasz, >>>>> >>>>> Many, many thanks for working on this! It's a great document and when done >>>>> it will be very useful indeed. >>>>> >>>>> Review comments follow... >>>> >>>> Thanks for review! >>>> >>>>> >>>>> On 24/07/18 16:06, Tomasz Figa wrote: >>> [snip] >>>>>> +13. Allocate destination (raw format) buffers via :c:func:`VIDIOC_REQBUFS` >>>>>> + on the ``CAPTURE`` queue. >>>>>> + >>>>>> + * **Required fields:** >>>>>> + >>>>>> + ``count`` >>>>>> + requested number of buffers to allocate; greater than zero >>>>>> + >>>>>> + ``type`` >>>>>> + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE`` >>>>>> + >>>>>> + ``memory`` >>>>>> + follows standard semantics >>>>>> + >>>>>> + * **Return fields:** >>>>>> + >>>>>> + ``count`` >>>>>> + adjusted to allocated number of buffers >>>>>> + >>>>>> + * The driver must adjust count to minimum of required number of >>>>>> + destination buffers for given format and stream configuration and the >>>>>> + count passed. The client must check this value after the ioctl >>>>>> + returns to get the number of buffers allocated. >>>>>> + >>>>>> + .. note:: >>>>>> + >>>>>> + To allocate more than minimum number of buffers (for pipeline >>>>>> + depth), use G_CTRL(``V4L2_CID_MIN_BUFFERS_FOR_CAPTURE``) to >>>>>> + get minimum number of buffers required, and pass the obtained value >>>>>> + plus the number of additional buffers needed in count to >>>>>> + :c:func:`VIDIOC_REQBUFS`. >>>>> >>>>> >>>>> I think we should mention here the option of using VIDIOC_CREATE_BUFS in order >>>>> to allocate buffers larger than the current CAPTURE format in order to accommodate >>>>> future resolution changes. >>>> >>>> Ack. >>>> >>> >>> I'm about to add a paragraph to describe this, but there is one detail >>> to iron out. >>> >>> The VIDIOC_CREATE_BUFS ioctl accepts a v4l2_format struct. Userspace >>> needs to fill in this struct and the specs says that >>> >>> "Usually this will be done using the VIDIOC_TRY_FMT or VIDIOC_G_FMT >>> ioctls to ensure that the requested format is supported by the >>> driver." >>> >>> However, in case of a decoder, those calls would fixup the format to >>> match the currently parsed stream, which would likely resolve to the >>> current coded resolution (~hardware alignment). How do we get a format >>> for the desired maximum resolution? >> >> You would call G_FMT to get the current format/resolution, then update >> width and height and call TRY_FMT. >> >> Although to be honest you can also just set pixelformat and width/height >> and zero everything else and call TRY_FMT directly, skipping the G_FMT >> ioctl. >> > > Wouldn't TRY_FMT adjust the width and height back to match current stream? Huh. Hmm. Grrr. Good point and I didn't read your original comment carefully enough. Suggestions on a postcard... Regards, Hans
