vaapi: dist new header

vaapi: register vaapisink as marginal on wayland

vaapsink, when used with the Intel VA-API driver, tries to display
surfaces with format NV12, which are handled correctly by
Weston. Nonetheless, COGL cannot display YUV surfaces, making fail
pipelines on mutter.

This shall be solved either by COGL or by making the driver to paint
RGB surfaces. In the meanwhile, let's just demote vaapisink as
marginal when the Wayland environment is detected, no matter if it is
Weston.

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

plugins: update mesa's vendor string in whitelist

Mesa has updated its VA-API Gallium driver vendor string:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=5db29d62ce1fefa3f2ee6e4a4688576fde4bde4a

This patch tries to cover both, the old and the new one.

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

meson: make version numbers ints and fix int/string comparison

WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.

plugins: handle vaapi allocator in allocation query

In propose_allocation() if the numer of allocation params is zero, the
system's allocator is added first, and lastly the native VA-API
allocator.

In decide_allocation(), the allocations params in query are travered,
looking for a native VA-API allocator. If it is found, it is reused as
src pad allocator. Otherwise, a new allocator is instantiated and
appended in the query.

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

vaapivideomemory: remove unused macro

GST_VAAPI_VIDEO_ALLOCATOR_NAME was added in commit 5b11b8332 but it
was never used, since the native VA-API allocator name has been
GST_VAAPI_VIDEO_MEMORY_NAME.

This patch removes GST_VAAPI_VIDEO_ALLOCATOR_NAME macro.

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

vaapisink: don't mask button events for foreign windows

Don't subscribe to button press events when using a foreing window,
because the user created window would trap those events, preveting the
show of frames.

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

autotools: use -fno-strict-aliasing where supported

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

meson: use -fno-strict-aliasing where supported

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

vaapi: add NULL-sentinel to kernel_names

The array needs to be NULL-terminated according to the
gst_plugin_add_dependency() documentation.

vaapipostproc: remove spurious code

This assignation is dead code, since gst_video_info_from_caps() set
to 1 by default.

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

vaapipostproc: if no p-a-r in out caps define a range

Instead of copying the pixel-aspect-ratio from the sink caps, define
an open range for the src caps pixel-aspect-ratio. Later it will be
defined.

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

vaapisink: check for display's color-balance properties

Check for display's color-balance properties, available by the VA-API
driver, before setting them.

Also logs an info message of those unavailable properties.

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

plugins: re-using buffer pool breaks renegotiation

at propose_allocation() we should not reuse the proposed buffer,
because it could break renegotiation.

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

plugins: use g_clear_object() to unref sinkpad_buffer_pool

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

build: meson: add missing GstGL dependency

libs: utils: egl: add missing guards for GstGL

plugins: remove dmabuf-import hack

Remove the hack to check if an upstream element has enabled the
property io-mode enabled as dmabuf-import.

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

libs: egl: utils: use eglGetPlatformDisplay()

eglGetDisplay() is currently broken in Mesa for Wayland.  Also using
eglGetDisplay() is rather fragile, and it is recommended to use
eglGetPlatformDisplay() when possible.

In order to do that, this patch uses the helper in GstGL. If
gstreamer-vaapi is not compiled with GstGL support, eglGetDisplay()
will be used.

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

vaapipostproc: lock ensure_filter with postproc_lock

gst_vaapipostproc_ensure_filter might free the allowed_srcpad_caps
and allowed_sinkpad_caps. This can race with copying these caps in
gst_vaapipostproc_transform_caps and lead to segfaults.

The gst_vaapipostproc_transform_caps function already locks
postproc_lock before copying the caps. Make sure that calls to
gst_vaapipostproc_ensure_filter also acquire this lock.

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

tests: test-filter: fix dereference before null check

Null-checking op_info suggests that it may be null, but it has already
been dereferenced on all paths leading to the check.

There may be a null pointer dereference, or else the comparison
against null is unnecessary.

tests: y4mreader: fix string state checkup

str cannot be null in that moment, but it may be the end of string.

tests: y4mreader: use int for fgetc

Assigning the return value of fgetc to char truncates its value.

It will not be possible to distinguish between EOF and a valid
character.

tests: y4mreader: fix incompatible cast

Passed pointer in parse_int() are unsigned int (32 bits, unsigned) but
they are dereferenced as a wider long (64 bits, signed). This may lead
to memory corruption.

meson: fix fallback for gstreamer-gl-1.0, it's now in -base

Automatic update of common submodule

From e8c7a71 to 3fa2c9e

videoconvert: gst_element_post_message() is transfer full on msg

For this reson we need not to unref the message, even if it failed.

Revert "vaapivideocontext: possible memleak when no bus attached"

This reverts commit 0438a3e62660e64ed390b6bb83bfb560b91664aa.

test: vaapicontext: process have-context bus message

test: vaapicontext: app context is not persistent

vaapivideocontext: only vaapisink process app context

gst.vaapi.app.Display context is made for applications that will
provide the VA display and the native display to used by the
pipeline, when are using vaapisink as overlay. There are no use
case for encoders, decoders, neither for the postprocessor.

In the case of the vaapisink, it shall query for gst.vaapi.Display
upstream first, and then, if there is no reply,
gst.vaapi.app.Display context will be posted in the bus for the
application. If the application replies, a GstVaapiDisplay object
is instantiated given the context info, otherwise a
GstVaapiDisplay is created with the normal algorithm to guess the
graphics platform. Either way, the instantiated GstVaapiDisplay
is propagated among the pipeline and the have-message bus message.

Also only vaapisink will process the gst.vaapi.app.Display, if
and only if, it doesn't have a display already set. This is
caused because if vaapisink is in a bin (playsink, for example)
the need-context is posted twice, leading to an error state.

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

vaapivideocontext: log the name of GstVaapiDisplay

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

vaapivideocontext: possible memleak when no bus attached

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

libs: window: wayland: remove unused header include

Remove wayland-client.h include since there is no exposed symbols from
it.

libs: encoder: h264,h265: guard rate control's macroblock

macroblock parameter appear on VA-API 1.0.0. It should be guarded.

Automatic update of common submodule

From 3f4aa96 to e8c7a71

libs: encoder: h264: Add Hierarchical-B encode

Frames are encoded as different layers. Frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.

B-frames, except the one in top most layer, are reference frames.
All the base layer frames are I or P.

eg: with 3 temporal layers

    T3:             B1            B3              B5              B7

    T2:                   B2                              B6

    T1:   I0                                P4                        P8

    T1, T2, T3: Temporal Layers
    P1...Pn:   P-Frames:
    B1...Bn:   B-frames:
    T1: I0->P4 , P4->P8 etc..
    T2: I0--> B2 <-- P4
    T3: I0--> B1 <-- B2, B2 --> B3 <-- P4

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add Hierarchical-P encode

Frames are encoded as different layers. A frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.

eg: with 3 temporal layers

T3:             P1            P3              P5              P7

T2:                   P2                              P6

T1:   P0                                P4                        P8

T1, T2, T3: Temporal Layers
P1...pn:   P-Frames:
P0->P1 , P0->P2, P2->P3, P0->P4......repeat

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Fix frame_num generation

The frame_num generation was not correctly implemented.
According to h264 spec, frame_num should get incremented
for each frame if previous frame is a referece frame.

For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add new property "prediction-type"

Adds new property "prediction-type" to select different reference
picture selection modes like hierarchical-p, hierarchical-b etc.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add machinery for implementing hierarchical-prediction

Adds some basic building blocks to ease the implementation
of hierarchical prediction modes.

-- add an utility method to find temporal level of each frame
-- define max_ref_frame count based on temporal level count
-- add temporal_level_div[] for finding temporal level each frame
to be encoded.
-- find ip_period based on temporal level count

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add property "temporal-levels"

Adds new property "temporal-levels" to select the number of
temporal levels to be included in the encoded stream.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: objects: Add a reference flag

We can have p-frame as non-ref and also b-frame as ref
which are not supported yet. Reference flag
is the first machinery needed for more advanced
reference picture selection modes.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: surface: egl: add comment

Add a warning comment when using old intel-vaapi-drivers (>1.8.4),
where the creation of surfaces from GEM fd may fail.

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

libs: display: egl: add gst_vaapi_display_egl_set_current_display()

Adds a new function that changes the internal EGL display to the
current one (eglGetCurrentDisplay()) and sets the current context
too (eglGetCurrentContext()).

This new function is called by gst_vaapi_texture_egl_create() updating
the GstVaapiDisplayEGL with the current EGL display.

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

libs: texture: egl: update EGL display and context

It is required to use the context of the calling thread when wrapping
a foreign texture. According the documentation of
GstVideoGLTextureUploadMeta:

 "The caller of gst_video_gl_texture_upload_meta_upload() must
  have OpenGL set up and call this from a thread where it is valid
  to upload something to an OpenGL texture."

This patch updates the EGL display and context in GstVaapiDisplay
instance to the one used by te renderer that uploads the texture.

Original-patch-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773453

plugins: centralize assignation of GL objects

Add plugin_set_gst_gl() where the GstGL objects are assigned.

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

plugins: set GL objects if ensured

Only set the GL display and GL other context if they are ensured.

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

plugins: set GL objects if context is handled

Only set the GL display and GL other context if they are extracted
correctly from the gstreamer's context.

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

plugins: fix memory leak when GL context is created

When the GL display and context are created inside an VAAPI element
the created GL context is leaked.

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

libs: display: egl: free leaked memory

The EGL VAAPI display forgot to release the egl display, context and
proxied VAAPI display.

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

libs: texture: egl: code style

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

libs: surface: egl: error message if no extension

Instead of silently fail to export the image if there is not available
the EGL_MESA_drm_image, log an error message. Also a code refactoring
was done.

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

plugins: direct rendering on memory:VASurface

As buffers negotiated with memory:VASurface caps feature can also be
mapped, they can also be configured to use VA derived images, in other
words "direct rendering".

Also, because of the changes in dmabuf allocator as default allocator,
the code for configuring the direct rendering was not clear.

This patch cleans up the code and enables direct rendering when the
environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING is defined,
even then the memory:VASurface cap feature is negotiated.

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

plugins: only dmabuf on srcpad if downstream

Set if source pad can handle dmabuf only if the GstGL context comes
from downstream.

It is possible to know that at two moments:

1\ In the case of GstGLTextureUpload caps feature is negotiated and
   downstream pool reports back gst.gl.GstGLContext.

2\ When GstGLContext is found as GstContext from dowstream.

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

vaapivideocontext: add inline documentation

Document function gst_vaapi_find_gl_local_context().

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

vaapivideocontext: return the direction of gl context

In function gst_vaapi_find_gl_context() add a direction parameter to
return back the direction where the GstGL context was found.

This is going to be useful when checking if downstream can import
dmabuf-based buffers.

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

plugins: add gst_vaapi_plugin_base_set_srcpad_can_dmabuf()

This patch refactors the code by adding the function
vaapi_plugin_base_set_srcpad_can_dmabuf(), it determines if the passed
GstGLContext can handle dmabuf-based buffers.

The function is exposed publicly since it is intended to be used later
at GstVaapiDisplay instantiation.

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

vaapiencode: allow to set property on runtime

Tis patch, allows some properties that we want to be set on
runtime. (eg. bitrate)

Note that all properties are under control by num_codedbuf_queued.

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

libs: encoder: allow to set bitrate on runtime

In case of streaming, controlling bitrate dynamically for encoder might be
important to manage quality of the streaming.

This patch is to support such a scenario.

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

vaapidecodebin: Register element if no VPP support is available too

VPP support is only needed for advanced deinterlacing, which is not
enabled by default either. Error out if it is selected but VPP is not
supported, and otherwise just work without VPP support.

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

Avoid infinite loop when vaapi_create_display fails

Which might be the case when using, for example, xvfb.

libs: utils: log warn if display fail

gstreamer-vaapi initializes the display by trial-and-error, thus
logging an error message if the display initialisation fails the user
may be weary of the error message in the screen, if using VA-API 1.0

This commit set the VA error log handler to GStreamer warning level
while calling vaInitialize() and set it to error after that.

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

plugins: try to create test display in order

When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.

The reason for this is to reduce the posibility of failure that could
blacklist the plugin.

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

libs: display: delay getting screen resolution

Instead of extracting the screen resolution at GstVaapiDisplay
creation, this patch delay it until the screen size is requested for
first time.

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

libs: display: egl: avoid two vaDisplay instantiates

GstVaapiDisplayEGL is a wrapper of another GstVaapiDisplay, either X11
or Wayland. Nonetheless it created another vaDisplay for it, instead
of using the wrapped one.

This patch enables the reuse of the wrapped vaDisplay avoiding
instantiating two.

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

libs: display: remove display_type from display info

Since it's no required to pass the display type in the display info,
the structure member is removed.

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

libs: display: remove display_type member

It is not used any more since GstVaapiDisplay was ported as a
GstObject-based. This information is part of the class information.

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

libs: display: remove parent member

Parent was a crumb left from display cache.

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

vaapi: Also register vaapipostproc without VPP support

It can still do simple deinterlacing then.

vaapipostproc: Allow running without VPP support

We returned FALSE from ::start() if VPP support is not available, but it
is only really needed for complex filters and during transform we check
for that. For simple deinterlacing it is not needed.

vaapipostproc: use scoped variable for return value

Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_transform_caps(), this patch uses the function
scoped pointer. Thus, the code is cleaner.

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

vaapipostproc: removed unused parameter

Removed caps parameter from gst_vaapipostproc_transform_caps_impl()
helper function since the it is not used.

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

vaapipostproc: use scoped variable for return value

Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_fixate_caps(), this patch uses the function scoped
pointer. Thus, the code is cleaner.

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

plugins: memory:DMABuf only handles planar formats

When glimagesink negotiates the caps feature memory:DMABuf the
exported dmabufs buffers with NV12 format are not well rendered, thus
setting only planar.

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

vaapiencode: flush pending frames before set format

Flush pending frames, if any, in the internal encorder, before setting
the new negotiated format.

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

vaapidecode: drain pending frames before set format

Drain pending frames, if any, in the internal decoder before setting
the new negotiated format.

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

tests: display: use GObject getter

Instead of using the gst_vaapi_display_get_property(), this patch
replaces it with g_object_get_property() to dump the available VA
display properties.

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

vaapisink: use GObject setter and getter

Instead of using gst_vaapi_display_set_property() or
gst_vaapi_display_get_property(), this patch set replace it usage
with g_object_set() or g_object_get().

Also the internal helper cb_set_value() is removed since it is not
used anymore.

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

libs: display: initialize value if they are not yet

This is a difference between the GObject API and the GstVaapi one: the
GValue passed to get a property value, in GObject has to be
initialized with g_value_init(), but in GstVaapi is has not.

In order to overcome this mismatch, this patch call g_value_init()
internally only in the passed one is not already initialized.

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

libs: display: optimize properties setters and getters

Shuffled some code to avoid to find the properties descriptor in the
array twice, adding the internal functions _set_property() and
_get_property().

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

libs: display: install properties in class

Install the properties in the class as a normal GObject. Implement
set_property() and get_property() vmethods.

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

libs: display: remove gst_vaapi_display_properties_init()

Remove gst_vaapi_display_properties_init() since it can be unrolled in
gst_vaapi_display_class_init()

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

libs: display: remove libgstvaapi_init_once()

It is not required since it can be unrolled in
gst_vaapi_display_class_init()

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

tests: test-display: remove display cache tests

Since commit ec3e10f6, display cache was removed. This patch removes
this leftovers in the display test.

libs: decoder: h264/h265: decode codec data only if opened

Fixes regression introduced by commit 2eb2b26a.

There is a use case when the decoder set the src caps and immediatly
tries to process the media codec_data, this happens before decoder is
even opened, thus priv->parser is not instantiated yet.

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

libs: encoder: change mbbrc from uint to enum

Instead of handling the macroblock bitrate control as a integer, this
patch changes it as a enum, which is more self documented in the
GStreamer elements.

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

Fix a typo in the prop string for compliance-mode

libs: encoder: don't unref properties

This patch fixes a regression introduced in commit 148f867c, since the
props variable is set to object's member variable
encoder->properties. And it is set in the instance initialization,
thus it will not be leaked.

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

vaapiencode/libs: encoder: fix leaks of properties

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

libs: decoder: at update_caps() decode codec_data

When updating the caps in decoder, if the caps has codec_data (avC
format), it has to be parsed to update the state of the decoder.

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

libs: context: fix wrong counter of the array of attributes

The counter value passed to vaCreateConfig is always +1.

This is a regression caused by commit e42ec3ad.

The present patch fixes wrong counting of the array of attributes.

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

libs: encoder: h265: support I/P/B QP setting seperatedly

Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.

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

libs: encoder: h264: support I/P/B QP setting seperatedly

Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
In addition, remove the limitation of (<= 4) when setting
slice_qp_delta.

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

libs: encoder: h264/h265: keep min_qp as is unless it's over init_qp

Creates new variable for QP for I frame and keep it at configuration and
use this for pic_init_qp and slice_qp_delta setting.

Since changing min qp doesn't make sense, keep min qp as is.

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

libs: encoder: h265: Add mbbrc property

This property supports Macroblock level Bitrate Control as the
following (same as h264 encoder):
0: auto
1: on
2: off

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

libs: encoder: h264: Add mbbrc property

This property supports Macroblock level Bitrate Control as the
following:
0: auto
1: on
2: off

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

libs: encoder: h265: add multi reference support

This is doing the same as h264 encoder as the following:

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.

Also this patch includes:
- Set num_negative_pics and num_positive_pics according to the number of
refs.
- Set delta_poc according to the number of refs.
- Increase max_dec_pic_buffering according to the number of refs
- Change max_num_reorder_pics according to num of bframes

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

libs: encoder: h265: add refs property

Users can provide the number of reference frame by this property,
which is exaclty same as h264.

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.

The maximum value is aligned to the value of the driver supported now.

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

libs: encoder: h264/5: determine num_ref_idx_active_override_flag according to reference list

Follows the specification as below:

7.4.7.1 in Rec. ITU-T H.265 v4 (12/2016)
num_ref_idx_active_override_flag equal to 1 specifies that the syntax
element num_ref_idx_l0_active_minus1 is present for P and B slices and
that the syntax element num_ref_idx_l1_active_minus1 is present for B
slices.
num_ref_idx_active_override_flag equal to 0 specifies that the syntax
elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
are not present.

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