GNOME Bugzilla – Bug 796986
v4l2convert can't import padded DMA buffers
Last modified: 2018-11-03 15:32:43 UTC
gst_v4l2_object_set_format already handles VIDIOC_S_FMT returning larger than requested buffers, and sets GstVideoMeta appropriately for the added padding. This happens for example for v4l2videodec, which can produce buffers padded to macroblock alignment. Currently such padded DMA buffers can't be imported info v4l2convert, as the OUTPUT queue format is set to the visible size, which causes VIDIOC_QBUF to fail with the incompatible larger DMA buffers. A gst_v4l2_object_set_format variant is needed that gets passed the padding information obtained from GstVideoMeta, to actually request a compatible format at the importing OUTPUT queue. I'm unsure whether the parameter added to this _set_format variant should be GstVideoMeta directly, a derived GstVideoInfo, or even GstVideoAlignment. Setting a padded queue format, and then setting the processed rectangle via the crop selection would allow v4l2convert to handle imported DMA buffers that are larger in either width or height than the negotiated visible size.
Created attachment 373372 [details] [review] v4l2object: add gst_v4l2_object_set_format_vmeta gst_v4l2_object_set_format already can handle VIDIOC_S_FMT returning larger than requested buffers, and set GstVideoMeta appropriately for the added padding. This patch adds gst_v4l2_object_set_format_vmeta that can request a padded format explicitly from an imported buffer's video meta. This will allow elements that support cropping to import padded DMA buffers.
Created attachment 373373 [details] [review] v4l2transform: handle buffers with video meta When importing buffers that come with GstVideoMeta, set the padded format and use cropping to select the visible rectangle to process.
Review of attachment 373373 [details] [review]: I don't see any checks the we are importing. Am I missing something, or will that always reset the format of the is video meta? Note the I'm working on making buffer importation safe and dladaptative in the general case, not just for v4l2transform. I'll send a first release for review today, you might want to rebase on that. I haven't worked on the G_SELECTION aspect yet.
You are right, I'm missing a check that the buffer is actually imported. For buffer copies this shouldn't be necessary. I'll fix that and rebase onto your work.
For the context, my work (I'll CC soon) only act on bytesperline for now. The reason is that it's not clear if and how cameras could support "cropping". The definition of enum_frameinterval does not say anything about padded or visible size. In my case, I have a multiplanar importer behind v4l2src, so the height padding is not a problem. If you have planar format in a single importation buffer it no longer work and your change becomes complementary to mine, as it fills that gap.
Just making it dependant on bug #583890 for now. I'd like to test both together.
Ok, just need to rebase now. I'll start working on src pad stride adaption soon. All we need to do is make sure both stride and width/height adaptation can cohabit.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/501.