[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 #22 from Gwenole Beauchesne <gb.devel at gmail.com> 2014-11-20 16:24:20 UTC ---
(In reply to comment #21)
> (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?

s/sink/sync/ :)

Nevermind, I found an easy place for it, where "it" = sync to VA surface if
element wants the VA surface id.

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