On Tue, Aug 21, 2018 at 8:29 PM Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> wrote: > > Hi Tomasz, > > On 08/08/2018 05:55 AM, Tomasz Figa wrote: > > On Tue, Aug 7, 2018 at 4:37 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > >>>>>>> +7. If all the following conditions are met, the client may resume the > >>>>>>> + decoding instantly, by using :c:func:`VIDIOC_DECODER_CMD` with > >>>>>>> + ``V4L2_DEC_CMD_START`` command, as in case of resuming after the drain > >>>>>>> + sequence: > >>>>>>> + > >>>>>>> + * ``sizeimage`` of new format is less than or equal to the size of > >>>>>>> + currently allocated buffers, > >>>>>>> + > >>>>>>> + * the number of buffers currently allocated is greater than or equal to > >>>>>>> + the minimum number of buffers acquired in step 6. > >>>>>> > >>>>>> You might want to mention that if there are insufficient buffers, then > >>>>>> VIDIOC_CREATE_BUFS can be used to add more buffers. > >>>>>> > >>>>> > >>>>> This might be a bit tricky, since at least s5p-mfc and coda can only > >>>>> work on a fixed buffer set and one would need to fully reinitialize > >>>>> the decoding to add one more buffer, which would effectively be the > >>>>> full resolution change sequence, as below, just with REQBUFS(0), > >>>>> REQBUFS(N) replaced with CREATE_BUFS. > >>>> > >>>> What happens today in those drivers if you try to call CREATE_BUFS? > >>> > >>> s5p-mfc doesn't set the .vidioc_create_bufs pointer in its > >>> v4l2_ioctl_ops, so I suppose that would be -ENOTTY? > >> > >> Correct for s5p-mfc. > > > > As Philipp clarified, coda supports adding buffers on the fly. I > > briefly looked at venus and mtk-vcodec and they seem to use m2m > > implementation of CREATE_BUFS. Not sure if anyone tested that, though. > > So the only hardware I know for sure cannot support this is s5p-mfc. > > In Venus case CREATE_BUFS is tested with Gstreamer. Stanimir: Alright. Thanks for confirmation. Hans: Technically, we could still implement CREATE_BUFS for s5p-mfc, but it would need to be restricted to situations where it's possible to reinitialize the whole hardware buffer queue, i.e. - before initial STREAMON(CAPTURE) after header parsing, - after a resolution change and before following STREAMON(CAPTURE) or DECODER_CMD_START (to ack resolution change without buffer reallocation). Would that work for your original suggestion? Best regards, Tomasz
