[Bug 724630] v4l2videodec: alignment support

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Feb 25 14:32:19 PST 2014


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

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #1 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-02-25 22:53:38 UTC ---
Took me a while to understand what you are trying to do, but I finally got that
the problem you are facing is in fact that you driver produces planar format
stored in a single buffer, but add some extra (non-standard) padding between
planes.

[ Y plane ]
--- padding Y
[ U plane ]
--- padding U
[ V plane]
--- padding V

Something that comes to my mind is that the new v4l2_plane API has been written
exactly to solve this kind of issue. Why can't your newly written driver use
the multi-planar API instead of guessing the padding this way ? How can we be
certain that for all drivers that the padding after Y, U and V will be uniform
? I could easily see drivers implementer that decide that their alignment is
the default for the format, but add extra padding only at the end. In this case
increasing the height the way you do to compute offset with uniform padding
will not work.

If instead you port your driver to the MPLANE API, you can set memory offset
and plane size for each of the plane and remove this problem. The memory can be
two seperate blocks but can also be from the same block, it does not matter
(some work needed for dmabuf, but probably not that much).

Let me know what you think of this, but so far I'm worried about this patch.

-- 
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.


More information about the gstreamer-bugs mailing list