libs: encoder: vp9: Fix initialization of ref_list

gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init:

 'memset' used with length equal to number of elements without
 multiplication by element size [-Werror=memset-elt-size]

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

encoder: h264: Fix Backward ReferencePicture flag setting

This is a regression introduced by e829b62 which
override the reference flags and caused issues with
latest intel-vaapi-driver.

libs: encoder: h265: fix code style

Trivial patch to remove a double ';' as end of instruction.

encoder: h264: Fix B frame encoding artifacts

The current implementation is updating the POC values only
in Slice parameter Buffer.But we are not filling the
picture order count and reference flags in VAPictureH264
while populating VA Picture/Slice structures.The latest
intel-vaapi-driver is directly accessing the above fields
from VAPicutreH264 provided as RefPicLists, which resulted
some wrong maths and prediction errors in driver.

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

libs: encoder: h265: remove unused macro definition

Since the h265 encoder doesn't use GValueArray, there is no need to
disable the Glib deprecation warnings, thus removing the macro
definition.

plugins: when debug disabled, default category is NULL

As in gstreamer-vaapi a common base class is used, the specific
default category is passed to the base-plugin initializator, thus
the log messages are categorized with the used plugin.

Nonetheless, when the gst-debug is disabled in compilation time,
it is needed to pass NULL to the base-plugin initializator. This
patch does that.

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

libs: h26x: adds gst_vaapi_utils_h26x_write_nal_unit()

Implements gst_vaapi_utils_h26x_write_nal_unit(), which writes NAL
unit length and data to a bitwriter.

Note that this helper function applies EPB (Emulation Prevention
Bytes), since otherwise produced codec_data might be broken when
decoder/parser considering EPB, starts parsing.

See sections 7.3 and 7.4 of the H264 and H264 specifications, which
describes the emulation_prevention_three_byte.

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

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

libs: utils: h26x: create vaapiutils_h26x

Since there is duplicated code in h264/265 encoder, we could
refactor it to avoid duplicated code.

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

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

libs: encoder: h264/5: fix wrong return value

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

docs: h264/h265: put parser to the example pipeline

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

libs: encoder: h265: fix reserved length of bits

Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8

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

O_CLOEXEC needs _GNU_SOURCE defined

From man open(2):

    The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified
    in POSIX.1-2001, but are specified in POSIX.1-2008.  Since glibc
    2.12, one can obtain their definitions by defining either
    _POSIX_C_SOURCE with a value greater than or equal to 200809L or
    _XOPEN_SOURCE with a value greater than or equal to 700.  In glibc
    2.11 and earlier, one obtains the definitions by defining
    _GNU_SOURCE.

And indeed, with the uClibc C library, O_CLOEXEC is not exposed if
_GNU_SOURCE is not defined. Therefore, this commit fixes the build of
gstreamer-vaapi with the uClibc C library.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779953

README: fix "Sources" section

Update the URL where the release source tarballs can be downloaded.

README: fix "Reporting bugs" section

The "Reporting bugs" section gives
https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi as the
link to report a bug, but this link says "Sorry, entering a bug into the
product gstreamer-vaapi has been disabled.".

This commit fixes the URL to point to the proper location, and also
removes the following paragraph that is no longer correct.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779954

plugins: retry to create the VA display

Particularly in GNOME Wayland, the negotiated or created GL context
defines a GLX environment, but VAAPI fails to create a GLX VA
display because there is no a DRI2 connection.

This patch retries to create the VA display if VA cannot create one
with the GL context parameters. Now using the old list of display
types.

This should also work in the case of systems with two GPU, when the
non-VAAPI has the graphics environment, and the VAAPI-enabled one
shall work headless.

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

vaapipostproc: texture upload if driver supports GL

Removes GstVideoGLTextureUploadMeta caps feature if the driver
doesn't support opengl.

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

vaapidecode: texture upload if driver supports GL

When the allowed source pad caps are generated, the GLTextureUpload caps are
only inserted if the driver support OpenGL.

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

configure: Add missing compiler flags

The AC_CHECK_HEADERS macro was failing to locate some headers, in
particular the va_enc_* headers due to missing compiler flags.

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

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

libs: window: wayland: handle more VAStatus to use vpp

Since the commit landed https://github.com/01org/intel-vaapi-driver/pull/55,
we should consider more returned VAStatus to use vpp.

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

libs: encoder: ensure profile when context initialization

We can't be sure that encoder's profile is assgined already or not
at context initialization.

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

libs: encoder: set rate control info only when query succeed

Currently, it set rate control information even when query fails.
In addition, it doesn't update any more since the flag
got_rate_control_mask is set to TRUE.

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

meson: Update version

Back to development

Release 1.11.2

vaapiencode: merge tags for downstream's info

Add encoder and codec name and the bitrate into the output for
informational purposes. Some muxers or application use it as
media metadata.

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

libs: encoder: caps can change at any time

The encoder should be able to change its caps even it is already
processing a stream.

This is suppose to happen after a flush so the codedbuf_queue should
be empty.

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

libs: encoder: h265: bail if nal unit type fails

Bail out if the NAL unit type is not recognized.

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

libs: decoder: h264,h265 avoid uninitialized variable

Configuring GCC to verify possible usage of uninitialized variables,
shows that found_index might be used without previous assignation.

This patch assigns a initial value to found_index, also avoid a
branching when returning the result value.

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

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>