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

[GStreamer (bugzilla.gnome.org)]

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

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |slomo at circular-chaos.org
     Ever Confirmed|0                           |1

--- Comment #2 from Sebastian Dröge <slomo at circular-chaos.org> 2013-07-15 05:46:45 UTC ---
(In reply to comment #0)

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

Sounds like a good idea IMHO :)

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

This seems a bit complicated, not sure if it's worth it? Also what would the
API look like? What if you want multiple dirty rectangles?

(In reply to comment #1)
> Of course, the other solution could also be to fix gst-ffmpeg/libav to to call
> gst_video_frame_map() with GST_MAP_WRITE only, instead of GST_MAP_READWRITE.
> That probably could be simpler than updating the GstVideoFrame API. :)

That won't be correct as libav is using our buffers also for reading (e.g. for
reference frames).

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