[Bug 704083] New: Improve GstBuffer/GstVideoFrame mappings for HW surfaces

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704083
  GStreamer | common | git

           Summary: Improve GstBuffer/GstVideoFrame mappings for HW
                    surfaces
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: common
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: gb.devel at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Hi, in context of hardware surfaces, a GstBuffer map would imply a surface read
(download) or write (upload) only. So, implementing GST_MAP_READWRITE might be
sub-optimal. Indeed, for correctness, RW mappings should be implemented as
surface download on map, and surface upload/commit on unmap.

For most decoders, that don't care of the initial contents since we are only
going to make the whole frame dirty, this would be suboptimal because the
initial surface download on map would not be necessary.

I would suggest two things.

GstBuffer layer. Add a flag to notify the GstMemory handlers that on
GST_MAP_READWRITE, we are going to effectively read from the buffer, prior to
writing to it. e.g. GST_MAP_READ_FIRST. In this case, GST_MAP_READWRITE could
mean read for "intermediate" operations to the caller and next write/commit on
un-map.

GstVideoFrame layer. Add an argument to specify the expected dirty rectangle
when we call gst_video_frame_map(). That way, the implementation could know
whether downloading from the HW surface is necessary or not. By dirty, I mean
that region is going to be trashed and we don't care of reading from it
initially.

WDYT?

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