[Bug 735391] New: mpeg2dec: fix decoding into hardware-mapped buffers

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735391
  GStreamer | gst-plugins-ugly | git

           Summary: mpeg2dec: fix decoding into hardware-mapped buffers
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-ugly
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: gb.devel at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Make sure to commit decoded contents into hardware mapped buffers. In some
situations, and for performance reasons actually, we might not be able to
directly write into buffers backed by 3rdparty hardware. So, this means that we
need to maintain some temporary surface/buffers and those are what are being
exposed through GstVideoMeta info. Then, internally, the implementation may
decide to efficiently convert that into a native format instead.

More precisely, VA-API exposes a vaDeriveImage() API but it might not always be
efficient to directly expose GPU memory buffers. So, a temporary surface
suitable for CPU interop is being exposed instead. This same happens for VDPAU
where there is no direct rendering API, so a temporary image is being used and
exposed.

In practice, we just need to carefully maintain map/unmap chains. On map, a
clean writable memory buffer is being exposed. On unmap, the contents written
by the SW decoder is to be committed. Then, if the frame is to be used again
(as reference for example), then it can be mapped again, but with read-only
flags this time.

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