vaapidecode: fix mismatch of the return type

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

libs: remove unused header

Since libgstvaapi is not distributed, there is no need to check for
private header inclusion. Thus removing it.

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

libs: utils: move gstvaapisurface.h to private headers

Since the utils don't expose API defined in gstvaapisource.h, it is
moved to their private headers where they are used.

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

libs: utils: remove va.h include in header

And include gstvaapicompat.h in the C files, since the VA-API is not
exposed in the headers.

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

libs: encoder: remove va.h include

Since it is already managed by gstvaapicompat.h

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

build: consolidate the VA sub API includes

Include all VA sub APIs headers in a single point (gstvaapicompat.h),
since they are all already included in va.h after VA-API 0.38.

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

build: check for va_vpp.h

Thus, in config.h the macro HAVE_VA_VA_VPP_H is defined. This will
allow us to handle the inclusion of the header better.

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

meson: don't export symbols by default

Only plugin entry points should be exported.

libs: decoder: h265: remove spurious code

Coverity scan:

Logically dead code: The indicated dead code may have performed some
action; that action will never occur.

By using pointer arithmetic is impossible to get NULL.

libs: context: use attribs index instead pointers

Coverity scan bug:

Out-of-bounds write. This could cause an immediate crash or incorrect
computations.

Coverity basically found that it is possible to assign more than 4
attribs in the array.

In my opinion this was produced because code pattern used pointer
arithmetic, which is not readable nor maintainable.

This patch refactors config_create() to use an array index rather than
pointer arithmetic. Also a run-time check for index size was added.

vaapiencode: h264: remove spurious code

Coverity scan bug:

An unsigned value can never be negative, so this test will always
evaluate the same way.

As len is guint32, there is no need to check it if it is equal or
bigger than zero.

vaapidecode: initialize variable

Coverity scan bug:

The variable will contain an arbitrary value left from earlier
computations.

Variable base_only is fetched from base-only property, and it may be
not assigned. It needs to be initialized.

libs: windows: wayland: fail if cannot remove last frame

Converity scan bug:

If the function returns an error value, the error value may be
mistaken for a normal value.

If g_atomic_pointer_compare_and_exchange() fails because the frame is
not the last one, the function fails. Thus, logging an info message.

libs: utils: glx: check return value

Coverity scan bug:

If the function returns an error value, the error value may be
mistaken for a normal value.

Function sscanf returns the number of assignations done. Validate this
return value with the number of expected variables to match.

libs: vaapi: object: remove unrequired NULL check

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

Variable klass has been validated as non-NULL several time before in
gst_vaapi_object_new() function, so there is no need to check it
again.

libs: encoder: h265: remove spurious assignation

Coverity scan bug:

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.

ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.

libs: encoder: h264: fix copy & paste error

Coverity scan bug:

The copied code will not have its intended effect.

This is a bug from commit cdaf15b2, where the intention is to
initialize RefPicList1 while setting RefPicList0.

libs: encoder: h265: fix possible integer overflow

Coverity scan bug:

Unintentional integer overflow. The expression's value may not be what
the programmer intended, because the expression is evaluated using a
narrow (i.e. few bits) integer type.

Cast operator to guint64 before computation to avoid narrowing.

merge with 3c5a6add

libs: decoder: mpeg4: fail if return value is not OK

Coverity scan bug:

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.

In the return value of decode_slice() or
gst_mpeg4_parse_video_packet_header() are not success, thus fail
decode_packet() function.

libs: decoder: h265: check for null

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

While looking for hte lowest poc, according to rest of the code, the
picture in the dbp (decoded picture buffer) might be NULL, thus we
could check for a NULL picture before assigned as found.

Also, split a comma operator because it is considered as a bad
practice because it possible side effects.

libs: decoder: h265: untaint loop control variable

Coverity scan bug:

Scalars (for example, integers) are not properly
bounds-checked (sanitized) before being used as array or pointer
indexes, loop boundaries, or function arguments are considered as
tainted.

In this case, num_nals were not checked before used as loop control.

libs: decoder: h264: remove unrequired NULL check

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

In the original commit for fill_picture_gaps() (commit 5abd2b90) the
prev_picture could be NULL, that's why the code did a null check. But,
since commit 52adebe7, the previous reference frames are tracked, thus
there is no need to check null anymore.

vaapidecode: fix gst_caps_new_simple call

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

vaapidecode: force add h264 MVC profiles in caps

When vaapih264dec's base-only profile is set to TRUE, fake MVC profile
support in caps.

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

libs: decoder: h264: decode MVC base view only

If processed SPS has mvc profile and the configuration is set to
base-only, the frame is drop.

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

vaapidecode: set h264 base-only to decoder

Set the base-only value when property is set and the internal
decoder is already instantiated or when the internal decoder
is created.

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

libs: decoder: h264: add setter for base-only mode

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

vaapidecode_props: h264: add base-only property

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

libs: encoder: h264: missing property enum documentation

libs: encoder: h264: add multi reference support

Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:

1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.

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

libs: encoder: h264: add refs property

Users can provide the number of reference frame by this property.

The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.

If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.

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

libs: encoder: implements gst_vaapi_encoder_ensure_max_num_ref_frames

This function will query VAConfigAttribEncMaxRefFrames to get the
maximum number of reference frames supported in the driver.
This will be used for h264/h265 encoding.

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

vaapiencode: h265: compare an unsigned int if not zero

An unsigned value can never be negative, so this test (greater than
zero) will always evaluate the same way. Thus change it to just if
it's not zero.

plugins: check gst_gl_ensure_element_data() return value

Refactor gst_vaapi_plugin_base_create_gl_context() in order to check
the return value of gst_gl_ensure_element_data(). The result is a code
bit cleaner.

plugins: avoid dead code detection

By using #elif macro, the static code analysis would stop to detect
these lines as dead code. Also it is inforced the mutually exclusive
environments.

vaapivideobufferpool: don't shift by negative since it's undefined

The function g_bit_nth_lsf() may return -1 if the request bit position
is not avaible. Thus, this patch check if the return value is not -1
in order to continue.

vaapisink: fix memory leak

vaapipostproc: fix memory leaks

libs: display: when appending formats change pointers to indexes

Thus, it fixes an invalid read when YV12 or I420 are not supported by
the driver.

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

libs: encoder: h264: Add uncompliant mode reducing coded buffer size

Added a new property "compliance-mode", which default is the normal
strict compliant mode.

The second mode, "restrict-buf-alloc", is to limit the coded buffer
allocation size to improve performance in some specific Intel
platforms (there is asignificant performance improvement in parallel
encodings). Under this new mode, we use the MinCR field in A.3.1 for
pre-calculating the coded-buffer size.

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

libs: utils_h264: Extend LevelLimit table with MinCR field

Add MinCR(Minimum Compression Ratio) field to GstVaapiH264LevelLimits
based on Annex A.3

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

libs: utils: libva 1.0 changed the logging

The logging mechanism in libva has changed it's functions
signatures. This patch updates that for libva versions >= 1.0

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

libs: decoder: h264: libva 1.0 deprecated baseline

libva 1.0 deprecated H.264 baseline profile and FMO support
(commit b4f332b3).

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

build: check for libva-2.0

Check for libva-2.0 since libva's developers decided to increase the
library's version number.

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

build: blacklist only libva 0.99.0

Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped
its API version to 1.0.0. Thus we have to blacklist only the MSDK's
libva (0.99.0)

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

build: meson: remove gstvaapidisplaycache.c

This is a missing bit of commit ec3e10f6

configure: do not break configure if gtk+-3.0 devel missing

Fix PKG_CHECK_MODULES rule for with_gtk=check condition to
set USE_GTK=0 if gtk+-3.0 is not available.

Since commit 85856c29a70d6de4aea5b708e04e9eb418190623
Author: Hyunjun Ko <zzoon@igalia.com>
Date:   Wed Jul 5 15:59:43 2017 +0900

    tests: elements: add testsuite of vaapi context

...configure fails if gtk+-3.0 development files are missing.

The "with_gtk" option defaults to "check" in configure.ac
which implies that if it is not explicitly requested then
configure will only enable it if it's available on the system.

However, the PKG_CHECK_MODULES rule that get's activated on
"check" condition did not provide default when gtk+-3.0 devel
packages are not found on the system.  Thus, it resulted in
configure failure.

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785452

tests: elements: add testsuite of vaapi context

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

vaapisink: fail if surface display is different

Replacing GstVaapiDisplay during rendering might be hiding problems
at some cases, even though it's safe currently since we use cache
of GstVaapidisplay.

Play safe by failing if this happens.

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

videocontext: support "gst.vaapi.app.Display" context

Through "gst.vaapi.app.Display" context, users can set their own VADisplay
and native display of their backend.

Attributes:
- display : pointer of VADisplay
- x11-display : pointer of X11 display (Display *), if they're using.

This patch creates GstVaapidisplayX11 if information provided through
"gst.vaapi.app.Display"

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

libs: display: x11: add gst_vaapi_display_x11_new_with_va_display()

Implements new API function so that users could create GstVaapiDisplay
with their own VADisplay within a native display as backend.

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

libs: display: pass display info when foreign display

When creating a GstVaapiDisplay using a foreign VADisplay, and render
with that display, it also requires native display of the backend.

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

libs: display: remove cache

Remove a bunch of code that handles the VADisplay cache, since the
context sharing should be doing this correctly.

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

tests: elements: add test for vaapipostproc

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

postproc: reconfigure when width or height changes

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

libs: encoder: vp9: array terminated in zeros

There is a crash when setting ref-pic-mode since the #GEnumValue
array is not terminated with a structured with all memvers being
zero.

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

vaapiencode: h264: add plugin documentation

Comment how the profile is set and other parameters.

libs: decoder: h264: push frames as soon as possible

Push frames downstream as soon as possible instead of waiting until
they are ejected from the DPB.

This patch makes the decoder not comply with the H.264 specification,
but it is required for some video cameras.

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

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

vaapidecode_props: h264: set low-latency in decoder

Set the low-latency property if the H264 decoder is already
instantiated, thus you could change the behavior in run-time.

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

vaapidecode: set h264 low latency to decoder

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

libs: decoder: h264: add getter/setter for low latency mode

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

vaapidecode_props: h264: add low latency property

Adding support for private data.

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

vaapidecode_props: add skeleton for h264 decoder properties

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

vaapidecode: properties callback in decoders map

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

meson: find python3 via python3 module

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

libs: encoder: h264: submit sps in case of IDR picture

If the picture is IDR, also submit a SPS header.

This means when frame number reaches to keyframe-period or an force
key unit event arrives, we insert SPS/PPS again.

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

libs: encoder: h264: set the frame as IDR if forced key unit

GST_VIDEO_CODEC_FRAME_IS_FORCE_KEYFRAME() is a flag usually used to manage
the `frame-lost` event in the case of streaming, such as RTP.

In case of this event, it is needed to start new GOP rather than just
produce an I-frame.

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

libs: encoder: h264: insert AU delimiter

Insert an AUD as the first NAL of each encoded frame.

Some applications require Access Unit Delimiter for decoding the
stream.

The AU delimeter insertion is done only when the aud parameter is
TRUE (by default is disabled). The reason of this it is because this
header is only available from Intel Gen9 and the VA intel driver
should be 1.8 or superior. Otherwise, the output will be corrupted.

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

Signed-off-by: Victor Jaquez <vjaquez@igalia.com>

libs: encoder: h264: initialize all elements of view_ids

Currently when num_views is changed by multiview-mode on sink caps, it produces
wrong MVC encoded stream since the array view_ids is not set properly according
to changed num_views.

So this patch initializes all of the array sequentially to handle this case.
Side effect is not going to happen by this patch since this array is being
handled by num_views.

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

Revert "encoder: h264: Use high profile by default"

This reverts commit 4aec5bdd7207fc0e45813ef14c9c0ad5174a8f75.

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

libs: encoder: h264: set profile via capsfilter

Until now, the encoder ignored the profile in src caps and chose one
according with the given parameters. But the encoder must honor the
profile specifed in src caps.

This patch do that, and if the encoder needs to choose the profile,
it will do it by following these rules:

1\ If given parameters are not compatible with given profile, the
   encoder will bail out with an error.
2\ The encoder will choose the higher profile indicated in the
   src caps.

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

vaapiencode: h264: set profile to src caps

So far vaapi encoder does not set profile to src caps. This patch makes it
setting profile to src caps, which is determined by itself.

In addition, if encoder chose different profile, which is not negotiated with
downstream, we should set compatible profile to make negotiation working.

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

vaapiencode: h264: verify if requested profile is supported

Check if the requested profile in source caps, is supported by the
VA driver. If it is not, an info log message is send saying that
another (compatible?) profile will be used.

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

vaapiencode: h264: improve set_config() vmethod

First check if downstream requests ANY caps. If so, byte-stream is
used and the profile will be choose by the encoder. If dowstream
requests EMPTY caps, the negotiation will fail.

Lately, byte-stream and profile are looked in the allowed caps.

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

vaapiencode: h264: check for avc in set_config()

The check for avc stream format was done in the vaapi encoder's
vmethod get_caps(), but that is wrong since it has to be check
when encoder set_format().

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

vaapipostproc: set multivew-mode flags to src caps

vaapipostproc didn't negotiate the proper multiview caps losing
downstream information.

This patch enables the playing of MVC encoded stream by setting
the proper multiview mode/flags and views to src caps, according
to sink caps.

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

vaapipostproc: add support for DMABuf caps feature

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

Signed-off-by: Julien Isorce <j.isorce@samsung.com>

vaapidecode: add support for DMABuf caps feature

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

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

vaapipluginbase: force dmabuf allocator if DMABuf caps feature

Instantiate all dmabuf allocator for src pad buffer pool if the
src caps ask for memory:DMABuf feature.

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

vaapipluginutil: add support for DMABuf caps feature

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

Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
vaapipluginutil: add support for DMABuf caps feature

vaapipluginbase: dmabuf memory map trial for raw caps

Only push dmabuf-based buffers with raw caps if gst_memory_map()
succeeds. Otherwise, use the the vaapi surfaces allocator.

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

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

vaapivideomemory: add gst_vaapi_dmabuf_can_map()

This new method checks the specified allocator can create GstMemory that can
be mapped.

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

vaapivideobufferpool: fix regression with video metas

There is another regression with 7a206923 when setting the video
info for the video meta, it should be the one from the image's
allocator rather from the allocation caps.

Test pipeline:

  gst-launch-1.0 filesrc location=bug766184.flv ! decodebin \
      ! tee ! videoconvert ! videoscale                     \
      ! video/x-raw, width=1920, height=1080 ! xvimagesink

plugins: update buffer size with the one reported by allocator

There is a regression in 7a206923, since the buffer pool ditches all
the buffers generated by them because the pool config size is
different of the buffer's size.

Test pipeline:

  gst-launch-1.0 filesrc location=big_buck_bunny_1080p_h264.mov \
      ! qtdemux ! vaapih264dec ! vaapipostproc ! xvimagesink    \
      --gst-debug=GST_PERFORMANCE:5

The allocator may update the buffer size according to the VA surface
properties. In order to do this, the video info is modified when the
allocator is created, which reports through the allocation info the
updated size, and set it to the pool config.

libs: decoder: h264: initialize active_sps/pps in reset

Since commits in https://bugzilla.gnome.org/show_bug.cgi?id=781142 landed,
they introduced regression in seek.

Formerly, once seek is done, decoder drops P-frames until I-frame arrives.
But since the commits landed, it doesn't drop P-frame and does try to
decode it continuously because active_sps is still alive. See ensure_sps function.
But there are prev_frames and prev_ref_frames reset already, then it
causes assertion.

So it's necessary to reset active_sps/pps also in reset method.

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

libs: encoder: fix compilation with old versions of libva

There are some symbols that are not used when compiling with old
version of libva and those generates a compilation error.

Original-patch-by: Matt Staples <staples255@gmail.com>

libs: encoder: Fix the quality level clamping

Change the hard-coded range of quality-level from {1-8} to {1-7},
since it is the range Intel Open source driver supports.
Also perform the range clamping only if the user provided
quality-level is greater than the max-range suppored by the driver,
because there could be non-intel drivers giving lower value than
the hard-coded max value 7.

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

libs: encoder: log out the name of the profile

Instead of printing a number, it is more readable to log out, in
case of error, the name of the failing profile.

libs: encoder: h264: changes raw number of profile to macro name of its

Changes raw number of profile to macro name of its to improve readability.

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

vaapivideobufferpool: remove allocation_vinfo private attribute

There is no need to keep this attribute internally since it is
already managed by the allocator.

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

vaapivideobufferpool: refactor set_config()

Refactor the set_config() virtual method considering a cleaner
approach to allocator instanciation, if it it not set or if it is
not valid for the pool.

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

plugins: distinguish allocation and negotiation caps

The vaapi video decoders might have different allocation caps from
the negotiation caps, thus the GstVideoMeta shall use the negotiation
caps, not the allocation caps.

This was done before reusing gst_allocator_get_vaapi_video_info(),
storing there the negotiation caps if they differ from the allocation
ones, but this strategy felt short when the allocator had to be reset
in the vaapi buffer pool, since we need both.

This patch adds gst_allocator_set_vaapi_negotiated_video_info() and
gst_allocator_get_vaapi_negotiated_video_info() to store the
negotiated video info in the allocator, and distinguish it from
the allocation video info.

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

vaapivideomemory: rename qdata quarks and ids

Also the parameter names were renamed to reflect their origin
and purpose.

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

vaapivideobufferpool: rename local variables

Renamed local video info structure names in set_config() vitual
method. The purpose of their renaming is to clarify the origin
of those structures, whether come from passed caps parameter
(new_allocation_vinfo) or from the configured allocator
(allocator_vinfo).

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

vaapivideobufferpool: rename video info structures

Renamed private GstVideoInfo structure video_info to allocation_vinfo
and alloc_info to negotiated_vinfo.

The purpose of these renaming is to clarify the origin and purpose of
these private variables:

video_info (now allocation_vinfo) comes from the bufferpool
configuration. It describes the physical video resolution to be
allocated by the allocator, which may be different from the
negotiated one.

alloc_info (now vmeta_vinfo) comes from the negotiated caps in
the pipeline. It represents how the frame is going to be mapped
using the video meta.

In Intel's VA-API backend, the allocation_vinfo resolution is
bigger than the negotiated_info.

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

libs: encoder: set framerate if bigger than 0/1

Just set the framerate parameter if the framerate numerator and
denominator are bigger than zero.

Otherwise, in Intel Gen6 driver, a warning is raised disabling the
bitrate control.

Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783532

libs: encoder: bitrate target percentage calculation

If the rate control is set to Constant Bit Rate (CBR) the target
percentage is 100%, otherwise is 70%

libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor ratecontrol param

Centralize the common configuration for the Rate Control parameter,
thus can be overloaded per each specific encoder.

libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor framerate param

Since the framerate VA parameter is calculated equally among all the
encoders, it is better to handle it in the base encoder class.

libs: encoder: vp9: Adds CBR and VBR Encoding support

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

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