tests: elements: vaapisink: handle nav events

The test app can now handle navigation events to rotate the
display.

tests: elements: clean up vaapisink test

- Use gst_element_send_event() instead of gst_pad_push_event()
- don't zero App structure
- check for pipeline parsing error
- only get vaapisink for property set

vaapisink: keep handle_events flag except that if user want to set

When state of vaapisink is changed from PLAYING to NULL, the handle_events
flag is set to FALSE, and never recovered, and then event thread is never
going to run.

So we should allow to set the flag only when users try it.

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

libs: window: x11: fix src rect info when using vpp

Since we started using VPP in VaapiWindowX11, we need to care about
the case that src rect and window's size are different.

So, once VPP has converted to other format, we should honor the
size of the VPP's surface as source rect. Otherwise, it is cropped
according the previous size of the source rect.

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

plugins: remove par from caps negotiation

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

tests: elements: add an example for ROI

This implements a pipleint to recognize difference between ROI and non-ROI.
See comments in this code in detail.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

vaapiencode: handle custom event GstVaapiEncoderRegionOfInterest

Handles new custom event GstVaapiEncoderRegionOfInterest
to enable/disable a ROI region.

Writes a way to use new event to document.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

tests: simple-encoder: add an option to set ROI

$ simple-encoder -r inputfile.y4m

And you'll got an output file in H264 with two regions of interest.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: encoder: h264: set ROI params during encoding

Set ROI params during encoding each frame, which are set via
gst_vaapi_encoder_add_roi ()

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: encoder: add api gst_vaapi_encoder_add/del_roi

Implements and exposes new api gst_vaapi_encoder_add/del_roi to set ROI regions.

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

libs: encoder/context: query region of interest support

Queries if the driver supports "Region of Interest" (ROI) during the config
creation.

  This attribute conveys whether the driver supports region-of-interest (ROI)
  encoding, based on user provided ROI rectangles.  The attribute value is
  partitioned into fields as defined in the VAConfigAttribValEncROI union.

  If ROI encoding is supported, the ROI information is passed to the driver
  using VAEncMiscParameterTypeROI.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: encoder: fix a comment

libs: encoder: guard quality level configuration

The quality level appeared in VA-API 0.36. So let's guard its
usage.

encoders: add quality level tuning

This patch adds the handling of VAEncMiscParameterTypeQualityLevel,
in gstreamer-vaapi encoders:

  The encoding quality could be set through this structure, if the
  implementation supports multiple quality levels. The quality level set
  through this structure is persistent over the entire coded sequence, or
  until a new structure is being sent. The quality level range can be queried
  through the VAConfigAttribEncQualityRange attribute. A lower value means
  higher quality, and a value of 1 represents the highest quality. The quality
  level setting is used as a trade-off between quality and speed/power
  consumption, with higher quality corresponds to lower speed and higher power
  consumption.

The quality level is set by the element's parameter "quality-level" with a
hard-coded range of 1 to 8.

Later, when the encoder is configured in run time, just before start
processing, the quality level is scaled to the codec range. If
VAConfigAttribEncQualityRange is not available in the used VA backend, then
the quality level is set to zero, which means "disabled".

All the available codecs now process this parameter if it is available.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

Back to development

Release 1.12.0

Revert "vaapidecodebin: fix element's classification"

This reverts commit 8cbe03599a4f27c2001380e2ec150c4f4267a9cf.

build: Require libva < 0.99.0

libva >= 0.99.0 is not currently supported by gstreamer-vaapi, so
fail to configure instead of failing late in the build.

This libva is bundled in msdk[1] and it is ahead in time with
respect the official and open source libva[2]. GStreamer-VAAPI
only supports the latter for now.

1. https://software.intel.com/en-us/media-sdk/download
2. https://github.com/01org/libva/

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

vaapidecodebin: fix element's classification

This bin should have similar classification as decodebin which is
"Generic/Bin/Decoder" otherwise it will appear wrongly as video
decoder.

Signed-off-by: Victor Toso <victortoso@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782063

Release 1.11.91

Revert "plugins: reject pixel-aspect-ratio with value 0/1"

This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.

plugins: reject pixel-aspect-ratio with value 0/1

Do not negotiate a pixel-aspect-ratio of 0/1.

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

plugins: handle pixel-aspect-ratio with value 0/1

When downstream negotiates a pixel-aspect-ratio of 0/1, the
calculations for resizing and formatting in vaapipostproc and
vaapisink, respectively, failed, and thus the pipeline.

This patch handles this situation by converting p-a-r of 0/1 to
1/1. This is how other sinks, such as glimagesink, work.

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

vaapivideobufferpool: fix leak of created allocator

Since it's created by itself, it should be unref-counted
after gst_buffer_pool_config_set_allocator call. Afterwards,
this allocator will be ref-counted again when assigning to priv->allocator.

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

vaapivideobufferpool: create or reconfig allocator

Sometimes a video decoder could set different buffer pool
configurations, because their frame size changes. In this case we
did not reconfigure the allocator.

This patch enables this use case, creating a new allocator inside
the VAAPI buffer pool if the caps changed, if it is not dmabuf-based.
If so, it is just reconfigured, since it doesn't have a surface pool.

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

test: elements: fix compilation flags

This issue was spotten on bug #766704

Original-patch-by: Hyunjun Ko <zzoon@igalia.com>

libs: windows: wayland: fix leak if failure of sync

Sometimes gst_vaapi_window_wayland_sync returns FALSE when poll returns EBUSY
during destruction.
In this case, if GstVaapiWindow is using vpp, leak of vpp surface happens.
This surface is not attached to anything at this moment, so we should release
it manually.

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

Automatic update of common submodule

From 60aeef6 to 48a5d85

libs: window: wayland: mark frames as done

When the frame listener callbacks 'done', the number of pending
frames are decreased. Nonetheless, there might be occasions where
the buffer listener callbacks 'release', without calling previously
frame's 'done'. This leads to problem with
gst_vaapi_window_wayland_sync() operation.

This patch marks as done those frames which were callbacked, but if
the buffer callbacks 'release' and associated frame is not marked
as 'done' it is so, thus the number of pending frames keeps correct.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: window: wayland: don't sync at destroy()

Don't call gst_vaapi_window_wayland_sync() when destroying the
wayland window instance, since it might lead to a lock at
gst_poll_wait() when more than one instances of vaapisink are
rendering in the same pipeline, this is because they share the
same window.

Since now all the frames are freed we don't need to freed the
private last_frame, since its address is invalid now.

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

Signed-off-by: Hyunjun Ko <zzoon@igalia.com>

libs: window: wayland: null buffer at destroy()

Fix leakage of the last wl buffer.

VAAPI wayland sink needs to send a null buffer while destruction,
it assures that all the wl buffers are released. Otherwise, the last
buffer's callback might be not called, which leads to leak of
GstVaapiDisplay.

This was inspired by gstwaylandsink.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: window: wayland: rt event queue at destroy()

The proxy object of wl_buffer for the last frame remains in the
wl_map. Even though we call wl_buffer_destroy() in
frame_release_callback(), the proxy object remains without being
removed, since proxy object is deleted when wayland server sees the
delete request and sends 'delete_id' event.

We need to call roundtrip before destroying event_queue so that the
proxy object is removed. Otherwise, it would be mess up as receiving
'delete_id' event from previous play, when playing in the next
va/wayland window with the same wl_display connection.

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

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: window: wayland: cancel read at poll message

Always call wl_display_cancel_read() when an errno is set, but
different to EAGAIN or EINTR.

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

vaapidecodebin: skips configuration once it's done

Skips configuration of creation of vpp/capsfilter and link them once it's done.
Otherwise, it always fails when it's trying to re-start playback.

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

vaapipostproc: fixes for memory leaks

The use of gst_vaapi_value_set_format() and gst_structure_*_value()
requires to clear the used GValue to avoid a memory leak.

plugins: enable direct rendering with envvar

Direct rendering (use vaDeriveImage rather than vaPutImage) has better
performance in some Intel platforms (Haswell, for example) but in others
(Skylake) is the opposite.

In order to have some control, the patch enables the direct rendering
through the environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING.

Also it seems to generating some problems with gallium/radeon backend.
See bug #779642.

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

vaapidecode: Don't renegotiate on every flush

If caps don't actually change, don't update the
decoder and don't set the do_renego flag forcing
downstream renegotiation

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

h264 decoder: Implement reset() for faster flush

Implement a custom reset() function for faster flushes
that just clear the reference pictures but don't reallocate
the DPB or clear out SPS/PPS

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

Implement decoder reset on flush, rather than recreating

Clear decoders out on a flush but keep the same instance,
rather than completely recreating them. That avoids
unecessarily freeing and recreating surface pools
and contexts, which can be quite expensive

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

libs: window: don't add an unused function

The macro GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE only defines
a function that is never used, thus when compiling we might see
this warning (clang):

gstvaapiwindow.c:147:1: warning: unused function 'gst_vaapi_window_class' [-Wunused-function]
GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE (GstVaapiWindow,
^

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

libs: window: remove surface_format member

Since we always convert to NV12, there is no need to keep a
variable for that. Let us hard code it.

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

libs: window: x11/wayland: use new api for conversion

Since gst_vaapi_window_vpp_convert_internal is created,
GstVaapiWindowX11/Wayland can use it for conversion.

Note that once it chooses to use vpp, it's going to use vpp
until the session is finished.

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

libs: window: add gst_vaapi_window_vpp_convert_internal()

If a backend doesn't support specific format, we can use vpp for conversion
and make it playing.

This api is originated from GstVaapiWindowWayland and moved to GstVaapiWindow,
so that GstVaapiWindowX11 could use it.

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

libs: window: x11/wayland: chaining up to GstVaapiWindow

Currently, GstVaapiWindowX11/Wayland are not descendants of GstVaapiWindow.
This patch chains them up to GstVaapiWindow to handle common members in GstVaapiWindow.

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

plugins: Fix usage of GST_GL_HAVE_WINDOW_* defines

When these definitions are false, they are undef in the
preprocessor, not a defined value of 0. When they are unset the
compile fails with:

 'GST_GL_HAVE_WINDOW_WAYLAND' undeclared (first use in this function)

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

Automatic update of common submodule

From 39ac2f5 to 60aeef6

Release 1.11.90

vaapiencode: h265: add main-10 in caps template

This patch adds h265's main-10 profile in encoder src caps template.

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

libs: encoder: h265: chroma and luma with format

If the profile is main-10 the bit_depth_luma_minus8, in the sequence
parameter buffer, shall be the color format bit depth minus 8, 10-8
which is 2. Also for bit_depth_chroma_minus8.

This patch gets the negotiated sink caps format and queries its
luma's depth and uses that value to fill the mentioned parameters.

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

libs: encoder: admit YUV420_10BPP as valid chroma

Accepts as supported the GST_VAAPI_CHROMA_TYPE_YUV420_10BPP chroma
type.

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

libs: encoder: h265: ensures profile given format

Set the VA profile as GST_VAAPI_PROFILE_H265_MAIN10 if the
configured color format is P010_10LE.

Otherwise, keep GST_VAAPI_PROFILE_H265_MAIN

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

libs: encode: merge all possible surface formats

When the function gst_vaapi_encoder_get_surface_formats() was added
it was under the assumption that any VA profile of the specific codec
supported the same format colors. But it is not, for example the
profiles that support 10bit formats.

In other words, different VA profiles of a same codec may support
different color formats in their upload surfaces.

In order to expose all the possible color formats, if no profile is
specified via source caps, or if the encoder doesn't have yet a
context, all the possible VA profiles for the specific codec are
iterated and their color formats are merged.

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

vaapiencode: add get_profile() vmethod

This new virtual method, get_profile(), if implemented by specific
encoders, will return the VA profile potentially determined by the
source caps.

Also it is implemented by h264 and h265 encoders, which are the main
users of this vmethod.

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

libs: encoder: pass profile to get_surface_formats()

In order to get the supported surface formats within a specific
profile this patch adds the GstVaapiProfile as property to
gst_vaapi_encoder_get_surface_formats().

Currently the extracted formats are only those related with the
default profile of the element's codec.

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

libs: encoder: dummy context for get_surface_formats()

Instead of creating (if it doesn't exist, yet) the encoder's context
the method gst_vaapi_encoder_get_surface_formats() now it creates
dummy contexts, unless the encoder has it already created.

The purpose of this is to avoid setting a encoder's context with a
wrong profile.

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

libs: encoder: refactor init_context_info()

In order to generate vaapi contexts iterative, the function
init_context_info() is refactored to pass, as parameters the
GstVaapiContextInfo and the GstVaapiProfile.

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

libs: encoder: initialize chroma_type

Instead of initialize the chroma_type with a undefined value, which
will be converted to GST_VAAPI_CHROMA_TYPE_YUV420 by GstVaapiContext,
this patch queries the VA config, given the received
GstVaapiContextInfo's parameters, and gets the first response.

In order to get the GstVaapiChromaType value, also it was needed to
add a new utility function: to_GstVaapiChromaType(), which, given a
VA_RT_FORMAT_* will return the associated GstVaapiChromaType.

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

vaapiencode: enhance logs of negotiated caps

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

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