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

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704083
  GStreamer | gstreamer (core) | git

--- Comment #21 from Gwenole Beauchesne <gb.devel at gmail.com> 2014-11-20 16:20:18 UTC ---
(In reply to comment #20)
> (In reply to comment #0)
> > 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.
> 
> I think the GLMemory design is smarter then this and that it should serve as
> inspiration. Basically, I think unmap() should never do anything other then
> setting flags or state.

That's indeed similar to the "locality" flags I had in mind, e.g. IN_SURFACE,
IN_IMAGE, as in "where does the up-to-date frame sit?". However, how could we
handle pipelines like swdec ! hwpostproc ! swpostproc ! hwsink? are we
guaranteed to get called through some ::mem_copy() hook where we could sink
states?

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