[Bug 724630] New: v4l2videodec: alignment support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=724630
  GStreamer | gst-plugins-good | 1.x

           Summary: v4l2videodec: alignment support
    Classification: Platform
           Product: GStreamer
           Version: 1.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: hugues.fruchet at st.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=269534)
 View: https://bugzilla.gnome.org/attachment.cgi?id=269534
 Review: https://bugzilla.gnome.org/review?bug=724630&attachment=269534

v4l2object alignment support

Some hardware requires that their buffers are aligned both in width and height.
V4L2 is supporting this through G/S_FMT ioctl where:
- g_fmt.fmt.pix.width/height are the unaligned width/height (the area inside
the buffer where the valid pixels are)
- g_fmt.fmt.pix.bytesperline is the amount of bytes to skip to switch from one
line of the buffer to the next line (so it's the width aligned expressed in
bytes)
- g_fmt.fmt.pix.sizeimage is the total size of buffer (aligned, from which we
can deduce the aligned height)

In Gstreamer, alignment is managed through video meta inside "info" structure.
gst_video_info_align(info, align) can be used to set the alignment constraint
(padding at right and bottom) inside info.

** Explanations of attached patch proposal:
* gst_v4l2_object_get_v4l2_alignment have been introduced to convert the V4L2
bytesperline & sizeimage informations into aligned width and height in pixels,
based on pixel format (quite painfull but not found a better way to do it).
I have not tested all the pixel formats (only NV12 on my hardware), and Samsung
Exynos 64x32 tiled format must be added.

* Exynos driver is using G_CROP to return the unaligned width/height while
G_FMT returns aligned width/height. Functionally it's a bit different as G_CROP
aims to express a window of interest inside the buffer (such as we can
encounter in H264 streams for ex. and is not related to hardware alignment
constraint). Nevertheless, I have tried to make the code compatible with both
approaches (anyway some tests are needed with Samsung hardware to check that
nothing was broken).

* in gst_v4l2_buffer_pool_alloc_buffer, a change was also needed to ensure
right computation of "offset" in case of non multi-planar:
-          else
-            offs += obj->bytesperline[i] *
-                GST_VIDEO_FORMAT_INFO_SCALE_HEIGHT (finfo, i, height);
height is wrong here, it should be height aligned.
In fact it seems that this function aims to compute the right offset and stride
arrays to give to gst_buffer_add_video_meta_full, but the "info" structure
already contains the correct ones (at least in case of non-multiplanar and
after having called gst_video_info_align with right alignment). So what have
been done in this patchset is not doing the extra computation in case of
non-multiplanar and give directly the stride & offset arrays from "info" to
gst_buffer_add_video_meta_full.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.