GNOME Bugzilla – Bug 733242
Fix issue of mem map
Last modified: 2014-07-23 22:21:52 UTC
I noticed this patch from tizen that seems to be required for my use case (vaapidecode ! videoconvert ! xvimagesink for example). When flags==GST_MAP_READ, this test fails. https://build.tizen.org/package/view_file?expand=1&file=0001-Fix-issue-of-mem-map.patch&package=gstreamer-vaapi&project=Tizen%3AMobile
Hi, (In reply to comment #0) > I noticed this patch from tizen that seems to be required for my use case > (vaapidecode ! videoconvert ! xvimagesink for example). When > flags==GST_MAP_READ, this test fails. > > https://build.tizen.org/package/view_file?expand=1&file=0001-Fix-issue-of-mem-map.patch&package=gstreamer-vaapi&project=Tizen%3AMobile I am not convinced by this one. The correct condition I initially had in mind and really wanted to make "unsupported" was requested map-flags == R/W but no direct-rendering was supported. There is a more general core GStreamer bug around to ensure that we deprecate plain R/W flags but rather have a notion of write-first+eventually-read or read-modify-write.
Marking it as duplicate of bug #704078 as R/W mappings are tracked here. *** This bug has been marked as a duplicate of bug 704078 ***
commit c3643b42a44f57b76af95596383e3ff2f88c24be Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Thu Jul 24 00:14:04 2014 +0200 vaapivideomemory: forbid R/W mappings if non direct-rendering mode. Disable read-write mappings if "direct-rendering" is not supported. Since the ordering of read and write operations is not specified, this would require to always download the VA surface on _map(), then commit the temporary VA image back to the VA surface on _unmap(). Some SW decoding plug-in elements still use R/W mappings though. https://bugzilla.gnome.org/show_bug.cgi?id=733242