GNOME Bugzilla – Bug 735391
mpeg2dec: fix decoding into hardware-mapped buffers
Last modified: 2018-11-03 15:34:39 UTC
Make sure to commit decoded contents into hardware mapped buffers. In some situations, and for performance reasons actually, we might not be able to directly write into buffers backed by 3rdparty hardware. So, this means that we need to maintain some temporary surface/buffers and those are what are being exposed through GstVideoMeta info. Then, internally, the implementation may decide to efficiently convert that into a native format instead. More precisely, VA-API exposes a vaDeriveImage() API but it might not always be efficient to directly expose GPU memory buffers. So, a temporary surface suitable for CPU interop is being exposed instead. This same happens for VDPAU where there is no direct rendering API, so a temporary image is being used and exposed. In practice, we just need to carefully maintain map/unmap chains. On map, a clean writable memory buffer is being exposed. On unmap, the contents written by the SW decoder is to be committed. Then, if the frame is to be used again (as reference for example), then it can be mapped again, but with read-only flags this time.
Created attachment 284423 [details] [review] mpeg2dec: fix decoding into hardware-mapped buffers
We could also consider this as the mpeg2 SW decoder fix to bug #704083. Though, the "commit" phase, i.e. unmap still needs to be paired.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/issues/8.