[Bug 704083] New: Improve GstBuffer/GstVideoFrame mappings for HW surfaces
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Jul 12 04:37:58 PDT 2013
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.
More information about the gstreamer-bugs
mailing list