On Fri, Feb 14, 2025 at 09:57:08AM -0500, Nicolas Dufresne wrote: > Le vendredi 14 février 2025 à 07:08 +0000, Sakari Ailus a écrit : > > Hi Zhaoxuan, > > > > On Fri, Feb 14, 2025 at 12:19:23PM +0800, Zhaoxuan Zhai wrote: > > > Hi all, > > > > > > Sorry I made a mistake. It should be VIDIOC_ENUM_FRAMESIZES instead of > > > VIDIOC_ENUM_FMT. I'm sorry for the mistake. > > > > > > 在 2025/2/14 12:08, Zhaoxuan Zhai 写道: > > > > Hi all, > > > > > > > > We are working on a camera driver. We plan to use v4l2 interface to send > > > > image data to users. We have a question we'd like to ask. > > > > > > > > The situation we are facing is as follows. > > > > > > > > We have an image processing unit that can process raw data collected by > > > > the sensor into the V4L2_PIX_FMT_NV12M format and send it to the user. > > > > > > > > However, due to the requirements of the V4L2_PIX_FMT_NV12M format, the > > > > width and height of the image must be divisible by 16. > > > > > > > > For example, when the sensor provides an image size of 2104x1560, after > > > > NV12M encoding, it should be pading to 2112x1566. But the additional 8 > > > > rows and 8 columns are padded with 0s and contain no actual content. > > > > > > > > So, we would like to ask, in this case, what size should we list in > > > > VIDIOC_ENUM_FMT? Should it be the actual image size with content, > > > > 2104x1560, or the padded size, 2112x1566?" > > > > I'd say the actual image size (i.e. where you have pixel data). The > > sizeimage field needs to reflect the padding and the user needs to be aware > > how the data is laid out in memory. > > I'd be happy to see spec clarification in this regard. I also think > that image size is best. Which part of the spec do you think should be clarified ? I've always thought that ENUM_FMT should report the image dimensions, with padding being reported through bytesperline and sizeimage. Is there a place where we say something else ? If so that should indeed be fixed. > For NV12M, you can absorb the padding in per plane bytesperline / > sizeimage of the v4l2_format structure. That means the enumerated size > will match the format. Though, for NV12 (single plane) you'd have to > set at least the padded height and implement the SELECTION API to > return the cropping area. NV12 is indeed ambiguous, as vertical padding reported by sizeimage could be just at the end of the image, or split between planes. > In practice, for application point of view, it would all have been > easier if the v4l2_format was always padded width/height, with the > display dimension explicitly provided. But I'm pretty sure upstream > drivers implement a mix. > > > Also cc Hans. -- Regards, Laurent Pinchart
