build: rename USE_HEVC_DECODER to USE_H265_DECODER

Rename to be consistent with H.264 and also H.265 encoder. The
meson build assumed this was already consistently named, and so
previously was not able to actually build the H.265 decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=778576

meson: gstreamer-codecparsers is a required dep

Just like in configure.ac.

meson: dist meson build files

Ship meson build files in tarballs, so people who use tarballs
in their builds can start playing with meson already.

libs: encoder: vp8: add CBR encoding mode

This patch enables the Constant BitRate encoding mode in VP8 encoder.
Basically it adds the configuration parameters required by libva to
CBR enconding.

Original-Patch-By: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749950

libs: encoder: vp8: fix bitrate calculation

Base encoder's unit of bitrate is in Kbps. We should honor it so
we use the value of bitrate in VA, in which is expressed in bps.

https://bugzilla.gnome.org/show_bug.cgi?id=749950

plugins: fix build when gcc

In commit a8e482f9 we added a function without parameters, but gcc
doesn't like that.

vaapi: add meson build

https://bugzilla.gnome.org/show_bug.cgi?id=778250

make: remove gstvaapiversion.h generation

https://bugzilla.gnome.org/show_bug.cgi?id=778250

plugins: use linear storage if not the same device

When dmabuf is negotiated downstream and decoding and rendering are
not done on the same device, the layout has to be linear in order for
the memory to be shared accross devices, since each device has its
own way to do tiling.

Right now this code is rather just a to-do comment, since we are not
fetching the device ids.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

libs: utils: add HEVC profiles representation

https://bugzilla.gnome.org/show_bug.cgi?id=778318

libs: decoder: h264: reduce frame number of gaps

Reduce frame num gaps so that we don't have to create unnecessary
dummy pictures, just throw them away.

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777506

vaapidecode: don't GLTextureUpload if dmabuf

Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
element can handle dmabuf-based buffers, avoiding its negotiation.

vaapidecode: make pool to export decoder's surface

Use new -base API gst_video_decoder_allocate_output_frame_full() to
pass the current proxy/surface to the pool.

The pool will will export thins given surface instead of exporting a
brand new surface that will never be filled in with meaningfull data.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

plugins: decoder can negotiate dmabuf downstream

vaapivideobufferpool: override acquire_buffer()

Overriding the vmethod acquire_buffer() it is possible to attach the
right GstMemory to the current acquired buffer.

As a matter of fact, this acquired buffer may contain any instantiated
GstFdmemory, since this buffer have been popped out from the buffer
pool, which is a FIFO queue. So there is no garantee that this buffer
matches with the current processed surface. Evenmore, the VA driver
might not use a FIFO queue. Therefore, it is no way to guess on the
ordering.

In short, acquire_buffer on the VA driver and on the buffer pool return
none matching data, we have to manually attach the right GstFdMemory to
the acquired GstBuffer. The right GstMemory is the one associated with
the current surface.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapivideomemory: export surface if it is provided

gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it
had to create that surface. Now it can also export an already provided
surface. It is useful to export decoder's surfaces (from VA context).

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapivideobufferpool: add GstVaapiVideoBufferPoolAcquireParams

Useful to let the pool know the current surface proxy when calling
gst_buffer_pool_alloc_buffer() / gst_buffer_pool_acquire_buffer()

https://bugzilla.gnome.org/show_bug.cgi?id=755072

libs: surface: add gst_vaapi_surface_{set,peek}_buffer_proxy()

These functions are useful when a dmabuf-based memory is instantiated in
order to relate the generated buffer @proxy with the processed @surface.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

libs: bufferproxy: gst_vaapi_buffer_proxy_{set,peek}_mem()

This patch adds a GstMemory as a variable member of the buffer proxy,
because we will need to associate the buffer proxy with the memory
which exposes it. Later, we will know which memory, in the video buffer
pool, is attached to the processed surface.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapipostproc: don't GLTextureUpload if dmabuf

Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
element can handle dmabuf-based buffers, avoiding its negotiation.

Similar as "vaapidecode: do not add meta:GstVideoGLTextureUploadMeta
feature if can dmabuf"

https://bugzilla.gnome.org/show_bug.cgi?id=755072

plugins: enable DMAbuf allocator to downstream

If the negotiated caps are raw caps and downstream supports the
EGL_EXT_image_dma_buf_import extension, then the created allocator
is the DMAbuf, configured to downstream.

At this moment, the only element which can push dmabuf-based buffers
to downstream, is vaapipostproc.

plugins: check if negotiate dmabuf with downstream

In order to enable, in the future, dmabuf-based buffers, the vaapi base
plugin needs to check if downstream can import dmabuf buffers.

This patch checks if downstream can handle dmabuf, by introspecting the
shared GL context. If the GL context is EGL/GLES2 and have the extension
EGL_EXT_image_dma_buf_import, then dmabuf can be negotiated.

Original-patch-by: Julien Isorce <j.isorce@samsung.com>

vaapivideomemory: release proxy's data if downstream

The surface created for downstream is going to be filled by VAAPI
elements. So, the driver needs write access on that surface.

This patch releases the derived image held by the proxy, thus the
surface is unmarked as busy.

This is how it has to be done as discussed on libva mailing list.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

libs: bufferproxy: add gst_vaapi_buffer_proxy_release_data()

Adds an API to request the user's data release in the buffer proxy.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapivideomemory: add direction to dmabuf allocator

Add GstPadDirection param to gst_vaapi_dmabuf_allocator_new(), thus
we later could do different thing when the allocated memory is for
upstream or dowstream, as required by VA-API.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

libs: utils: return NULL if failed to get surface formats

Thus, when generating the allowed caps, the element will throw a
warning and it will use its caps template.

This behavior might be a bug in the VA driver.

https://bugzilla.gnome.org/show_bug.cgi?id=775490

Revert "vaapidisplay: mark X11 display as compatible with EGL"

This reverts commit 200b1baabc066f8a4102f82f539655d588200ec9.

vaapipostproc: set GST_VAAPI_POSTPROC_FLAG_SIZE according to src caps

A value of width/height property should be set to out caps,
if negotiation had been going properly.
So we can use srcpad_info when making decision of scaling.

https://bugzilla.gnome.org/show_bug.cgi?id=778010

plugins: handle GL params through context query

If the element instantiated the GL display and context, they should
handle them too through the context query.

https://bugzilla.gnome.org/show_bug.cgi?id=777409

plugins: create a GL context on certain conditions

If a GstVaapiDisplay is not found in the GStreamer context sharing,
then VAAPI elements look for a local GstGLContext in gst context
sharing mechanism ('gst.gl.local.context').

If this GstGLContext not found either then, only the VAAPI decoders
and the VAAPI post-processor, will try to instantiate a new
GstGLContext.

If a valid GstGLContext is received, then a new GstVaapiDisplay will
be instantiated with the platform, API and windowing specified by the
instantiated GstGLContext.

Original-Patch-By: Matt Fischer <matt.fischer@garmin.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777409

vaapivideocontext: context type can be rejected

Instead of calling g_return_val_if_fail() to check the context type, we
should use a normal conditional, since it is possible that other context types
can arrive and try to be assigned. Otherwise a critical log message is
printed.

This happens when we use playbin3 with vaapipostproc as video-filter.

https://bugzilla.gnome.org/show_bug.cgi?id=777409

vaapipostproc: use sink caps par if not requested

Use the sink caps pixel-aspect-ratio to fixate the src caps, if it
is not already set.

https://bugzilla.gnome.org/show_bug.cgi?id=777395

vaapipostproc: set interlace mode

if the vaapipostproc is configured to not do deinterlacing, the
interlace-mode in the src caps should be the same as the input caps.

https://bugzilla.gnome.org/show_bug.cgi?id=777395

vaapisink: fix gcc compiler warning

warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

vaapisink: don't use member variable outside lock

Thus a race condition segfault is avoided.

Original-patch-by: Matt Staples <staples255@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777146

plugins: avoid log flood when activating pool

Every time a new buffer is allocated, the pool is activated. This
doesn't impact in performance since gst_buffer_pool_set_active()
checks the current state of the pool. Nonetheless it logs out a
message if the state is the same, and it floods the logging subsystem
if it is enabled.

To avoid this log flooding first the pool state is checked before
changing it.

vaapidecode: update internal decoder sink caps

When a new sink caps arrive the internal decoder state is updated
and, if it is, request a downstream renegotiation.

Previously, when new caps arrived the whole decoder where destroyed
and recreated. Now, if the caps are compatible or has the same codec,
the internal decoder is kept, but a downstream renegotiation is
requested.

https://bugzilla.gnome.org/show_bug.cgi?id=776979

Back to development

Release 1.11.1

vaapi: bump ifdef to API 0.40.0 for log redirect

vaSetInfoCallback() is not released yet. It is going to appear in
VA-API 0.40.0

vaapiutils: Fix compilation with latest and previous libva releases

vaSetInfoCallback() was defined after 0.39.4 / 1.7.3, so check for
0.39.5 instead.

libs: display: redirect logging at initialize

Redirect libva's logs to GStreamer logging mechanism. This is
particularly useful when VA is initialized, because it always logs
out the drivers details.

In order to achieve this a new helper function was added as a wrapper
for the vaInitialize() function.

https://bugzilla.gnome.org/show_bug.cgi?id=777115

plugins: provide at least two buffers in sink pool

Adds two buffers as the default value of minimum buffer.

This would be used when creating and proposing vaapi bufferpool for
sink pad, hence the upstream element will keep, at least, these two
buffers.

https://bugzilla.gnome.org/show_bug.cgi?id=775203

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: decoder: h264: don't update cloned attributes

If the frame is a cloned picture, its PTS comes from its parent
picture.  In addition, the base decoder doesn't set a valid PTS to
the frame corresponding to the cloned picture.

https://bugzilla.gnome.org/show_bug.cgi?id=774254

vaapivideomemory: check for display

This patch fixes the check of display, rather than check for the
meta, which it is known it exists.

vaapivideomemory: rename dmabuf allocator parameters

Rename the parameters 'vip' and 'flags' to 'alloc_info' and
'surface_alloc_flags' respectively. The purpose of this change is
to auto-document those parameters.

Also, aligned to this patch, the local 'alloc_info' variable was
renamed as 'surface_info', because it stores the possible surface's
video info, not the allocate one.

vaapivideomemory: rename vip to alloc_info parameter

In order to auto-document the code, this patch renames the 'vip'
parameter in the functions related to gst_vaapi_video_allocator_new ()
to 'alloc_info', since it declares the allocation video info from
the vaapi buffer pool.

vaapivideomemory: use GST_VIDEO_INFO_FORMAT_STRING()

Use the existing local macro GST_VIDEO_INFO_FORMAT_STRING() to get
the video format string.

vaapivideomemory: unroll gst_vaapi_surface_new_with_format()

gst_vaapi_surface_new_with_format() is a wrapper for
gst_vaapi_surface_new_full (). In this case, the former is simpler
than the first. This patch changes that.

vaapipostproc: notify if src pad caps changed

If src pad caps have changed, it needs to notify it downstream. In
addition, do not set passthrough if they have changed.

Otherwise, transform sometimes starts processing before caps change.
The passthrough value will be set in fixate later in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=775204

vaapidecodebin: capsfilter to optimize negotiation

Add a capsfilter forcing the caps
"video/x-raw(memory:VASurface), format=(string)NV12" between the
queue and the vaapipostproc so no renegotiation is required.

https://bugzilla.gnome.org/show_bug.cgi?id=776175

vaapivideomemory: fail surface/image configuration

To detect and handle errors during allocator_configure_surface_info()
and allocator_conigure_image_info().

https://bugzilla.gnome.org/show_bug.cgi?id=776084

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

vaapisink: ensures raw caps at start()

Calls gst_vaapi_plugin_base_get_allowed_raw_caps() at start() to avoid
race conditions at get_caps(), especially with multiple src elements.

https://bugzilla.gnome.org/show_bug.cgi?id=776303

libs: surface: fix error handling code style

vaapivideomemory: add gst_video_info_update_from_surface()

With this function is possible to refactor and remove duplicated code
between dmabuf configuration and direct rendering/uploading
configuration.

vaapivideomemory: no log object at initialization

When an instance of GstVaapiVideoAllocator fails at initializing, the
log message should not include the allocator's object, because it is
going to be unrefed.

vaapidecode: lock stream when setting caps

Revert "vaapidecode: implement negotiate() vmethod"

This reverts commit 3285121181295c544480fc6ba756845b16285d30.

videodecode's negotiate() vmethod is also called when events arrive,
but this would mean that the proper configuration of sink pad might
not be complete, thus we should not update the src pad.

Let's keep the old non-vmethod negotitate().

Revert "encoders: demote to RANK_NONE since not fit for autoplugging yet"

This reverts commit f182b8be2ba05965e6d31a4d380d6563b9b53a77.

vaapiencode: get surface formats in get_caps()

Query for the supported surface formats in config at get_caps() vmethod.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: encoder: add gst_vaapi_encoder_get_surface_formats()

This method will return the valid surface formats in the current
config. If the are no VAConfig it is created with the information
available.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: encoder: split set_context_info()

Split set_context_info() adding init_context_info() which only
initialises the GstVaapiContextInfo structure inside GstVaapiEncoder
required for VAConfig.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: context: skip VAContext if no frame size

If GstVaapiContextInfo has just initial information, without frame's
width and height, skip the creation of the VAContext, just keep the
VAConfig.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: context: split context_create()

Split the funcion context_create() into context_create() and
config_create().

Decoupling VAConfig and VAContext during context creation, we could
query the VAConfig for the supported surface's formats without creating
a VAContext.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

libs: drm: find render node in hybrid system

Originally the drm backend only tried to open the first render node
found. But in hybrid system this first render node might not support
VA-API (propietary Nvidia driver, for example).

This patch tries all the available nodes until a finding one with a
VA-API supported driver.

https://bugzilla.gnome.org/show_bug.cgi?id=774811

Original-patch-by: Stirling Westrup <swestrup@gmail.com> and
                   Reza Razavi <reza@userful.com>

vaapivideomemory: refactor code for readability

Added the inlined function allocator_configure_pools() moving out code
from gst_vaapi_video_allocator_new() to make clear that it is a
post-initalization of the object.

vaapivideomemory: log error if not VA image

Log an error message if the test image for surface downloading
cannot be allocated or mapped.

vaapivideomemory: remove unused macros

These macros are not used. Let us remove them.

vaapivideomemory: rename video for allocation_info

Since video_info stores the GstVideoInfo of the allocation caps,
it is clear if we rename it as allocation_info, to distinguish it
later from negotiation_info.

vaapivideomemory: add real GstVaapiDmaBufAllocator

Instead of defining GstVaapiDmaBufAllocator as a hackish decorator of
GstDmaBufAllocator, now, since the expose of the GstDmaBufAllocator's
GType, GstVaapiDmaBufAllocator is a full feature GstAllocator inherited
from GstDmaBufAllocator.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

vaapivideomemory: errors in gst_vaapi_dmabuf_allocator_new()

Add a helper function to initialize the gst_debug_vaapivideomemory,
to use it either by the GstVaapiVideoAllocatorClass or
GstVaapiDmabufAllocator (which is a decorator of GstDmaBufAllocator).

Later, log possible errors when calling gst_vaapi_dmabuf_allocator_new ()

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapiencode: release internal encoder at stop()

As the internal encoder is created at start(), let's release it at
stop() vmethod, to be consistent.

gst_vaapiencode_destroy() is called since it also resets the input and
output states, which is something that the base class does internally
after calling stop() vmethod.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

Automatic update of common submodule

From f49c55e to 39ac2f5

vaapiencode: call ensure_encoder() at start()

Currently, specific encoder is created during set_format(). This might
lead to race condition when creating profiles with multiple encoders.

This patch moves ensure_encoder() call to start() vmethod to ensure
avoiding the race condition.

https://bugzilla.gnome.org/show_bug.cgi?id=773546

vaapidecodebin: bring back dynamic configuration

In commit ca0c3fd6 we remove the dynamic configuration if the bin
because we assumed that the bin will be always static as it is
registered.

Nonetheless we were wrong, because it is possible to request, with a
property, to avoid the use of the post-processor.

Since we want to add a way to disable the post-processor through
environment variables, this remove feature is required again.

If the environment variable GST_VAAPI_DISABLE_VPP is defined the
postprocessor inside of the vaapidecodebin is disabled, then
vaapidecodebin is an alias of the old vaapidecode.

https://bugzilla.gnome.org/show_bug.cgi?id=775041

vaapidecode: implement negotiate() vmethod

Instead of decorating the negotiate() method, let us override it,
so the stream is locked while called.

https://bugzilla.gnome.org/show_bug.cgi?id=775040

common: use https protocol for common submodule

https://bugzilla.gnome.org/show_bug.cgi?id=775110

build: add LIBVA_WAYLAND_CFLAGS to libgstvaapiegl

In case libva-wayland has its headers not installed in default
locations (like /usr/include), the build fails to include "wayland-client.h":

   CC       libgstvaapi_egl_la-gstvaapiutils_egl.lo
 In file included from gstvaapidisplay_wayland.h:27:0,
                  from gstvaapidisplay_egl.c:35:
 /usr/include/va/va_wayland.h:31:28: fatal error: wayland-client.h: No such file or directory
  #include <wayland-client.h>

As we already passed VA_CLAGS, /usr/include/va/va_wayland.h could be found, but it is
our fault not to instruct the system that we ALSO care for va_wayland. We correctly query
for libva-wayland.pc in configure and use this in other places as well. It is thus only
correct and consequent, to do it also at this spot.

https://bugzilla.gnome.org/show_bug.cgi?id=773946

vaapivideocontext: log a message if no bus

Raise a warning if there is no bus when the element tries to post a
message.

vaapisink: create display at open()

Instead of creating the VA display before setting the bus to the
element, it is created when the element is opened.

Basically, this commit is a revert of
5e5d62cac79754ba60057fc2516135aad8d7de35

That was done when the GStreamer's context sharing was not mature
enough as now. There is no reason to keep this hack.

vaapidecode: don't add video crop meta

Since the differentiation of negotiation caps and allocation caps,
there is no need to add a video crop meta with the negotiation caps.
Hence, removing it.

https://bugzilla.gnome.org/show_bug.cgi?id=773948

remove the video converter from vaapi buffer meta

Since all the video converter were deprecated in gstreamer-1.2, we don't need
to handle them anymore in the vaapi's buffer meta.

This patch removes its usage and the buffer meta's API for that.

https://bugzilla.gnome.org/show_bug.cgi?id=745728

plugins: destroy source pad allocator and pool

First, deactivate source pad pool when the out caps change, and if so,
destroy texture map, the source pad allocator and pool only if the
new caps are different from the ones already set.

plugins: don't destroy sink pad allocator

Don't destroy sink pad allocator at _set_caps() because it will be done at
ensure_sinkpad_buffer_pool() if it is required.

plugins: first validate the out caps

When calling _set_caps() first validate the out caps before doing
anything else.

vaapidecode: negotiate after destroying allocator

This is related with bug 758907 when no vaapipostproc is used (no
vaapidecodebin). In order to negotiate downstream we need to destroy
the source pad allocator, otherwise the same allocated buffers are
used, failing the mapping.

vaapivideomemory: remove GST_VAAPI_TYPE_VIDEO_INFO

Remove redundant GST_VAAPI_TYPE_VIDEO_INFO, since it is a duplicate of
GST_TYPE_VIDEO_INFO created before gstreamer 1.6, where the boxed type
was created.

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: update the src pad allocator video info

Update the size, stride and offset of the source pad allocator video
info, so the pool could set the correct GstVideoMeta

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideomemory: add missing documentation

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: use early return without goto

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: add allocator to allocation query

This patch adds the created allocator to the allocation query either
in decide_allocation() and propose_allocation() vmehtods.

With it, there's no need to set the modified allocator's size in the
pool configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideobufferpool: set correct buffer size

We should set the correct buffer size when we are configuring the pool,
otherwise the buffer will be discarded when it returns to the pool.

Indeed when the ref-count of a buffer reaches zero, its pool will queue
it back (and ref it) if, and only if, the buffer size matches the
configured buffer size on the pool.

This issue can be debugged with GST_DEBUG=*PERF*:6, see gstbufferpool.c

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideomemory: check for memory allocator

When calling gst_vaapi_video_memory_copy() the allocator of the memory
to copy should be allocated by the vaapi allocator.

This patch does this verification.

vaapivideomemory: code style fixes

A cosmetic commit for enhance readability of the casts and method
preconditions.

vaapivideomemory: unroll gst_vaapi_video_allocator_free()

Instead of having a gst_vaapi_video_memory_free() that is only going to
be called by gst_vaapi_video_allocator_free(), let's just remove the first
and merged into the second.

vaapivideomemory: avoid virtual methods casting

Use the expected virtual method signatures for readability.

vaapivideomemory: remove unimplemented methods

Remove unimplemented method for allocator mem_share() and mem_is_span().

vaapivideomemory: fail if frame map can't get plane

If map() vmethod in GstVideMeta cannot get the plane data, return false,
thus the caller will not try to read invalid memory.

https://bugzilla.gnome.org/show_bug.cgi?id=774213

vaapivideomemory: lock map and unmap operations

In order to avoid race condition when two threads call map/unmap the same
VA surface, this patch mutex these operations.

https://bugzilla.gnome.org/show_bug.cgi?id=774213

vaapivideomemory: refactor vaapi memory unmapping

There were duplicated code in gst_video_meta_unmap_vaapi_memory() and
gst_vaapi_video_memory_unmap() when unmapping.

This patch refactors both methods adding the common function
unmap_vaapi_memory(). This also ensures, if direct rendering is enabled, it
is correctly reset.

Additionally, only when mapping flag has the WRITE bit, it set the image as
current, which was done in gst_video_meta_map_vaapi_memory() but no in
gst_vaapi_video_memory_map().

In order to make this, the mapping flags were required, so instead of
overloading mem_unmap() virtual function, mem_unmap_full() is overloaded.

https://bugzilla.gnome.org/show_bug.cgi?id=774213