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? Best regards, Tomasz