[09:48] <svarbanov> hverkuil: Hi Hans, venus has few encoder patches which I cannot find in any pull request, are you just missed them?
[09:50] <hverkuil> There were quite a few still-in-progress venus patches, so it is likely that I postpone processing them until it was settled.
[09:50] <hverkuil> If you mail me a list of patches (ideally in the form of patchwork links) that are ready for merging, then I'll make a pull request for it today.
[09:52] <svarbanov> hverkuil: sure I will send you a list of Acked patches, thanks!
[09:54] <svarbanov> hverkuil: if you think it is better I can create a branch and make pull requests to you in the future?
[09:57] <hverkuil> svarbanov: let me get back to you on that later.
[15:26] <hverkuil> tfiga: can you reply to my last email about 'venus: amend buffer size for bitstream plane'? https://patchwork.linuxtv.org/patch/53145/
[15:31] <svarbanov> hverkuil: we already have driver s5p-mfc which use sizeimage provided by userspace (but it clamps between some values, i.e. sanitize sizeimage), see https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L420
[15:31] <hverkuil> svarbanov: that's not according to the spec either.
[15:32] <hverkuil> Also, that driver predates (I believe) VIDIOC_CREATE_BUFS.
[15:34] <hverkuil> My main problem is that I don't know what the point of this 'feature' is. The driver knows the hardware and so should come up with a suitable value.
[15:34] <ezequielg> hverkuil: tfiga: so, as per the spec sizeimage for compressed formats is an upper limit.
[15:34] <ezequielg> and it seems the user can't set a smaller sizeimage
[15:35] <hverkuil> ezequielg: you're talking now about the mfc driver?
[15:35] <ezequielg> i'm talking about the spec :-)
[15:35] <hverkuil> V4L2 spec or the stateful codec spec?
[15:36] <svarbanov> hverkuil: I understand your point. I do expect that the userspace will know what is the maximum supported resolution and can guess better then driver what could happen in case of Dynamic resolution change
[15:36] <ezequielg> V4L2 spec
[15:36] <ezequielg> sizeimage in struct v4l2_pix_format and struct v4l2_pix_format_mplane
[15:37] <ezequielg> in the context of the s5p-mfc discussion here
[15:37] <hverkuil> In the v4l2 spec the driver sets sizeimage, never the application. That sizeimage is a lower limit: all buffers must be at least this size.
[15:38] <ezequielg> i think tfiga was suggeting to accept smaller than maximum sizeimage values, when he reviewed the JPEG encoder
[15:39] <ezequielg> and I was about to do the same as s5p-mfc, make the driver set sizeimage if the user passes a nil-valued field. and otherwise, accept the application-defined value.
[15:39] <ezequielg> but I see now that the spec says otherwise :-)
[15:39] <hverkuil> JPEG is very different from MPEG: the buffer should be large enough to contain a single compressed worst-case JPEG image.
[15:41] <hverkuil> MPEG (and H264 etc) is a bitstream, so for a stateful codec the size doesn't matter as much.
[15:43] <svarbanov> hverkuil: the other point for this is that for example Venus cannot (or at least I think it is not possible) to support CREATE_BUFS for the decoder OUTPUT queue because I need to register buffer addresses before start_streaming
[15:45] <hverkuil> svarbanov: I see no reason why you can't support CREATE_BUFS. What you can't support is adding new buffers with CREATE_BUFS. But it should be fine to use CREATE_BUFS as a direct REQBUFS replacement.
[15:49] <svarbanov> hverkuil: it is a firmware limitation, if you start the buffer interaction you cannot add new buffers in input decoder queue, but you can add buffers in decoder output queue
[15:50] <hverkuil> svarbanov: so that's fine. Just return an error if someone attempts to add new buffers. But CREATE_BUFS is fine as a REQBUFS replacement.
[15:50] <svarbanov> hverkuil:  if you are talking about CREATE_BUFS before STREAMON that will work
[15:51] <hverkuil> yes.
[16:21] <huangd> Hello, question about V4L2_BUF_FLAG_LAST for m2m drivers. Is it supported for the application to pass this flag to driver on OUTPUT queue to inform that this is the last OUTPUT data? Currently on k4.18 and I can see it's not zeroed and does get passed to driver, but documentation only indicates driver setting this flag on CAPTURE queue.
[16:44] <hverkuil> huangd: no, that's not allowed. This flag is specific to the CAPTURE data and is set by the driver.
[16:45] <hverkuil> It should really be cleared when a buffer is queued. It's cleared when you queue a capture buffer, but not when you queue an output buffer.
[17:04] <huangd> kverkuil: Thanks for letting me know that. If that's the case, is there anyway to communicate something similar from application to driver? I'm working on a video decoder, and our hardware isn't able to discover the end of a stream on its own to set that flag on the last capture buffer.
[17:08] <hverkuil> Userspace will typically call VIDIOC_DECODER_CMD with command STOP to tell the decoder that there is no more data and that any pending output buffers should be processed.
[17:09] <hverkuil> See also the codec spec (work in progress), section 4.6.10: https://hverkuil.home.xs4all.nl/request-api/uapi/v4l/dev-decoder.html
[17:10] <hverkuil> I recommend you also post a message to the linux-media mailinglist describing that your HW codec (which HW by the way?) can't detect the end-of-stream marker.
[17:10] <hverkuil> We may have to add some capability to signal userspace about this.
[18:01] <huangd> hverkuil: HW is Imagination D5520. Thanks for the link to the codec spec, I'll adjust my driver to fit the drain model especially and message the mailing list.
[18:01] <huangd> New question for the same driver, we're currently reusing capture buffers as the driver's reference buffers, meaning that we need to allocate at least enough capture buffers for them to not have to be recycled before the end of a GOP. Looks like we can extract that number needed from sps, but that'd require us to reqbufs and queue at least one output buffer before we can reqbufs the capture buffers. Is there a better way about this, and is this an acceptable
[18:01] <huangd> behavior?