ndufresne: hi, I think we already discussed this at some point, but do you know why gst may not set the sizeimage for planes? https://hastebin.com/kadiyawire.hs
look at he plane_fmt in the second ioctl
I would also like to understand why is choosing NV21M (NM21) as decoder capture and NV21 (single-planar) for converter output instead of NV12M that's supported by both
javier__: simply because userspace is not supposed to
the driver is suppose to override it, it's a security threat to use buffer sizes from usespace
javier__: that being said, we do set the size for encoded formats
javier__: for the NV12 thingy, I don't think I understand
it should try and choose the best fit, now NV12M and NV12 is an idiocy brought by the requirement of being backward compatible
This does not fit well with GStreamer (and most other library) who does not have multiple representation of NV12
ndufresne: re: user-space not supposed too - right, but in the other ioctls sizeimage != 0
I'm asking because later gst fails with:
0:00:01.029560206   785    0xf4320 WARN                    v4l2 gstv4l2object.c:4166:gst_v4l2_object_decide_allocation:<v4l2video0dec0> error: Video device did not suggest any buffer size.
javier__: I said, we do set it for encoded format,  pixelformat=v4l2_fourcc('H', '2', '6', '4'),
we do that, because other then CODA, no driver are able to estimate the maximum encoded framesize
javier__: ideally, we'd also have a ring buffer exposed for encoded (byte stream) formats
ndufresne: ah, sorry I missed that comment
coda estimation is quite naïve though, but it seems to work so far
right now, the size we request is likely too small for 4K and more
ndufresne: right, you mentioned before that I should look at coda to see how they estimate the decoded frame size
that's possible, or just have a chat with pH5
maybe you could come up with something shared between drivers, there is no HW specific code in Philipp's estimator
ndufresne: thanks, I will. And what's the solution for the other issue? v4l2 having different representations for multi-planar and single-planar but gst not having it?
javier__: in gst, what I'm trying to do (and hopefully it works) is to always choose MPLANE where supported
but there is no code to try and figure-out if you do DMABuf importation or USERPTR
to be honnest, if we don't port all driver with multi-planar support to mplane, userspace won't always be able to figure-out
that's my opinion, but basically, if we don't deprecate the old nethod at some point, I don't think we'll progress much on this field
ndufresne: that code to choose mplane if supported is how gst is supposed to work already in mainline or out-of-tree code you are working on?
it's already in mainline, it's trial and error
ndufresne: Ok, thanks for the info. I'll look at that
ndufresne: one last question, S_FMT for s5p-mfc capture queue currently returns -EBUSY in mainline
in that case how gst estimated the decoded frame size?
ndufresne: nvm, I know what happens